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

cmds:

fly ssh console -s -a udns                               

# look up ipv4only.arpa which should return well-known rfc7090 addresses
# 192.0.0.170, 192.0.0.171
e148e432f24789:/app# nslookup -type=A ipv4only.arpa
Server:		fdaa::3
Address:	[fdaa::3]:53

Non-authoritative answer:

# test querying example.com to see if the in-VM resolver works at all:
e148e432f24789:/app# nslookup -type=A example.com
Server:		fdaa::3
Address:	[fdaa::3]:53

Non-authoritative answer:
Name:	example.com
Address: 93.184.215.14

Why?

1 Like

From General to Questions / Help

Added machines

cc: @thomas?

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

(I’ve been trying to figure out whether I can get away with making my local VMs (Qubes-ish :ice_cube: desktop) be IPv6-only—so am on the alert for any hints about little surprises…)

Hi:

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):

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.