AdGuardHome icon indicating copy to clipboard operation
AdGuardHome copied to clipboard

DNS64/NAT64 Support in AdGuardHome?

Open gtxaspec opened this issue 2 years ago • 1 comments

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 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!

gtxaspec avatar Nov 07 '22 21:11 gtxaspec

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.

jdreskell avatar Nov 13 '22 08:11 jdreskell

Looks like this issue has been visited on the other AdGuard products: AdGuard IOS: https://github.com/AdguardTeam/AdguardForiOS/issues/796 AdGuard Android: https://github.com/AdguardTeam/AdguardForAndroid/issues/1884#issuecomment-396570435 AdGuard dnsproxy: https://github.com/AdguardTeam/dnsproxy/issues/40

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

gtxaspec avatar Dec 03 '22 07:12 gtxaspec

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).

ameshkov avatar Dec 04 '22 17:12 ameshkov

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

gtxaspec avatar Dec 08 '22 02:12 gtxaspec

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

jdreskell avatar Dec 12 '22 00:12 jdreskell

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

gtxaspec avatar Jan 25 '23 04:01 gtxaspec

^ 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

rapdodge avatar Jan 27 '23 14:01 rapdodge

@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.

EugeneOne1 avatar Feb 06 '23 14:02 EugeneOne1

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 avatar Nov 18 '23 14:11 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!

Srylax avatar Nov 19 '23 20:11 Srylax