Simon Arlott via dns-operations wrote: > I currently have this cached list of nameservers for dynect.net: > > ;; AUTHORITY SECTION: > dynect.net. 14931 IN NS cgydc01dnsext01.us.oracle.com. > dynect.net. 14931 IN NS tvp02dnsext02.tvp.oracle.com. > dynect.net. 14931 IN NS sydc01dns03.au.oracle.com. > dynect.net. 14931 IN NS trdc01dnsext01.us.oracle.com. > dynect.net. 14931 IN NS adc08dnsext02.us.oracle.com. > dynect.net. 14931 IN NS rmdc02dnsext01.us.oracle.com. > dynect.net. 14931 IN NS llg07dnsext02.llg.oracle.com. > dynect.net. 14931 IN NS llg07dnsext01.llg.oracle.com. > dynect.net. 14931 IN NS iad-dns-master.oraclecorp.com. > dynect.net. 14931 IN NS adc08dnsext01.us.oracle.com. > dynect.net. 14931 IN NS rmdc02dnsext02.us.oracle.com. > ;; WHEN: Fri May 27 17:10:08 BST 2022 > > All of these hostnames are NXDOMAIN in the oracle.com/oraclecorp.com > zones. Looks like someone has reconfigured the nameservers for > dynect.net and then immediately pulled the A/AAAA records for the old > names without waiting out the TTL on the old NS records.
This was https://www.dynstatus.com/incidents/1xlbp98xr3y2. > Unbound gives up and returns SERVFAIL for anything using dynect.net > because it exceeds the maximum number of NXDOMAIN responses for > nameserver hostnames. I opened a bug report against Unbound here: https://github.com/NLnetLabs/unbound/issues/687 This was apparently a mitigation for "NX NS Attack": https://nlnetlabs.nl/downloads/unbound/CVE-2020-12662_2020-12663.txt Well, Petr warned us: https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/ Unlike traditional random subdomain attacks, in case of NXNSAttack queries are generated by resolver itself. This difference allows vendors to implement simple mitigation techniques like limiting number names resolved when processing a single delegation etc. Obvious advantage is that it is simple, at least in theory. Disadvantage of mitigation based on counters is that it requires vendors to invent arbitrary limits not based in the DNS protocol specification, basically determining maximum packet amplification factor. At the same time these arbitrary limits might break resolution for some domains because they put additional limits on the resolution process. This is a very practical problem because recently published research estimates that 4 % of second-level domains (example.com.) have a problem in their delegation from top-level (com.), so any change which adds arbitrary limits to retries during resolution process has to be weighted very carefully. In upcoming days we will see how successful vendors were in determining their magic numbers and if they get away without breaking any major domains. -- Robert Edmonds _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
