[DNSOP] Re: draft-ietf-dnsop-3901bis

[Tobias Fiebig <[e-mail]>]

Moin,

reading the discussion, i seriously believe that this is a viable
compromise and the closest we may ever get to consensus on this point.

Generally, I also follow your argument.

If anyone has strong opinions to the contrary, please speak up (and
ideally attach text or send PRs ;-))!

With best regards,
Tobias

On Thu, 2025-08-14 at 08:21 -0700, Tommy Jensen wrote:
>  
> On 8/13/25 14:36, Philipp S. Tiesel wrote:
>  
>  
> >   Hi, 
> >  
> > 
> >  
> > >  
> > > On 13. Aug 2025, at 00:25, Mark Andrews <[e-mail]> wrote:
> > >  
> > >  
> > >  
> > > > On 11 Aug 2025, at 20:06, Tobias Fiebig <[e-mail]>
> > > > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Dr.-Ing. Tobias Fiebig
T [phone]
M [e-mail]
Pronouns: he/him/his