[DNSOP] Re: [Ext] Re: what problem are we trying to solve, was Call for Adoption: draft-davies-internal-tld

[Ted Lemon <[e-mail]>]

Thanks!

BTW, this is actually documented in section 7 of RFC6303. Rereading that section, I get a sense of where Paul's objection is coming to: I think the recommendation about DNSSEC trust anchors there is hopelessly impractical. However, the preceding two paragraphs seem correct.

They also anticipate the advice I was given in this working group when preparing RFC8375 (home.arpa). Section 6 of RFC8375 discusses this problem, and the motivations for the delegation requestion in section 7, in detail, and is based on advice that was given by folks in this WG about this problem.

Paul, I will note that you are called out specifically in the acknowledgments as having reviewed this text, although I do not remember at this late date what you said. Andrew Sullivan is cited as the source for the actual text that appears in the document, and may have more to say about this (or may not, no pressure).

> On 17 Jun 2025, at 13:04, Petr Špaček <[e-mail]> wrote:
> 
> On 5/6/25 20:09, Paul Hoffman wrote:
>> On May 6, 2025, at 09:56, Ted Lemon <[e-mail]> wrote:
>>> 
>>> I think that you're trying to solve two different problems here. The first problem is just generally what can you do to avoid causing a validation failure? The second problem is, how can you actually validate locally served domains?
>>> 
>>> They are both really interesting questions, and I think that it would be very useful to consider how we would solve the problem of validating locally served domain.
>>> 
>>> However, this is not absolve us of the responsibility to make sure that we don't accidentally cause validation failures where they are inappropriate. We already have prior art on this. We know how to solve this problem. RFCs that solve this problem all solve that and exactly the same way.
>> ...and that way might not work the way we want, and thus should be defined in RFCs before we make recommendations about them. In specific, we don't have any RFCs that deal with insecure delegation for clients that move around.
> 
> This is provably incorrect. 10.in-addr.arpa is an insecure delegation which with network-dependent content, and it works for decades. Please let's not create more diversions from the actual problem at hand, which is the missing insecure delegation. I.e. I fully agree with Ted Lemon.
> 
> -- 
> Petr Špaček
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]