-1

We had one of our nameservers go down yesterday and everyone in the office was scratching their heads wondering why our other DNS didn't pick up the load in a timely manner (if at all). The two nameservers are not in master-slave configuration, but their zones and records in the zones are all identical. It should be noted that the two nameservers live on two completely different networks (Comcast and Verizon) as well.

I theorized that because we only had one NS entry in each zone file, no resolver would ever see the secondary nameserver -- and was looked at is if I had two heads. We have one entry in each zone (on each nameserver), ns1.xxxxx.com. So my question is: am I right in thinking that whatever resolver -- whether it be a Windows machine or a mobile device -- will not know about our secondary nameserver, ns2.xxxxx.com, unless we explicitly put an NS entry for that server into each zone file?

I am a programmer primarily, and am now being introduced to DNS, so I want to make sure that I have the right idea of things before bringing my idea to the table as a solution again. I certainly do see many people all over Google having multiple NS entries -- sometimes up to 4 -- in a zone file for any given website.

Thanks for any help, folks.

Trevor Yokum
  • 3
  • 1
  • If you gave the name people could have help you. Also you seem to be under the (false) impression that (authoritative) nameservers are ordered: they are not, because they are a set. They also are returned in random order most of the times. So resolvers will use all of them but a non responsive one will provoke longer delays before resolver learn it is unresponsive and switch to the others one. Only if they are correctly listed in parent of course, so yes all need to be `NS` records otherwise noone sees them, `ns1`, `ns2`, ... is just a convention not an hardcoded norm. – Patrick Mevzek Jul 20 '18 at 13:22

2 Answers2

0

You should have NS records for all the nameservers you want to be used both in the zone itself and in the delegation information added to the parent zone (managed through your registrar).
This should all match, both parent ⟷ your zone and obviously the copies of your zone on all the nameservers.

I think you should really look into having zone transfers or some other automated means of keeping the zone data in sync. It seems almost inevitable that things will not actually be accurately synced otherwise (like your example with the NS records).

As for the client machines you mention, these will not generally care about authoritative nameservers at all. Typically they just have one or more resolver servers specified by IP in their configuration, these resolver servers in turn deal with the actual work of looking up names.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • Okay, gotcha. Thanks so much for the answer. I checked on our registrar, GoDaddy, and found that our most used websites (what we care about right this second, anyways) are delegated as nameservers under the "Manage DNS" section. Our nameservers in total are very small, so syncing them is not an issue for us. If we were much bigger, we'd be doing it differently, and eventually will have to. So, furthermore, if the delegation on GoDaddy is what *really* matters, then what will adding those second NS entries (along with glue records) to our zones do for us exactly? – Trevor Yokum Jul 19 '18 at 15:24
  • @TrevorYokum With a different `NS` rrset in your own zone, your nameservers will claim (and they are the authoritative source) that the set of nameservers is actually something else. Expect inconsistent behavior if you do that. There is no reason to consider deliberately messing that up. – Håkan Lindqvist Jul 20 '18 at 00:00
  • @TrevorYokum Putting it differently, it’s trivial to do it right and then the results are straightforward, but if you do it wrong it’s very much a non-trivial failure mode where implementation-specific behavior and cache state will matter. That type of mismatch is not supposed to exist, it’s not something that has a defined behavior in the standards. – Håkan Lindqvist Jul 20 '18 at 00:25
  • I think I'm understanding what you're saying. And also, I really appreciate you taking the time to explain this stuff. I'm so new to DNS and I'm trying to get a good grasp on it and you're really helping me. So what you're saying is that, for instance, if a resolver were to cache the DNS entries for one of our .coms (currently having only one NS entry) rather than the parent's delegation (on GoDaddy, with two NS entries), the second nameserver will not be noticed until the TTL expires on that NS and it goes to grab the DNS records again? Just wanna make sure I'm understanding. – Trevor Yokum Jul 20 '18 at 12:20
  • @TrevorYokum no, resolvers will learn of a problem before the TTL ends. Typically (this is implementation dependent) they keep the information about all nameservers and query the fastest one. They keep reply times to see how it changes and switch as necessary, including also using the non fastest ones for a percentage of queries in order not to stick with only one. They will however keep in cache, and reply from there, the specific records asked for, like `A` or `AAAA` for `www`. – Patrick Mevzek Jul 20 '18 at 13:25
  • Having a different set of NS in your zone and its parent is called a lame delegation and will only give you troubles, like Håkan Lindqvist said. There is no reason to put yourself in this case, DO NOT DO THAT. Many providers are able to provide you "secondary DNS service" if you want to manage only one nameserver. They also provide full DNS service if you prefer to outsource everything so that you have one less thing to do yourself. – Patrick Mevzek Jul 20 '18 at 13:27
  • @PatrickMevzek Got it!!! Thanks for the absolutely wonderful explanation. I'm actually of the mind that we should not even be maintaining our own nameservers simply to take two servers out of commission here and free up some rack space. Other services (AWS, Google, etc) have proven to be very reliable from what I've seen online from folks. We unfortunately have some opposition from the top of the chain here at work to that idea -- which is fine, but makes for headaches sometimes. Again, thanks so much for that explanation. – Trevor Yokum Jul 20 '18 at 13:42
-1

What is most important is that the parent domain has the right delegations for both nameservers. I don't think that a failure to have an explicit NS record 'pointing' to the second server is in itself an error, as long as it does have a proper delegation in the parent domain and considers itself authoritative.

See: https://www.howtoforge.com/troubleshooting-common-dns-misconfiguration-errors

Gerrit
  • 1,347
  • 7
  • 8
  • *I don't think that a failure to have an explicit NS record 'pointing' to the second server is in itself an error* is begging for trouble; likely in harder to track ways, where implementation specific behavior and cache state may be the differentiating factor – Håkan Lindqvist Jul 19 '18 at 11:40
  • I have duly pointed out that it is only NOT a failure if the second nameserver has proper delegation in the parent zone and answers authoritatively. In any other case it is an immediate failure. – Gerrit Jul 19 '18 at 11:45
  • And what I'm saying is that it will be a problem regardless. Ie, it's trivial to do this right and get consistent behavior, not doing it right may save a very minimal amount of work (I guess this is what your point is?) but that puts you in a very much non-trivial problem space where you have inconsistent data and things will behave in different ways. – Håkan Lindqvist Jul 19 '18 at 11:51
  • You are right of course that it is asking for trouble. My point is only that focusing on the NS records could fool someone into believing that a resolver will try to read the NS records and fallback to other nameservers mentioned therein as is exactly the suggestion made in the question. They follow the delegations in the parent zone. – Gerrit Jul 19 '18 at 12:02
  • Ok, I would suggest maybe rephrasing that part of the answer to align with what you are now writing in comments. Also, keep the partially cached scenarios in mind. – Håkan Lindqvist Jul 19 '18 at 13:04