rDNS for IPv6 (resolv hostnames from IP-Adress)

[KGBist2000]

Hello,
in my configuration I am using Adguard home with unbound. the network setup is following:

1. Router/Gateway is an Fritz!Box with DHCP for IPv4 and IPv6
2. FritzBox is providing via DHCP the the IP for DNS-Service (Adguard Home)
3. Adguard and unbound are providing are collecting all DNS-Queries in my LAN
4. Unbound is running on the same machine as Adguard on port 5335
5. Adguard is configured for Upstream to unbound.

In Adguard in the client list I see different clients with hostname + IP. unfortunately only for IPv4 it is working well. For IPv6 clients/queries are not resolved in the list. Following I defined in the Upstream-Field on Adguard Home:

[/fritz.box/]192.168.76.1:53
[/fritz.box/]fd00::3631:c4ff:fec5:a5ae:53
[/76.168.192.in-addr.arpa/]192.168.76.1
[/0.0.0.d.f.ip6.arpa/]192.168.76.1
[/0.0.8.e.f.ip6.arpa/]192.168.76.1
127.0.0.1:5335

my internal IPv6 IPs are:
fd00: ....
fe80: ....

Is there a trick how to define the rDNS for IPv6 ?

[ameshkov]

@EugeneOne1 isn't this a known issue that we're already going to fix in v0.106.0 alongside the PTR rework?

[KGBist2000]

Hi, I hope so, but I did not found in the related issues (e.g. #2704), that IPv6 is in focus. But to have not the same clients (IPv4 and IPv6 adress) it would be good that:

1. There is a possibility forward IPv6 Queries for internal domains to the Internal DNS or DHCP server
2. That Aduard Home summarize the Client with same IPv6 and IPv4 adress to one client in the Client-Browser

[EugeneOne1]

@KGBist2000, the implied issue is #1868. But unfortunately, I have not yet investigated the connection between it and your question. It's going to be done in the nearest future.

[KGBist2000]

yes, I thing for the 1. Topic the issue #1868 is the same.
I look forward then for the next release.

[kiwilad-nz]

Was this issue resolved because I have issues with half my IPv6 (statically reserved) addresses not resolving to PTR too.
I am using v0.106.3.

[jumpsmm7]

Well I can tell you from my experience, I run a "hybrid" IPV6 where devices use both slaac and stateful if the device is capable, and ra-names are shared between IPV4 and IPV6 host freely. Adguard should be able to identify the hostnames that are shared between the two coming from ra-names with no problem. If it can't, it should be able to atleast see the MAC address associated with the IPV6 address, and still able to match the address to the device that way. DNSMASQ supports the option to add-mac and add-subnet through EDNS0 options. I imagine the devices could be matched to their respective hostnames via this method before attempting to add host names to addresses using WHOIS which is potentially leaking client information upstream.

[kiwilad-nz]

That sounds like a logical solution. I dunno what you use, but pfSense is what I use for my router solution, and it took me a while to work out a workaround but I could not get the SLAAC hostnames showing up in my resolver )maybe they were), I'ld have to double check.

[jumpsmm7]

It is worth mentioning Pihole is able to identify clients via EDNS0 information handed out by for example dnsmasq. Given this capability they are able to better match IPV6 addressing to the appropriate Clients. https://discourse.pi-hole.net/t/support-for-add-subnet-option-from-dnsmasq-ecs-edns0-client-subnet/35940 . Maybe something similar can be done with AdguardHome to mitigate the leaking of client ipv6 information upstream using WHOIS. Services like NextDNS are also able to leverage these options to better identify clients.

[bengalih]

I just wanted to add my observation to this issue as I have been trying to setup AdGuard on my network which utilizes dual-stack.
After several rounds of testing it appears that AdGuard DOES properly resolve any PTR records (IPv4 and IPv4) assuming:

1. AdGuard is properly configured to point towards DNS server which host these records
   and
2. The appropriate PTR records exist on the server for AdGuard to query. This ofc means that the in-arpa zone for the appropriate range (public or private) is created and populated with entires.

If the PTR record is found, AdGuard should display it along with the "rDNS" qualifier in the Client page showing that it was resolved over DNS.
If however it is unable to find the IPv6 PTR record it then does the WHOIS query and in most cases will not return anything from this as most users are unable to create PTR records for all their IPv6 address space (as this is in the hands of the ISP). At best you might get back a generic PTR that the ISP created.

The issues/challenges in actual usage are thus:

1. The security issue of AdGuard defaulting to sending requests out to WHOIS. On the one hand, if you are utilizing IPv6 GUA addressing on your network the idea is that all of those addresses will be used for external communications. This should seemingly only be a concern when using SLAAC and in those cases RFC 4941 privacy extensions can be utilized. This issue seems to be referenced in:
   SLAAC IPV6 addressing associated with Private reverse DNS servers not kept private when No hostname available. #3817
   I'm not entirely sure what the "leak" concern there is about, but the option to simply disable WHOIS lookups if not preferred should probably be implemented.

2. Getting PTR records populated into DNS. This can be a challenge depending on your configuration. Unless the same device if providing DHCP and DNS services for both stacks, it can be exceedingly difficult (and sometimes nigh impossible) to get all the IPv6 PTR records created for a client. This is especially true if not using stateful/static addressing. However, even with stateful addressing there is the possibility of a client generating one or more ULA which may be used in communication which has not had a PTR RR created.
   If using SLAAC, you would need to disable privacy extensions so the address is deterministic and possibly have to manually create PTR RRs for each client. However even in this case a ULA may occasionally be seen in the logs. Also, if using SLAAC without the privacy extensions we revisit point Check DNS performance with a DNS benchmark #1 above which could be considered a risk leaking this info our to WHOIS if the RR cannot be resolved locally.

[jumpsmm7]

I second @bengalih post. I agree an option should be present to disable whois for client name space resolution, or at least only allow its use for devices more than one hop away.

An example of a device that is one hop.

traceroute to 192.168.1.18 (192.168.1.18), 30 hops max, 60 byte packets
1 RPI3.Some-Network (192.168.1.18) 1.567 ms 1.391 ms 1.320 ms