"DNS Server" DHCP option for IPV6 and delegated prefix

[iamperson347]

Hey All - I searched around a bit and poked around on the firewall but could not determine an answer.

Let's say you get a delegated prefix for IPv6 on your WAN, and track that interface in a subnet/vlan that you have a DNS server deployed in. The DNS server gets an IPv6 address as expected. You set the "DNS Server" DHCP option setting in other subnets (via dhcpv6 which flows down to RA/SLAAC) to hand out that DNS server IPv6 address.

I can make the IPv6 address "static" via a dhcp6 static mapping for the last portion of the address, but since it's a delegate prefix, the first portion of the address could change (thus making the DHCP Server option invalid).

Opnsense has something to handle this scenario for firewall rules (Dynamic IPv6 Host aliases). Is there any such option available for use in other portions of the firewall config (such as setting the ipv6 DNS Server to hand out as described in the above scenario)? I check the ISC DHCPv6 and Dnsmasq configs and didn't see an option available.

Thanks!

[meyergru]

That is why "IPv6 only" is not a viable option currently, unless you have static prefixes.

You can always use the link-local address or emply ULAs to fix that. Also, IPv4 DNS servers can hand out IPv6 addresses for names.

What is worse is that much more of the dynamic data that has been handed out via DHCPv6 will get invalid when the prefix changes without the client even knowing: IPs and routes being among them.

That is why you should differentiate between purposes you use IPv6 for:

1. For outbound access. For this purpose, going with SLAAC as described here will most probably fit every need better than DHCPv6. Also, you can choose to use IPv6 privacy extensions. Plus, you do not even need an IPv6 DNS server - stay with IPv4.

2. For internal access / addressing: use IPv4.

3. For making services in your networks available via IPv6 from outside: Use reverse proxies.

That using IPv6 "only" is a bad idea for multiple reasons has been discussed over and over, like here and here and here and here.

[Monviech (Cedrik)]

You can use dnsmasqs ipv6 server option with the address [::] which will always offer the current GUA of the host dnsmasq runs on.

Then you can use forwarding from dnsmasq to your internal dns server, e.g using the link local address LLA or a statically configured ULA.

[meyergru]

You can use dnsmasqs ipv6 server option with the address [::] which will always offer the current GUA of the host dnsmasq runs on.
...

Which does not really help until the client requests a new DHCP offer with the correct prefix after the old lease has timed out.

[Monviech (Cedrik)]

This is true, I guess you have to work with shorter lease times then or use static ULAs for this kind of internal traffic.

Though, as dnsmasq injects the DNS server into router advertisements as rddns, it should send out new ones with the new dns server when the old prefix changes. I assume.

[meyergru]

Correct, but RDDNS is not supported by all clients. That is the reason why many people still have DHCPv6 with SLAAC: namely, for DNS server publication only, while IPs and routes are distributed by RA.

As I wrote, I have good reasons to not use DHCPv6 - at least with dynamic prefixes. SLAAC and RAs are the logical way to enact changes on the clients when they are neccessary.

I usually even forego IPv6 DNS servers by any means, because they are redundant with dual-stack, anyway.

[iamperson347]

I guess I was trying to make things "fully dual stack," but it just doesn't look ideal if you can't get a static prefix. Granted, my ISP typically doesn't change it, but I know for a fact that it isn't static.

I was going to go down the ULA path as a I could make those static, but if you advertise services over both ipv4 and ipv6 internal (via DNS) to your network (using ipv6 ULA), clients seem to prefer ipv4 in that case. I think there is a proposal to change that.... and that would allow you to have true static ipv6 addressing for internal services (where the ISP doesn't provide static prefix delegations). https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/

Maybe I should just stick to ipv4 DNS servers being advertised. It stinks because it feels like it's not fully full stack, but local ipv4 probably isn't going away for a very long time I would guess.

[iamperson347]

Thinking through my previous post... I guess ULA's, despite the usage preference issues I mentioned in my previous post, would be fine specifically for DNS server advertisements since DNS lookups aren't even involved there. In the grand scheme of things, I'm just trying to eliminate having to make manual config changes in the firewall if my prefix gets changed.