Hi Ted, On 1 May 2025, at 23:46, Ted Lemon <[email protected]> wrote:
> Okay, but if they are not going to the authoritative servers to get the > chain of trust, they are going to the local full-service resolver or some > public third-party resolver. And so if there is an insecure delegation, that > resolver can make up an answer, and it will “validate” correctly as insecure. That is a possible outcome, I think, but again it's hard to compare against reality since in reality I don't think this is a common situation. It's possible, for example, that any device in this situation these days is likely to be managed within the realm of control that .internal has useful meaning, which makes all of this seem a bit unnecessary. Perhaps it's reasonable to wait until it's clear that there is a problem before dreaming up solutions. > But if the delegation is securely denied, that can’t happen. That’s why it’s > important for there to be an insecure delegation to a black hole name server. One word of warning here; it's messy to imagine new delegations to AS112 servers, if that's how we are to imagine "black hole name server" in a global context. Such delegations can reasonably be imagined to be lame, or at least not reliably not lame. This working group decided some time ago that's better approach was to use DNAME rather than delegation as the mechanism to shift unwanted traffic to AS112 servers. This advice has been ignored by the IETF since then, more than once I think, but I still think it's good advice. A DNAME RR has never before been deployed in the root zone and we know from other adjacent scenarios that there are some practical problems with the idea of installing the first one. It seems superficially attractive to imagine a course of action along the lines you suggested but there are dragons. An insecure delegation from the root zone to the root servers is cleaner, I think. (There's still the issue of quite how and whether the IETF should instruct the IANA to make changes to the root zone, the adjacent dragons of which make the other ones look rather small and inoffensive.) I am still far from convinced that there is anything useful for the IETF to say, here. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
