> On 12 Apr 2020, at 03:57, John Levine <jo...@taugh.com> wrote: > > In article > <cahpuvdx5ihg5_hiwyatuxxxvug6luh1nqefgtfvsm-f--bx...@mail.gmail.com> you > write: >> Sure. Brian was asking specifically asking about the TLD case, so my >> answer was in that context. For that space, I think one of the issues is: >> even if they were willing to verify all the delegations, it isn't clear what >> they are permitted to do about it, beyond notification to the registrants >> (or so I've heard). > > Remember that in ICANN contracted TLDs and in some ccTLDs, a registry > can only contact registrants by going through the registrars.
So they sent the notices via the registrar. There is nothing preventing that. Just a unwillingness to exercise the path. Registrars that fail to pass on notices would, I presume, be in breach of contract. > While I > can imagine some hack (EPP probably) for the registry to tell the > registrar about inconsistent NS, I don't see the point. The lousy > registrars won't care, the good ones could check and notify themselves > if they want to. The parent zone operators are already required to perform the checks (see STD 13). Just because many have been too lazy to do so doesn’t excuse them of the responsibility they took on when choosing to manage the zone. Now if they want to amend the contract they have with the registrars so that they do they checks they are free to do so but they still have to ensure the checks are done. "As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so.” I don’t see “unless you are a TLD operator” in there as a exemption. The “and remain so” implies the regular checks need to be made. The instructions clearly require “both sides” to check and take steps remedy inconsistencies. The requirement to communicate through a registrar is not a “get out of gaol free” card. > I suppose you could make a general observation that DNS operators can > check for inconsistent NS and when practical warn the child operator > but that sounds like "don't forget to brush your teeth" sort of advice. > R's, > John > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
