<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">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.<br>
      <br>
                                                                     
              - Kevin<br>
      <br>
      On 6/9/2014 5:38 PM, Sid Shapiro wrote:<br>
    </div>
    <blockquote
cite="mid:CAJYWScZq2POEovRk-bEKxkX1b32EY4cm6-drPRv0tCEzrumZMQ@mail.gmail.com"
      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 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>
        <br>
        <br>
        <div class="gmail_quote">On Mon, Jun 9, 2014 at 2:32 PM, Kevin
          Darcy <span dir="ltr"><<a moz-do-not-send="true"
              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 moz-do-not-send="true" href="http://www.example.com"
                  target="_blank">www.example.com</a> and your
                searchlist ends in the domain <a moz-do-not-send="true"
                  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 moz-do-not-send="true"
                  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 class="h5"><br>
                    On 6/9/2014 4:36 PM, Sid Shapiro wrote:<br>
                  </div>
                </div>
              </div>
              <blockquote type="cite">
                <div>
                  <div class="h5">
                    <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: <a
                                moz-do-not-send="true"
                                href="tel:%28510%29%20741-6846"
                                value="+15107416846" target="_blank">(510)
                                741-6846</a>   Mobile: <a
                                moz-do-not-send="true"
                                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 moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
              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 moz-do-not-send="true"
              href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
            <a moz-do-not-send="true"
              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>
  </body>
</html>