[dns-operations] dynect.net outage
edmonds at mycre.ws
Sun May 29 23:12:11 UTC 2022
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:
This was apparently a mitigation for "NX NS Attack":
Well, Petr warned us:
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.
More information about the dns-operations