DoH response results are different between ipv4 and ipv6
Hello, my name is ikutakanpani
I recently discovered that some Google pages were inaccessible, and while investigating, I found a strange DNS response.
In my environment, the DNS server has a DoH proxy, and when a DNS packet arrives, it sends a DoH request to NextDNS.
The strange thing is that the DoH (curl) response is different between ipv4 and ipv6.
The actual command response is listed below.
This topic has been machine translated from Japanese.
ipv4
curl --ipv4 -v https://dns.nextdns.io/[ID]/[distinguished name]/resolve?name=fonts.googleapis.com
* Host dns.nextdns.io:443 was resolved.
* IPv6: (none)
* IPv4: 103.170.232.254, 167.179.109.118
* Trying 103.170.232.254:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=dns.nextdns.io
* start date: Apr 22 00:00:00 2025 GMT
* expire date: Jul 21 23:59:59 2025 GMT
* subjectAltName: host "dns.nextdns.io" matched cert's "dns.nextdns.io"
* issuer: C=AT; O=ZeroSSL; CN=ZeroSSL ECC Domain Secure Site CA
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Connected to dns.nextdns.io (103.170.232.254) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://dns.nextdns.io/[ID]/[distinguished name]/resolve?name=fonts.googleapis.com
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: dns.nextdns.io]
* [HTTP/2] [1] [:path: /[ID]/[distinguished name]/resolve?name=fonts.googleapis.com]
* [HTTP/2] [1] [user-agent: curl/8.14.1]
* [HTTP/2] [1] [accept: */*]
> GET /[ID]/[distinguished name]/resolve?name=fonts.googleapis.com HTTP/2
> Host: dns.nextdns.io
> User-Agent: curl/8.14.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Request completely sent off
< HTTP/2 200
< content-type: application/dns-json
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< content-length: 325
< date: Sat, 21 Jun 2025 04:16:29 GMT
<
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"fonts.googleapis.com.","type":1}],"Answer":[{"name":"fonts.googleapis.com.","type":1,"TTL":300,"data":"172.217.161.42"}],"Additional":[{"name":".","type":41,"TTL":0,"data":"\n;; OPT PSEUDOSECTION:\n; EDNS: version 0; flags:; udp: 1232"}]}
ipv6
$ curl --ipv6 -v https://dns.nextdns.io/[ID]/[distinguished name]/resolve?name=fonts.googleapis.com
* Host dns.nextdns.io:443 was resolved.
* IPv6: 2001:19f0:7001:5e19:5400:2ff:fec8:7b5a, 2a0b:4341:b02:166:5054:ff:fe53:ab1
* IPv4: (none)
* Trying [2001:19f0:7001:5e19:5400:2ff:fec8:7b5a]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=dns.nextdns.io
* start date: Apr 22 00:00:00 2025 GMT
* expire date: Jul 21 23:59:59 2025 GMT
* subjectAltName: host "dns.nextdns.io" matched cert's "dns.nextdns.io"
* issuer: C=AT; O=ZeroSSL; CN=ZeroSSL ECC Domain Secure Site CA
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Connected to dns.nextdns.io (2001:19f0:7001:5e19:5400:2ff:fec8:7b5a) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://dns.nextdns.io/[ID]/[distinguished name]/resolve?name=fonts.googleapis.com
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: dns.nextdns.io]
* [HTTP/2] [1] [:path: /[ID]/[distinguished name]/resolve?name=fonts.googleapis.com]
* [HTTP/2] [1] [user-agent: curl/8.14.1]
* [HTTP/2] [1] [accept: */*]
> GET /[ID]/[distinguished name]/resolve?name=fonts.googleapis.com HTTP/2
> Host: dns.nextdns.io
> User-Agent: curl/8.14.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Request completely sent off
< HTTP/2 200
< content-type: application/dns-json
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< content-length: 324
< date: Sat, 21 Jun 2025 04:16:46 GMT
<
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"fonts.googleapis.com.","type":1}],"Answer":[{"name":"fonts.googleapis.com.","type":1,"TTL":300,"data":"64.233.185.95"}],"Additional":[{"name":".","type":41,"TTL":0,"data":"\n;; OPT PSEUDOSECTION:\n; EDNS: version 0; flags:; udp: 1232"}]}
1 reply
-
I certainly would be interested to hear an official response on this from @NextDNS, but for what it's worth, I see the same behavior when testing the IPv4 vs v6 curl statements you posted.
It's certainly not uncommon for a single A record to resolve to multiple IP addresses, whether it's for redundancy or a more primitive version of load-balancing. But doing a `dig` against the NextDNS servers for 'fonts.googleapis.com' only returns a single IP for the A record, which matches your curl behavior.
I did do a reverse lookup (`dig -x`) against the two IP addresses from my testing and both have PTR records resolving to Google's 1e100[.]net backbone:lax17s49-in-f10.1e100.net. lax31s11-in-f10.1e100.net.
They are likely geographically close to the NextDNS POP to which you're querying, so your PTR records from the same reverse lookup query would look differently than the two I got.
Anyway, I'm just adding additional points of observation. Not claiming there is an issue or not. Hopefully you'll get a more formal response to clarify what you're seeing.
Content aside
-
1
Votes
- 5 days agoLast active
- 1Replies
- 33Views
-
3
Following