DNS info disapears
Andris Kalnozols
andris at hpl.hp.com
Fri Sep 6 06:41:15 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.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
More information about the bind-users
mailing list