A DNAME does not break the DNSSEC chain of trust. An insecure delegation is needed to do that.
“Black hole servers” can be any set of servers. For d.f.ip6.arpa (half of the top of the ULA reverse trees) they are the same as the parent servers. d.f.ip6.arpa. 3600 IN NS a.ip6-servers.arpa. d.f.ip6.arpa. 3600 IN NS d.ip6-servers.arpa. d.f.ip6.arpa. 3600 IN NS c.ip6-servers.arpa. d.f.ip6.arpa. 3600 IN NS b.ip6-servers.arpa. d.f.ip6.arpa. 3600 IN NS e.ip6-servers.arpa. d.f.ip6.arpa. 3600 IN NS f.ip6-servers.arpa. If the traffic is too much a DNAME can be added to the DELEGATED zone. e.g. internal. SOA ... internal. NS <server1> internal. NS <server2> ... internal. DNAME 10.in-addr.arpa. Mark > On 2 May 2025, at 07:58, Joe Abley <[email protected]> wrote: > > 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] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
