anonion0
commented
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 arpaThe 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
BenBE
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.