<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Well, you shouldn't be getting an
NXDOMAIN just because some of your auth servers are off-line, but
you could get some query timeouts if performance to your failover
servers is really bad (or blocked, due to firewall rules, bad
routes, etc.), or, if your expire times are *really* low, and the
master's been down a while, it's possible the zone may have
expired on the slaves.<br>
<br>
In any of those cases, I'm suspecting you're using nslookup, and
you might be suffering from its horrible misfeature where it
searchlists on a query failure, and then reports the *last* RCODE
it received as the result of the entire lookup. So, for example,
if your query is <a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> and your searchlist ends in the
domain department1.example.com, if the first query fails (e.g.
with a timeout or a SERVFAIL), nslookup might work through the
searchlist, ultimately querying
<a class="moz-txt-link-abbreviated" href="http://www.example.com.department1.example.com">www.example.com.department1.example.com</a>, which returns NXDOMAIN,
and that's what nslookup (mis-)reports as the result of the query.<br>
<br>
You can avoid this by dot-terminating the original query (thus
inhibiting nslookup's searchlist behavior), or even better, using
a real DNS troubleshooting tool like dig or host. If you want to
continue to use nslookup, at the very least add the -debug flag so
you can see what it's really doing under the covers.<br>
<br>
- Kevin<br>
On 6/9/2014 4:36 PM, Sid Shapiro wrote:<br>
</div>
<blockquote
cite="mid:CAJYWScZDgi=StYtHhpNuB-caaTxxvmBt5t1gozFg2eoTbJfokQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hello,
<div>I've got 6 name-servers, 2 in each of 3 global regions.
Each name-server has a net connection. Each name-server is
authoritative. the domains it server have all six NS records.</div>
<div><br>
</div>
<div>My question has to do with redundancy. If one of my
"regions" goes down, I would have expected that a query
against a domain would reach one of the other region's
name-servers. However, during a maintenance window when one
regions was off the air, I did some simple queries. I did not
have a lot of time to do a lot of detailed testing and
tracing. I was simply trying to see if I could get a query
resolved. </div>
<div><br>
</div>
<div>What I got, was a "no name-server" error. I do not have the
exact message, nor the timings. I could see (somehow) that
there might be some time-out issue on the client, but the no
name-servers response came pretty quickly.</div>
<div><br>
</div>
<div>This doesn't seem like a configuration problem, although I
suppose it might be. It seems more like a misunderstanding how
redundancy works at the domain level.</div>
<div><br>
</div>
<div>Have I totally misunderstood a concept here?</div>
<div>Thanks<br clear="all">
<div>
<div dir="ltr">
<div>--</div>
<div>Sid Shapiro
<a moz-do-not-send="true"
href="mailto:sid_shapiro@bio-rad.com" target="_blank">sid_shapiro@bio-rad.com</a><br>
</div>
<div>
Bio-Rad Corporate IT - Desk: (510) 741-6846 Mobile:
(510) 224-4343</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
</body>
</html>