Ticket ID: SIXXS #801779 Ticket Status: Invalid PoP: gblon02 - Goscomb Technologies (London)
strange DNS delegation
Shadow Hawkins on Saturday, 06 September 2008 03:21:51
(NIC handle: RT744-RIPE)
hi,
i have delegated reverse DNS for my subnet (R7228, 2a01:348:6:78::2, 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa) to two nameservers: loreley.flyingparchment.org.uk, ns3.purplecow.org. however, i see the following strange behaviour:
loreley:/etc/bind# dig 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ns @ns1.goscomb.net
;; QUESTION SECTION:
;4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. IN NS
;; ANSWER SECTION:
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.sixxs.net.
loreley:/etc/bind# dig 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ns @ns1.sixxs.net
;; QUESTION SECTION:
;4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. IN NS
;; AUTHORITY SECTION:
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 604800 IN NS ns3.purplecow.org.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 604800 IN NS loreley.flyingparchment.org.uk.
(note that ns1.goscomb.net is the authority for the parent zone, 8.4.3.0.1.0.a.2.ip6.arpa).
it seems the nameservers don't agree on authority. my local recursor cannot resolve addresses in this subnet:
loreley:/etc/bind# dig -x 2a01:348:184:1::1 @nscache0.lon4.goscomb.net
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1646
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
curiously, if i query using a recursor that doesn't have the bogus 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa NS record pointing at sixxs, it _does_ resolve. however, if i flush the cache and "poison" it with this record by querying it immediately after the flush, it suddenly becomes unable to resolve:
root@harmony:~#host 2a01:348:184:1::1 localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa domain name pointer harmony.flyingparchment.org.uk.
root@harmony:~#rndc flush
root@harmony:~#host -t ns 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa name server ns3.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa name server ns1.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa name server ns2.sixxs.net.
root@harmony:~#host 2a01:348:184:1::1 localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa not found: 3(NXDOMAIN)
it seems this problem would be solved by removing the "4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa NS ns1.sixxs.net" from the POP's auth server (ns*.goscomb.net).
strange DNS delegation
Jeroen Massar on Saturday, 06 September 2008 22:59:37
What exactly is the problem with this?
The reverse delegation is working fine, see below.
You are specifically asking a server for a record which ns{1|2|3}.goscomb.net doesn't know the answer for, but it knows that ns{1|2|3}.sixxs.net is responsible (from it's point of view, as it is auth only and it doesn't know much else), they in turn then tell you to ask your DNS servers as they (ns{1|2|3}.sixxs.net) don't know the answer either.
This is correct behavior.
--
$ dig +trace 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ptr
; <<>> DiG 9.5.0-P2 <<>> +trace 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ptr
;; global options: printcmd
. 288144 IN NS G.ROOT-SERVERS.NET.
. 288144 IN NS H.ROOT-SERVERS.NET.
. 288144 IN NS I.ROOT-SERVERS.NET.
. 288144 IN NS J.ROOT-SERVERS.NET.
. 288144 IN NS K.ROOT-SERVERS.NET.
. 288144 IN NS L.ROOT-SERVERS.NET.
. 288144 IN NS M.ROOT-SERVERS.NET.
. 288144 IN NS A.ROOT-SERVERS.NET.
. 288144 IN NS B.ROOT-SERVERS.NET.
. 288144 IN NS C.ROOT-SERVERS.NET.
. 288144 IN NS D.ROOT-SERVERS.NET.
. 288144 IN NS E.ROOT-SERVERS.NET.
. 288144 IN NS F.ROOT-SERVERS.NET.
;; Received 500 bytes from 217.169.138.1#53(217.169.138.1) in 7 ms
ip6.arpa. 172800 IN NS NS.ICANN.ORG.
ip6.arpa. 172800 IN NS NS.LACNIC.NET.
ip6.arpa. 172800 IN NS SEC1.APNIC.NET.
ip6.arpa. 172800 IN NS NS-SEC.RIPE.NET.
ip6.arpa. 172800 IN NS TINNIE.ARIN.NET.
;; Received 220 bytes from 2001:503:ba3e::2:30#53(A.ROOT-SERVERS.NET) in 106 ms
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns2.goscomb.net.
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns3.goscomb.net.
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns1.goscomb.net.
;; Received 155 bytes from 2001:dc0:2001:a:4608::59#53(SEC1.APNIC.NET) in 353 ms
1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.sixxs.net.
1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.sixxs.net.
1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.sixxs.net.
;; Received 153 bytes from 195.238.232.74#53(ns1.goscomb.net) in 43 ms
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 604800 IN NS ns3.purplecow.org.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 604800 IN NS loreley.flyingparchment.org.uk.
;; Received 165 bytes from 2001:7b8:3:1e:290:27ff:fe0c:5c5e#53(ns2.sixxs.net) in 25 ms
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 3600 IN PTR harmony.flyingparchment.org.uk.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 8600 IN NS ns3.purplecow.org.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 8600 IN NS loreley.flyingparchment.org.uk.
;; Received 231 bytes from 2a01:348:0:6:4d4b:69f2:0:1#53(loreley.flyingparchment.org.uk) in 26 ms
strange DNS delegation
Shadow Hawkins on Sunday, 07 September 2008 04:08:09
Sorry, the delegation is not working fine:
root@harmony:~#rndc flush
root@harmony:~#dig 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa NS @localhost
; <<>> DiG 9.3.5-P1 <<>> 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa NS @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1212
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. IN NS
;; ANSWER SECTION:
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.sixxs.net.
;; Query time: 2840 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 7 02:54:44 2008
;; MSG SIZE rcvd: 113
root@harmony:~#dig -x 2a01:348:184:1::1 @localhost
; <<>> DiG 9.3.5-P1 <<>> -x 2a01:348:184:1::1 @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1577
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. IN PTR
;; Query time: 623 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 7 02:55:03 2008
;; MSG SIZE rcvd: 90
root@harmony:~#
Additionally, BIND logs this in syslog:
Sep 7 02:55:03 harmony named[5079]: [ID 873579 daemon.info] lame server resolving '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa' (in '4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa'?): 193.1.31.74#53
Sep 7 02:55:03 harmony named[5079]: [ID 873579 daemon.info] lame server resolving '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa' (in '4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa'?): 2001:838:1:1:210:dcff:fe20:7c7c#53
Sep 7 02:55:03 harmony named[5079]: [ID 873579 daemon.info] lame server resolving '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa' (in '4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa'?): 2001:7b8:3:1e:290:27ff:fe0c:5c5e#53
Sep 7 02:55:03 harmony named[5079]: [ID 873579 daemon.info] lame server resolving '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa' (in '4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa'?): 2001:770:18:8::4#53
Sep 7 02:55:03 harmony named[5079]: [ID 873579 daemon.info] lame server resolving '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa' (in '4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa'?): 213.197.29.32#53
Sep 7 02:55:03 harmony named[5079]: [ID 873579 daemon.info] lame server resolving '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa' (in '4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa'?): 193.109.122.62#53
(These IPs are for ns[123].sixxs.net)
Normally, when an authority wants to indicate delegation to someone else, it does not return the entire queried address. Instead, it returns the part which is delegated. For example:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ptr @ns.lacnic.net
zsh: correct 'ptr' to 'pitr' [nyae]? n
; <<>> DiG 9.3.5-P1 <<>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ptr @ns.lacnic.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1113
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. IN PTR
;; AUTHORITY SECTION:
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns2.goscomb.net.
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns1.goscomb.net.
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns3.goscomb.net.
You can see the response only shows 8.4.3.0.1.0.a.2.ip6.arpa, not the entire address. Indeed, if we ask for PTR, ns1.goscomb.net returns the expected result:
root@harmony:~#dig 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ptr @ns1.goscomb.net
;; AUTHORITY SECTION:
1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.sixxs.net.
1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.sixxs.net.
1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.sixxs.net.
But if we ask for NS, we get the incorrect delegation:
root@harmony:~#dig 4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ns @ns1.goscomb.net
;; ANSWER SECTION:
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.sixxs.net.
4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.sixxs.net.
BIND caches this incorrect NS return, and expects ns1.sixxs.net to answer queries for this zone - which it cannot do, because it is not the authority.
strange DNS delegation
Jeroen Massar on Tuesday, 09 September 2008 21:34:34
Strange, this indeed seems to reproduce the problem:
$ dig +trace 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ns
; <<>> DiG 9.5.0-P2 <<>> +trace 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa ns
;; global options: printcmd
. 469678 IN NS f.root-servers.net.
. 469678 IN NS a.root-servers.net.
. 469678 IN NS k.root-servers.net.
. 469678 IN NS d.root-servers.net.
. 469678 IN NS i.root-servers.net.
. 469678 IN NS b.root-servers.net.
. 469678 IN NS e.root-servers.net.
. 469678 IN NS j.root-servers.net.
. 469678 IN NS m.root-servers.net.
. 469678 IN NS h.root-servers.net.
. 469678 IN NS c.root-servers.net.
. 469678 IN NS l.root-servers.net.
. 469678 IN NS g.root-servers.net.
;; Received 500 bytes from 2001:838:2:1:2a0:24ff:feab:3b53#53(2001:838:2:1:2a0:24ff:feab:3b53) in 8 ms
ip6.arpa. 172800 IN NS TINNIE.ARIN.NET.
ip6.arpa. 172800 IN NS NS-SEC.RIPE.NET.
ip6.arpa. 172800 IN NS NS.LACNIC.NET.
ip6.arpa. 172800 IN NS NS.ICANN.ORG.
ip6.arpa. 172800 IN NS SEC1.APNIC.NET.
;; Received 220 bytes from 192.203.230.10#53(e.root-servers.net) in 158 ms
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns2.goscomb.net.
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns3.goscomb.net.
8.4.3.0.1.0.a.2.ip6.arpa. 172800 IN NS ns1.goscomb.net.
;; Received 155 bytes from 2001:500:13::c7d4:35#53(TINNIE.ARIN.NET) in 102 ms
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.sixxs.net.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.sixxs.net.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.4.8.1.0.8.4.3.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.sixxs.net.
;; Received 183 bytes from 195.90.120.55#53(ns2.goscomb.net) in 10 ms
Thus as long as you don't query for NS's you should be fine for the time being, this should not be an issue as one generally only queries for PTR records under .arpa anyway.
Notified Goscomb to look into this further.
State change: invalid
Jeroen Massar on Saturday, 06 September 2008 22:58:07
The state of this ticket has been changed to invalid
Posting is only allowed when you are logged in. |