DNS info disapears

Andris Kalnozols andris at hpl.hp.com
Sun Sep 8 22:31:15 UTC 2002


> > I see two problems here.  One is with the delegation records for the
> > `shopcanberra.com' zone while the other is that the problem you are
> > seeing happens only when making recursive queries to a name server
> > which is running BIND 8.3.2 or 8.3.3.
> > 
> > As for the delegation problem, RFC-1034 requires that the NS records
> > be consistent on both sides of the zone cut.  The parent zone (com.)
> > reports:
> > 
> >   ; <<>> DiG 8.3 <<>> shopcanberra.com ns +norec @f.gtld-servers.net
> >   ; (1 server found)
> >   ;; res options: init defnam dnsrch
> >   ;; got answer:
> >   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54712
> >   ;; flags: qr; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
> >   ;; QUERY SECTION:
> >   ;;      shopcanberra.com, type = NS, class = IN
> > 
> >   ;; ANSWER SECTION:
> >   shopcanberra.com.       2D IN NS        NS1.shopcanberra.com.
> >   shopcanberra.com.       2D IN NS        NS2.shopcanberra.com.
> > 
> >   ;; ADDITIONAL SECTION:
> >   NS1.shopcanberra.com.   2D IN A         66.250.88.98
> >   NS2.shopcanberra.com.   2D IN A         66.250.88.99
> > 
> > The child zone, however, reports the following NS RRset:
> > 
> >   ; <<>> DiG 8.3 <<>> shopcanberra.com ns +norec @66.250.88.98
> >   ; (1 server found)
> >   ;; res options: init defnam dnsrch
> >   ;; got answer:
> >   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48923
> >   ;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
> >   ;; QUERY SECTION:
> >   ;;      shopcanberra.com, type = NS, class = IN
> > 
> >   ;; ANSWER SECTION:
> >   shopcanberra.com.       4H IN NS        ns1.dnsroyal.com.
> >   shopcanberra.com.       4H IN NS        ns2.dnsroyal.com.
> > 
> >   ;; ADDITIONAL SECTION:
> >   ns1.dnsroyal.com.       4H IN A         66.250.88.99
> >   ns2.dnsroyal.com.       4H IN A         66.250.88.98
> > 
> > Either the zone data should be changed to agree with the parent
> > or the domain's registrar needs to be contacted to update their
> > delegation information.
> > 
> > I am able to reproduce your resolution problems with BIND 8.3.2
> > and 8.3.3.  Prior versions of BIND 8 and BIND 9.2.1 do not pull
> > the rug out from under you after two queries.  What seems to be
> > happening is this:
> > 
> >   1. With no cached data, the name server resolves the domain
> >      name from the GTLD servers:
> > 
> >        ; <<>> DiG 8.3 <<>> NS1.shopcanberra.com
> >        ;; res options: init recurs defnam dnsrch
> >        ;; got answer:
> >        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
> >        ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> >        ;; QUERY SECTION:
> >        ;;      NS1.shopcanberra.com, type = A, class = IN
> > 
> >        ;; ANSWER SECTION:
> >        NS1.shopcanberra.com.   2D IN A  66.250.88.98
> > 
> >        ;; AUTHORITY SECTION:
> >        shopcanberra.com.       2D IN NS  NS1.shopcanberra.com.
> >        shopcanberra.com.       2D IN NS  NS2.shopcanberra.com.
> > 
> >        ;; ADDITIONAL SECTION:
> >        NS1.shopcanberra.com.   2D IN A  66.250.88.98
> >        NS2.shopcanberra.com.   2D IN A  66.250.88.99
> > 
> >      This is non-authoritative data with a TTL of two days.  Unless a
> >      subsequent query returns an authoritative answer with a different
> >      TTL value, name servers other than 8.3.2 and 8.3.3 will still be
> >      able to resolve above domain name for two days.
> > 
> >   2. A second query for the NS1.shopcanberra.com returns the same
> >      answer except that the TTL is now shorter by the elapsed time
> >      between the two queries.
> > 
> >   3. A third query, however, all of the sudden reports NXDOMAIN:
> > 
> >      ; <<>> DiG 8.3 <<>> NS1.shopcanberra.com
> >      ;; res options: init recurs defnam dnsrch
> >      ;; got answer:
> >      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2
> >      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> >      ;; QUERY SECTION:
> >      ;;      NS1.shopcanberra.com, type = A, class = IN
> > 
> >      ;; AUTHORITY SECTION:
> >      shopcanberra.com.  2h59m58s IN SOA  ns1.dnsroyal.com. server.dnsroyal.co
> > m.
> >      (
> >                                         1029804702      ; serial
> >                                         8H              ; refresh
> >                                         2H              ; retry
> >                                         5w6d16h         ; expiry
> >                                         1D )            ; minimum
> > 
> > Perhaps Mark Andrews, the acknowledged BIND expert, could offer his
> > expertise with the following questions regarding 8.3.2 and 8.3.3:
> > 
> >   1.  The default value of the `auth-nxdomain' option seems to have
> >       changed from "yes" to "no".  Only when I explicity configure
> >       "auth-nxdomain yes" will the AA bit appear in query #3.
> 
> 	The default changed when named was brought into compliance
> 	with RFC 2038 (1999/01/02). 

It would be worthwhile to update `doc/html/options.html' in any future
BIND 8 release to reflect this change that's been in effect since v8.2.
 
> >   2.  There seems to be some bad TTL arithmetic going on.  If a query
> >       for the SOA record is made directly to an authoritative name
> >       server, the TTL shows up as 4 hours.  In this case, the answer to
> >       the recursive query is reporting a TTL that is short by one hour.
> 
> 	This is max-ncache-ttl taking effect.
> 
> >   3.  The glue records (NS[12].shopcanberra.com) do not exist as
> >       authoritative data.  Are the new rules in the credibility
> >       pecking order such that an authoritative NXDOMAIN will
> >       displace non-authoritative glue?
> 
> 	Of course.

This needs to be explored a bit further because this particular flavor
of broken delegation for `shopcanberra.com' reveals two different kinds
of BIND resolution behaviors - one for v8.3.2/8.3.3 exemplified by the
above queries and another for previous versions of BIND 8 and the latest
version of BIND 9 (9.2.2rc1).

Discrepency #1: Starting with a fresh cache, make repeated queries for
                the glue record `NS1.shopcanberra.com'.

    v8.3.2/8.3.3
    ------------
    As has been demonstrated, the resolution algorithm does not seem to
    be satisfied with a cached answer from a non-authoritative source.
    A policy is in place to aggressively seek authoritative data and
    use the credibility rules to update cached data whenever possible.
    After two queries, NXDOMAIN is the returned answer.

    v8.3.1/9.2.2rc1
    ---------------
    The answer will always be the non-authoritative glue record from the
    `com' zone.  This makes sense if the resolution policy is supposed
    to be conservative, i.e., if the answer is in the cache, it's always
    good enough to be returned in a response until updated by more
    credible data from a subsequent query.

    Which is the correct behavior?

Discrepancy #2: For the v8.3.1/9.2.2rc1 name server, force it to get
                authoritative data by asking for the MX record(s) for
                shopcanberra.com.  The zone's more credible NS RRset
                will replace the one from the parent zone's delegation.
                Now make another query for NS1.shopcanberra.com.

    v8.3.2/8.3.3
    ------------
    According to your previous post, Mark, the authoritative NXDOMAIN
    has higher credibility than the non-authoritative glue (agreed).
    This should then properly replace the glue record whose sudden
    disappearance can be explained as a side-effect of the broken
    delegation.  The above queries show this to be the case.

    v8.3.1/9.2.2rc1
    ---------------
    Here's what a BIND 8.3.1 name server repeatedly gives as an answer:

      ; <<>> DiG 8.3 <<>> NS1.shopcanberra.com 
      ;; res options: init recurs defnam dnsrch
      ;; got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
      ;; QUERY SECTION:
      ;;      NS1.shopcanberra.com, type = A, class = IN

      ;; ANSWER SECTION:
      NS1.shopcanberra.com.   1d23h59m30s IN A  66.250.88.98

      ;; AUTHORITY SECTION:
      shopcanberra.com.       3h59m46s IN NS  ns2.dnsroyal.com.
      shopcanberra.com.       3h59m46s IN NS  ns1.dnsroyal.com.

      ;; ADDITIONAL SECTION:
      ns2.dnsroyal.com.       1d23h59m46s IN A  66.250.88.98
      ns1.dnsroyal.com.       1d23h59m46s IN A  66.250.88.99

    BIND 9.2.2rc1 returns the same answer except that the additional
    section is always absent.

    Why aren't the credibility rules being followed in this case
    to replace NS1.shopcanberra.com with NXDOMAIN?

    Does the broken delegation have anything to do with the missing
    additional section from the BIND 9 response?

As always, thanks for your help in explaining these issues.

Andris



More information about the bind-users mailing list