Current behavior
This is loosely related to the dns64 module (and its dns64-prefix config option). The existing behavior of this module should not change, it's really an independent feature, just in the same ballpark area.
Describe the desired feature
When unbound is running in a NAT64/DNS64 scenario, it may not actually have IPv4 connectivity itself (i.e. be behind the same NAT64.) In this case, any domain that has solely IPv4 NS will fail to resolve, since unbound is trying to reach it over IPv4.
An option to make unbound internally translate its outgoing packets from IPv4 to the NAT64 prefix would make this work nicely. This would be optional behavior enabled with a switch somewhere; it could use the dns64-prefix option as default, or have its own prefix setting.
(I checked out the unbound source and looked around, but the code base is too complex for me to figure out how to add this feature, sorry.)
Potential use-case
The use case for this is running a validating recursor on devices inside a NAT64 domain. Might be a larger network with one fat NAT64 gateway but with a desire for distributing/splitting out recursors. Might be a laptop with a local recursor.
Current behavior This is loosely related to the
dns64
module (and itsdns64-prefix
config option). The existing behavior of this module should not change, it's really an independent feature, just in the same ballpark area.Describe the desired feature When unbound is running in a NAT64/DNS64 scenario, it may not actually have IPv4 connectivity itself (i.e. be behind the same NAT64.) In this case, any domain that has solely IPv4 NS will fail to resolve, since unbound is trying to reach it over IPv4.
An option to make unbound internally translate its outgoing packets from IPv4 to the NAT64 prefix would make this work nicely. This would be optional behavior enabled with a switch somewhere; it could use the
dns64-prefix
option as default, or have its own prefix setting.(I checked out the unbound source and looked around, but the code base is too complex for me to figure out how to add this feature, sorry.)
Potential use-case The use case for this is running a validating recursor on devices inside a NAT64 domain. Might be a larger network with one fat NAT64 gateway but with a desire for distributing/splitting out recursors. Might be a laptop with a local recursor.