Unbound not registering IPv6 Link Local addresses

[elyl]

If I do an nslookup with Unbound, using an IPv4 address that I have a DHCP lease for, it returns the local name, e.g:

Code Select Expand

> nslookup 10.0.0.1
1.0.0.10.in-addr.arpa   name = OPNsense.internal.
If I do the same thing with a link local IPv6 address, it doesn't give me anything:

Code Select Expand

nslookup fe80::1
** server can't find 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa: NXDOMAIN
If I look up the GUA IPv6, it does give me a result:

Code Select Expand

nslookup 2603:xxxx:ffbb
b.b.f.f.xxxx.3.0.6.2.ip6.arpa        name = OPNsense.internal.
If I look up the link local address in the NDP Table, it is in there, and maps back to a MAC address that I have a DHCP lease for.  I have "Register ISC DHCP4 Leases" turned on, and "Do not register IPv6 Link-Local addresses" turned off in Unbound settings.

How do I get Unbound to respond with a hostname for fe80 addresses?

My use case is for Pihole, I want to resolve client IP addresses to friendly names.  If a request is made to pihole via IPv4, it seems to resolve the client name, but if it's IPv6 (which most devices on my network seem to be using), it just gives me the fe80 link local address as the client name.

[meyergru]

The short answer to your question is: You don't. Use IPv4 instead.

First: Did you enable DHCPv6? With just SLAAC, any client can get an IPv6 address, but there is nothing like a DNS name that could be registered alongside a (non-existent) request.

Second: Linking IPv6 link-local addresses to DNS names does not make very much sense. When you look at the output for "ifconfig" on your OpnSense, you will most likely see the same lladdr multiple times, only suffixed by %interface. That explains why there is no lladdr entry in DNS for OpnSense itself.

For example, you could not even ping a link-local address without giving the interface. DNS, on the other hand, cannot store interface names alongside the actual IPv6 address. Thus, it makes not much sense to put any lladdr into DNS, as discussed many years ago: https://www.kame.net/newsletter/20000216/, and I quote: "Link-local address ... SHOULD NOT put it into intranet DNS database (only exception is when your intranet has only single link, which is usually untrue).".

IDK why or if pihole does that, but if you really need names attached to your IPv6 clients locally, you would most likely need:

1. DHCPv6
2. An ULA addressing scheme

Note, however, that many IPv6-capable devices cannot use DHCPv6 at all (anything Android being a promiment example). You could get away by assigning all those devices static IPv6 addresses based on their known MACs and hence - known EUI64. If you have dynamic IPv6 prefixes, like me, you cannot use their GUA even with "track interface" enabled. LL addresses are out of the question either, so you will have to use ULA.

For reverse lookups, you cannot expect meaningful names at all, because of RFC 4941. You simply do not know which IPv6 a client chooses to use. That is the reason why IPv6 firewall rules for specific clients can only be expressed using their MAC (and be enforced only via additional means like 802.1x).

[elyl]

Interesting.  I am using DHCPv6, since whenever I turn on SLAAC, I get weird behavior on my Android devices (generally work fine, IPv6 tests pass, but various apps refuse to open and I need to get off wifi to open them).  So I have RA set to Managed so it's DHCPv6 only and Android devices only get IPv4.

My DHCPv6 settings are sending the DNS server (pihole).  I guess if I leave them blank, it uses Unbound instead (which I don't want as no Pihole blocking).  If I get SLAAC working and turn DHCPv6 off, how does it decide which DNS server to use?  Does it just revert to the IPv4 DNS server?  What if IPv4 connectivity is broken somehow (I have a WWAN backup connection that I'm also trying to get working, which is IPv6 only, with some kind of IPv4 over IPv6 nonsense)?

[meyergru]

1. You can have an IPv4 DNS server serve IPv6 addresses and vice versa, so having only one is not a problem. One DNS server will suffice. IPv6 will per default be prioritized higher but most applications fall back to IPv4 if IPv6 is not available.

2. You can distribute a DNS server address via SLAAC/NDP (RDNSS) and if you do not check the box "Do not send any DNS configuration to clients" in radvd, it will be sent. You can set another DNSv6 server in DHVPv6 and then use that information in RADVD instead. Otherwise, the DNS server configured in OpnSense will be used (i.e.: not neccessarily Unbound).

However, support for some features of IPv6 differs by operating system: https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

If IPv4 connectivity is broken and IPv6 is available, it will be prioritized anyway. If the target is IPv4 only, you will be out of luck anyway unless there is some ISP-side trickery that does the translation. This usually happens via CG-NAT anyway, so technically, IPv4 is not really broken.

IDK why your Android devices do not work correctly when you use SLAAC - I only use that and would at most resort to "assisted" mode. Also, I am a fan of using the same name server for OpnSense itself and the clients (i.e. I setup some recursive DNS servers for Unbound upstream and then use that for anything else). You could look at the network configuration of your Android devices, especially which DNS server(s) are provided (as I said, one suffices). I would guess this stems from a setup involving unbound, pi-hole and a dual-WAN. I have no experience with (nor need for) pi-hole.

[elyl]

I went somewhat back to the drawing board with IPv6 last night.  I think I had made things so complicated trying to get it working in the past.  I now have DHCPv6 turned off, and RA set to Unmanaged.  So far, so good.  Android and non-Android devices passing ipv6-test.com and the usual problem apps on Android working correctly.

I set RA to not send any DNS info, and eventually my clients reverted to having the IPv4 DNS address only.  However, in pihole, all those clients started showing DNS requests coming from my WAN IP address, rather than an fe80???

Well, I have been trying to get WAN failover working correctly with my cable internet, failing over to a cellular modem (T-mobile with cgNAT) but not been having much luck.  I have WAN IPv4 and IPv6 gateways, and WWAN IPv4 and IPv6 gateways, with they set up as failover groups and my firewall default routes set to use the failover groups.  I have not yet been able to make this work, everything goes through WAN, but WWAN generally shows as down and there's never any failover.

Anyway, switching the firewall routes back to 'default' from 'FailoverIPv4'/'FailoverIPv6' gateway groups now gives the correct originating (IPv4) address for each client in Pihole, rather than WAN IP.

I guess it's back to the drawing board on the WAN failover stuff, too.  Thanks for your help in pointing me back towards SLAAC, this has probably solved a number of weird issues I've been having.