Obsoleting keep-response-order option in BIND 9.19/9.20+

[Fred Morris]

It's not BIND's fault or responsibility, but I hope it is well documented 
and remains well documented.

On Fri, 11 Feb 2022, Ondřej Surý wrote:
> [...]
> when out-of-order response processing was introduced in BIND 9.11.0, there was
> a “defensive” option added called keep-response-order that takes ACL as option
> to enable the previous behaviour where the DNS responses were sent in the same
> order as the received DNS queries.
>
> For BIND 9.19 (development) and 9.20 (stable) release scheduled in 2 years, we
> plan to make BIND 9 rely on DNS clients being compliant with RFC 7766[1]:
>
>> 7.  Response Reordering
>> [...]
>>    For the avoidance of future doubt, this requirement is clarified.
>>    Authoritative servers and recursive resolvers are RECOMMENDED to
>>    support the preparing of responses in parallel and sending them out
>>    of order, regardless of the transport protocol in use.  Stub and
>>    recursive resolvers MUST be able to process responses that arrive in
>>    a different order than that in which the requests were sent,
>>    regardless of the transport protocol in use.
>>
>>    In order to achieve performance on par with UDP, recursive resolvers
>>    SHOULD process TCP queries in parallel and return individual
>>    responses as soon as they are available, possibly out of order.
>>
>>    Since pipelined responses can arrive out of order, clients MUST match
>>    responses to outstanding queries on the same TCP connection using the
>>    Message ID.  If the response contains a question section, the client
>>    MUST match the QNAME, QCLASS, and QTYPE fields.  Failure by clients
>>    to properly match responses to outstanding queries can have serious
>>    consequences for interoperability.

Let's face it, DNS is hard to do right.

Having done several different things involving DNS over TCP these last few 
years this behavior has caught my attention, notwithstanding that I hadn't 
read 7766 for comprehension.

Coding a client under these conditions, let me offer a few defensive 
strategies:

* send the prepended length field with the message from the application
   layer (hopefully it ends up in the same packet)

* don't expect the prepended length field to be prepended in the same
   packet as the reply

* for that matter don't expect that a response which would fit in a
   UDP packet will arrive in a single read

* when in doubt, connect + send a request + get a response + close

* send a single request and wait for a single response (manage any
   queueing on your end) even if you plan to send multiple requests

* if the response doesn't look right hang up and try again

I strongly counsel against premature optimization.

I hope those suggestions can also serve to inform server implementers / 
operators.

(I think the RFC has a number of biases towards server implementers / 
operators, some plain, some more along the lines of moral hazard.)

--

Fred Morris