[FR] integrated NAT64 translation for outbound packets (e.g. when DNS64 in use) #721
Comments
eqvinox
added a commit
to eqvinox/unbound
that referenced
this issue
Jul 23, 2022
This implements NLnetLabs#721. It's not really polished but does work. TODO: - clean up code formatting - make NAT64 prefix configurable instead of hardcoding it
Merged
eqvinox
added a commit
to eqvinox/unbound
that referenced
this issue
Nov 5, 2022
This implements NLnetLabs#721. It's not really polished but does work. TODO: - clean up code formatting - make NAT64 prefix configurable instead of hardcoding it
eqvinox
added a commit
to eqvinox/unbound
that referenced
this issue
Nov 5, 2022
This implements NLnetLabs#721. Includes documentation and some very basic tests. Please refer to doc for further detail.
eqvinox
added a commit
to eqvinox/unbound
that referenced
this issue
Nov 7, 2022
This implements NLnetLabs#721. Includes documentation and some very basic tests. Please refer to doc for further detail.
|
Ran into this issue today too. Thanks for the PR, hope it gets merged soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current behavior
This is loosely related to the
dns64module (and itsdns64-prefixconfig 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-prefixoption 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.
The text was updated successfully, but these errors were encountered: