While this is an interesting issue how does this differ from what already exists for every mobile device which connects to a network with private names today? These names resolve it NXDOMAIN or not depending on the attachment point. Traditionally stub resolvers only keep answers for as long as they need them for. That is usually significantly less than the TTL of the returned answer, often milliseconds. If there is a on device cache it can be partially flushed on SSID changes. If the device is worried about spoofed answers it can install (additional) trust anchors based on SSID that are initially added using out of band methods and maintained using RFC 5055.
For hardwired devices there are profiles that can be set by the user when they connect. They flush the local cache today of you have a Mac and other OS have similar capabilities. Trust anchors can be set via that mechanism. Note negative trust anchors are NOT used above. -- Mark Andrews > On 7 May 2025, at 04:11, Paul Hoffman <paul.hoff...@icann.org> wrote: > > On May 6, 2025, at 09:56, Ted Lemon <mel...@fugue.com> 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 > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
