Primary DNS Server

Portal Home > Knowledgebase > Articles Database > Primary DNS Server

Posted by Diana Magers, 02-13-2012, 01:29 PM
Trying to think what would happen if my primary DNS server went off line what server would process my request then?
Posted by silasistefan, 02-13-2012, 02:46 PM
do you have a secondary DNS? if yes, that one will process... if not... nobody
Posted by fshagan, 02-14-2012, 11:11 AM
If you have both authoritative name servers on the same server, like many dedicated and VPS hosts do, then when the server is down, so are all the sites. What's worse is that email is bounced immediately, giving the sender the impression that you have run out of town with their money, gone bankrupt, or just disappeared. That can happen any time your server with both authoritative name servers on it is not available; it doesn't have to be "down" for more than a millisecond for this to happen. If you have your authoritative name servers on different physical servers, and one doesn't respond, the requester ... browser, ftp program or email server ... simply queries the remaining name server. Because they pick the name server to query randomly, only about half of your requests will have to make a second query. Better yet, if your site is down, but at least one of your authoritative name servers is still up and running, email is not bounced. It is held for a delivery later, giving you from 4 to 48 hours (depending on the mail server) to get the site back on-line. (And, if you are using a mail service like Google Apps, the email is delivered on time because the DNS record is still there to point the mail to the third party.)
Posted by brianoz, 02-14-2012, 08:40 PM
Email is not bounced when DNS is down - that's a rather common but completely untrue beleif. Email is queued/retried for 4 hours, then a warning email goes to the originator, then email is retried for around 4 days, and THEN it bounces. This retrying is a requirement of the relevant email transport RFCs. When DNS is down, it generates a server failure message (SERVFAIL from memory) in the resolver; this is quite different from NXDOMAIN. All this is documented in the various RFCs if you care to check.
Posted by fshagan, 02-15-2012, 01:28 AM
Sorry, everything I have read on this issue says if the authoritative nameservers cannot be reached (i.e., they are both or all three down), then the email is bounced. Email queuing happens when the MX record is read. If the sending system can't reach the MX record, it is as if the email address and the domain has simply disappeared. In any case, name servers must not resolve to the same IP address (see http://www.iana.org/procedures/names...uirements.html).
Posted by foobic, 02-15-2012, 02:20 AM
SERVFAIL is the error you get when DNS is up, but misconfigured for the domain requested. But it's not going to be NXDOMAIN either, since the parent nameservers will provide IP addresses for the (non-responsive) authoritative nameservers. Testing this on a spare domain delegated to some long-dead nameservers I found that dig shows "connection timed out; no servers could be reached", and exim log shows: So it looks like you're right, at least for exim - it is deferring delivery rather than bouncing the message instantly.
Posted by plumsauce, 02-15-2012, 02:44 AM
That is a "local" configuration choice made by the administrator of the sending server. Administrators who have to deal with sender complaints of non-delivery seldom use that setting if they want to continue getting a paycheck. You may be confusing it with a setting that says for example "immediately drop mail if domain reported unknown". That would be a response of NXDOMAIN from the parent servers which is quite a different animal than a child server being down. Look at the document again. It is the guidelines for the IANA maintained or directly delegated root servers. First sentence.
Posted by fshagan, 02-15-2012, 10:41 AM
But is it prevalent? Missing any email from a client is a very serious issue. Is it your position that authoritative name servers can share an IP, and the "single point of failure" error message given by utilities like http://intodns.com should be ignored?
Posted by brianoz, 02-15-2012, 05:49 PM
I guess the best way to think about it is from a logical point of view - if there's no response from a DNS server, would it make sense to bounce an email? From a logical point of view, this happens all the time, even to major sites, and would result in oceans of lost email. The RFC, which I could dig up if people want, says that implementations MUST queue....
Posted by Chris-Solutrix, 02-16-2012, 12:44 PM
If you are worried about your primary DNS server going offline you should look into finding a company to provide you with failover DNS hosting and automatic traffic redirection. That way if the primary goes offline you have a solution in place that kicks in when need be.
Posted by dotHostel, 02-16-2012, 01:06 PM
From a resolver point of view there isn't a "primary" name server. If you are using Bind`s VIEW feature, or a nameserver software that doesn't provide zone transfers, multiple primary servers is a requirement. Last edited by dotHostel; 02-16-2012 at 01:19 PM.
Posted by fshagan, 02-17-2012, 05:31 PM
If you get time, I'd like to see the reference. But its not a big deal, as the requirements still exist for name servers to be hosted on separate servers. From a logical point of view, I would imagine the mail servers relay a ton of UCE that is addressed to defunct email addresses. With 80 - 90% of the email consisting of UCE you could estimate a large amount of undeliverable email. Do the mail servers really queue that mail, retrying queries through the DNS system looking for non-existent name servers?
Posted by cutabovehost, 02-18-2012, 02:40 AM
Seems like I recall the server does queue I have not tested that in a very long time but seems like that is what happened. Seems like I recall as well that you can set the amount of time to queue mail before bouncing it. I recall the VPS.net DC in London went out and both of their NS were in the same DC which causes their site to be down among other things.
Posted by fshagan, 02-18-2012, 11:28 AM
I know the queue time is configurable; what I thought was that you didn't have to queue mail at all when the authoritative name servers did not exist. I'll have to defer to plumsauce on that issue though, as he has infinitely more knowledge of the standards than I do. Without the email queuing issue, there is no compelling reason to have name servers on different IP addresses for the average VPS user. If his server is down, so are his name servers, and so is his email. There's no difference to him if it takes an hour, four hours or 48 hours for the server to come back up, as when the site comes back up, so do the name servers, and the mail that is still queued will be delivered (some will have been bounced depending on the sender's configuration). I'm sure there are exceptions, such as having email not delayed at all if you are using something like Google Apps; if you have at least one name server still responding, email will continue to flow through to Gmail even when your VPS is down. But for the average host with hobby sites it doesn't matter.
Posted by dotHostel, 02-18-2012, 11:34 AM
Again, from RFC 2182:
Posted by cutabovehost, 02-18-2012, 12:34 PM
Hello, Well I do know for a fact that you are supposed to have two name servers registered for every domain registered. At least two that is. So even if you have both of them not answering for whatever reason when they query the root servers they will get a result for the name servers. They just won't answer if they are down. I would think at that point the email server would enter the queue and wait for said time then retry to deliver. If the domain does not exist at all I would guess at the point it would fail and send the notice back to the user that sent the email to be delivered. Actually I tested this and it does in fact return it immediately for a non-existing domain:
Posted by foobic, 02-19-2012, 12:22 AM
I've often suspected that some ISPs are actually ignoring that one and avoiding undesirable load on the net (and particularly their own network) by not retrying failed lookups for a period - effectively caching the failed lookup. So a 2 minute reboot or network glitch can turn into an hour or more of apparent downtime for all visitors using that certain ISP's resolvers. But that was based on observations and client reports many years ago when I was using a standard cPanel reseller setup. It would be interesting to test accurately for some popular ISPs now. Following up on the earlier test for the record, both Google apps mail and my own exim (standard DA config) finally gave up on sending to the non-resolving domain after 72 hours.
Posted by brianoz, 02-19-2012, 08:10 AM
I'm fairly sure failed resolves are cached, but not for long - maybe 30 minutes or so, just from experience? And exim won't retry a host for a while after a lookup fails, effectively doing the same, but limited to email from a specific server rather than being ISP wide. Of course, it's been pretty common for ISP's to do random wrong stuff with DNS! Last edited by brianoz; 02-19-2012 at 08:21 AM.
Posted by brianoz, 02-19-2012, 08:30 AM
And, for fshagan who was asking about the RFC specifying that email must be queued: By the way, I'm not arguing against redundant DNS servers here; I'm arguing against the people who think that they are providing a service that is useful in a way which it is not. This is important, as understanding how DNS works can help you build systems that actually ARE more reliable, rather than just appearing to be more reliable! In other words - let's put the effort in where it makes a difference!
Posted by dotHostel, 02-19-2012, 09:20 AM
The server(s) querying the authoritative name servers usually are intermediate cache name servers that may be using different routes than the client applications. You can't discard the situation where a network issue in the route cache-auth ns precludes the name resolution because you are using only one auth ns but the route client-server is fine and the server could answer requests from the client. BTW IMO you can't discuss DNS assuming all services are provided by just one server (or VPS) as it is a very poor archictecture even though it is a common one adopted by cheap / clueless providers. Last edited by dotHostel; 02-19-2012 at 09:24 AM.
Posted by dotHostel, 02-19-2012, 10:45 AM
The RFC doesn't mention failure to resolve the domain name. Retries are all about connection attempts and timeouts. You can't try to connect without an IP. Last edited by dotHostel; 02-19-2012 at 10:56 AM.
Posted by dotHostel, 02-19-2012, 11:07 AM
5. Address Resolution and Mail Handling Last edited by dotHostel; 02-19-2012 at 11:10 AM.
Posted by fshagan, 02-19-2012, 02:43 PM
I'm still unclear if the RFC requires caching if there are no auth ns to be found. To recap what I think we've seen from the quotes from the RFCs: Incorrect domain names are bounced immediatelyDelivery attempts after obtaining the MX record must be retried So we have bounces if the domain name doesn't exist; the mail sender queries the DNS system and if the top level domain doesn't exist the email is bounced. That makes sense. All the other quotes seem to fit into #2 above; the RFC seems to deal with the situation where a auth ns has responded with a MX or CNAME record, and can't find the IP address. But what happens when the DNS system says "go ask ns1.some-nameserver.com or ns2.some-nameserver.com where to deliver that email" and the sender can't resolve to those name servers? In any case, your quote from RFC 2182: seems applicable to the types of clients I advise (the SMB market) as to whether they should risk flaunting what seems to be an arbitrary and useless rule about hosting both name servers on the same server.
Posted by dotHostel, 02-19-2012, 03:38 PM
Exactly. I think the explanation for the lack of recommendation for this case is because it is unlikely to happen when nameservers are deployed following the relevant RFCs (multiple name servers, geographic and network diversity, etc). Anyway ... I read that as "don't assume anything" Last edited by dotHostel; 02-19-2012 at 03:45 PM.
Posted by fshagan, 02-20-2012, 11:48 AM
I will definitely temper my "email bounces" message with more "mights" and "maybes". Quoting the RFCs warms all of our hearts, but the people I talk to are likely to think RFC is some kind of new fast food place.

Add to Favourites Print this Article