DNS Server Slave – NS record in master

domain-name-system

I'm setting up a basic DNS system with a master server (1.1.1.1) and a slave server (2.2.2.2) for "example.com" domain.

I don't know if I should add the NS record in the master server for the slave server as this example:

; Records in MASTER server 1.1.1.1
; name servers
  IN  NS     ns1.example.com. ; DNS Int 1 - MASTER
  IN  NS     ns2.example.com. ; DNS Int 2 - SLAVE

; glue records
  ns1       IN  A      1.1.1.1  ; name server definition MASTER
  ns2       IN  A      2.2.2.2  ; name server definition SLAVE

What's the difference in adding, or not, the NS record for the slave server? I understand that the NS record means that THOSE servers there are authoritative for the domain, "example.com" in this case. But, if I do not add the NS record for the master server, I'd still get authoritative answers from the slave as it got he's zone information from the master.

So what's the difference?

Thanks!

Best Answer

Given your example, there are actually two questions that need to be answered here.

Do I need multiple nameservers?

Yes. A thousand times yes. If an authoritative nameserver for your domain can't be reached, it vanishes from the internet. You must have multiple nameservers and they must be geo-redundant, i.e. located at different physical locations.

Server hardware dies. It's inevitable.
Site level disasters happen. Fire, flood, earthquakes, electrical surges, etc. Your DNS servers should not be physically at the same site in order to be resilient to unplanned disasters.
Routing problems happen. If all of your DNS servers share a common upstream peer, they vanish from the internet when that peer experiences a total outage. When routing problems occur between that peer and specific remote networks, all of your servers become unavailable to remote devices that are behind that routing path. Having multiple servers that do not share an upstream peer make you significantly more resilient to upstream routing problems of all sorts.

What is the difference between listing a master and a slave in the NS records?

From the perspective of a DNS client, there is no difference at all. From the perspective of a server admin, it's a best practice to only expose the slave servers to the internet and have a "hidden" master that only the slave servers and your private networks can communicate with.

Downtime for the master doesn't impact your internet facing redundancy. The slaves can be disconnected from the master for quite some time with there being no ill effects. The maximum length of time is determined by the expiry field in the SOA record of every zone hosted on the slaves.
Fewer mistakes are exposed to the internet facing name servers. Major syntax problems are unlikely to be allowed to propagate over zone transfers. Even if you make a mistake so significant that it results in the nameserver process self-terminating, or entire domains being unloaded, the worst that happens to the slaves is that they briefly lose contact with the master. The clients don't notice a thing.
Security benefits. If the master is compromised, changes can be pushed to all of the slave servers by an attacker. If a slave server is compromised, changes can only be made to that one server. (of course, if you let them into one server, odds are pretty good that the others have similar exploits they can rely on...but reduced profile still doesn't hurt)

Related Solutions

DNS – How to Test Glue Record

Glue records only ever exist in the parent zone of a domain name.

Hence in the case of your example.org domain name, first find the .org name servers:

% dig +short org. NS
a0.org.afilias-nst.info.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
c0.org.afilias-nst.info.
d0.org.afilias-nst.org.

Then, for as many of these as you feel like testing, explicitly ask those name servers for the NS records for your domain:

% dig +norec @a0.org.afilias-nst.info. example.org. NS

You should get back the correct list of NS records in the "AUTHORITY SECTION". For any name servers that have correctly configured glue you should see those glue A (and/or AAAA) records appear in the "ADDITONAL SECTION".

Setting up a master DNS server, using goDaddy as slave

OK, first things first: Go to you local book store (or library if it's got a decent selection of technical books) and pick up a copy of DNS & BIND - any edition will be sufficient, though if you're buying one buy the latest. Then read this book cover to cover, or at least read through chapters 1, 2, 3, 5 and 6.

I am absolutely serious about this - If you try to set up DNS without a solid understanding of what's going on you are in for a wold of pain, suffering and mysterious breakage. Spending a day with a good book on DNS will pay for itself the first time you have a problem.

Now to actually answer your questions :-)

Re: the issue of being flagged as spam: Hosting your own DNS may or may not solve the problem of your system being flagged as a spam source -- The question you haven't asked/answered is WHY you are being flagged as a spam source (Is it your IP, the lack of SPF records, a bad reverse-DNS entry, or is your server perhaps misconfigured and really being used to send spam?).
You need to answer that question first, then pursue solutions based on what you discover.

If after investigating the incident problem you still want to host your own DNS (either as part of a solution to the incident problem, or just for the experience) . . .

I'm pretty sure the error you're getting from GoDaddy is their way of saying you're missing glue records -- In plain English "You want us to use ns1.xxx.com as a nameserver for xxx.com, but we have no way of finding that server".

Prior to using a host within in your own zone as an NS you need to create glue records for it. You can do this in GoDaddy's domain manager's "Host" box -- Add a domain host for each NS you want to use, and the system should then let you specify those hosts as the domain's nameservers.

BIG IMPORTANT WARNING
Before you flip the switch check, double-check and triple-check that the servers you're about to set as the authoritative NS are working properly (they resolve all the names they're supposed to resolve, you can query them from a machine off your network, etc.).

Many admins (probably every one who has ever set up DNS) probably has a horror story about screwing up and knocking their domain off the internet for a while -- Don't be a statistic like the rest of us :-)