-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.

Improve this question
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, 2018 at 13:22

2 Answers 2

Reset to default
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.

Improve this answer
7
  • 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, 2018 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, 2018 at 0: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, 2018 at 0: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, 2018 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, 2018 at 13:25
-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

Improve this answer
5
  • 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, 2018 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, 2018 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, 2018 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, 2018 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, 2018 at 13:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .