Skip to main content
Webmasters

Return to Answer

replaced http://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link
Community Bot
Community Bot
  • 1

Even if you did have the authoritative nameservers for your zone, the only point where you have any actual control, answering with the records in some fixed order of your choosing it's still entirely possible (and actually common) for a resolver server to reorder them before passing the answer on to the client and even if the answer arrives in the desired order to the client host the resolver library can also reorder the resultresolver library can also reorder the result.

Even if you did have the authoritative nameservers for your zone, the only point where you have any actual control, answering with the records in some fixed order of your choosing it's still entirely possible (and actually common) for a resolver server to reorder them before passing the answer on to the client and even if the answer arrives in the desired order to the client host the resolver library can also reorder the result.

Even if you did have the authoritative nameservers for your zone, the only point where you have any actual control, answering with the records in some fixed order of your choosing it's still entirely possible (and actually common) for a resolver server to reorder them before passing the answer on to the client and even if the answer arrives in the desired order to the client host the resolver library can also reorder the result.

Source Link
Håkan Lindqvist
Håkan Lindqvist
  • 131
  • 2

The resource records that exist for a specific combination of name, class and type form what is called a resource record set (RRSet). Just like this term suggests (it being a set) there is no defined order for these records.

Even if you did have the authoritative nameservers for your zone, the only point where you have any actual control, answering with the records in some fixed order of your choosing it's still entirely possible (and actually common) for a resolver server to reorder them before passing the answer on to the client and even if the answer arrives in the desired order to the client host the resolver library can also reorder the result.

Just as an example, look at these queries issued in direct sequence to a caching resolver server:

$ dig @127.0.0.1 www.google.com +noall +answer

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> @127.0.0.1 www.google.com +noall +answer
; (1 server found)
;; global options: +cmd
www.google.com.         275     IN      A       173.194.71.106
www.google.com.         275     IN      A       173.194.71.147
www.google.com.         275     IN      A       173.194.71.104
www.google.com.         275     IN      A       173.194.71.105
www.google.com.         275     IN      A       173.194.71.99
www.google.com.         275     IN      A       173.194.71.103
$ dig @127.0.0.1 www.google.com +noall +answer

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> @127.0.0.1 www.google.com +noall +answer
; (1 server found)
;; global options: +cmd
www.google.com.         274     IN      A       173.194.71.103
www.google.com.         274     IN      A       173.194.71.147
www.google.com.         274     IN      A       173.194.71.99
www.google.com.         274     IN      A       173.194.71.106
www.google.com.         274     IN      A       173.194.71.105
www.google.com.         274     IN      A       173.194.71.104
$

From what it sounds like you are trying to achieve, I don't think adding multiple A records is part of the solution. It will at best give you a crude form of load balancing but never any kind of reliable failover.