On Thu, Jul 30, 2020 at 1:21 PM Joe Abley <[email protected]> wrote:
> > $ORIGIN ORG. > > BADDOMAIN NS ... > BADDOMAIN NS ... > NS1.BADDOMAIN A 192.0.2.1 > > GOODDOMAIN NS NS1.BADDOMAIN.ORG. > GOODDOMAIN NS ... > > If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some > equivalent reason) then the zone cut betwen ORG and BADDOMAIN.ORG will be > removed (the BADDOMAIN.ORG NS set will disappear) but the A record above > will remain, since it is linked to another domain, 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), although it is not completely clear whether the policy choice of keeping vs suspending the NS1.BADDOMAIN is a contractual requirement (it probably is), since the EPP spec discourages but does not forbid suspension/deletion of these NS glue records. Clearly, removing those glue records would cause the other delegations to fail, and possibly for other domains to become unresolvable. So, this points to an area of overlap between policy and technology, where alternative implementations of maintaining the ability to resolve the other domains, might be possible by making other technology choices. E.g. changing the name of the object N, to make it subordinate to some other domain, while the suspension is operative, e.g. by using the other domain (E) as the parent in place of the suspended domain (D). Clearly, changing that would likely require policy changes for any contracts that currently would not permit that change, as well as modifications of the EPP spec. The latter would not (I don't believe at least) be done in DNSOP. However, is it appropriate to discuss the requirement or request to have the EPP spec (and contracts) changed, as a topic for DNSOP? Do we know how many contracts would be impacted? Are those all strictly from the 2002 era? 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. Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
