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 <m3...@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@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