Re: [musl] TCP fallback open questions

[Florian Weimer <fweimer@redhat.com>]

* Rich Felker:

>> TCP DNS has pipelining.
>
> Has that always been a thing? If so, it might advise a different way
> to do this.

Like most things DNS, it's controversial.  There's certainly the glibc
precendent.

I found this:

| 6.2.1.1.  Query Pipelining
| 
|    Due to the historical use of TCP primarily for zone transfer and
|    truncated responses, no existing RFC discusses the idea of pipelining
|    DNS queries over a TCP connection.
| 
|    In order to achieve performance on par with UDP, DNS clients SHOULD
|    pipeline their queries.  When a DNS client sends multiple queries to
|    a server, it SHOULD NOT wait for an outstanding reply before sending
|    the next query.  Clients SHOULD treat TCP and UDP equivalently when
|    considering the time at which to send a particular query.
| 
|    It is likely that DNS servers need to process pipelined queries
|    concurrently and also send out-of-order responses over TCP in order
|    to provide the level of performance possible with UDP transport.  If
|    TCP performance is of importance, clients might find it useful to use
|    server processing times as input to server and transport selection
|    algorithms.
| 
|    DNS servers (especially recursive) MUST expect to receive pipelined
|    queries.  The server SHOULD process TCP queries concurrently, just as
|    it would for UDP.  The server SHOULD answer all pipelined queries,
|    even if they are received in quick succession.  The handling of
|    responses to pipelined queries is covered in Section 7.

<https://www.rfc-editor.org/rfc/rfc7766#section-6.2.1.1>

But I'm too out-of-touch to tell whether this is good advice (for client
behavior).

>> The glibc stub resolver exercises that, sending
>> the A and AAAA queries back-to-back over TCP, probably in the same
>> segment.  I think it should even deal with reordered responses (so no
>> head-of-line blocking), but I'm not sure if recursive resolver code
>> actually exercises it by reorder replies.
>
> Do real-world servers reliably do out-of-order responding, starting
> multiple queries received over the same connection in parallel and
> responding to them in the order answers become available?

There's a security requirement to collapse multiple outgoing queries for
the same QNAME/QCLASS/QTYPE, so strict sequential processing without
updating global state isn't really possible.  It's a small step from
sending out the responses in parallel.

Section 7 in RFC 7766 recommends this as well.

>> Historically, it's unfriendly to keep TCP connections to recursive
>> resolvers open for extended periods of time.  Furthermore, it
>> complicates the retry logic in the client because once you keep
>> connections open, RST in response to a send does not indicate an error
>> (the server may just have dropped the question), so you need to retry in
>> that case with a fresh connection.
>
> We definitely wouldn't keep them open for an extended period since the
> expectation is that they won't normally be used, and since tying up
> fds is bad. But if there's nasty corner case handling for when the
> server decides it doesn't want to answer more questions on your
> existing socket (possibly even within a single run) the prospect of
> using a single connection for multiple queries becomes less appealing.

It's about reviving a connection that's been dormant for a while, not
the case of back-to-back or parallel queries for A/AAAA.  TCP treats
uncoordinated connection close like a network error, and DNS doesn't
have a coordination protocol.  The DNS resolver eventually needs to shut
down connections from clients that are inactive, which requires an
uncoordinated close.  On the client side, the BSD sockets API isn't
really good at telling this from a bona-fide networking problem even if
it has additional data.

Thanks,
Florian