Question about BIND's handling of mismatched glue
Ollie Cook
ollie at uk.clara.net
Tue Nov 12 14:08:08 UTC 2002
Hi,
I am trying to ascertain why I cannot retrieve an SOA RR for a particular zone
from a recursive only BIND installation running BIND 8.3.3.
I enclose as detailed debugging information as I can gather, and my
interpretation of it.
I think the problem may lie with glue records in the GTLD servers not matching
what the authoritative servers for the zone return, but I would appreciate
clarification of that, if possible.
I found the following similar post to the list from not long ago:
http://marc.theaimsgroup.com/?l=bind-users&m=103292931926205&w=2
which suggests that the glue records in the GTLD servers are 'copies' of the
A records in the child zone.
Is this 'automatic' in the sense that if the child A RRs for the glue records
disappear, they will also disappear from the GTLD servers by some means (i.e.
GTLD servers query authoritative servers at intervals), or in a looser sense
that they ought to match but this is not enforced?
Any assistance would be most gratefully received.
Yours,
Ollie
--------- problem report --------
Problem: recursive-only nameserver cannot retrieve SOA for lifelinenetwork.org
Versions: 195.8.69.7 is running BIND 8.3.3
Configuration: 195.8.69.7's named.conf:
options {
datasize 340M;
fake-iquery no;
directory "/var/named";
listen-on { 195.8.69.7; };
query-source address 195.8.69.7 port *;
};
logging {
category lame-servers{ null; };
};
zone "." {
type hint;
file "root.cache";
};
Evidence:
Trying a recursive lookup by querying the BIND 8.3.3 server fails:
; <<>> DiG 8.3 <<>> soa lifelinenetwork.org @195.8.69.7
; (1 server found)
; ; res options: init recurs defnam dnsrch
; ; got answer:
; ; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6
; ; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
; ; QUERY SECTION:
; ; lifelinenetwork.org, type = SOA, class = IN
; ; Total query time: 1 msec
; ; FROM: mutare.noc.clara.net to SERVER: 195.8.69.7
; ; WHEN: Tue Nov 12 13:01:10 2002
; ; MSG SIZE sent: 37 rcvd: 37
Trying to retrieve SOA manually works:
1) GTLD servers report authoritative nameservers for lifelinenetwork.org as:
; <<>> DiG 8.3 <<>> ns lifelinenetwork.org @F.GTLD-SERVERS.NET.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUERY SECTION:
;; lifelinenetwork.org, type = NS, class = IN
;; ANSWER SECTION:
lifelinenetwork.org. 2D IN NS NS3.BAIDEN.COM.
lifelinenetwork.org. 2D IN NS NS4.BAIDEN.COM.
;; ADDITIONAL SECTION:
NS3.BAIDEN.COM. 2D IN A 213.171.200.58
NS4.BAIDEN.COM. 2D IN A 81.27.96.160
;; Total query time: 148 msec
;; FROM: mutare.noc.clara.net to SERVER: F.GTLD-SERVERS.NET. 192.35.51.30
;; WHEN: Tue Nov 12 13:03:03 2002
;; MSG SIZE sent: 37 rcvd: 115
2) Query authoritative servers for SOA RR:
; <<>> DiG 8.3 <<>> soa lifelinenetwork.org @213.171.200.58
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;; lifelinenetwork.org, type = SOA, class = IN
;; ANSWER SECTION:
lifelinenetwork.org. 1H IN SOA ns3.baiden.com. root.lifelinenetwork.org. (
10 ; serial
15M ; refresh
10M ; retry
1D ; expiry
1H ) ; minimum
;; ADDITIONAL SECTION:
ns3.baiden.com. 1H IN A 213.171.200.58
;; Total query time: 13 msec
;; FROM: anteros.uk.clara.net to SERVER: 213.171.200.58 213.171.200.58
;; WHEN: Tue Nov 12 13:22:01 2002
;; MSG SIZE sent: 37 rcvd: 108
; <<>> DiG 8.3 <<>> soa lifelinenetwork.org @81.27.96.160
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; lifelinenetwork.org, type = SOA, class = IN
;; Total query time: 16 msec
;; FROM: anteros.uk.clara.net to SERVER: 81.27.96.160 81.27.96.160
;; WHEN: Tue Nov 12 13:23:41 2002
;; MSG SIZE sent: 37 rcvd: 37
Discussion:
Presumably, I've followed the same steps that BIND ought to:
- get nameserver names and glue records for zone from root and GTLD
servers
- query each such nameserver for the SOA record for the zone
I can't see how it's giving SERVFAIL, when at least one of the authoritative
nameservers is giving correct data (213.171.200.58).
I do notice that the glue for BAIDEN.COM nameservers doesn't match what the
authoritative servers say, but should this matter? Does BIND trust the glue
from the GTLD servers?
; <<>> DiG 8.3 <<>> a NS3.BAIDEN.COM. @k.gtld-servers.net
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; NS3.BAIDEN.COM, type = A, class = IN
;; ANSWER SECTION:
NS3.BAIDEN.COM. 2D IN A 213.171.200.58
;; AUTHORITY SECTION:
BAIDEN.COM. 2D IN NS NS.ADLHOSTING.COM.
BAIDEN.COM. 2D IN NS NS4.BAIDEN.COM.
;; ADDITIONAL SECTION:
NS.ADLHOSTING.COM. 2D IN A 81.27.96.160
NS4.BAIDEN.COM. 2D IN A 81.27.96.160
;; Total query time: 88 msec
;; FROM: anteros.uk.clara.net to SERVER: k.gtld-servers.net 192.52.178.30
;; WHEN: Tue Nov 12 13:10:40 2002
;; MSG SIZE sent: 32 rcvd: 126
; <<>> DiG 8.3 <<>> +norec a NS3.BAIDEN.COM. @81.27.96.160
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48972
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; NS3.BAIDEN.COM, type = A, class = IN
;; AUTHORITY SECTION:
BAIDEN.COM. 1H IN SOA ns.adlhosting.COM. ns.intec.net. (
2002090102 ; serial
1H ; refresh
30M ; retry
1w3d ; expiry
1H ) ; minimum
;; Total query time: 23 msec
;; FROM: anteros.uk.clara.net to SERVER: 81.27.96.160 81.27.96.160
;; WHEN: Tue Nov 12 13:14:16 2002
;; MSG SIZE sent: 32 rcvd: 94
--------- end problem report --------
--
Oliver Cook Systems Administrator, ClaraNET
ollie at uk.clara.net 020 7903 3065
More information about the bind-users
mailing list