When using the default DNS64 prefix, reverse lookups for synthesized addresses
work. For example, a reverse lookup for 64:ff9b::185.49.140.10 properly
resolves to PTR dicht.nlnetlabs.nl and PTR open.nlnetlabs.nl.
Same behavior when setting dns64-prefix to a GUA prefix.
But when using a ULA prefix ("dns64-prefix: fd01:db8::/96"), reverse lookups
fail (NXDOMAIN).
- Is this behavior intentional? The cause most likely is filtering of reverse
lookups for private address space. But shouldn't the dns64-prefix be
excluded from such filtering?
- If it is indeed intentional, what would be the best way to work around it?
Setting "unblock-lan-zones: yes" does the trick, but seems a bit too radical.
The setting
local-zone: "d.f.ip6.arpa." nodefault
is a more granular method to unblock the part that is needed for you.
Because in fact the dns64 prefix is more specific, it would be a good
idea to perhaps keep the default, local-zone: "d.f.ip6.arpa." static,
with a more specific cut-out: local-zone: "8.b.d.0.1.0.d.f.ip6.arpa."
transparent. You may also need domain-insecure:
"8.b.d.0.1.0.d.f.ip6.arpa." or domain-insecure: "d.f.ip6.arpa." to make
it work.
I am not sure what works with dns64, but these are the local-zone
options that you seem to be getting at with the unblock-lan-zones option.
Because in fact the dns64 prefix is more specific, it would be a good
idea to perhaps keep the default, local-zone: "d.f.ip6.arpa." static,
with a more specific cut-out: local-zone: "8.b.d.0.1.0.d.f.ip6.arpa."
transparent. You may also need domain-insecure:
"8.b.d.0.1.0.d.f.ip6.arpa." or domain-insecure: "d.f.ip6.arpa." to make
it work.
"local-zone: 8.b.d.0.1.0.d.f.ip6.arpa. transparent" fixes it (while not
touching the default for d.f.ip6.arpa.). "domain-insecure" is not required,
d.f.ip6.arpa. is not signed.
I wonder whether it would be a good idea for unbound to add such an exception
for the specified dns64-prefix automatically?