The in-VM resolver fdaa::3 does not answer ipv4only.arpa

[ignoramous]

Hi:

@mayailurus

Out of curiousity… Did this come up in the context of NAT64, by any chance?

Not really. We run a public DNS resolver (DoH and DoT only) on Fly and it turns out, some DNS clients / stubs (like Tailscale & AdGuard), send a query for ipv4only.arpa to determine if the endpoint serving the URL is indeed a DNS resolver.

Our code forwards incoming non-internal DNS queries to fdaa::3 due to the guarantee that it should just work (or at least, it shouldn’t really be breaking anything):

fdaa::3 DNS server returning NXDOMAIN for A queries

Thank you! I’m pretty slapdash with .internal; for instance, for a few weeks I wasn’t even copying the query record to nxdomain/noerror responses, and dig would grok them and Golang would not. If you spot more things like this, I can fix them quickly. (Of course, if you use fdaa::3 as your system DNS server, I’m proxying requests to a real DNS server, and the handling of those should not be slapdash. It’s important not to break “real” DNS, but .internal is something less than real.)