- never trust a single DNS server as a source of truth
- always rely on transport encryption, which DNS on port 53 (via UDP) does not offer
- verify your results statistically, rotate servers (DNS ronin), and endpoint protocols in order to verify there's no MITM
- deactivate message compression if possible. Naive implementations are vulnerable to both stack and buffer overflows (see NAMEWRECK).
- don't rely on DNS cookies, and always assume there can be multiple records with different types in a reply to a single question.
- DNS TTL 0 is a fix for stupidity, and nothing else.
If any of the above isn't respected it's your fault as a DNS client, because the protocol was designed when the internet was a nice place and everybody literally knew everybody via the /etc/hosts file dumps.
That's why I'm a strong believer in DNS via HTTPS, because having a better and more reliable transport protocol would fix a lot of the issues people/clients have to face.
DNS via TLS turned out to be useless because the dedicated port 853 for it literally gets blocked by ISPs and nobody can do shit about it.
PowerDNS tried this early on, it ended poorly because a client with a large installed base assumed that answers following the question section would start with a compression pointer.
There have been a few DNS flags days in recent years where recursive DNS resolvers would remove certain work arounds for bugs in authoritative DNS servers (or server configs).
In short, classical DNS has a long list of issues.
As for caching the NSEC or NSEC3, that's an optimization that is not possible without DNSSEC, but DNS resolution would work equally well without this feature.
Most recursive resolvers are not open to the public, so they don't need extensive protection from malicious clients. Caching an NSEC or NSEC3 helps against certain denial of service attacks. But it has a cost in term of failing in the case of bad NSEC/NSEC3 data.
That said, point of DNS flags days is to just break protocol violations instead of creating a work around. If you don't, you get into the mess where certain websites only work with certain browsers, etc. Many years ago, browsers would take a very lenient stance at wrong web PKI certificates allowing the user to grant an exceptions. These days, that is mostly over.
This would be an excellent security research topic. How to design non-single point of failure security that both fail safe and do not cause down time when misconfigured.
The bug here as I understand it: this hosting provider has a client whose DNS authority server DNSSEC-signs their records. That server is misconfigured.
When you look up a nonexistent record in DNS, you get a simple response back that says there aren't any matching records. Easy enough!
But you can't do that in DNSSEC, because denial "needs" to be signed. What DNSSEC does instead is essentially return a descriptor of a lexicographically ordered span of records that does exist, and doesn't include the record you were looking for. You notice that, and interpret as denial. See, simple! Oh, also, the names in those records are password-hashed, because otherwise DNSSEC would be publishing raw zone dumps to serve errors. Except those password hashes are very straightforwardly cracked. But I digress. The records carrying these spans in modern servers are called NSEC3s. Think of a tuple (start-name, stop-name, record-types).
If you asked this client's server for a nonexistent A record, you'd get an NSEC3 back that properly established the covering span of names in which A was nonexistent --- but it erroneously signaled that other record types for that span (most notably MX) were also nonexistent.†
The fun part of this bug is that it's effectively a vulnerability: an attacker can query random recursive caches for nonexistent record types to generate a cached denial records for records that do exist. Which is not something that can't go wrong in ordinary unsigned DNS! It's a vulnerability that DNSSEC adds to the DNS.
This is your periodic reminder that virtually none of the industry's largest tech companies (and concomitantly well-resourced security teams) use DNSSEC, which you can confirm quickly for yourself by running `host -t ds <domain>` and noting that they don't have DS records.
Previous (recent) thread, in which DNSSEC blew up (checks notes) all of Slack: https://news.ycombinator.com/item?id=29378633
† (If I've got the particulars of this wrong, that makes it even funnier, since it's suggesting that it's difficult even to describe what can go wrong with DNSSEC).