DNS info disapears

Mark_Andrews at isc.org Mark_Andrews at isc.org
Fri Sep 6 14:01:51 UTC 2002


> > 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.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). 

>   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.
 
>   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?

	No.  It wasn't retrieving the cached NODATA response for type ANY.

Index: bin/named/ns_resp.c
===================================================================
RCS file: /proj/cvs/isc/bind8/src/bin/named/ns_resp.c,v
retrieving revision 8.180
diff -u -r8.180 ns_resp.c
--- bin/named/ns_resp.c	20 Aug 2002 22:29:15 -0000	8.180
+++ bin/named/ns_resp.c	6 Sep 2002 13:35:42 -0000
@@ -3003,7 +3003,7 @@
 					*dnamep, type, class);
 				continue;
 			}
-			if (type == T_ANY)
+			if (type == T_ANY && dp->d_type != T_ANY)
 				continue;
 			hp->rcode = NOERROR_NODATA;
 			if (dp->d_size == 0) { /* !RETURNSOA */
> 
> Andris
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list