On 30/07/2020 15:44, Brian Dickson wrote:
On Thu, Jul 30, 2020 at 1:21 PM Joe Abley <jab...@hopcount.ca
<mailto:jab...@hopcount.ca>> wrote:
$ORIGIN ORG.
BADDOMAIN NS ...
BADDOMAIN NS ...
NS1.BADDOMAIN A 192.0.2.1
GOODDOMAIN NS NS1.BADDOMAIN.ORG <http://NS1.BADDOMAIN.ORG>.
GOODDOMAIN NS ...
If BADDOMAIN.ORG <http://BADDOMAIN.ORG> is suspended (or if the
domain is suppressed for some equivalent reason) then the zone cut
betwen ORG and BADDOMAIN.ORG <http://BADDOMAIN.ORG> will be removed
(the BADDOMAIN.ORG <http://BADDOMAIN.ORG> NS set will disappear) but
the A record above will remain, since it is linked to another
domain, GOODDOMAIN.ORG <http://GOODDOMAIN.ORG>, that depends upon
it. Without a zone cut, that makes the ORG servers authoritative for
the A record.
To a certain extent, this behaviour is a consequence of (a) the
venerable operaetional need to suspend domains because they have
been implicated in abuse and (b) the EPP data model used in the ORG
registry, which itself has its origins in the RRP data model used
before the re-delegation of ORG to PIR in 2002. As such, it's
tempting to assert that the behaviour is a contractual requirement
shared with all other gTLDs that are operated subject to the same
contract that exists between PIR and ICANN, hence my question about
applicability.
Yes, this does appear to be driven by EPP (the data model and the RFCs
for said),
Only if you take the "hosts as objects" case (where any hosts to be used
as to be provision like a domain but by just providing, in some cases,
some IP addresses), which is only one of the two, the other being "hosts
as attributes (of a domain object)"
The problem is similar to the following:
- registrar A is sponsor of domainA.example
- this domain has (not necessarily using them) hosts
"ns1.domainA.example" and "ns2.domainA.example"
- at some point, registrar B creates domainB.example ...
using ns1.domainA.example and ns2.DomainA.example
Now, registrar A CAN NOT delete domain domainA.example anymore because
it has "child" nameservers used elsewhere and if he could do that we are
back to the "orphaned glue records" problem.
It can not for the same reasons delete the nameservers themselves, just
update their names or IP addresses.
There are various solutions, all bad in some aspects:
- let the registrar A eat the bill (of domainA.example being renewed
forever) and that is all
- convince registrar B to change the delegations (and no matter what
amount of garbage you put in the zone server by those nameservers it
would still not guarantee anything is changed)
- have nameservers be changed in their hostnames, so that after the
domain can be deleted as not having child nameservers anymore; this
works only in the "hosts as objects" case above and not always as change
of hostname is not implemented by all registries or with restrictions
like not internal->external renaming
(which is also a major arguments by registrars to dislike the hosts as
attributes case)
- have the registry let the domain be deleted and then have domainB be
broken (which it is already in a way since the delegations to those
nameservers can be explicitly made broken; but the difference is between
registrar A breaking registrar B stuff, or the registry breaking
registrar B stuff).
However, is it appropriate to discuss the requirement or request to have
the EPP spec (and contracts) changed, as a topic for DNSOP?
The above problems, for me, are only loosely related to EPP.
You could use any other provisioning protocol (if it existed) and have
the same problem of DNS management.
The problems comes more from having a single space (the registry
zonefile) be managed by multiple actors (registrars), collaboratively
but also in competition.
Or does anyone know if more recent contracts include similar language,
and what rough order of magnitude of contracts would be impacted?
E.g. If the number of contracts is O(12), vs O(1000), the conversation
is likely to be very different.
See my other message where I quote ICANN resources where this question
is part of the application of any 2012-era gTLD operator.
--
Patrick Mevzek
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
