RADHCPv6 is not a standard software daemon; the term likely conflates Router Advertisement (RA) services with DHCPv6. To provide DNS servers to clients, you must configure either the radvd daemon for RA options or a dedicated DHCPv6 server like odhcpd or kea-dhcp6. This guide clarifies the distinction and provides correct configuration steps for both approaches.
Understanding the Protocol Distinction
In IPv6 networking, client configuration relies on two primary mechanisms: Stateful and Stateless address assignment. It is crucial to distinguish between how routers announce their presence and how specific parameters like DNS servers are delivered. The Router Advertisement (RA) message, sent by the local router, informs hosts about available prefixes and default gateways. Historically, RAs could also carry DNS information via Option 23, but many modern operating systems ignore these options in favor of information provided by a DHCPv6 server. A true DHCPv6 server handles stateful configuration, assigning IP addresses and providing explicit DNS server addresses through Type 23 (DNS Recursive Name Server) options. If your goal is to bypass ISP DNS caches and force devices to use specific internal or public DNS resolvers, relying solely on RA messages may be insufficient because client behavior varies. Some Linux distributions and BSDs prioritize DHCPv6 DNS records over RA DNS records, while Windows often ignores RA DNS options entirely unless explicitly configured to do so. Therefore, the most reliable method for enterprise or strict home lab environments is to run a DHCPv6 server rather than relying on the router daemon alone.Why RADHCPv6 Is Not a Standard Daemon
The confusion often arises because some older or specific embedded systems might bundle RA and DHCP functions under a non-standard name. However, in standard Linux distributions such as Debian, Ubuntu, Fedora, or Arch Linux, there is no package namedradhcpv6. You will typically encounter radvd (Router Advertisement Daemon) which only sends RAs, or odhcpd which handles both SLAAC and DHCPv6. Attempting to install a non-existent package will result in errors. Identifying the correct daemon installed on your system is the first step toward successful configuration.
Configuring odhcpd for DHCPv6 DNS
The most common solution on modern Linux routers using OpenWrt or standard kernel-based setups involvesodhcpd. This daemon manages the DHCPv6 service and can easily inject DNS server addresses into the responses sent to clients. Unlike radvd, odhcpd maintains a lease database, allowing for more granular control over client configurations.
To configure odhcpd, you must edit its configuration file, typically located at /etc/odhcpd.conf or within the network interface definitions in /etc/config/network depending on the distribution. The key parameter is dhcp_option or the explicit definition of DNS servers in the interface section. For example, in an interface definition, you would specify the mode as server and list the DNS servers.
config interface 'lan'
option ifname 'eth0'
option proto 'dhcpv6'
option dhcpv6 'server'
option dns '2001:4860:4860::8888 2001:4860:4860::8844'systemctl restart odhcpd. Verify that the service is running and listening on UDP port 547 using ss -ulnp | grep :547.
Alternative: Using radvd for RA-Based DNS
If you cannot run a DHCPv6 server due to hardware limitations or specific network policies, you may attempt to push DNS information viaradvd. This method uses the ICMPv6 Router Advertisement messages to include DNS information. Note that this is less reliable across different client operating systems.
Edit the radvd.conf file to define the interface and the DNS options. The syntax involves specifying the Rdnss directive within the interface block.
interface eth0 {
AdvSendAdvert on;
prefix 2001:db8:1::/64 {
AdvOnLink on;
AdvAutonomous on;
};
Rdnss 2001:4860:4860::8888 {
AdvRdnssLifetime 3600;
};
};radvd.conf, restart the daemon with systemctl restart radvd. Clients receiving these advertisements will update their DNS resolver lists if their OS supports parsing RA RDNSS options. However, as noted, Windows clients often do not process these options automatically, making this approach inferior to a full DHCPv6 setup for cross-platform compatibility.
For more details on managing DNS records dynamically, see Making DNSmasq Handle Dynamic IP Hostnames. Additionally, understanding how interfaces auto-configure can help troubleshoot why some devices might not receive these settings immediately, as discussed in Understanding Auto-configured Interfaces SLAAC (accept_ra1) on Non-Router Devices.
Verifying the Configuration
Regardless of the method chosen, verification is essential. On the client side, you can check the received DNS configuration using tools likeresolvectl on systemd-based Linux systems or ipconfig /all on Windows. Look for the source of the DNS entries. If they originate from the DHCPv6 server, the MAC address or DHCP identifier should match your router's lease table.
Use tcpdump on the router interface to observe traffic. Filter for DHCPv6 messages with tcpdump -i eth0 port 547. You should see Solicit messages from clients and Advertise/Reply messages from the server containing the DNS options. If you see no traffic, ensure that firewall rules on the router allow inbound UDP 547 and outbound UDP 546 traffic. Similarly, check that the client’s firewall is not blocking these ports.
If issues persist, consult resources on resolving connectivity problems, such as those found in Troubleshooting SSH Connection Issues, as network stack misconfigurations can sometimes affect broader communication protocols beyond just DNS.
Frequently Asked Questions
Can I mix RA DNS and DHCPv6 DNS?
Yes, but client behavior determines which takes precedence. Most modern Linux clients prefer DHCPv6 DNS records if available, ignoring RA RDNSS options. Windows typically ignores RA DNS options entirely unless manually configured. To ensure consistency, it is best practice to rely solely on DHCPv6 for DNS delivery if possible.What happens if my DHCPv6 server goes down?
Clients will retain their existing DNS cache and leased addresses for the duration of the lease time. New clients attempting to join the network will fail to obtain IP addresses or DNS configurations until the service is restored. Ensure high availability by running redundant DHCPv6 instances if your network requires constant uptime.How do I test DHCPv6 without connecting real devices?
You can use a virtual machine or container with a DHCPv6 client tool likedhcpcd or ndisc6. Run ndisc6 -r eth0 fe80::1 to send a Router Solicitation and observe the response. Then, initiate a DHCPv6 request to verify that the DNS options are correctly formatted in the reply packet.