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 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users