Bug in Unbound configuration prevents IPv6 communication to DNS servers

[schnipp]

While restructuring my network, I noticed that Unbound is not able to communicate with external DNS servers over IPv6.

Debug logging showed the following error message:

Code Select Expand

2024-12-20T18:24:50    Error    unbound    [5544:1] error: can't bind socket: Can't assign requested address for fe80::ff:fe00:fe port 24152 (len 28)
Further checking showed that in the Unbound configuration (/var/unbound/unbound.conf) for outgoing communication, the link-local address is configured for IPv6. This obviously cannot work because this network is not routable. Manually editing the Unbound configuration to the GUA ULA temporarily solves the problem until OPNsense rewrites the configuration.

Either the persistent GUA ULA of the interface or the assigned network (/64) must be configured as the IPv6 address. In the latter case, Unbound should also take temporary addresses (IPv6 Privacy Extensions) into account. However, I have not tried the latter.

Can anyone reproduce the problem that OPNsense for Unbound configures the link-local address for outgoing IPv6 communication?

My WAN interface configuration:
- DHCPv6
- Only request IPv6 prefix
- Sent Prefix Hint
- IPV6 Privacy Extensions enabled

OPNsense 24.7.11_2-amd64

[schnipp]

In addition (excerpt from unbound documentation)

outgoing-interface: <IPv4/IPv6 address or IPv6 netblock>

[...]
If an IPv6 netblock is specified instead of an individual IPv6 address, outgoing UDP queries will use a randomised source address taken from the netblock to counter spoofing.

Maybe, it's better to configure the whole IPv6 netblock instead of a single GUA ULA. Perhaps, this does not work in FreeBSD. So, more tests are needed.

[schnipp]

Now, the unbound configuration contains the public IPv6 address and everything works. I cannot reproduce this issue. Maybe it's a race condition bug somewhere.

[Clete2]

Is there a command I can run to validate?

[schnipp]

Is there a command I can run to validate?

You can have a look at the "outgoing-interface" parameters in the unbound configuration file (/var/unbound/unbound.conf). If the values contain an IPv6 link local address (prefix: fe80::/10) instead of a public IPv6 address, the unbound DNS resolver is not able to reach public DNS servers via its IPv6 address.

In case unbound tries to reach a DNS server via IPv6 and the configured outgoing interface contains only a link local address for IPv6 you'll find an error message in the log (cannot bind socket or bad address [I forgot the exact wording see #1]),

[Patrick M. Hausen]

By default there should be no outgoing interface configured at all. This is the relevant part of my config:

Code Select Expand

# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::
interface-automatic: yes

If the problematic behaviour you observe is triggered by changing the listen interface and/or the outgoing interface to anything but "All (recommended)", I suggest to follow the recommendation. It exists for a reason.

For your current situation: if you configured an explicit outgoing interface - does that interface have a GUA at all?

[schnipp]

By default there should be no outgoing interface configured at all. This is the relevant part of my config:

Often it should be sufficient, to let this option in the default state. In my case I had to configure outgoing interfaces, otherwise forward DNS servers (for specific domains) are not reachable via a policy based IPsec tunnel. The unbound documentation states: "Outgoing queries are sent via a random outgoing interface to counter spoofing".

Code Select Expand

# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::
interface-automatic: yes


Is there a configuration option in Opnsense to set "interface-automatic: yes"? According to the unbound documentation, this is an experimental feature.

[Ben S]

My WAN interface configuration:
- DHCPv6
- Only request IPv6 prefix
- Sent Prefix Hint
- IPV6 Privacy Extensions enabled

OPNsense 24.7.11_2-amd64

My reading of the code is that in this case it would use the link-local address as you have seen.  It looks as if setting the 'Optional prefix ID' under Settings > WAN > DHCPv6 may cause it to use the GUA, if that's something you can try (i.e. if the prefix for your ISP is bigger than /64 and you can assign a /64 to your WAN interface).

[schnipp]

My reading of the code is that in this case it would use the link-local address as you have seen.  It looks as if setting the 'Optional prefix ID' under Settings > WAN > DHCPv6 may cause it to use the GUA, if that's something you can try (i.e. if the prefix for your ISP is bigger than /64 and you can assign a /64 to your WAN interface).

The problem is already solved but the reason is unknown. Possibly a race condition.