Open Isonami opened 1 month ago
/cc @demarcush
DNS64:
% dnslookup www.youtube.com "https://[2606:4700:4700::6400]/dns-query"
dnslookup master
Server: https://[2606:4700:4700::64]/dns-query
dnslookup result (elapsed 672.885567ms):
;; opcode: QUERY, status: NOERROR, id: 36506
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.youtube.com. IN A
;; ANSWER SECTION:
www.youtube.com. 214 IN CNAME youtube-ui.l.google.com.
youtube-ui.l.google.com. 214 IN A 216.58.212.174
youtube-ui.l.google.com. 214 IN A 142.250.186.110
youtube-ui.l.google.com. 214 IN A 142.250.185.174
youtube-ui.l.google.com. 214 IN A 172.217.16.206
youtube-ui.l.google.com. 214 IN A 172.217.18.14
youtube-ui.l.google.com. 214 IN A 142.250.185.78
youtube-ui.l.google.com. 214 IN A 142.250.184.238
youtube-ui.l.google.com. 214 IN A 142.250.186.46
youtube-ui.l.google.com. 214 IN A 172.217.23.110
youtube-ui.l.google.com. 214 IN A 142.250.185.206
youtube-ui.l.google.com. 214 IN A 142.250.185.110
youtube-ui.l.google.com. 214 IN A 142.250.185.142
youtube-ui.l.google.com. 214 IN A 142.250.186.142
youtube-ui.l.google.com. 214 IN A 142.250.185.238
youtube-ui.l.google.com. 214 IN A 216.58.206.46
youtube-ui.l.google.com. 214 IN A 216.58.206.78
Regular:
% dnslookup www.youtube.com "https://[2606:4700:4700::1111]/dns-query"
dnslookup master
Server: https://[2606:4700:4700::1111]/dns-query
dnslookup result (elapsed 887.474621ms):
;; opcode: QUERY, status: NOERROR, id: 13352
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.youtube.com. IN A
;; ANSWER SECTION:
www.youtube.com. 152 IN CNAME youtube-ui.l.google.com.
youtube-ui.l.google.com. 152 IN A 142.250.185.206
youtube-ui.l.google.com. 152 IN A 172.217.16.206
youtube-ui.l.google.com. 152 IN A 172.217.23.110
youtube-ui.l.google.com. 152 IN A 142.250.186.142
youtube-ui.l.google.com. 152 IN A 142.250.185.142
youtube-ui.l.google.com. 152 IN A 142.250.186.46
youtube-ui.l.google.com. 152 IN A 142.250.186.110
youtube-ui.l.google.com. 152 IN A 216.58.212.174
youtube-ui.l.google.com. 152 IN A 216.58.206.78
youtube-ui.l.google.com. 152 IN A 216.58.206.46
youtube-ui.l.google.com. 152 IN A 142.250.185.174
youtube-ui.l.google.com. 152 IN A 172.217.18.14
youtube-ui.l.google.com. 152 IN A 142.250.185.110
youtube-ui.l.google.com. 152 IN A 142.250.185.78
youtube-ui.l.google.com. 152 IN A 142.250.185.238
youtube-ui.l.google.com. 152 IN A 142.250.184.238
Only difference is when you query a domain for AAAA which doesn't have AAAA entries:
% RRTYPE=AAAA dnslookup ipv4.google.com "https://[2606:4700:4700::64]/dns-query"
dnslookup master
Server: https://[2606:4700:4700::64]/dns-query
dnslookup result (elapsed 808.855929ms):
;; opcode: QUERY, status: NOERROR, id: 11053
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ipv4.google.com. IN AAAA
;; ANSWER SECTION:
ipv4.google.com. 60 IN CNAME ipv4.l.google.com.
ipv4.l.google.com. 60 IN **AAAA 64:ff9b::acd9:10ce**
In this case instead of returning an empty response, it returns the dns64 version.
One can try and make distinct entries for dns64 resolvers (although a redundant pursuit).
I'm sorry, had bad explanation.
Main problem that if system has both ipv4 and ipv6 it usually tries to resolve both A and AAAA records and may priorities AAAA answer. And then it depends on software will it fallback to A record or not. That might brake something.
Example:
> resolvectl status
Link 2 (enp34s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: 2606:4700:4700::6400
Curl fallback to ipv4
> curl -vvv ipv4.l.google.com
* Host ipv4.l.google.com:80 was resolved.
* IPv6: 64:ff9b::8efb:240e
* IPv4: 172.217.168.206
* Trying [64:ff9b::8efb:240e]:80...
* Trying 172.217.168.206:80...
* Connected to ipv4.l.google.com (172.217.168.206) port 80
But ping will fail
> ping ipv4.l.google.com
PING ipv4.l.google.com (64:ff9b::8efb:240e) 56 data bytes
^C
--- ipv4.l.google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3049ms
I've personally observe problem with openvpn, it always tries to connect to dns64 address first.
Ok, since fixing the problem from upstream of all those projects will make all our lives miserable, I propose we remove them for now and maybe add a toggle-option to sdns:// specification for resolvers with dns64 capabilities.
I'll try to make a PR, no promises.
Example ips from the list:
Is it expected behavior? They have different resolve results for A queries.
Cloudflare link about theirs dns64 resolvers https://developers.cloudflare.com/1.1.1.1/infrastructure/ipv6-networks/