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. What has been proposed here is that we do the same thing for the internal domain. I think if you want to do something different for the internal domain, you need to actually propose a technical reason why we should do something different and not simply say that what we did previously was incorrect. Absent any such technical reason I think we should do the same thing for internal that we've done for home.arpa and for the RFC 1918 reverse look up domains. The fact that the delegation would be from the route may change precisely how we request such a delegation. But this doesn't change the technical situation. So I think if the IETF is not allowed to tell ICANN what to do here that's OK. ICANN has already taken action on this. What we should do is reflect back to ICANN what is required in order to implement the decision that they have taken. That would mean that we would tell them that we think they should put an insecure denial of existence for internal in the root. I think precisely how to phrase this request is really up to the IESG. We need not concern ourselves with that question. We should simply say what we think should happen. > On 6 May 2025, at 18:46, John R Levine <jo...@taugh.com> wrote: > > On Tue, 6 May 2025, Philip Homburg wrote: >> Adding an insecure delegation is a good way to tell validators that there is >> going to be an insecure zone. It is a practical mechanism that is proven to >> work. >> >> I have no clue how to design a protocol where a mobile device can attach >> to an unknown network and get (negative) trust anchors without potentially >> compromising the entire security of DNSSEC. >> >> If you have an idea what such a protocol could look like, maybe you can share >> it. > > For devices that move from one network to another, probably some variety of > TOFU, the first time you start up a device you do it on your home network and > it fetches the anchors. After that they don't change, or maybe the old key > signs the new one like for root key rolls. > > For devices that stay put, the same thing could work, or they could just > believe their local cache. > > I realize this is not bulletproof, but it seems less bad than, well, > there's a negative anchor at the root so anything goes. > > R's, > John > > _______________________________________________ > 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
