Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"

[Greg Choules]

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 <bind at jubileegroup.co.uk> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240301/cfb8f4e9/attachment.htm>