Hostname resolution and IPv6

FAQs Community How-to's
1

A while ago I decided to adopt IPv6 (next to IPv4) for my local network, which consist of a DSL modem (bridge), gateway/router annex Wi-Fi Access Point (running dd-wrt) and a dedicated Pi-hole (NanoPi NEO2). My pi-hole originally acted as DHCP server in order to have the hostnames displayed in the query log without the need for 'conditionally forwarding' those requests to my gateway (which in fact acted as DHCP server on the LAN side pre Pi-hole).

However to enable IPv6 on the internet I had to activate RA (Router Advertisements) on my dd-wrt router. Activating 'Enable IPv6 support (SLAAC + RA)' (which in fact is more than SLAAC+RA, namely with the addition of dnsmasq's stateless DHCPv6 providing dns-server information) on the DHCP settings did introduce some 'problems':

  • IPv6 hosts soliciting receive two responses, i.e. one from the real gateway (router) and one from Pi-hole (no acting as a gateway), a result every hosts assigns itself two global IPv6 addresses;
  • Pi-hole hostname resolution became a mess, i.e. not resolving the IPv6 addresses generated triggered by the router's advertisements.

In order to overcome these issues I have changed my configuration back to having my gateway/router do DHCP and internal DNS (hostname lookup) by means of dsnmasq. However to enable IPv6 DNS resolution (since Pi-hole runs on a different machine and IPv6 RA does not sent specific DNS-server info) I have added additional options to dd-wrt's dnsmasq (see below). I de-activated radvd on dd-wrt since dnnmasq handles the router advertisements. After enabling "Use Conditional Forwarding" on my Pi-hole everything now works fine with IPv6 (and IPv4).

(/tmp/dnsmasq.conf on dd-wrt, lines until 'additional options' are generated by dd-wrt, dependent on the options activated in dd-wrt UI, additional options are entered manually in UI)
interface=br0
resolv-file=/tmp/resolv.dnsmasq
domain=local
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-lease-max=48
dhcp-option=br0,3,192.168.168.168
dhcp-authoritative
dhcp-range=br0,192.168.168.200,192.168.168.239,255.255.255.0,1440m
dhcp-host=00:00:00:00:00:00,M-SERVER,192.168.168.2,1440m
dhcp-host=00:00:00:00:00:00,N300A-IP,192.168.168.3,1440m
bogus-priv
conf-file=/etc/rfc6761.conf
clear-on-reload
dhcp-rapid-commit
stop-dns-rebind
dhcp-option=252,"\n"
cache-size=0
dns-forward-max=150

#additional options
local=/local/
#expand-hosts
dhcp-option=br0,option:dns-server,192.168.168.192
dhcp-option=br0,option6:dns-server,[fe80::1:f0ff:fee7:9c07]
dhcp-range=br0,::,constructor:br0,ra-names,ra-stateless,64,1440m

Hope this will solve internal hostname lookup for others using IPv6.

1 Like
2

Thank you for that write-up - this would certainly benefit users running dd-wrt with dnsmasq handling DHCP, probably as well as those running a router OS with a customisable dnsmasq.

However, that configuration may still not have all IPv6 addresses associated with hostnames:
With IPv4, clients may (or may not) register a hostname with a DHCP server during DHCP lease negotiation, which in turn may (or may not - some routers don't) populate a co-located DNS resolver with the respective DNS records.

There is no equivalent procedure for IPv6, specifically when auto-configuration is used.
If configured as DHCP server, dnsmasq (as well as Pi-hole) would make an effort to associate IPv6 addresses with hostnames by applying some heuristics, but that's not guarantueed to always work.

I'd like to also suggest an alternative approach:
Since you can control your router's behaviour, you could consider to distribute an IPv4 address as local DNS server exclusively, i.e. do not provide IPv6 DNS resolvers at all.

That would prompt your clients to contact Pi-hole via IPv4 only, and IPv4 addresses are easier to associate with hostnames.
Note that is fully sufficient, as a DNS resolver would return A and AAAA records as requested, regardless whether the query arrived via IPv4 or IPv6.

This would work with IPv4-only as well as dual-stack machines.
The one drawback would be that IPv6-only hosts would be unaware of a DNS resolver, and thus not be able to resolve DNS.