I’m seeing quite an odd error from 1.1.1.1 when trying to resolve hosts in the ip6-servers.arpa and in-addr-servers.arpa zones, which simply contain the hosts “a” through “f” for the various name servers.
Querying just the base of the zone (eg. ip6-servers.arpa) returns the SOA for that zone as expected, but querying for one of the name server names (eg. a.ip6-servers.arpa) returns an NXDOMAIN and the SOA for the arpa zone, which is especially odd: the ip6-servers.arpa zone appears to be known when querying for it directly, but when querying for names inside that zone, only the arpa zone is found.
Additionally, querying for reverse IP’s in the ip6.arpa and in-addr.arpa zones works fine, it’s just querying for the nameservers of those zones that is the issue.
Running a measurement in RIPE atlas seems to indicate that this is a global issue, and tests with other public recursors yield the expected results, so it just seems to be a configuration error on 1.1.1.1.
Ah I hadn’t noticed C was down. I can ping it, but it’s not responding to queries.
I don’t think the behaviour I’m seeing would be caused by that though. If a server was not responding, I’d expect a SERVFAIL, whereas getting an NXDOMAIN with the SOA for the parent zone says to me that the resolver has no knowledge of the child zone.
If 1.1.1.1 uses a local copy of the root or arpa zones (rather than querying the root servers) and it’s mismatched or outdated, then that would make more sense to me as a cause. Perhaps some names are setup to use a local copy that doesn’t currently exist?
