DNS64: Not resolving and synthesizing correctly for CNAME chain (rfc6147#section-5.1.5)

[GoetzGoerisch]

Prerequisites

• [X] I have checked the Wiki and Discussions and found no answer

• [X] I have searched other issues and found no duplicates

• [X] I want to report a bug and not ask a question or ask for help

• [X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARM64

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

v0.107.48

Action

AdGuard configured for DNS64

AdGuardHome.yml:

...
  use_dns64: true
  dns64_prefixes:
    - 64:ff9b::/96
...

$ nslookup -debug -type=aaaa 'www.zdf.de' 'fd23:ff12:fde5:20::53'
Server:		fd23:ff12:fde5:20::53
Address:	fd23:ff12:fde5:20::53#53

------------
    QUESTIONS:
	www.zdf.de, type = AAAA, class = IN
    ANSWERS:
    ->  www.zdf.de
	canonical name = ssl.zdf.de.edgekey.net.
	ttl = 240
    ->  ssl.zdf.de.edgekey.net
	canonical name = e8383.e6.akamaiedge.net.
	ttl = 240
    AUTHORITY RECORDS:
    ->  e6.akamaiedge.net
	origin = n0e6.akamaiedge.net
	mail addr = hostmaster.akamai.com
	serial = 1713621457
	refresh = 1000
	retry = 1000
	expire = 1000
	minimum = 1800
	ttl = 240
    ADDITIONAL RECORDS:
------------
Non-authoritative answer:
www.zdf.de	canonical name = ssl.zdf.de.edgekey.net.
ssl.zdf.de.edgekey.net	canonical name = e8383.e6.akamaiedge.net.

Expected result

Expected to follow https://datatracker.ietf.org/doc/html/rfc6147#section-5.1.5 AAAA record is correctly synthesized from AdGuardHome and the upstream CNAME chain and A record.

Output from Cloudflare DNS64 server for comparison

nslookup -debug -type=aaaa 'www.zdf.de' '2606:4700:4700::64'
Server:		2606:4700:4700::64
Address:	2606:4700:4700::64#53

------------
    QUESTIONS:
	www.zdf.de, type = AAAA, class = IN
    ANSWERS:
    ->  www.zdf.de
	canonical name = ssl.zdf.de.edgekey.net.
	ttl = 2434
    ->  ssl.zdf.de.edgekey.net
	canonical name = e8383.e6.akamaiedge.net.
	ttl = 34
    ->  e8383.e6.akamaiedge.net
	has AAAA address 64:ff9b::687a:252c
	ttl = 8
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
Non-authoritative answer:
www.zdf.de	canonical name = ssl.zdf.de.edgekey.net.
ssl.zdf.de.edgekey.net	canonical name = e8383.e6.akamaiedge.net.
Name:	e8383.e6.akamaiedge.net
Address: 64:ff9b::687a:252c

Actual result

see above, AAAA is not synthesized.

AdGuard upstream server is Cloudflare DNS 2606:4700:4700::1111 or tls://one.one.one.one

Additional information and/or screenshots

Another sample to test ipv4.google.com or ipv4.myip.wtf

[GoetzGoerisch]

ping @ainar-g

[ainar-g]

Apologies for the delay. @EugeneOne1, please investigate.

[GoetzGoerisch]

@EugeneOne1 anything I could help with? I found many other domain with such CNAME chains e.g., status.bitwarden.com

[HaeImCH]

I'm experiencing the same problem on version v0.107.52 of AdGuard Home (Windows).

I've found that the workaround is to directly use a DNS64 server as the upstream server.

[GoetzGoerisch]

I've found that the workaround is to directly use a DNS64 server as the upstream server. This workaround only works if you want or can use the well-know prefix.

@ainar-g @EugeneOne1 any update on this?

[GoetzGoerisch]

Should I file a separate issue to dnsproxy?

[EugeneOne1]

@GoetzGoerisch, hello and apologies for late reply. This issue requires some refactoring of the DNS resolution code, which is currently in progress, see #3350. While this affects AdGuard Home, I'd say the issue is entirely on the dnsproxy side, but a separate issue isn't really necessary.

[GoetzGoerisch]

@EugeneOne1 Thank you for this update. Looking forward to getting this fixed. Therefore, please mark it as bug and not feature request, thanks.

[GoetzGoerisch]

@EugeneOne1 @ainar-g any update on this?

[thesyntaxslinger]

Just found this was happening for me today as well. How come there has been no movement on it? @GoetzGoerisch did you end up finding an alternative/fix?

I use a custom prefix so using a DNS64 upstream resolver won't work.

[GoetzGoerisch]

Yes, as a workaround I deployed an instance of unbound upstream of AdGuardHome, using the desired NAT64 prefix.

But depending on the types of client devices served, you might not need DNS64 at all and use PREF64 [RFC8981] on this subnet.

[thesyntaxslinger]

Yeah I just made an instance of unbound with dns64 enabled and it fixed the issue. But why would I run adguard home now. There is really no point of running 2 dns servers just for this.

[thesyntaxslinger]

More importantly, why is this labelled as a feature request?

[thesyntaxslinger]

@EugeneOne1 There is a setting in dnscrypt-proxy that you can turn on to enable dns64 which properly synthasizes the AAAA record.

[dns64]

## Static prefix(es) as Pref64::/n CIDRs

prefix = ['64:ff9b::/96']

## DNS64-enabled resolver(s) to discover Pref64::/n CIDRs
## These resolvers are used to query for Well-Known IPv4-only Name (WKN) "ipv4only.arpa." to discover only.
## Set with your ISP's resolvers in case of custom prefixes (other than Well-Known Prefix 64:ff9b::/96).
## IMPORTANT: Default resolvers listed below support Well-Known Prefix 64:ff9b::/96 only.

#resolver = ['[2001:db8::69]:53']

Uncommenting the "prefix" setting properly synthasizes the AAAA record, but it does introduce another weird bug that makes a packet malformed.