Actually if a DNS operator is requesting that NS records pointing to them be removed then the TLD only need to look at the enclosing SOA of NS’s address records to find a valid contact.
As was pointed out to ICANN, the DNS operator is a party that needs to be listened to, and yes they have acknowledged that publicly. This was with respect to .CM (delegation) and RIPE NCC (operator) and cm.cctld.authdns.ripe.net. They are still working through the details of how to correct it. See the thread https://lists.dns-oarc.net/pipermail/dns-operations/2019-June/018816.html I’m also pretty sure the Courts would also agree that pointing NS records to operators that don’t want the requests is something that should be corrected by all parties involved in the delegation (registrant, registrar, registry). I’d actually like to see some case law here. Parent zone operators might stop this BS that they can’t take action when it has been expected from the very beginning. Yes, there is a chance that the DNS operator would be in breach of contract by requesting the removal, but a little bit of due diligence on behalf of the registry should be able to detect that and result in push back to the Courts. If you are already returning REFUSED when you request the removal of the NS record pointing to yourself you can’t fake the SOA record of the zone in question. Mark > On 9 Jul 2019, at 8:15 am, Ted Lemon <mel...@fugue.com> wrote: > > There’s a reason people are ignoring them. There’s no mechanism for > validating such change requests nor checking that they are authorized. RFC > 1033 was written in a rather different time. > > Sent from my iPhone > >> On Jul 8, 2019, at 5:34 PM, Mark Andrews <ma...@isc.org> wrote: >> >> The problem here is that there is no post delegation maintenance occurring. >> If you are no longer under contract to serve the zone you should be able to >> request the NS records pointing to your servers be removed. If the zone >> operator continues to list your servers in the zone you are able to request >> that the entire delegation be removed with documented attempts to correct >> the delegation first. >> >> There where checks and balances built into the system. See RFC 1033. The >> problem is that people are ignoring those checks and balances. >> >> Mark >> >>> On 9 Jul 2019, at 2:42 am, Michael J. Sheldon <mshel...@godaddy.com> wrote: >>> >>> This is something that has bugged me for a long time, and I'd love to see a >>> good solution to. >>> >>> If a record is requested from an authoritative server, where the zone >>> exists, but the records does not exist, the negative response is cached for >>> <minimum> period of time. >>> >>> If a record is requested from an authoritative server, where the zone does >>> not exist, generally the response is REFUSED, but *this is not cached* by >>> the requesting server. This results in a nearly continuous stream of >>> retries, which continue to result in the same response. Our authoritative >>> servers see no less than 15%, and sometimes as much as 25% of our worldwide >>> traffic as these non-authoritative responses. >>> >>> There needs to be a means to signal to a recursive server that it should >>> not requery a REFUSED response for a specified period of time. Given that >>> these responses to not have ANSWER records to put a TTL on, return a (new) >>> EDNS record? >>> >>> Michael Sheldon >>> Dev-DNS Services >>> GoDaddy.com >>> >>> _______________________________________________ >>> 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 -- 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
