Critical Cache Poisoning Vulnerability in Dnsmasq

(bug in HN, have to have this for next block to format correctly)

  --fast-dns-retry=[<initial retry delay in ms>[,<time to continue retries in ms>]]
      Under normal circumstances, dnsmasq relies on DNS clients to do retries; it does not generate timeouts itself. Setting this option instructs dnsmasq to generate its own retries starting after a delay which defaults to 1000ms. If the second parameter is given this controls how long the retries will continue for otherwise this defaults to 10000ms. Retries are repeated with exponential backoff. Using this option increases memory usage and network bandwidth. If not otherwise configured, this option is activated with the default parameters when --dnssec is set.

  --dnssec
      Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the DNSSEC records needed to validate the replies. The replies are validated and the result returned as the Authenticated Data bit in the DNS packet. In addition the DNSSEC records are stored in the cache, making validation by clients more efficient. Note that validation by clients is the most secure DNSSEC mode, but for clients unable to do validation, use of the AD bit set by dnsmasq is useful, provided that the network between the dnsmasq server and the client is trusted. Dnsmasq must be compiled with HAVE_DNSSEC enabled, and DNSSEC trust anchors provided, see --trust-anchor. Because the DNSSEC validation process uses the cache, it is not permitted to reduce the cache size below the default when DNSSEC is enabled. The nameservers upstream of dnsmasq must be DNSSEC-capable, ie capable of returning DNSSEC records with data. If they are not, then dnsmasq will not be able to determine the trusted status of answers and this means that DNS service will be entirely broken.

Query ID prediction attacks are not in fact the point of DNSSEC, which will not actually meaningfully address this attack because almost nothing in the DNS is signed.

No it didn't. The DNSSEC was a DoD/TIS project meant to make the DNS security model cohere with IPSEC, which at the time people believed would be the standard transport on the Internet. Then, when DNSSEC began to be taken more seriously as an operational security measure, it was because of the difficulty in authenticating additional data records in DNS responses --- the attacks Eugene Kashpureff used during his weird AlterNIC coup attempt. These aren't ID collision attacks at all.

It wasn't until Kaminsky combined transaction IDs with additional data poisoning in 2008 --- an entirely novel attack --- that BIND began randomizing and gave up on holding out for DNSSEC. You'll notice that since 2008 DNS cache poisoning has basically vanished as a real operational security concern. That's not because of DNSSEC.

It can be actively exploited in the same way that TCP initial sequence numbers can be exploited: when something else goes horribly wrong in the protocol stack. Contra the claim across the thread that the fundamental fix to this problem is DNSSEC (which is never going to happen), the real fix for all this stuff is not to trust this layer of the TCP/IP stack for authentication in the first place: you do cryptography, at the transport layer (not in the name lookup) so that IP address spoofing doesn't matter in the first place.

Sure. As it is a fundamental flaw in the DNS protocol itself, it is not unique to dnsmasq (it applies to any resolver).

> DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives).

Interesting assertion -- do you have anything to back this up?

While DNSSEC can prevent a name server operator from effectively modifying zone data (at least without the signing key and for resolvers that bother to validate), protecting against an authoritative name server operator from maliciously modifying the zone data in their server was not a significant consideration in any of the IETF/implementation discussions I was in (back in the late 90s, I ran ISC during the development of BIND 9.0 and participated quite heavily in DNS-related working groups).

Transport security obviously only protects the channel of communication. It does nothing for ensuring the authenticity of the data. In order to protect the data so it doesn't matter where the data comes from (authoritative, resolver, off the back of a truck, etc.), you have to take the steps DNSSEC takes. This was recognized as far back as 1993.

Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)