On Sat, Jan 31, 2015 at 5:12 PM, J- P <[email protected]> wrote: > I have a question regarding secondary A records for redundancy using an App
Short answer: If something cares about the ordering of DNS records, it is broken. GORY DETAILS All A records for a given domain name are peers. There is no "primary" or "secondary". Some nameservers will rotate the order of records automatically, so that DNS clients will get the records in a different order each time. This is often termed "round robin". Some nameservers will always return records in the same order. Unless you control all the nameservers at some level, you cannot guarantee round robin behavior. For example, if you control all the authoritative servers for a name, you can ensure clients will always get rotated records. Or, if you control all caching resolvers used by all involved clients (say, all DNS servers used in your organization), you can ensure rotated records. Unless you control all software at *every* level, you cannot guarantee DNS record order. In general, this means you cannot depend on DNS record order. You have to assume reordering of records may occur. DNS round robin can be used as an imperfect load-balancing mechanism. Since clients get records in different orders, some will ask one server, some will ask another. It's imperfect because a given server can still get an uneven share of the load due to coincidence, and when that happens, you can't do anything about it. By default, Microsoft's DNS implementation does round robin: https://technet.microsoft.com/en-us/library/cc787484%28v=ws.10%29.aspx Having multiple A records can be used as an availability mechanism, but it's generally a pretty bad idea. Clients can spend long periods of time trying the same down server, and some implementations may not even try other records/servers. > This article seems to say that web browsers will retry a second ip if one > fails to res;pond > and that it is the OS & or the browser that allows this to happen. That is not "round robin". That is "fallback" or "failover", or simply "trying multiple addresses". The behavior of this is implementation-dependent. Behavior varies with browser, OS, resolver library, phase of the moon, etc. Some web browsers and HTTP libraries -- especially older ones -- are notorious for only using the first answer, and never trying another, and never querying DNS again once a name has been resolved. That usually manifests as "can no longer connect until you close and re-open the app". In programming terms, when given a name to connect to, apps/libraries typically call gethostbyname() or its equivalent. That function returns a list of addresses. Some apps/libraries just try the first address in the list. Others try the first, but then if it doesn't work, will try the next, and so on. (Again, the ordering of addresses in that list cannot be guaranteed.) Broadly speaking, most "modern" web browsers and libraries will try more than one address, but if you don't control the environment, you can't count on that. -- Ben
