On Thu, 30 Jul 2020, Joe Abley wrote:
I do not believe that is correct. The first and foremost purpose is for
the bit to signal the parent zone's behaviour in a public way that
prevents targeted / coerced attacks from the parent. This allows
policy violations to be rejected even if these violating DNS answers
are DNSSEC signed.
Has anybody done a survey to find out how many TLD zones actually fits the description of
"delegation-only"?
I know for a fact that ORG does not today and I would say is unlikely ever to.
So this statement aged badly with today's announcement from Afilias:
http://www.circleid.com/posts/20200811-afilias-to-protect-tlds-against-potential-orphan-glue-exploits/
Afilias has informed registrars and registry clients that it is
taking steps to remove orphan glue records from 200+ TLD zones
in its care. This will eliminate the potential for a handful of
domain names to be misused.
Afilias identified a handful of domain names among the 20 million names
For example, any nameserver N that is subordinate to domain D and linked to
some other domain E will be served authoritatively from the ORG zone if domain
D is suspended and while E continues to be delegared. Suspensions happen
regularly, e.g. for domains implicated in technical abuse. There are several
thousand examples of such N today and history suggests the number is not
becoming smaller. Even if the number of such N could reach zero in ORG, we
could never assume the number would remain at zero and still would not be able
to assert usefully that the zone is delegation-only.
I don't think ORG is particularly special in this regard; it seems possible
that other (possibly many other; possibly most or all) TLD zones are similar.
If there are no TLD zones that actually are delegation-only then there seems no
obvious application for it, regardless of whether we consider it to be useful
or not.
Well, 200+ TLD's are now removing this problematic orphan glue due to
security reasons unrelated to this draft.
So my question to Joe is, did you have any other concerns with allowing
this draft to move forward?
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
