I have a DNS record with three A records: the main site, and two backups. However, when clients perform a DNS lookup, they reach a backup site.
How can I change the order of the DNS records in dot.tk's DNS server?
-
4As long as the DNS is working does it matter what order the DNS lookup resolves with? it's something you shouldn't need to do on regular basis anyhow. You could always write a PHP to do your own lookup and sort in the order you like. I'd be more concerned with hosting an important site on a free .tk domain :P– Simon HayterCommented Jul 29, 2014 at 21:34
-
@Simon Hayter, backup links could have limited infrastructure (i.e. less bandwidth, smaller hardware, etc) causing a degraded end user experience.– user2320464Commented Jun 12, 2016 at 15:42
Add a comment
|
3 Answers
You're touching on a "feature" of DNS known as DNS Round Robin. It's deliberate. You have no control over the order in which records which satisfy a particular query are provided.
http://en.wikipedia.org/wiki/Round-robin_DNS
It's crude; but surprisingly effective as a load-balancer.
If, in fact, the "backup" machines should not be touched unless the primary fails, you need to be more sophisticated with your zone files. You could change the TTL (time-to-live period) for the A record to a small number (e.g. 60 seconds) and then set up a script to change that A record via RFC 2136 when you want folks to fail over.
If you have 3 A records coughing up 3 different answers, you are supposed to get rough distribution equally amongst the 3. (one can also assume that M$ DNS will screw this up, but I don't actually know...)
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.
If you run your own name server using BIND this is configured with the rrset-order parameter
rrset-order defines the order in which multiple records of the same type are returned.
There are three options,
fixed - records are returned in the order they are defined in the zone file
random - records are returned in a random order
cyclic - records are returned in a round-robin fashion
See details here, http://www.zytrax.com/books/dns/ch7/queries.html#rrset-order
