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