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

[Ondřej Surý]

Thanks Fred, those are all good advices for the DNS over TCP implementors.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 11. 2. 2022, at 18:32, Fred Morris <m3047 at m3047.net> wrote:
> 
> 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
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users