The Apple resolver at least clears the cache whenever it detects a network transition. So the problem Paul is describing wouldn't happen. Dunno what other mobile devices do.
I think its worth documenting this behavior if the working group wants to do that work. > On 6 May 2025, at 22:42, Mark Andrews <ma...@isc.org> wrote: > > 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
