<div dir="ltr">Again - thanks for the quick response - that'll teach me to post without all the facts. I simply don't remember what the specific error was, darn it. It might have been NXDOMAIN or SERVFAIL - I didn't write it down. <div>
The test I was running was on a barely, if ever used, domain, so I was pretty sure it wasn't cached anywhere.</div><div><br></div><div>I'm trying to figure out ways to test this without taking name servers offline :-)</div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div>--</div><div>Sid Shapiro <a 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>
<br><br><div class="gmail_quote">On Mon, Jun 9, 2014 at 2:47 PM, Kevin Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com" target="_blank">kcd@chrysler.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>That scenario still shouldn't have led
to an NXDOMAIN. If none of the delegated nameservers are
responding, you'd get a timeout or SERVFAIL. So I think there's
still some investigation to be done. But using dig instead of
nslookup at least makes things clearer :-)<br>
<br>
Of course, caching may complicate things here. The NS records
published at the apex (which I assume were all 6 of them) take
precedence over the delegation NS'es, so for a period of time,
some resolvers would be able to resolve names in the zone, and
some would not. Eventually, depending on your TTLs, everyone would
expire the cached NS records and the zone would be completely
unresolvable.<span class="HOEnZb"><font color="#888888"><br>
<br>
- Kevin</font></span><div><div class="h5"><br>
<br>
On 6/9/2014 5:38 PM, Sid Shapiro wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">Thanks, Kevin, for your quick reply. In the last
few minutes, I've come to realize that my problem is likely that
the domain is only registered with two name servers - the one
which were offline. Even though the zone has 6 NS records, the
.com servers probably only know of the ones in the registration.
So registration and DNS not in sync. Silly mistake.
<div>
<br>
</div>
<div>(And FWIW, I *was* using dig, not nslookup)</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div dir="ltr">
<div>--</div>
<div>Sid Shapiro
<a href="mailto:sid_shapiro@bio-rad.com" target="_blank">sid_shapiro@bio-rad.com</a><br>
</div>
<div>Bio-Rad Corporate IT - Desk: <a href="tel:%28510%29%20741-6846" value="+15107416846" target="_blank">(510) 741-6846</a> Mobile:
<a href="tel:%28510%29%20224-4343" value="+15102244343" target="_blank">(510) 224-4343</a></div>
</div>
</div>
<br>
<br>
<div class="gmail_quote">On Mon, Jun 9, 2014 at 2:32 PM, Kevin
Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com" target="_blank">kcd@chrysler.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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 href="http://www.example.com" target="_blank">www.example.com</a> and your
searchlist ends in the domain <a href="http://department1.example.com" target="_blank">department1.example.com</a>,
if the first query fails (e.g. with a timeout or a
SERVFAIL), nslookup might work through the searchlist,
ultimately querying <a href="http://www.example.com.department1.example.com" target="_blank">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
<div>
<div><br>
On 6/9/2014 4:36 PM, Sid Shapiro wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<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 href="mailto:sid_shapiro@bio-rad.com" target="_blank">sid_shapiro@bio-rad.com</a><br>
</div>
<div> Bio-Rad Corporate IT - Desk: <a href="tel:%28510%29%20741-6846" value="+15107416846" target="_blank">(510)
741-6846</a> Mobile: <a href="tel:%28510%29%20224-4343" value="+15102244343" target="_blank">(510)
224-4343</a></div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote></div><br></div>