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

[Paul Hoffman <[e-mail]>]

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.

Assume that a resolver for a corporate network uses .example as a TLD for its internal users. A user starts up their laptop when outside the network, and try to access foo.example.

- If .example is not listed in the root zone, they get a short-lived NXDOMAIN. When they move on to the corporate network after a short period of time, and try again, they get the address for foo.example.

- If .example has an insecure delegation, they get a two-day TTL to a nameserver that will tell them that foo.example doesn't exist.  When they move on to the corporate network after a short period of time, they still believe that foo.example doesn't exist because they believe the nameserver for .example is the one in the insecure delegation at the root.

This can probably be fixed, but we don't currently have such a fix in an RFC. I suspect there will be strong disagreement about what the fix should be (I have no opinion, and probably won't later). Saying "We already have prior art on this" understates what the "this" is.

--Paul Hoffman