On Thu, 30 Jul 2020, Joe Abley wrote:
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.
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.
You are mixing up the generic policy of delegation only with the exact
semantics of the bit. The .org is definately what I would call a
delegation-only domain. Now let's examine the corner case you have
and see if/what we can do.
Rephrasing what you are saying is that "sometimes we need to take over
our children and we currently do this in such a away that we would no
longer appear to be delegation only".
So you are saying that if ns1.example.org serves another-example.org
and example.org is suspended for abuse, that you will still service
A records for ns1.example.org and NS records for another-example.org
containing ns1.example.org but no NS records for example.org? In
the hopes that another-example.org keeps working?
Wouldn't that already fail with DNS servers like unbound with:
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: yes
harden-referral-path: yes
which is the default in Fedora / RHEL / CentOS and maybe others?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
