GitLab

Summary

The default rrset-order changed in bind 9.12 to sort returned results in an rrset rather than to randomize them. This is not listed in the change notes and is an operationally dangerous change. For example, this breaks services relying on DNS round-robin load balancing by overloading the machine with the lowest IP address. Even when the authority returns round-robin rrsets, bind 9.12 still sorts them by default.

This silent default change may be a critical issue in bind 9.12 that could cause major service incidents. It may be necessary to broadly communicate this broken/changed behavior and recommend fixes.

Steps to reproduce

Resolve a name with multiple records in the rrset. With bind versions prior to 9.12, each lookup returns results in a different order. In bind 9.12, results are returned sorted. (As an example, doing an "ssh" or "curl" with a bind 9.12 resolver will always try the first IP, whereas with previous versions of bind9 different IPs will be tried.) For example these are sorted (while the authority ns1.google.com even permutes with each lookup):

$ dig +short www.youtube.com @127.0.0.1
youtube-ui.l.google.com.
172.217.3.110
172.217.6.206
172.217.7.14
172.217.10.46
172.217.10.78
172.217.10.142
172.217.10.238
172.217.11.14
172.217.11.46
172.217.12.142
172.217.12.174

With the above, many clients using the stock Linux system libraries will always connect to "172.217.3.110".

What is the current bug behavior?

rrsets with the default configuration are sorted.

What is the expected correct behavior?

rrset responses should be randomized by default.

Relevant configuration files

Behavior with the default configuration.

Relevant logs and/or screenshots

Possible fixes

I suspect this commit changed the behavior:

03be5a6b

The issue is fixed by adding back in:

rrset-order { order random; };

If this is an intentional change, it should be discussed much more widely in the community as this has potentially operational implications.