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
