Re: Obsoleting keep-response-order option in BIND 9.19/9.20+
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
Re: Obsoleting keep-response-order option in BIND 9.19/9.20+
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
Obsoleting keep-response-order option in BIND 9.19/9.20+
Hi, 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 > >RFC 1035 is ambiguous on the question of whether TCP responses may be >reordered -- the only relevant text is in Section 4.2.1, which >relates to UDP: > > Queries or their responses may be reordered by the network, or by > processing in name servers, so resolvers should not depend on them > being returned in order. > >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. We haven’t found any evidence that the option was ever used in production to un-break a non-compliant DNS client and hence we plan to directly make the option to do nothing instead of graceful removal which would force us to support the option for the next 6 years. The option will be marked obsolete, so named-checkconf will issue a warning, and removed in BIND 9.21+ development release. 1. https://datatracker.ietf.org/doc/html/rfc7766#section-7 -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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
