Default of rrset-order silently changed to be sorted (rather than random)
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.174With 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:
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.