DNS64 not always generate synthetic IPv6 addresses for IPv4-only destinations

[L2jLiga]

Hello, thanks for your great software!
I'm using AdGuardHome latest release (v0.107.57 as of now) and as far as I know it uses dnsproxy under the hood, so creating issue here

What I have:

• Setup NAT64 with Jool, prefix is fd02:21:64::/96
• Setup AdGuardHome with DNS64 and added my prefix
• Set DHCP option 108
• Added prefix to PREF64 ND

Description of issue:

so my Android phone now using IPv6-only, but unfortunately some applications does not work. Digging a bit I found that synthetic IPv6 does not generates, I guess it could be related to having some CNAME records in response, but not sure.

Attaching powershell commands I used to test + wireshark pcap

Expected result:

• got synthetic IPv6 for ru-mum.m.alibaba.com like fd02:21:64::2ff6:88b9

Actual result:

• got only CNAME for AAAA query and CNAME + IPv4 for A query

Current workaround:

Currently I have to disable DHCP option 108 to get IPv4 address as well

Additional info:

pcap file: AdGuardHome-DNS64.zip

(GitHub does not allow attach pcap directly, so compressed to zip)

PowerShell terminal

┏[ 91395 from  miniNB][ 0.434s][admin@kubernetes]
┖[~]
└─Δ Resolve-DnsName ru-mum.m.alibaba.com -Type A

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
ru-mum.m.alibaba.com           CNAME  43    Answer     ru-mum.m.alibaba.com.gds.alibabadns.com
ru-mum.m.alibaba.com.gds.aliba CNAME  43    Answer     default.ovs.us.wagbridge.ae.alibabacorp.com
badns.com
default.ovs.us.wagbridge.ae.al CNAME  43    Answer     default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com
ibabacorp.com

Name       : default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com
QueryType  : A
TTL        : 47
Section    : Answer
IP4Address : 47.246.136.185


┏[ 91395 from  miniNB][ 0.106s][admin@kubernetes]
┖[~]
└─Δ Resolve-DnsName ru-mum.m.alibaba.com -Type AAAA

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
ru-mum.m.alibaba.com           CNAME  117   Answer     ru-mum.m.alibaba.com.gds.alibabadns.com
ru-mum.m.alibaba.com.gds.aliba CNAME  117   Answer     default.ovs.us.wagbridge.ae.alibabacorp.com
badns.com
default.ovs.us.wagbridge.ae.al CNAME  117   Answer     default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com
ibabacorp.com

Name                   : gds.alibabadns.com
QueryType              : SOA
TTL                    : 241
Section                : Authority
NameAdministrator      : none
SerialNumber           : 2018122017
TimeToZoneRefresh      : 1800
TimeToZoneFailureRetry : 600
TimeToExpiration       : 3600
DefaultTTL             : 360


┏[ 91395 from  miniNB][ 0.054s][admin@kubernetes]
┖[~]
└─Δ Resolve-DnsName default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com -Type A

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
default.ovs.us.wagbridge.ae.alibabacorp.com.gd A      106   Answer     47.246.137.66
s.alibabadns.com

┏[ 91395 from  miniNB][ 0.085s][admin@kubernetes]
┖[~]
└─Δ Resolve-DnsName default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com -Type AAAA

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
default.ovs.us.wagbridge.ae.alibabacorp.com.gd AAAA   104   Answer     fd02:21:64::2ff6:8942
s.alibabadns.com

┏[ 91395 from  miniNB][ 0.062s][admin@kubernetes]
┖[~]
└─Δ Resolve-DnsName github.com -Type A

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
github.com                                     A      23    Answer     140.82.121.4

┏[ 91395 from  miniNB][ 0.036s][admin@kubernetes]
┖[~]
└─Δ Resolve-DnsName github.com -Type AAAA

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
github.com                                     AAAA   22    Answer     fd02:21:64::8c52:7904

[L2jLiga]

For example, when I doing same request via Google DNS64 it returns IPv6 with well-defined prefix, so I expect to receive it from dnsproxy as well

PowerShell terminal

└─Δ Resolve-DnsName ru-mum.m.alibaba.com -Type AAAA -Server 2001:4860:4860::64

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
ru-mum.m.alibaba.com           CNAME  120   Answer     ru-mum.m.alibaba.com.gds.alibabadns.com
ru-mum.m.alibaba.com.gds.aliba CNAME  120   Answer     default.ovs.us.wagbridge.ae.alibabacorp.com
badns.com
default.ovs.us.wagbridge.ae.al CNAME  120   Answer     default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com
ibabacorp.com

Name       : default.ovs.us.wagbridge.ae.alibabacorp.com.gds.alibabadns.com
QueryType  : AAAA
TTL        : 120
Section    : Answer
IP6Address : 64:ff9b::2ff6:8942

[L2jLiga]

Found related issue: AdguardTeam/AdGuardHome#7514

[L2jLiga]

I guess something goes wrong here:

dnsproxy/proxy/dns64.go

Lines 130 to 138 in 1177916

	case *dns.CNAME, *dns.DNAME:
	// If the response contains a CNAME or a DNAME, then the CNAME or
	// DNAME chain is followed until the first terminating A or AAAA
	// record is reached.
	//
	// Just treat CNAME and DNAME responses as passable answers since
	// AdGuard Home doesn't follow any of these chains except the
	// dnsrewrite-defined ones.
	filtered, hasAnswers = append(filtered, ans), true

This code is called here:

dnsproxy/proxy/dns64.go

Lines 95 to 98 in 1177916

	var hasAnswers bool
	if resp.Answer, hasAnswers = p.filterNAT64Answers(resp.Answer); hasAnswers {
	return nil
	}

So in case if DNS response contains any CNAME it returns nil, after that it handled here:

dnsproxy/proxy/dns64.go

Lines 292 to 295 in 1177916

	dns64Req := p.checkDNS64(origReq, origResp)
	if dns64Req == nil {
	return nil
	}

which also returns nil and DNS64 request doesn't happen at all, this leads to returning just CNAME records while for IPv4 there's also A type records

[L2jLiga]

Looks like this block is incorrect, it should not set "hasAnswer" variable, because answer can be only when AAAA received.
According to RFC 6147:

If the response contains a CNAME or a DNAME, then the CNAME or DNAME
chain is followed until the first terminating A or AAAA record is
reached.

At the moment when performDNS64 called we already followed chain and there's no IPv6 address - hence we have to query for A records to obtain IPv4 and synthesize IPv6, am I missing something?