DNS info disapears

[Andris Kalnozols]

> Hi,
> 
> I have a weird and annoying problem that I need help on.
> 
> >From my name server I (its bind 8.3.3) I lookup a domain name
> 
> with a host -a
> 
> # host -a shopcanberra.com
> Trying "shopcanberra.com"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40594
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;shopcanberra.com.              IN      ANY
> 
> ;; ANSWER SECTION:
> shopcanberra.com.       172799  IN      NS      NS1.shopcanberra.com.
> shopcanberra.com.       172799  IN      NS      NS2.shopcanberra.com.
> 
> ;; AUTHORITY SECTION:
> shopcanberra.com.       172799  IN      NS      NS1.shopcanberra.com.
> shopcanberra.com.       172799  IN      NS      NS2.shopcanberra.com.
> 
> ;; ADDITIONAL SECTION:
> NS1.shopcanberra.com.   172799  IN      A       66.250.88.98
> NS2.shopcanberra.com.   172799  IN      A       66.250.88.99
> 
> 
> But on the 3rd lookup and everyone after that, the IP information goes
> missing,
> 
> # host -a shopcanberra.com
> Trying "shopcanberra.com"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61644
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;shopcanberra.com.              IN      ANY
> 
> ;; ANSWER SECTION:
> shopcanberra.com.       172798  IN      NS      NS1.shopcanberra.com.
> shopcanberra.com.       172798  IN      NS      NS2.shopcanberra.com.
> shopcanberra.com.       14400   IN      SOA     ns1.dnsroyal.com.
> server.dnsroyal.com. 1029804702 28800 7200 3600000 86400
> 
> ;; AUTHORITY SECTION:
> shopcanberra.com.       172798  IN      NS      NS1.shopcanberra.com.
> shopcanberra.com.       172798  IN      NS      NS2.shopcanberra.com.
> 
> 
> Same thing happens when say I ping NS1.shopcanberra.com
> 
> it resolves the first 2 times, and then no longer resolves.
> 
> OnceI restart named, it just happens again with the same thing. I
> query man other name servers they dont have the problem I am having.
> 
> Does anyone have any ideas why this happens and a solution for it ?
> 
> Thanks so much.

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.com.
     (
                                        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.

  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.

  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?

  4.  A month ago, I posted another observed anomaly with BIND
      8.3.3 and 8.3.2 (Expect NOERROR/NODATA, get SERVFAIL)

        http://marc.theaimsgroup.com/?l=bind-users&m=102860974705016&w=2

      but saw no response.  Perhaps these observed glitches are
      related?

Andris