[dns-operations] dynect.net outage

[Robert Edmonds]

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