AdGuardHome does not resolve private IP's when requested on IPv6 address of AdGuardHome

deekerman commented

2026-03-04 03:28:37 -05:00

Owner

Originally created by @Haringstad on GitHub (Jan 5, 2022).

Have a question or an idea? Please search it on our forum to make sure it was not yet asked. If you cannot find what you had in mind, please submit it here.

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

[x ] I am running the latest version
[ x] I checked the documentation and found no answer
[x ] I checked to make sure that this issue has not already been filed

Issue Details

Version of AdGuard Home server:
- AdGuard Home
  Version: v0.107.2
  Channel: release
  Go version: go1.16.12
  Build time: 2021-12-29T19:56:36Z+0000
  GOOS: linux
  GOARCH: arm64
  Race: false
  Dependencies:
  github.com/AdguardTeam/dnsproxy@v0.40.4-0.20211229192924-90569a17b881 (sum: h1:nPMyvZUn1uSa5xVPSjJpZCDkn3+kLnNR7B3XTKk9tKs=)
  github.com/AdguardTeam/golibs@v0.10.3 (sum: h1:FBgk17zf35ESVWQKIqEUiqqB2bDaCBC8X5vMU760yB4=)
  github.com/AdguardTeam/urlfilter@v0.15.1 (sum: h1:dP6S7J6eFAk8MN4IDpUq2fZoBo8K8fmc6pXpxNIv84M=)
  github.com/NYTimes/gziphandler@v1.1.1 (sum: h1:ZUDjpQae29j0ryrS0u/B8HZfJBtBQHjqw2rQ2cqUQ3I=)
  github.com/aead/chacha20@v0.0.0-20180709150244-8b13a72661da (sum: h1:KjTM2ks9d14ZYCvmHS9iAKVt9AyzRSqNU1qabPih5BY=)
  github.com/aead/poly1305@v0.0.0-20180717145839-3fee0db0b635 (sum: h1:52m0LGchQBBVqJRyYYufQuIbVqRawmubW3OFGqK1ekw=)
  github.com/ameshkov/dnscrypt/v2@v2.2.3 (sum: h1:X9UP5AHtwp46Ji+sGFfF/1Is6OPI/SjxLqhKpx0P5UI=)
  github.com/ameshkov/dnsstamps@v1.0.3 (sum: h1:Srzik+J9mivH1alRACTbys2xOxs0lRH9qnTA7Y1OYVo=)
  github.com/beefsack/go-rate@v0.0.0-20200827232406-6cde80facd47 (sum: h1:M57m0xQqZIhx7CEJgeLSvRFKEK1RjzRuIXiA3HfYU7g=)
  github.com/cheekybits/genny@v1.0.0 (sum: h1:uGGa4nei+j20rOSeDeP5Of12XVm7TGUd4dJA9RDitfE=)
  github.com/digineo/go-ipset/v2@v2.2.1 (sum: h1:k6skY+0fMqeUjjeWO/m5OuWPSZUAn7AucHMnQ1MX77g=)
  github.com/fsnotify/fsnotify@v1.5.1 (sum: h1:mZcQUHVQUQWoPXXtuf9yuEXKudkV2sx1E06UadKWpgI=)
  github.com/go-ping/ping@v0.0.0-20210506233800-ff8be3320020 (sum: h1:mdi6AbCEoKCA1xKCmp7UtRB5fvGFlP92PvlhxgdvXEw=)
  github.com/google/go-cmp@v0.5.5 (sum: h1:Khx7svrCpmxxtHBq5j2mp/xVjsi8hQMfNLvJFAlrGgU=)
  github.com/google/gopacket@v1.1.19 (sum: h1:ves8RnFZPGiFnTS0uPQStjwru6uO6h+nlr9j6fL7kF8=)
  github.com/google/renameio@v1.0.1 (sum: h1:Lh/jXZmvZxb0BBeSY5VKEfidcbcbenKjZFzM/q0fSeU=)
  github.com/insomniacslk/dhcp@v0.0.0-20210310193751-cfd4d47082c2 (sum: h1:NpTIlXznCStsY88jU+Gh1Dy5dt/jYV4z4uU8h2TUOt4=)
  github.com/josharian/native@v0.0.0-20200817173448-b6b71def0850 (sum: h1:uhL5Gw7BINiiPAo24A2sxkcDI0Jt/sqp1v5xQCniEFA=)
  github.com/kardianos/service@v1.2.0 (sum: h1:bGuZ/epo3vrt8IPC7mnKQolqFeYJb7Cs8Rk4PSOBB/g=)
  github.com/lucas-clemente/quic-go@v0.24.0 (sum: h1:ToR7SIIEdrgOhgVTHvPgdVRJfgVy+N0wQAagH7L4d5g=)
  github.com/marten-seemann/qtls-go1-16@v0.1.4 (sum: h1:xbHbOGGhrenVtII6Co8akhLEdrawwB2iHl5yhJRpnco=)
  github.com/mdlayher/ethernet@v0.0.0-20190606142754-0394541c37b7 (sum: h1:lez6TS6aAau+8wXUP3G9I3TGlmPFEq2CTxBaRqY6AGE=)
  github.com/mdlayher/netlink@v1.4.0 (sum: h1:n3ARR+Fm0dDv37dj5wSWZXDKcy+U0zwcXS3zKMnSiT0=)
  github.com/mdlayher/raw@v0.0.0-20210412142147-51b895745faf (sum: h1:InctQoB89TIkmgIFQeIL4KXNvWc1iebQXdZggqPSwL8=)
  github.com/miekg/dns@v1.1.45 (sum: h1:g5fRIhm9nx7g8osrAvgb16QJfmyMsyOCb+J7LSv+Qzk=)
  github.com/patrickmn/go-cache@v2.1.0+incompatible (sum: h1:HRMgzkcYKYpi3C8ajMPV8OFXaaRUnok+kx1WdO15EQc=)
  github.com/pkg/errors@v0.9.1 (sum: h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=)
  github.com/satori/go.uuid@v1.2.0 (sum: h1:0uYX9dsZ2yD7q2RtLRtPSdGDWzjeM3TbMJP9utgA0ww=)
  github.com/ti-mo/netfilter@v0.4.0 (sum: h1:rTN1nBYULDmMfDeBHZpKuNKX/bWEXQUhe02a/10orzg=)
  github.com/u-root/u-root@v7.0.0+incompatible (sum: h1:u+KSS04pSxJGI5E7WE4Bs9+Zd75QjFv+REkjy/aoAc8=)
  go.etcd.io/bbolt@v1.3.6 (sum: h1:/ecaJf0sk1l4l6V4awd65v2C3ILy7MSj+s/x1ADCIMU=)
  golang.org/x/crypto@v0.0.0-20211215153901-e495a2d5b3d3 (sum: h1:0es+/5331RGQPcXlMfP+WrnIIS6dNnNRe0WB02W0F4M=)
  golang.org/x/net@v0.0.0-20211216030914-fe4d6282115f (sum: h1:hEYJvxw1lSnWIl8X9ofsYMklzaDs90JI2az5YMd4fPM=)
  golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c (sum: h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=)
  golang.org/x/sys@v0.0.0-20211216021012-1d35b9e2eb4e (sum: h1:fLOSk5Q00efkSvAm+4xcoXD+RRmLmmulPn5I3Y9F2EM=)
  golang.org/x/text@v0.3.7 (sum: h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=)
  gopkg.in/natefinch/lumberjack.v2@v2.0.0 (sum: h1:1Lc07Kr7qY4U2YPouBjpCLxpiyxIVoxqXgkXLknAOE8=)
  gopkg.in/yaml.v2@v2.4.0 (sum: h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY=)
  howett.net/plist@v0.0.0-20201203080718-1454fab16a06 (sum: h1:QDxUo/w2COstK1wIBYpzQlHX/NqaQTcf9jyz347nI58=)
How did you install AdGuard Home:
- Github Installer Script
How did you setup DNS configuration:
- IoT
If it's a router or IoT, please write device model:
- Raspberry Pi 4
CPU architecture:
- ARM64
Operating system and version:
- Raspbian

Expected Behavior

Resolving private IPv4 addresses when requesting them at the IPv6 address of AdGuardHome

Actual Behavior

Whenever I request: host 192.168.12.1 172.16.12.20, I do get an answer.
Whenever I request: host 192.168.12.1 2001:1c04:3c32:c102::11a, I do not get an answer:

host 192.168.12.22 2001:1c04:3c32:c102::11a
Using domain server:
Name: 2001:1c04:3c32:c102::11a
Address: 2001:1c04:3c32:c102::11a#53
Aliases:

Host 22.12.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

host 192.168.12.22 172.16.12.201
Using domain server:
Name: 172.16.12.201
Address: 172.16.12.201#53
Aliases:

22.12.168.192.in-addr.arpa domain name pointer orange-pi-desktop.delaars12.loc.

host www.pindakaas.nl 2001:1c04:3c32:c102::11a
Using domain server:
Name: 2001:1c04:3c32:c102::11a
Address: 2001:1c04:3c32:c102::11a#53
Aliases:

www.pindakaas.nl has address 167.99.193.205
www.pindakaas.nl has address 109.235.74.225
www.pindakaas.nl has IPv6 address 2a03:b0c0:1:e0::445:9001
www.pindakaas.nl has IPv6 address 2a01:518:1:41:2::53

Originally created by @Haringstad on GitHub (Jan 5, 2022). Have a question or an idea? Please search it [on our forum](https://github.com/AdguardTeam/AdGuardHome/discussions) to make sure it was not yet asked. If you cannot find what you had in mind, please [submit it here](https://github.com/AdguardTeam/AdGuardHome/discussions/new). ### Prerequisites Please answer the following questions for yourself before submitting an issue. **YOU MAY DELETE THE PREREQUISITES SECTION.** - [x ] I am running the latest version - [ x] I checked the documentation and found no answer - [x ] I checked to make sure that this issue has not already been filed ### Issue Details * **Version of AdGuard Home server:** * AdGuard Home Version: v0.107.2 Channel: release Go version: go1.16.12 Build time: 2021-12-29T19:56:36Z+0000 GOOS: linux GOARCH: arm64 Race: false Dependencies: github.com/AdguardTeam/dnsproxy@v0.40.4-0.20211229192924-90569a17b881 (sum: h1:nPMyvZUn1uSa5xVPSjJpZCDkn3+kLnNR7B3XTKk9tKs=) github.com/AdguardTeam/golibs@v0.10.3 (sum: h1:FBgk17zf35ESVWQKIqEUiqqB2bDaCBC8X5vMU760yB4=) github.com/AdguardTeam/urlfilter@v0.15.1 (sum: h1:dP6S7J6eFAk8MN4IDpUq2fZoBo8K8fmc6pXpxNIv84M=) github.com/NYTimes/gziphandler@v1.1.1 (sum: h1:ZUDjpQae29j0ryrS0u/B8HZfJBtBQHjqw2rQ2cqUQ3I=) github.com/aead/chacha20@v0.0.0-20180709150244-8b13a72661da (sum: h1:KjTM2ks9d14ZYCvmHS9iAKVt9AyzRSqNU1qabPih5BY=) github.com/aead/poly1305@v0.0.0-20180717145839-3fee0db0b635 (sum: h1:52m0LGchQBBVqJRyYYufQuIbVqRawmubW3OFGqK1ekw=) github.com/ameshkov/dnscrypt/v2@v2.2.3 (sum: h1:X9UP5AHtwp46Ji+sGFfF/1Is6OPI/SjxLqhKpx0P5UI=) github.com/ameshkov/dnsstamps@v1.0.3 (sum: h1:Srzik+J9mivH1alRACTbys2xOxs0lRH9qnTA7Y1OYVo=) github.com/beefsack/go-rate@v0.0.0-20200827232406-6cde80facd47 (sum: h1:M57m0xQqZIhx7CEJgeLSvRFKEK1RjzRuIXiA3HfYU7g=) github.com/cheekybits/genny@v1.0.0 (sum: h1:uGGa4nei+j20rOSeDeP5Of12XVm7TGUd4dJA9RDitfE=) github.com/digineo/go-ipset/v2@v2.2.1 (sum: h1:k6skY+0fMqeUjjeWO/m5OuWPSZUAn7AucHMnQ1MX77g=) github.com/fsnotify/fsnotify@v1.5.1 (sum: h1:mZcQUHVQUQWoPXXtuf9yuEXKudkV2sx1E06UadKWpgI=) github.com/go-ping/ping@v0.0.0-20210506233800-ff8be3320020 (sum: h1:mdi6AbCEoKCA1xKCmp7UtRB5fvGFlP92PvlhxgdvXEw=) github.com/google/go-cmp@v0.5.5 (sum: h1:Khx7svrCpmxxtHBq5j2mp/xVjsi8hQMfNLvJFAlrGgU=) github.com/google/gopacket@v1.1.19 (sum: h1:ves8RnFZPGiFnTS0uPQStjwru6uO6h+nlr9j6fL7kF8=) github.com/google/renameio@v1.0.1 (sum: h1:Lh/jXZmvZxb0BBeSY5VKEfidcbcbenKjZFzM/q0fSeU=) github.com/insomniacslk/dhcp@v0.0.0-20210310193751-cfd4d47082c2 (sum: h1:NpTIlXznCStsY88jU+Gh1Dy5dt/jYV4z4uU8h2TUOt4=) github.com/josharian/native@v0.0.0-20200817173448-b6b71def0850 (sum: h1:uhL5Gw7BINiiPAo24A2sxkcDI0Jt/sqp1v5xQCniEFA=) github.com/kardianos/service@v1.2.0 (sum: h1:bGuZ/epo3vrt8IPC7mnKQolqFeYJb7Cs8Rk4PSOBB/g=) github.com/lucas-clemente/quic-go@v0.24.0 (sum: h1:ToR7SIIEdrgOhgVTHvPgdVRJfgVy+N0wQAagH7L4d5g=) github.com/marten-seemann/qtls-go1-16@v0.1.4 (sum: h1:xbHbOGGhrenVtII6Co8akhLEdrawwB2iHl5yhJRpnco=) github.com/mdlayher/ethernet@v0.0.0-20190606142754-0394541c37b7 (sum: h1:lez6TS6aAau+8wXUP3G9I3TGlmPFEq2CTxBaRqY6AGE=) github.com/mdlayher/netlink@v1.4.0 (sum: h1:n3ARR+Fm0dDv37dj5wSWZXDKcy+U0zwcXS3zKMnSiT0=) github.com/mdlayher/raw@v0.0.0-20210412142147-51b895745faf (sum: h1:InctQoB89TIkmgIFQeIL4KXNvWc1iebQXdZggqPSwL8=) github.com/miekg/dns@v1.1.45 (sum: h1:g5fRIhm9nx7g8osrAvgb16QJfmyMsyOCb+J7LSv+Qzk=) github.com/patrickmn/go-cache@v2.1.0+incompatible (sum: h1:HRMgzkcYKYpi3C8ajMPV8OFXaaRUnok+kx1WdO15EQc=) github.com/pkg/errors@v0.9.1 (sum: h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=) github.com/satori/go.uuid@v1.2.0 (sum: h1:0uYX9dsZ2yD7q2RtLRtPSdGDWzjeM3TbMJP9utgA0ww=) github.com/ti-mo/netfilter@v0.4.0 (sum: h1:rTN1nBYULDmMfDeBHZpKuNKX/bWEXQUhe02a/10orzg=) github.com/u-root/u-root@v7.0.0+incompatible (sum: h1:u+KSS04pSxJGI5E7WE4Bs9+Zd75QjFv+REkjy/aoAc8=) go.etcd.io/bbolt@v1.3.6 (sum: h1:/ecaJf0sk1l4l6V4awd65v2C3ILy7MSj+s/x1ADCIMU=) golang.org/x/crypto@v0.0.0-20211215153901-e495a2d5b3d3 (sum: h1:0es+/5331RGQPcXlMfP+WrnIIS6dNnNRe0WB02W0F4M=) golang.org/x/net@v0.0.0-20211216030914-fe4d6282115f (sum: h1:hEYJvxw1lSnWIl8X9ofsYMklzaDs90JI2az5YMd4fPM=) golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c (sum: h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=) golang.org/x/sys@v0.0.0-20211216021012-1d35b9e2eb4e (sum: h1:fLOSk5Q00efkSvAm+4xcoXD+RRmLmmulPn5I3Y9F2EM=) golang.org/x/text@v0.3.7 (sum: h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=) gopkg.in/natefinch/lumberjack.v2@v2.0.0 (sum: h1:1Lc07Kr7qY4U2YPouBjpCLxpiyxIVoxqXgkXLknAOE8=) gopkg.in/yaml.v2@v2.4.0 (sum: h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY=) howett.net/plist@v0.0.0-20201203080718-1454fab16a06 (sum: h1:QDxUo/w2COstK1wIBYpzQlHX/NqaQTcf9jyz347nI58=) * **How did you install AdGuard Home:** * Github Installer Script * **How did you setup DNS configuration:** * IoT * **If it's a router or IoT, please write device model:** * Raspberry Pi 4 * **CPU architecture:** * ARM64 * **Operating system and version:** * Raspbian ### Expected Behavior Resolving private IPv4 addresses when requesting them at the IPv6 address of AdGuardHome ### Actual Behavior Whenever I request: host 192.168.12.1 172.16.12.20, I do get an answer. Whenever I request: host 192.168.12.1 2001:1c04:3c32:c102::11a, I do not get an answer: host 192.168.12.22 2001:1c04:3c32:c102::11a Using domain server: Name: 2001:1c04:3c32:c102::11a Address: 2001:1c04:3c32:c102::11a#53 Aliases: Host 22.12.168.192.in-addr.arpa. not found: 3(NXDOMAIN) host 192.168.12.22 172.16.12.201 Using domain server: Name: 172.16.12.201 Address: 172.16.12.201#53 Aliases: 22.12.168.192.in-addr.arpa domain name pointer orange-pi-desktop.delaars12.loc. host www.pindakaas.nl 2001:1c04:3c32:c102::11a Using domain server: Name: 2001:1c04:3c32:c102::11a Address: 2001:1c04:3c32:c102::11a#53 Aliases: www.pindakaas.nl has address 167.99.193.205 www.pindakaas.nl has address 109.235.74.225 www.pindakaas.nl has IPv6 address 2a03:b0c0:1:e0::445:9001 www.pindakaas.nl has IPv6 address 2a01:518:1:41:2::53

deekerman

2026-03-04 03:28:37 -05:00

closed this issue
added the
question
label

deekerman commented

2026-03-04 03:28:48 -05:00

Author

Owner

@jumpsmm7 commented on GitHub (Jan 5, 2022):

There are plenty of instances where this has been noted. Ipv6 works if you are using DHCP, but if you are using for DNS only you need a corresponding reverse arpa inside the
Private reverse DNS servers The DNS servers that AdGuard Home uses for local PTR queries. These servers are used to resolve the hostnames of clients with private IP addresses, for example "192.168.12.34", using reverse DNS. If not set, AdGuard Home uses the addresses of the default DNS resolvers of your OS except for the addresses of AdGuard Home itself.
It should be noted that slaac addresses cannot be identified via this means, only a stateful address with correct hostname extensions.

@jumpsmm7 commented on GitHub (Jan 5, 2022): There are plenty of instances where this has been noted. Ipv6 works if you are using DHCP, but if you are using for DNS only you need a corresponding reverse arpa inside the `Private reverse DNS servers The DNS servers that AdGuard Home uses for local PTR queries. These servers are used to resolve the hostnames of clients with private IP addresses, for example "192.168.12.34", using reverse DNS. If not set, AdGuard Home uses the addresses of the default DNS resolvers of your OS except for the addresses of AdGuard Home itself.` It should be noted that slaac addresses cannot be identified via this means, only a stateful address with correct hostname extensions.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@Haringstad commented on GitHub (Jan 6, 2022):

As you can see here those are specified:

And also specified the Private reverse DNS servers:

Hence my bug report. And when I resolve at the aforementioned servers, it
resolves fine.

@Haringstad commented on GitHub (Jan 6, 2022): As you can see here those are specified: ![image](https://user-images.githubusercontent.com/7832166/148384337-3fc031c8-d276-412e-823b-60bb62c1828f.png) And also specified the Private reverse DNS servers: ![image](https://user-images.githubusercontent.com/7832166/148384372-b233fdd3-2d09-43c7-b5c8-b96ac5980fdc.png) Hence my bug report. And when I resolve at the aforementioned servers, it resolves fine.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@Haringstad commented on GitHub (Jan 6, 2022):

There are plenty of instances where this has been noted. Ipv6 works if you are using DHCP, but if you are using for DNS only you need a corresponding reverse arpa inside the Private reverse DNS servers The DNS servers that AdGuard Home uses for local PTR queries. These servers are used to resolve the hostnames of clients with private IP addresses, for example "192.168.12.34", using reverse DNS. If not set, AdGuard Home uses the addresses of the default DNS resolvers of your OS except for the addresses of AdGuard Home itself. It should be noted that slaac addresses cannot be identified via this means, only a stateful address with correct hostname extensions.

What I addressed is: coming from an IPv6 host, resolving against the IPv6 address of AdGuardHome, requesting the IPv4 address of a machine, I get the already posted result. So I am not trying to resolve a slaac address. I am trying to get the IPv4 address (private one) while my host that is requesting, is talking with AdGuardHome over IPv6.

@Haringstad commented on GitHub (Jan 6, 2022): > There are plenty of instances where this has been noted. Ipv6 works if you are using DHCP, but if you are using for DNS only you need a corresponding reverse arpa inside the `Private reverse DNS servers The DNS servers that AdGuard Home uses for local PTR queries. These servers are used to resolve the hostnames of clients with private IP addresses, for example "192.168.12.34", using reverse DNS. If not set, AdGuard Home uses the addresses of the default DNS resolvers of your OS except for the addresses of AdGuard Home itself.` It should be noted that slaac addresses cannot be identified via this means, only a stateful address with correct hostname extensions. What I addressed is: coming from an IPv6 host, resolving against the IPv6 address of AdGuardHome, requesting the IPv4 address of a machine, I get the already posted result. So I am not trying to resolve a slaac address. I am trying to get the IPv4 address (private one) while my host that is requesting, is talking with AdGuardHome over IPv6.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@tuxnet commented on GitHub (Jan 6, 2022):

IPv6 addresses cannot be marked as "private"....
Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them)

@tuxnet commented on GitHub (Jan 6, 2022): IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them)

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@jumpsmm7 commented on GitHub (Jan 6, 2022):

IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them)

However some form of acknowledgement should be made so that when I define something like [/some.ipv6.prefix.ip6.arpa/] inside the private DNS section, adguard home should know that anything with resembling (or within) that ptr should not be resolved to the upstream and should be left as private. I am not worried about trying to resolve those addresses, but I don't want them to be resolved by the upstream either.

@jumpsmm7 commented on GitHub (Jan 6, 2022): > IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them) However some form of acknowledgement should be made so that when I define something like [/some.ipv6.prefix.ip6.arpa/] inside the private DNS section, adguard home should know that anything with resembling (or within) that ptr should not be resolved to the upstream and should be left as private. I am not worried about trying to resolve those addresses, but I don't want them to be resolved by the upstream either.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@jumpsmm7 commented on GitHub (Jan 6, 2022):

IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them)

It should be able distinguish if I tell it what is private. So if I say [/some.ipv6.prefix.ip6.arpa/] in the private section, it should know anything within that ptr is private.

@jumpsmm7 commented on GitHub (Jan 6, 2022): > IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them) It should be able distinguish if I tell it what is private. So if I say [/some.ipv6.prefix.ip6.arpa/] in the private section, it should know anything within that ptr is private.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@tuxnet commented on GitHub (Jan 7, 2022):

It should be able distinguish if I tell it what is private. So if I say [/some.ipv6.prefix.ip6.arpa/] in the private section, it should know anything within that ptr is private.

yes, i would also find it good if it were possible to configure that...

@tuxnet commented on GitHub (Jan 7, 2022): > It should be able distinguish if I tell it what is private. So if I say [/some.ipv6.prefix.ip6.arpa/] in the private section, it should know anything within that ptr is private. yes, i would also find it good if it were possible to configure that...

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@Haringstad commented on GitHub (Jan 10, 2022):

IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them)

Hm, this is weird. First of all, whenever you request an IP from a resolver, and that resolver knows where to "find" the answer for that IPv4 address, it just should answer.

In my configuration, it shows that I point correctly to the DNS server(s) for the private information. Therefore, if the

[/168.192.in-addr.arpa/]192.168.12.6
[/168.192.in-addr.arpa/]2001:1c04:3c32:c103::59f

lines are not respected by the resolving part, (like DNSMASQ certainly does) than there is something wrong.

So, it does not matter if the IPv6 address is "private", or "public". The resolver gets a request to resolve an 168.192.in-addr.arpa address, and due to configuration, it should provide that answer.

Unlike assumptions made above, that it cannot be done.

@Haringstad commented on GitHub (Jan 10, 2022): > IPv6 addresses cannot be marked as "private".... Therefore, IPv4 PTRs cannot be resolved via IPv6. (AdGuardHome treats them like normal public IP addresses because it cannot distinguish between them) Hm, this is weird. First of all, whenever you request an IP from a resolver, and that resolver knows where to "find" the answer for that IPv4 address, it just should answer. In my configuration, it shows that I point correctly to the DNS server(s) for the private information. Therefore, if the `[/168.192.in-addr.arpa/]192.168.12.6` `[/168.192.in-addr.arpa/]2001:1c04:3c32:c103::59f` lines are not respected by the resolving part, (like DNSMASQ certainly does) than there is something wrong. So, it does not matter if the IPv6 address is "private", or "public". The resolver gets a request to resolve an `168.192.in-addr.arpa` address, and due to configuration, it should provide that answer. Unlike assumptions made above, that it cannot be done.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@tuxnet commented on GitHub (Jan 10, 2022):

Here is an example:
AdGuardHome IP: 2001:xx:yy:5::1, 10.10.5.1
Upstream DNS servers: tls://dns.quad9.net
Private reverse DNS servers: [/10.10.in-addr.arpa/]10.10.5.11:5353

NOTE: All upstreams for private ranges must go to the “Private reverse DNS servers” field and not the main “Upstream DNS servers” field. Entering something like [/192.in-addr.arpa/]192.168.8.8 into the main field will have no effect.

user@cli-02 ~ % nslookup
> server 2001:xx:yy:5::1
Default server: 2001:xx:yy:5::1
Address: 2001:xx:yy:5::1#53
> 10.10.11.1
Server:		2001:xx:yy:5::1
Address:	2001:xx:yy:5::1#53

** server can't find 1.11.10.10.in-addr.arpa: NXDOMAIN
> server 10.10.5.1
Default server: 10.10.5.1
Address: 10.10.5.1#53
> 10.10.11.1
Server:		10.10.5.1
Address:	10.10.5.1#53

1.11.10.10.in-addr.arpa	name = test-dns-1.example.com.

AdGuard Home does not process the requests coming from the IPv6 2001::x range.

However, if I log on to the AdGuard Home server and enter ::1 as the server, it works.

[user@dns-01 ~]$ nslookup
> server ::1
Default server: ::1
Address: ::1#53
> 10.10.11.1
1.11.10.10.in-addr.arpa	name = test-dns-1.example.com.

If I have time, I will test with an address from the fc00::/7 range.

@tuxnet commented on GitHub (Jan 10, 2022): Here is an example: AdGuardHome IP: 2001:xx:yy:5::1, 10.10.5.1 Upstream DNS servers: tls://dns.quad9.net [Private reverse DNS servers:](https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#upstreams-for-rdns) [/10.10.in-addr.arpa/]10.10.5.11:5353 > NOTE: All upstreams for private ranges must go to the “Private reverse DNS servers” field and not the main “Upstream DNS servers” field. Entering something like [/192.in-addr.arpa/]192.168.8.8 into the main field will have no effect. ``` user@cli-02 ~ % nslookup > server 2001:xx:yy:5::1 Default server: 2001:xx:yy:5::1 Address: 2001:xx:yy:5::1#53 > 10.10.11.1 Server: 2001:xx:yy:5::1 Address: 2001:xx:yy:5::1#53 ** server can't find 1.11.10.10.in-addr.arpa: NXDOMAIN > server 10.10.5.1 Default server: 10.10.5.1 Address: 10.10.5.1#53 > 10.10.11.1 Server: 10.10.5.1 Address: 10.10.5.1#53 1.11.10.10.in-addr.arpa name = test-dns-1.example.com. ``` AdGuard Home does not process the requests coming from the IPv6 2001::x range. However, if I log on to the AdGuard Home server and enter ::1 as the server, it works. ``` [user@dns-01 ~]$ nslookup > server ::1 Default server: ::1 Address: ::1#53 > 10.10.11.1 1.11.10.10.in-addr.arpa name = test-dns-1.example.com. ``` If I have time, I will test with an address from the fc00::/7 range.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@EugeneOne1 commented on GitHub (Jan 13, 2022):

@Haringstad, as tuxnet correctly noted, the IPv6 address of the request's source most probably considered non-local by AdGuard Home. The wiki page section tuxnet pointed refers to the RFC 6303, which specifies all the registries of addresses that are considered locally-served for AGH (both IPv4 and IPv6). Requests from only these address ranges for other locally-served addresses are responded due to privacy reasons, see #2704. We also have a feature request for an ability to specify these ranges manually (#3142).

Note also that basic upstream servers specified for these private ranges (first screenshot from that comment) are ignored so you can safely remove those.

I'll close the issue for now. Please feel free to reopen it if anything remains unclear.

@EugeneOne1 commented on GitHub (Jan 13, 2022): @Haringstad, as **tuxnet** correctly noted, the IPv6 address of the request's source most probably considered non-local by AdGuard Home. The [wiki page section](https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#upstreams-for-rdns) **tuxnet** pointed refers to the [RFC 6303](https://datatracker.ietf.org/doc/html/rfc6303), which specifies all the registries of addresses that are considered locally-served for AGH (both IPv4 and IPv6). Requests **from** only these address ranges for other locally-served addresses are responded due to privacy reasons, see #2704. We also have a feature request for an ability to specify these ranges manually (#3142). Note also that basic upstream servers specified for these private ranges (first screenshot from [that](https://github.com/AdguardTeam/AdGuardHome/issues/4089#issuecomment-1006555032) comment) are ignored so you can safely remove those. I'll close the issue for now. Please feel free to reopen it if anything remains unclear.

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@scyto commented on GitHub (Oct 28, 2024):

Am I supposed to add here if I assert this is still a bug, or open a new issue?

@scyto commented on GitHub (Oct 28, 2024): Am I supposed to add here if I assert this is still a bug, or open a new issue?

deekerman commented

2026-03-04 03:28:49 -05:00

Author

Owner

@fuomag9 commented on GitHub (Feb 5, 2025):

I believe this is a bug

dig -x 192.168.5.52 @ipv4 works
dig -x 192.168.5.52 @ipv6 does not work

@fuomag9 commented on GitHub (Feb 5, 2025): I believe this is a bug ``` dig -x 192.168.5.52 @ipv4 works dig -x 192.168.5.52 @ipv6 does not work ```

Rows
Columns

AdGuardHome does not resolve private IP's when requested on IPv6 address of AdGuardHome #3353

Prerequisites

Issue Details

Expected Behavior

Actual Behavior