DNS64/NAT64 Support in AdGuardHome?

[gtxaspec]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to request a feature or enhancement and not ask a question

Description

Hello,

Didn't see this in any documentation, or in any previously opened issues or discussions. Tested with latest AGH Edge release.

Regarding DNS64 support in AGH, I have IPv6 only clients (ex. 2001:db8:beef:4000::1), whom can access IPv4 hosts via a NAT64 jool translator (2001:db8:beef:4::/96).

Traditionally, We would use bind9 to specify a translator in named.conf.options, such as (dns64 2001:db8:beef:4::/96 { clients { !translator; dns64-good-clients; }; };

The IPv6 only clients would then be able to query the DNS server, and if presented with a DNS entry that was IPv4 ONLY, the response would be 2001:db8:beef:4:8.8.8.8 for example.

I would ideally wish to replace bind9 with AdGuardHome.

The question now is, does AdGuardHome support DNS64/NAT64? If it does, how would it be configured? If it does not, this would be a great feature to add to the existing features.

Thanks!

[jdreskell]

Following. I used the guide at https://www.jool.mx/en/dns64.html to do this setup. I'd like to use AGH instead of bind to serve my network.

[gtxaspec]

Looks like this issue has been visited on the other AdGuard products:
AdGuard IOS: AdguardTeam/AdguardForiOS#796
AdGuard Android: AdguardTeam/AdguardForAndroid#1884 (comment)
AdGuard dnsproxy: AdguardTeam/dnsproxy#40

@ameshkov @ainar-g would you be able to look into this for AGH too? =D

[ameshkov]

DNS64 is already supported by dnsproxy which AdGuard Home uses under the hood. So this task may be split in two parts: expose DNS64 prefix setting via AdGuardHome.yaml (can be done relatively quickly) and expose it via the UI (later).

[gtxaspec]

@ameshkov great to hear! I look forward to a future release sometime =D

[jdreskell]

Wonderful News! @ameshkov is there a release version this would be planned in? Cheers!

[gtxaspec]

tested latest master, working well. can't wait for this to be introduced into the UI =D

[rapdodge]

^ same
tested on v0.108.0-a.421+d52f1d0e, working great, waiting to be implemented via webui :D

Server:  alpine-agsmartdns
Address:  192.168.1.130

Non-authoritative answer:
Name:    github.com
Addresses:  64:ff9b::14cd:f3a6
          20.205.243.166

[EugeneOne1]

@gtxaspec, @jdreskell, @rapdodge, hello. We've filled the separate issue (#5460) about exposing the setting to UI. We'll close this issue for now, so please upvote and track the mentioned one.

[Srylax]

I can't get this to work when the domain returns a CNAME:

dig AAAA ipv4.google.com

; <<>> DiG 9.10.6 <<>> AAAA ipv4.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40352
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipv4.google.com.		IN	AAAA

;; ANSWER SECTION:
ipv4.google.com.	300	IN	CNAME	ipv4.l.google.com.

;; AUTHORITY SECTION:
l.google.com.		2	IN	SOA	ns1.google.com. dns-admin.google.com. 583327338 900 900 1800 60

;; Query time: 60 msec
;; SERVER: 2001:XXXX:XXXX:XXXX::2#53(2001:XXXX:XXXX:XXXX::2) 
;; WHEN: Sat Nov 18 15:29:19 CET 2023
;; MSG SIZE  rcvd: 115

here with cloudflares dns64 server:
dig @2606:4700:4700::64 AAAA ipv4.google.com

; <<>> DiG 9.10.6 <<>> @2606:4700:4700::64 AAAA ipv4.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56134
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ipv4.google.com.		IN	AAAA

;; ANSWER SECTION:
ipv4.google.com.	123	IN	CNAME	ipv4.l.google.com.
ipv4.l.google.com.	123	IN	AAAA	64:ff9b::acd9:a82e

;; Query time: 53 msec
;; SERVER: 2606:4700:4700::64#53(2606:4700:4700::64)
;; WHEN: Sat Nov 18 15:31:11 CET 2023
;; MSG SIZE  rcvd: 93

When I query ipv4.l.google.comwith dig it successfully returns the dns64 mapping but when I query ipv4.google.com via chromes net-internals it gives this response:

Resolved IP addresses of "ipv4.google.com": ["142.250.203.110"].
No alternative endpoints.

adguard query log:

15:35:56
ipv4.google.com
Type: AAAA, Plain DNS
Response:
CNAME: ipv4.l.google.com. (ttl=248)

15:35:55
ipv4.google.com
Type: A, Plain DNS
Response: 
CNAME: ipv4.l.google.com. (ttl=248)
A: 142.250.203.110 (ttl=248)

15:35:55
ipv4.google.com
Type: HTTPS, Plain DNS
Response: CNAME: ipv4.l.google.com. (ttl=7)

[Srylax]

Ok so turns out UDM is rewriting when the ad blocking feature is on: https://help.ui.com/hc/en-us/articles/9794438523799
This fucks up dns64...
With it turned off it works perfectly.
Thank you!