On 8/13/25 14:36, Philipp S. Tiesel wrote:
Hi,
On 13. Aug 2025, at 00:25, Mark Andrews <[email protected]> wrote:
On 11 Aug 2025, at 20:06, Tobias Fiebig <[email protected]> wrote:
Moin,
On Mon, 2025-08-11 at 19:55 +1000, Mark Andrews wrote:
Which only “works” with trivial configurations.
What happens if 2.0.0/24 is reachable out interface A and interface B
is IPv6 only with a PREF64?
Then I'd say that it is covered by the point being made
<bcp14>SHOULD</bcp14> and not <bcp14>MUST</bcp14>.
SHOULD is a cop out. What we are designing SHOULD work everywhere
WITHOUT
manual intervention.
I agree SHOULD (making this behavior the default unless some exception
applies) is inappropriate. I think the presented arguments justify
making this an option for resolvers who are aware of their XLAT
situation, but it should be a MAY meaning the default is to trust the OS
stack.
Translating IP addresses in a DNS server is unnecessary work. It is also
a security flaw as you are potentially redirecting DNS queries to places
other than where they are intended to go according to the routing table.
If there are no IPv4 routes, there are no security issues. If there
are (but no default route)
maybe disabling address synthesis and setting up CLAT is easier, but
for wich use-cases?
- Recursors on Laptops with split-VPN?
- My chaotic VyOS VPN router at home?
This assumes the admin of the DNS resolver is always the same as the
admin of the system. I suggest this isn't true and telling the RFC
readers that the default behavior is to handle address synthesis instead
of trusting their available OS stack seems a heavy ask unless they want
to take that responsibility on (which I agree many will or even should
for perf reasons presented).
The ways to configure one's own network are endless. What if there are
two interfaces each with their own PREF64? What if the second Interface
only offers reachability for RFC1918? What if the operator has been
squatting non-RFC1918 space and the 2.0.0.0/24 reachable via Interface
B is _not_ the one they want to use for DNS resolution?
All the more reason to NOT do this. It’s not something that can be done
safely.
It is perfectly safe if you have no IPv4 connectivity and much less
error-prone than integrating CLAT.
The only drawback of doing address synthesis instead of CLAT is that
DNS server vendors get additional bug reports for broken network
setups that should not have enabled address synthesis in the first place.
Again, this assumes the resolver admin has the option of configuring the
OS stack. If they do, they MAY optimize this way, but requiring them to
seems like a leap.
I think that all of that is sufficiently covered by
<bcp14>SHOULD</bcp14>.
However, to make this more clear, we could add text along the lines of:
"Specific operational scenarios may differ. As such, it is
<bcp14>RECOMMENDED</bcp14> that implementations offer configuration
options that allow an operator fine-grained control of prefixes to
exclude from PREF64 based address synthesis."
The general point, though, was brought forward to me by multiple
operators, who are struggling with the current situation, and would
appreciate the currently sketched solution.
Agreed! It should be documented here, just optional and not the default.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
