Closed BenBE closed 1 year ago
This may be an issue with your DNS resolver.
n3map simply relies on the system's configured resolver to get the nameserver IPs. The recursive nameserver doing the actual name resolution should be able to correctly resolve the nameserver's A
records (whether glue records are involved or not).
I tested various recursive nameservers, and they can resolve it no problem. Even Google's public resolver can do it:
$ dig @8.8.8.8 a.ns.arpa A
[..]
;; ANSWER SECTION:
a.ns.arpa. 87098 IN A 198.41.0.4
[..]
Are you using a public resolver by any chance?
It would be interesting to see what happens when you turn DNSSEC validation on (pretty sure the validation will fail for that NXDOMAIN
response).
Of course, issues with the system resolver could be avoided by adding a full iterative resolver to n3map, but I really don't want to do that (maybe if dnspython had one already...).
For the other two issues:
The baisc idea is to just let n3map cycle through the available nameservers and it will stop using those that do not answer correctly (configurable using --max-retries
and --max-errors
).
If the resolution of nameservers fails, you can specify them manually and get the same behavior, e.g.:
n3map -vv -o arpa.zone {a..m}.root-servers.net arpa
The issue you had with b.root-servers.net
is because by default, n3map tries to enumerate NSEC
zones by making direct NSEC
queries as well as the occasional A
query to avoid descending into sub-zones (e.g. you can see it skip over arpa.
when you enumerate the root zone). But some servers do not allow queries for NSEC
records at all (only a handful of the root servers do).
The command above will spit out a bunch of errors for all the servers that don't respond to NSEC
queries, but should then succeed using the remaining ones.
Alternatively, you could use --query-mode=A
(short -A
), which will only make A
queries (but requires roughly 2x as many queries total):
n3map -Avv -o arpa.zone b.root-servers.net arpa
I'll have a look if I can manage to capture a pcap of the initial NS resolution phase for that zone.
Though I can reproduce this issue directly by calling dig with 1.1.1.1
as the nameserver:
$ dig @1.1.1.1 a b.ns.arpa.
; <<>> DiG 9.18 <<>> @1.1.1.1 a b.ns.arpa.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32966
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;b.ns.arpa. IN A
;; AUTHORITY SECTION:
arpa. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023021301 1800 900 604800 86400
;; Query time: 11 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Feb 14 00:34:54 CET 2023
;; MSG SIZE rcvd: 114
$ dig +dnssec @1.1.1.1 a b.ns.arpa.
; <<>> DiG 9.18 <<>> +dnssec @1.1.1.1 a b.ns.arpa.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48380
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;b.ns.arpa. IN A
;; AUTHORITY SECTION:
arpa. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023021301 1800 900 604800 86400
arpa. 86400 IN RRSIG SOA 8 1 86400 20230226180000 20230213170000 13759 arpa. Vho+SP4yE3eH/YGjL/ggoGlY3iBAU6b2jZ/mAGYZul3beBcvhXvqIq/B lMdWu1iB2+XwECSudllBrnaazAP35r96YBGnm4ugYJbMcPyeBWG6VVp4 JxECdc8a2C0E5gQVarScH1UuFlDRrUF0r1HoPkcyRaHun0/+qAAtLi3R H4Lx3YQ6UoRheN/o8xeYpMBodryACr0lk3gyrLCUsWSlUsZUknxB2SV6 Yd7Sbdirxm9XttMLULpfPwV02++1uZSnlxva6AJ3Cdm9kYmWdPndRcHo bFqlgxIp/V/+SSvm/By0kHjNcdk7CZ2mZe9UdHDdxZtRIJf1NO/mCwbx sz7i7Q==
iris.arpa. 86400 IN NSEC a.ns.arpa. NS DS RRSIG NSEC
iris.arpa. 86400 IN RRSIG NSEC 8 2 86400 20230226180000 20230213170000 13759 arpa. Yrx2ylSzLFtjzlaz91XtcgX0Hqcbn+VXR1ODX0udj5YrDseuhPJpj/eT /fJOWWnjr+M8D6hJpTnJHESPrt2IIz4A2vbFK9TR3UHr56MD8qmIs1ZP itbFohI+IiOT7WJwc9K2e34kRdrEufo26r0+VSmwJ+dvsWqt++3ljJ6o yLTjouKetRkLKmsWvmM4nwgGFuccpBvCHoae5NPZbS3EQJYXw1UnNFWV mpKCnXQ0WEhog/1yb0BziU/pr6mXvqKf6qkxGCwwaWlv1nmzO3hfwiz/ 9NyjeExprSAWFvxM+0HCnyDl6x/BOpmK8dTyEK1fx1ve+PCL6UXAmiH9 Z5ABkw==
;; Query time: 11 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Feb 14 00:35:15 CET 2023
;; MSG SIZE rcvd: 734
I managed to work around the issues locally (with the various options mentioned).
What most confused me is, that n3map seems to completely fail if even just one nameserver cannot be resolved (???) …
I just discovered the same thing, 1.1.1.1
really does exhibit this (weird) behavior. Validation fails of course:
$ drill -S @1.1.1.1 a.ns.arpa A
;; Number of trusted keys: 1
;; Chasing: a.ns.arpa. A
DNSSEC Trust tree:
a.ns.arpa. (A)
|---Error in denial of existence: RR not covered by the given NSEC RRs
|---arpa. (NSEC as112.arpa. NS SOA RRSIG NSEC DNSKEY )
| |---arpa. (DNSKEY keytag: 13759 alg: 8 flags: 256)
| |---arpa. (DNSKEY keytag: 42581 alg: 8 flags: 257)
| |---arpa. (DS keytag: 42581 digest type: 2)
| |---. (DNSKEY keytag: 951 alg: 8 flags: 256)
| |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
|---Error in denial of existence: RR not covered by the given NSEC RRs
|---iris.arpa. (NSEC a.ns.arpa. NS DS RRSIG NSEC )
|---arpa. (DNSKEY keytag: 13759 alg: 8 flags: 256)
|---arpa. (DNSKEY keytag: 42581 alg: 8 flags: 257)
|---arpa. (DS keytag: 42581 digest type: 2)
|---. (DNSKEY keytag: 951 alg: 8 flags: 256)
|---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
No trusted keys found in tree: first error was: RR not covered by the given NSEC RRs
;; Chase failed.
I'm quite confused about why the server it is acting this way, but IMHO it's clearly wrong.
What most confused me is, that n3map seems to completely fail if even just one nameserver cannot be resolved (???) …
That could be remedied. I'll open a another issue for it.
Let's consider enumerating
arpa.
:Running
dig ns arpa.
shows the full GLUE records, though asking for the A records directly does not yield a result:If you provide an authoritive nameserver, in this case both
.
andarpa.
are served by essentially the same servers fromroot-servers.net.
, there is two issues further arising:Number one is: Some server's won't respond properly to queries (as can be seen with
a.root-servers.net.
):Number two can be seen with
b.root-servers.net.
:Only with
c.root-servers.net.
(and the others in the NS RRset), the enumeration succeeds:Would be nice if the resolution of (working) nameservers could be made more robust for cases like this.