Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "sortlist" options and a value "fixed" for "rrset-order" option. These options allow to specify a on order of the resource records in the responses. The "fixed" value for "rrset-order" option will make named to record the order the records are defined in the zone file and it's disabled at the compile time because it blows up memory use. Relying on the order of the resource records in the DNS responses has been always wrong, but we are still keeping the "rrset-order" option, but please don't use it. The "sortlist" option allows to define a complicated rules when and how to reorder the resource records in the responses. The same caveats as with the "rrset-order" apply - relying on any specific order of resource records in the DNS responses is wrong. We are not aware of any other (major) DNS server that would have similar behaviour as this was never specified in the DNS protocol. If you know of any software or hardware relying on any specific order of the resource records in the DNS messages, it needs to be reported as a bug to the respective vendor. They will be deprecated as of BIND 9.20 and removed in BIND 9.22. Cheers, -- 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
Re: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01.03.24 08:24, Ondřej Surý wrote: The "sortlist" option allows to define a complicated rules when and how to reorder the resource records in the responses. The same caveats as with the "rrset-order" apply - relying on any specific order of resource records in the DNS responses is wrong. We are not aware of any other (major) DNS server that would have similar behaviour as this was never specified in the DNS protocol. If you know of any software or hardware relying on any specific order of the resource records in the DNS messages, it needs to be reported as a bug to the respective vendor. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. I found it especially nice because it doesn't matter which service are we using - if there are multiple IP's for _anything_, return topologically closer first. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
Hi there, On Fri, 1 Mar 2024, Matus UHLAR wrote: On 01.03.24 08:24, Ond?ej Sur? wrote: > The "sortlist" option allows to define a complicated rules when and > how to reorder the resource records in the responses. The same > caveats as with the "rrset-order" apply - relying on any specific > order of resource records in the DNS responses is wrong. > > We are not aware of any other (major) DNS server that would have > similar behaviour as this was never specified in the DNS protocol. > If you know of any software or hardware relying on any specific > order of the resource records in the DNS messages, it needs to > be reported as a bug to the respective vendor. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. Maybe I need more of my morning $beverage but this sort of thing seems to me to militate against other - existing - efficiency mechanisms. Network performance isn't just about topology, there are things like performance and load to consider. Might your tweaked responses just send clients to a nearby but tragically overloaded server? My preference would be to let those people whose job it is to think about this stuff - which, reading this list, clearly they do - get on with their job. Observations welcome of course. -- 73, Ged. -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
2nd $beverage consumed. I have never liked sortlist since I inherited it 16 years ago in my previous job. For me it suffers from at least one fundamental problem: - If a client, say at location "1", is given a bunch of sorted A records with the server at location "1" first, what does the client do when the server at location "1" is down? Clients come in many varieties. Some are capable of cacheing multiple answers, timing out and trying a different one, some are not. This leads to service reliability issues because, even though a perfectly healthy instance of the service may exist at site "2", clients (at site "1") are still told by DNS, go to site "1" The DNS service is not (by default) either application or client-aware. It just gives the answers you tell it to, whether they're working or not. If you want an efficient, reliable multi-site service, use load-balancers that can direct traffic from local clients to a local service instance, or use an application aware DNS server (I can think of one; I'm sure others exist) that monitors availability, delay and whatever other metrics are important and feeds the DNS resolvers with *the* answer they want them to give to a client at this moment in time. ECS would even allow said box to be aware of client location, to use as an additional metric when making this decision. In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. On Fri, 1 Mar 2024 at 10:12, G.W. Haywood wrote: > Hi there, > > On Fri, 1 Mar 2024, Matus UHLAR wrote: > > On 01.03.24 08:24, Ond?ej Sur? wrote: > > > The "sortlist" option allows to define a complicated rules when and > > > how to reorder the resource records in the responses. The same > > > caveats as with the "rrset-order" apply - relying on any specific > > > order of resource records in the DNS responses is wrong. > > > > > > We are not aware of any other (major) DNS server that would have > > > similar behaviour as this was never specified in the DNS protocol. > > > If you know of any software or hardware relying on any specific > > > order of the resource records in the DNS messages, it needs to > > > be reported as a bug to the respective vendor. > > > > I don't know about _requirement_, but I have used this option as poor > > man's way to implement geographically local IP addresses > > - to anyone return topologically closer IP addresses first, others next. > > Maybe I need more of my morning $beverage but this sort of thing seems > to me to militate against other - existing - efficiency mechanisms. > > Network performance isn't just about topology, there are things like > performance and load to consider. Might your tweaked responses just > send clients to a nearby but tragically overloaded server? > > My preference would be to let those people whose job it is to think > about this stuff - which, reading this list, clearly they do - get on > with their job. > > Observations welcome of course. > > -- > > 73, > Ged. > -- > 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
> On 1 Mar 2024, at 10:37, Greg Choules via bind-users > wrote: > > In summary, Do the hard work of traffic steering somewhere else and let your > DNS resolvers deliver the chosen answer. Don't make the resolvers themselves > try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01/03/2024 11:02, Jim Reid wrote: On 1 Mar 2024, at 10:37, Greg Choules via bind-users wrote: In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best +1 -- 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