Why not run a local copy of the root? It should be a good practice for large recursives, plus you get better latency.
Marek On Mon, May 16, 2016 at 2:34 PM, Wessels, Duane <[email protected]> wrote: > Hi Brian, > > I think what you're suggesting has already been proposed. See > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ and > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/ > > DW > > >> On May 16, 2016, at 2:23 PM, Brian Somers <[email protected]> wrote: >> >> Hi folks, >> >> I work at OpenDNS. We saw a DoS attack in Miami on Friday night around >> 10-11:00pm PST, consisting of UDP DNS requests for AAA.BBB.CCC.DDD where >> each of AAA, BBB, CCC and DDD are three digit numbers not greater than 500. >> >> Each query was answered with an NXDOMAIN by the root servers, Although our >> resolvers cached the NXDOMAIN for 1 hour (we cap negative responses at 1 >> hour despite the larger SOA MINIMUM) it was ineffective in reducing the load >> on the root servers as every varying query was another root server request. >> >> We eventually blackholed all TLDs from 000 to 500 to stifle the problem >> (locally delegating them to 127.0.0.1 where we don’t listen). >> >> However, during the attack, we also saw a huge number of TCP sockets in >> TIME_WAIT talking to root servers (probably all root servers). I’m curious >> if >> >> 1. Are root servers doing some sort of tar pitting where they send a TC and >> then firewall port 53? >> 2. Has anyone ever considered a better way than responding with NXDOMAIN? >> >> The second is a loaded question, but it occurs to me that a new type of >> negative response to (say) 111.222.333.444/IN/A might be an NXDOMAIN with an >> SOA record (as we do now) but also with an indicator that 444 and below are >> NXDOMAINs. I’m not sure what that might look like, maybe "444/IN/NS .” in >> the AUTHORITY section where “.” is the NS value meaning that 444 is actually >> delegated to nobody. >> >> Thoughts/comments? >> >> — >> Brian >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
