<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 2/2/2010 5:25 PM, Rob Tanner wrote:
<blockquote cite="mid:C78DE66E.34F3B%25rtanner@linfield.edu" type="cite">
<title>Having multiple name servers - is it really necessary</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hi,<br>
<br>
We have two registered name servers to answer internet queries. One is
on site and the other is a service of our ISP. The problem is that
every once in a while the secondary server doesn’t successfully
complete zone transfers and the data expires. </span></font></blockquote>
As the domain owner, you can set the expiration interval in the SOA
record. Sounds like you set the interval way too short. Expiration
intervals of a month or more are common. You need to give yourself
enough time to detect that replication is broken, and fix it.<br>
<br>
As for detecting whether replication is broken or not, you could
implement either <br>
a) scanning your logs to ensure that refresh queries and/or zone
transfers are occurring, or<br>
b) probing the secondary/secondaries to see if their version of the
zone is up to date (look at the serial number in the SOA),<br>
c) both of the above<br>
<br>
These measures may require that you force updates on a regular basis,
which you can do by making some sort of "dummy" change, if no "real"
changes have been made recently.<br>
<br>
<blockquote cite="mid:C78DE66E.34F3B%25rtanner@linfield.edu" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> I’m not sure what technically how the server
answers when queried for addresses it no longer thinks are valid, but
even after it’s fixed it takes a while for the bad data to go away. <br>
</span></font></blockquote>
If the zone truly *expires* then a nameserver will typically give a
SERVFAIL response for any query of a name in the zone.<br>
<br>
Since SERVFAIL usually isn't cached very long, I'm assuming that by
"bad data" you mean the staleness of the data leading up to the
eventual expiration of the zone. Once replication connectivity has been
restored, then a refresh would be forced on the slave, and it would
have a current version of the zone (how you do that depends on what DNS
implementation you're using, in extreme cases it might be necessary to
delete a file, or completely drop and re-add the slave-zone definition
in the config).<br>
<br>
As for stale records cached in non-authoritative servers, you as the
domain owner control the persistence of those through your TTL settings
on the individual records, and the negative-TTL setting in the SOA
record for the zone.<br>
<br>
<blockquote cite="mid:C78DE66E.34F3B%25rtanner@linfield.edu" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">What I’m wondering is, what are the
consequences of simply not using the secondary server. Right now we are
looking at hardened appliances configured into a high availability
cluster and I figure the pipe to the outside has a high likelihood of
going down then does the cluster. So, if name servers out in the
internet can’t even reach our server because our connection is down, is
that something that also propagates and get’s cached (i.e. Is no data
treated the same as bad data by upstream bind servers?</span></font><br>
</blockquote>
<font face="Calibri, Verdana, Helvetica, Arial">Well, the Internet
standards explicitly require at least 2 nameservers, and if the
zone/zones is/are delegated directly from a registry, usually they
enforce that rule.<br>
<br>
It would not be advisable to only have 1 delegated nameserver. Many
apps distinguish between "host not found" and "cannot connect" errors.
In the case of a store-and-forward subsystem like SMTP mail, for
instance, the former is fatal while the latter will be retried for some
period of time.<br>
<br>
Also, more generally, putting all your eggs in one basket -- "if this
fails then this other thing probably won't work either" -- rarely forms
the basis of a responsible disaster recovery plan.<br>
<br>
- Kevin<br>
<br>
</font>
</body>
</html>