Wishful thinking: OpenWRT userland can now replace dnsmasq with two separate programs. The DHCP server, odhcpd, is already included (for DHCP6). They just need to write the DNS software.
I always disable/remove dnsmasq when I can. Compared to the alternatives, I have never liked it. This is at least the second major dnsmasq coding mistake that has been published in recent memory.^1 Pi-Hole was based on dnsmasq which turned me off that as well.
While the functionality/complexity of dnsmasq makes me nervous and I use it (I don't have a use case for it), it isn't clear to me that dnsmasq is doing anything wrong in this particular case.
I'm confused. There are no "special characters" in domain names -- they're length-tagged 8-bit clean. Hostnames (as opposed to domain names) are limited by convention to a subset of ASCII, but that shouldn't impact resolver logic.
What resolvers silently discard (or do anything else weird with) requests with QNAMES that have non-hostname queries (which aren't "malformed")?
The "special character" thing sounds like a red herring: IIUC, dnsmasq isn't dealing with lost responses correctly, creating a window for birthday collision attack?
Dnsmasq forwards invalid requests (containing invalid characters) to the resolver. The resolver silently ignores these requests.
However, Dnsmasq continues to wait for a response. The attacker only needs to brute force 32 bits (source port and TxID) to falsify a response and poison the cache.
The correct and expected behaviour of Dnsmasq would have been not to forward invalid requests to the resolver.
They aren't "invalid requests". You can put literally anything in a domain name (see RFC 2181, section 11) and the upstream should respond. I'm curious what resolvers are dropping these requests.
The correct behavior is for dnsmasq to forward requests to the upstream regardless of the content of the QNAME. If dnsmasq doesn't get a response back in some reasonable amount of time, it should (probably) return SERVFAIL to its client.
Further, DNS mostly uses UDP which is unreliable -- all DNS clients must deal with the query or response being lost. Dnsmasq's timeouts might be overly long (I didn't bother to check), but this is a minor configuration issue.
This sounds like the (well known) birthday attack, the defense of which is precisely the point of DNSSEC. AFAIK, dnsmasq supports DNSSEC, so the right answer is to turn on validation.
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.
> Query ID prediction attacks are not in fact the point of DNSSEC
Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (or more generally, flooding attacks) aim to corrupt DNS data? Do you deny the 16-bit transaction ID allows for effective flooding attacks?
As for "almost nothing in the DNS is signed", while it's true the percentage of second-level domains aren't signed, the DNS root is signed, all generic top-level domains, and the vast majority of country code TLDs are signed. In some countries (e.g., The Netherlands) more than 50% of the zones in their ccTLD are signed. As we've seen empirically, with improved automation/tools and authoritative servers that turn on DNSSEC-signing by default, the percentage will go up.
I deny that query ID protection was the impetus for the development of DNSSEC and that the earliest advocacy for it as an operational security tool, rather than a (government-funded) design improvement for the entire TCP/IP stack, was about query ID prediction. Like you, I was there at the time; if the NANOG archives go back that far, you'll see me on the threads babbling about this.
This notion of DNSSEC signatures being widespread comes up in every thread about the protocol. Here's a little thingy I threw together because I got tired of typing out the bash "dig" loop to regenerate it in threads:
Note that the Tranco list is international, so captures popular zones in places that have automatic (and security-theatric) DNSSEC signatures, as well as amplifying the impact of vendors like Cloudflare who have several different zones in the top 1000. Even with all that included: single digits.
It's been over 30 years of tooling work on DNSSEC --- in recent time intervals, DNSSEC adoption in North America has gone down. Stick a fork in it.
I guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw.
In any event, that's a nice site that provides useful stats.
Thanks! For what it's worth: I think hashing out the origins of DNSSEC is a super interesting conversation to have, and I'm happy you're here pushing back on what I'm saying (the truth is going to be somewhere in between the two of us).
(The graph shows that DNSSEC usage is instead increasing since the end of last year, and at that time, its lowest point, was only ever as low as it was back in 2023.)
That page doesn't load right now, but when it does, I encourage people to click through to it and see what I was talking about. Thanks for sourcing it for me!
It's still not loading for me but as I recall from the last time this was posted, it showed 2023 with a 15% (!) drop in North American signed zones, and us still well below the peak --- that peak being less than 1% of all North American zones.
There is a 15% drop like you describe, but as the other commenter said, it doesn't show usage falling for the past year (as you had implied).
I have no dog in this race, I don't care about DNSSEC. If you can't access the page, that's your business. But it bothers me that you would assert this data agrees with your point without even looking at it. That's pretty uncharitable.
> it doesn't show usage falling for the past year (as you had said).
Note how he cleverly did not say that; he said “in recent time intervals”. And you can certainly count the time from 2023-2024 as being “recent”. He technically was not wrong, and technically did not lie.
Alright. I've edited my comment to "implied." I'm assuming he's engaging in reasonably good faith and would temper his statement if he learned that adoption has been rising for a year. If I believed otherwise I wouldn't bother engaging at all.
(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.
> Too many domains which are incorrectly configured leading to non-existing domain errors.
That's an interesting and somewhat surprising data point given the use of DNSSEC validation at public resolvers (e.g., 1.1.1.1, 8.8.8.8, etc.). Might be something that would be useful to track by those following DNSSEC deployment.
For selectively disabling DNSSEC validation, I gather PiHole+dnsmasq doesn't support Reverse Trust Anchors (RTA). Unfortunate.
Yes. RFC 2181 § 11 explicitly contradicts this report.
That said, I should point out that there is nowadays a loophole for special-casing labels that begin with underscore, called out by the SVCB document. The loophole does not allow for dropping the client requests, though.
On the gripping hand, all that this report boils down to is a rediscovery that if the queried server does not answer immediately, there's a window for an attacker with access to the path between client and server (or at least the ability to blindly route packets into that path with forged source addresses) to inject forged responses; that the message ID and random port number system is woefully inadequate for making brute forcing hard at even late 1990s network speeds; and that most of the mitigation techniques for forgery (including the PowerDNS one called out in this report) are useless if the attacker can see the query packet go by in the first place. The right answer is proper cryptography, not nonsense about punctuation characters that are supposedly "malformed".
If the report is correct, then I think something else is being inferred / implied.
If dnsmasq was only caching the ANSWER section, then the only thing which could be poisoned would be the qname. If cache poisoning for arbitrary domain names is being observed, then it would seem that information from the ADDITIONAL or AUTHORITY is being cached as well.
The report and others are calling this "cache poisoning". That's a misnomer. It is not cache poisoning in the long-standing sense of the phrase. It is very simply equally long-standing simple DNS/UDP brute force response forgery.
They're also relying upon the random source port being allocated from a subset of the available port range, 32768 to 61000 in their default setting.
The claim in the code is that it is Google Public DNS that is failing to respond to queries where the domain name has had an extra label prepended, and that label is 1 character long and the character is a tilde.
Google Public DNS has no such non-response problems with ~.www.example.com in my part of the world.
However, note that they are injecting the forged responses from the very same machine that sent the initial query to dnsmasq, with no delay whatsoever. Whereas it takes Google Public DNS a second or so to look up ~.www.example.com here. So really there's no methodologically sound evidence that Google Public DNS even has the fault with these punctuation characters as claimed.
is this "avunit" someone from the reporting team? it seems created few hours ago, and it's using 8.8.8.8 which does not timeout as they claim; and the crux of the attack there is just that local UDP is faster than remote UDP
edit: the only github account of the reporter is github.com/idealeer . this avunit is something random
Hint: Look at the mailing list post and the repository's "About" blurb. There are probably only 2 people in the world who want their own new coined name for this old hat stuff to stick. (-: They put their demonstration code up and sent out their mailing list post just over 130 minutes apart.
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.
I think the issue is that dnsmasq will happily forward requests that contain characters outside the ASCII subset, but the upstream resolver will silently drop them after correctly determining that they're invalid. So the special characters are a way of reliably triggering the silent drop upstream. This is required because it takes many attempts for the brute force attack to succeed.
"Those [length] restrictions aside, any binary string whatever can be used as the label of any resource record.
Dnsmasq should (MUST in RFC 2119 language) forward requests -- it would be a bug not to. The upstream resolver shouldn't (MUST NOT in RFC 2119 language) silently drop them -- it would be a bug if they did.
Brute forcing transaction/port ID collisions to poison the cache is a long known flaw in the DNS protocol (it has been known since at least 1993) that led to the creation of DNSSEC.
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's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.
I have around here somewhere the mail spool of the mailing list contemporaneous to the time and stand by my interpretation (the dns-security@tis.com list) --- I also worked "at TIS" (at Network Associates), writing the DNS security checks for NAI's security scanner (which included serverside components that actively exploited all these attacks) --- but that was a year or two after the contract, as I understand it. The COAST paper you're citing predates practical exploitation of QID prediction by 2 years, and the most significant DNS spoofing exploits of the time (the ones Kashpureff used) did not involve QID prediction.
I think the Kremlinology here is super interesting and I'm happy to keep digging with you, but again: DNS spoofing was a live issue for a couple months in 1995, when it was resolved by QID randomization in BIND (and then QID+port randomization in djbdns), and then a live issue again for about a month and a half in 2008, when it was finally resolved by QID+port randomization in BIND. DNSSEC had nothing at all to do with it.
I can't think of a recursing resolver which discards / disallows non-hostname queries. The only case I've run into, ever, is the stub resolver in the Ignition SCADA platform (running Java on top of the Azul JVM).
(It's on my list to try loading the Python 2 version of dnspython and see if that works. Yeah, Ignition's internal scripting layer is running Jython, at version 2.)
Edit: that's not to say that some middlebox isn't dropping them in the name of "securitah".
Your hostnames with emojis are violating RFC 1123 as modified by RFC 2181. But as I said, it is a convention and, of course, RFCs aren't laws of physics, you can violate them at the risk of potential interoperability failure (e.g., maybe what this disclosure stumbled on?)
I thought they have accidentally "responsibly disclosed" the vulnerability directly into a public mailing list, but the attached pdf is dated >3 months ago.
So assume it's a bit of an inaccurate phrasing.
EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.
Sure, but the author publishes their email address on the main dnsmasq page:
Contact.
There is a dnsmasq mailing list at http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss which should be the first location for queries, bugreports, suggestions etc. The list is mirrored, with a search facility, at https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/. You can contact me at simon@thekelleys.org.uk.
google's dns resolver 8.8.8.8 correctly resolves the "special character" domains btw; so if you have 8.8.8.8 as your recursive resolver in dnsmasq, this doesn't seem to be an issue.
They're giving Google Public DNS as example of a failure here. Whereas what happens in my testing is that it's a cache miss for Google Public DNS, which takes a little over 1 second to look everything up from cold in my part of the world for ~.www.example.com .
And in that second they have more than enough time, at LAN speeds (since they are injecting the forged responses from the dnsmasq client machine), to send a tonne of forged DNS/UDP responses which are only around a hundred bytes long each.
A bit surprising that the transaction ID is only 16 bits. Presumably the source port doesn't even need to be guessed if someone is on the path between dnsmasq and the upstream DNS server.
Correct. And this isn't surprising to those of us who have been involved in this stuff for years. This is a very well known problem, is not specific to dnsmasq, and not a novel discovery by these people in any way.
DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Transport security like dnscrypt and DoH were created to solve this problem. DNS cookies are also strong mitigations.
> 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.
Transport security decisively addresses query ID prediction attacks, without requiring forklift upgrades of the entire DNS infrastructure of the Internet, and has the benefit of working for individual sites even when not widely deployed elsewhere. If the concern is transactional attacks like this dnsmasq thing, advocating for DNSSEC instead of DoH/DoT seems like engineering malpractice.
Transport security protects the channel, not the data. DNSSEC protects the data so that the channel doesn't matter. Given how the DNS is deployed particularly in enterprise environments, there have been too many times when protecting the channel simply meant data corruption crept in someplace in the sometimes ridiculous chains of forwarders and caches.
Oh, and it doesn't appear dnsmasq supports DoH/DoT forwarding (not positive as I don't use it and haven't looked at the code). It does support DNSSEC.
At multiple points on this thread you tell other people here that DNSSEC is the correct solution both for this dnsmasq security issue and for query ID prediction attacks generally. All of those are channel attacks that have nothing to do with the authenticity of DNS records.
I happen to think DNSSEC, writ large, is also engineering malpractice, but when I use that term just upthread, I was referring to your insistence that people deploy a top-down data authentication mechanism in order to resolve a trivial transaction spoofing attack, given the availability of multiple existing tools that decisively address those kinds of problems without any of the expense and coordination required for DNSSEC.
You're all over this thread and every other DNS thread, even the ones that don't have much to do with DNSSEC, constantly complaining about DNSSEC. Why?
Last time you were arguing DNSSEC wouldn't solve BGP hijacks because whoever was hijacking the DNS server would just hijack the web server instead.
I'm unclear there is a security issue with dnsmasq -- maybe leaving a transaction alive too long (but then again, what does "too long" mean these days?). However, I haven't looked into the "vulnerability" referenced to be sure (the "malformed name" aspect of the report doesn't fill me with confidence).
I contend that creating signatures over the data at the sending side and then validating those signatures at the receiving end is superior protection to encrypting the channel over which the data is transmitted. Protecting the data is end-to-end. Protecting the channel is hop-by-hop. If you could ensure that the client speaks directly to the authoritative(s), the protection would be equivalent. But that's not how the DNS is operationally deployed (dnsmasq is a perfect example: forwarders really shouldn't exist).
I would agree with you that operationally, DNSSEC deployment is lacking (i.e., water is wet) and the requirement for both the authoritative side and resolving side to simultaneously implement is a (very) heavy lift. However, even your Tranco stats show that there are pockets of non-trivial deployment (e.g., governments) and I believe the trend is increased deployment over the long term globally.
Fortunately, it's not either/or. I personally prefer DoT/DoH to a trusted (i.e., that I run) resolver that DNSSEC validates. Unfortunately, as dnsmasq doesn't appear to implement forwarding to DoT/DoH resolvers, you're left with DNSSEC or not using dnsmasq (which is what I gather you're recommending).
So you're saying the end user does not care about the data (IP addresses, mail servers, etc.) for the domain names they're trying to reach and they'd be perfectly happy (say) going to the IP address of an attacker controlled website instead of their bank? Interesting position.
They're being contrarian and pedantic for the sake of being contrarian and pedantic. No, DNSSEC doesn't protect anything the user cares about because it protects IP addresses and the user doesn't care about IP addresses. Yes, DNSSEC protects the user because it blocks one vector by which they can be redirected to a phishing site.
there are easily 300m+ installs of dnsmasq that will never be updated, because they are buried in forked , unmaintained firmwares on consumer routers.
We truly need a "right to repair" for IOT & consumer networking devices. Any device not receiving monthly security updates should have the firmware keys & source published so the community can take over.
Many router firmwares have dnsmasq for DNS but may never be upgraded?
There are a number of other DNS servers which are not written in C, which support transport-secured DNS like DoH (DNS-over-HTTP), DoT, and DoQ; but do they correctly handle this malformed input?
Dnsmasq forwards queries with special characters (e.g., ~, !, *, _) to upstream recursive resolvers.
Some upstream recursive resolvers silently discard such malformed queries (no NXDomain/ServFail response).
Dnsmasq does not validate or detect this situation, and waits silently, creating a large attack window.
During this window, attackers can brute-force TxID (16-bit) and source port (16-bit) with a high probability of success (birthday paradox effect).
Security Impact
Attackers can poison any cached domain name in Dnsmasq.
[...]
We recommend adding:
Detection mechanisms when upstream resolvers remain silent.
Rate limiting and spoof-detection techniques, similar to those in PowerDNS
Setting your upstream to 1.1.1.1 or 8.8.8.8 should mitigate this, as these appear to respond with NXDOMAIN to invalid domains rather than fail silently which would close the window for the attack.
Better solution that doesn't rely on DNSSEC is use stub resolver that can forward requests on DoH; like unbound or dnsdist.
dnsmasq cannot do this and just forwards UDP to UDP and TCP to TCP. (and doesn't know DoT or DoH)
DoH (and DoT, DNS over TLS) doesn't have this problem, as the whole thing is secured. (Well, this concrete problem might actually be prevented just by using plain old DNS over TCP, but I am not sure about that.)
Wishful thinking: OpenWRT userland can now replace dnsmasq with two separate programs. The DHCP server, odhcpd, is already included (for DHCP6). They just need to write the DNS software.
I always disable/remove dnsmasq when I can. Compared to the alternatives, I have never liked it. This is at least the second major dnsmasq coding mistake that has been published in recent memory.^1 Pi-Hole was based on dnsmasq which turned me off that as well.
1.
https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq...
https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...
https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-b...
https://web.archive.org/web/20210119133618if_/https://www.js...
https://seclists.org/oss-sec/2021/q1/49
Anyway, never gonna happen. Just wishful thinking.
Would OpenWrt even be vulnerable in the first place?
If you're using dnsmasq behind NAT or a stateful firewall, how would an attacker be able to access the service in the first place?
While the functionality/complexity of dnsmasq makes me nervous and I use it (I don't have a use case for it), it isn't clear to me that dnsmasq is doing anything wrong in this particular case.
> This is at least the second major dnsmasq coding mistake that has been published in recent memory.
What was the first?
There was like a memory corruption RCE not long ago.
I'm confused. There are no "special characters" in domain names -- they're length-tagged 8-bit clean. Hostnames (as opposed to domain names) are limited by convention to a subset of ASCII, but that shouldn't impact resolver logic.
What resolvers silently discard (or do anything else weird with) requests with QNAMES that have non-hostname queries (which aren't "malformed")?
The "special character" thing sounds like a red herring: IIUC, dnsmasq isn't dealing with lost responses correctly, creating a window for birthday collision attack?
Dnsmasq forwards invalid requests (containing invalid characters) to the resolver. The resolver silently ignores these requests.
However, Dnsmasq continues to wait for a response. The attacker only needs to brute force 32 bits (source port and TxID) to falsify a response and poison the cache.
The correct and expected behaviour of Dnsmasq would have been not to forward invalid requests to the resolver.
No.
They aren't "invalid requests". You can put literally anything in a domain name (see RFC 2181, section 11) and the upstream should respond. I'm curious what resolvers are dropping these requests.
The correct behavior is for dnsmasq to forward requests to the upstream regardless of the content of the QNAME. If dnsmasq doesn't get a response back in some reasonable amount of time, it should (probably) return SERVFAIL to its client.
Further, DNS mostly uses UDP which is unreliable -- all DNS clients must deal with the query or response being lost. Dnsmasq's timeouts might be overly long (I didn't bother to check), but this is a minor configuration issue.
This sounds like the (well known) birthday attack, the defense of which is precisely the point of DNSSEC. AFAIK, dnsmasq supports DNSSEC, so the right answer is to turn on validation.
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.
> Query ID prediction attacks are not in fact the point of DNSSEC
Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (or more generally, flooding attacks) aim to corrupt DNS data? Do you deny the 16-bit transaction ID allows for effective flooding attacks?
As for "almost nothing in the DNS is signed", while it's true the percentage of second-level domains aren't signed, the DNS root is signed, all generic top-level domains, and the vast majority of country code TLDs are signed. In some countries (e.g., The Netherlands) more than 50% of the zones in their ccTLD are signed. As we've seen empirically, with improved automation/tools and authoritative servers that turn on DNSSEC-signing by default, the percentage will go up.
I deny that query ID protection was the impetus for the development of DNSSEC and that the earliest advocacy for it as an operational security tool, rather than a (government-funded) design improvement for the entire TCP/IP stack, was about query ID prediction. Like you, I was there at the time; if the NANOG archives go back that far, you'll see me on the threads babbling about this.
This notion of DNSSEC signatures being widespread comes up in every thread about the protocol. Here's a little thingy I threw together because I got tired of typing out the bash "dig" loop to regenerate it in threads:
https://dnssecmenot.fly.dev/
Note that the Tranco list is international, so captures popular zones in places that have automatic (and security-theatric) DNSSEC signatures, as well as amplifying the impact of vendors like Cloudflare who have several different zones in the top 1000. Even with all that included: single digits.
It's been over 30 years of tooling work on DNSSEC --- in recent time intervals, DNSSEC adoption in North America has gone down. Stick a fork in it.
I guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw.
In any event, that's a nice site that provides useful stats.
Thanks! For what it's worth: I think hashing out the origins of DNSSEC is a super interesting conversation to have, and I'm happy you're here pushing back on what I'm saying (the truth is going to be somewhere in between the two of us).
> in recent time intervals
If you get to pick the specific time interval, you can prove anything.
Why don’t you link the full graph? <https://www.verisign.com/en_US/company-information/verisign-...>
(The graph shows that DNSSEC usage is instead increasing since the end of last year, and at that time, its lowest point, was only ever as low as it was back in 2023.)
That page doesn't load right now, but when it does, I encourage people to click through to it and see what I was talking about. Thanks for sourcing it for me!
I took a look at it. It comports much closer with what GP was saying. It shows adoption being flat as a percentage and rising in absolute terms.
It's still not loading for me but as I recall from the last time this was posted, it showed 2023 with a 15% (!) drop in North American signed zones, and us still well below the peak --- that peak being less than 1% of all North American zones.
https://web.archive.org/web/20250720163940/https://www.veris...
There is a 15% drop like you describe, but as the other commenter said, it doesn't show usage falling for the past year (as you had implied).
I have no dog in this race, I don't care about DNSSEC. If you can't access the page, that's your business. But it bothers me that you would assert this data agrees with your point without even looking at it. That's pretty uncharitable.
> it doesn't show usage falling for the past year (as you had said).
Note how he cleverly did not say that; he said “in recent time intervals”. And you can certainly count the time from 2023-2024 as being “recent”. He technically was not wrong, and technically did not lie.
Alright. I've edited my comment to "implied." I'm assuming he's engaging in reasonably good faith and would temper his statement if he learned that adoption has been rising for a year. If I believed otherwise I wouldn't bother engaging at all.
(bug in HN, have to have this for next block to format correctly)
> AFAIK, dnsmasq supports DNSSEC, so the right answer is to turn on validation.
Just disabled DNSSEC in my PiHole. Too many domains which are incorrectly configured leading to non-existing domain errors.
And at least as far as I could find, PiHole has no way to selectively disable DNSSEC validation for certain domains.
> Too many domains which are incorrectly configured leading to non-existing domain errors.
That's an interesting and somewhat surprising data point given the use of DNSSEC validation at public resolvers (e.g., 1.1.1.1, 8.8.8.8, etc.). Might be something that would be useful to track by those following DNSSEC deployment.
For selectively disabling DNSSEC validation, I gather PiHole+dnsmasq doesn't support Reverse Trust Anchors (RTA). Unfortunate.
> The attacker only needs to brute force 32 bits (source port and TxID) to falsify a response and poison the cache.
And to be clear: while there are 4.3 billion numbers, the birthday paradox means you only need to spam 65,535 UDP packets to succeed
I've not read the details, but given that things aren't being matched against themselves--
Seems like you need to send ~ 2^16 requests and then ~ 2^16 spoofed replies.
Yes. RFC 2181 § 11 explicitly contradicts this report.
That said, I should point out that there is nowadays a loophole for special-casing labels that begin with underscore, called out by the SVCB document. The loophole does not allow for dropping the client requests, though.
On the gripping hand, all that this report boils down to is a rediscovery that if the queried server does not answer immediately, there's a window for an attacker with access to the path between client and server (or at least the ability to blindly route packets into that path with forged source addresses) to inject forged responses; that the message ID and random port number system is woefully inadequate for making brute forcing hard at even late 1990s network speeds; and that most of the mitigation techniques for forgery (including the PowerDNS one called out in this report) are useless if the attacker can see the query packet go by in the first place. The right answer is proper cryptography, not nonsense about punctuation characters that are supposedly "malformed".
Something we have known since 2002.
* https://cr.yp.to/djbdns/forgery.html
The DNS protocol is a terrible protocol. This report is not some novel discovery.
A nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...)
If the report is correct, then I think something else is being inferred / implied.
If dnsmasq was only caching the ANSWER section, then the only thing which could be poisoned would be the qname. If cache poisoning for arbitrary domain names is being observed, then it would seem that information from the ADDITIONAL or AUTHORITY is being cached as well.
The report and others are calling this "cache poisoning". That's a misnomer. It is not cache poisoning in the long-standing sense of the phrase. It is very simply equally long-standing simple DNS/UDP brute force response forgery.
* https://github.com/Avunit/Dnsmasq-Cache-Poisoning/blob/main/...
They're also relying upon the random source port being allocated from a subset of the available port range, 32768 to 61000 in their default setting.
The claim in the code is that it is Google Public DNS that is failing to respond to queries where the domain name has had an extra label prepended, and that label is 1 character long and the character is a tilde.
Google Public DNS has no such non-response problems with ~.www.example.com in my part of the world.
However, note that they are injecting the forged responses from the very same machine that sent the initial query to dnsmasq, with no delay whatsoever. Whereas it takes Google Public DNS a second or so to look up ~.www.example.com here. So really there's no methodologically sound evidence that Google Public DNS even has the fault with these punctuation characters as claimed.
is this "avunit" someone from the reporting team? it seems created few hours ago, and it's using 8.8.8.8 which does not timeout as they claim; and the crux of the attack there is just that local UDP is faster than remote UDP
edit: the only github account of the reporter is github.com/idealeer . this avunit is something random
Hint: Look at the mailing list post and the repository's "About" blurb. There are probably only 2 people in the world who want their own new coined name for this old hat stuff to stick. (-: They put their demonstration code up and sent out their mailing list post just over 130 minutes apart.
I think someone misunderstood the mailing list post and made a PoC. Because google's 8.8.8.8 does NOT timeout...
Novel or not, this seems like it can be actively exploited?
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).
I think the issue is that dnsmasq will happily forward requests that contain characters outside the ASCII subset, but the upstream resolver will silently drop them after correctly determining that they're invalid. So the special characters are a way of reliably triggering the silent drop upstream. This is required because it takes many attempts for the brute force attack to succeed.
No. RFC 2181, section 11 states explicitly:
"Those [length] restrictions aside, any binary string whatever can be used as the label of any resource record.
Dnsmasq should (MUST in RFC 2119 language) forward requests -- it would be a bug not to. The upstream resolver shouldn't (MUST NOT in RFC 2119 language) silently drop them -- it would be a bug if they did.
Brute forcing transaction/port ID collisions to poison the cache is a long known flaw in the DNS protocol (it has been known since at least 1993) that led to the creation of DNSSEC.
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's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.
I have around here somewhere the mail spool of the mailing list contemporaneous to the time and stand by my interpretation (the dns-security@tis.com list) --- I also worked "at TIS" (at Network Associates), writing the DNS security checks for NAI's security scanner (which included serverside components that actively exploited all these attacks) --- but that was a year or two after the contract, as I understand it. The COAST paper you're citing predates practical exploitation of QID prediction by 2 years, and the most significant DNS spoofing exploits of the time (the ones Kashpureff used) did not involve QID prediction.
I think the Kremlinology here is super interesting and I'm happy to keep digging with you, but again: DNS spoofing was a live issue for a couple months in 1995, when it was resolved by QID randomization in BIND (and then QID+port randomization in djbdns), and then a live issue again for about a month and a half in 2008, when it was finally resolved by QID+port randomization in BIND. DNSSEC had nothing at all to do with it.
I can't think of a recursing resolver which discards / disallows non-hostname queries. The only case I've run into, ever, is the stub resolver in the Ignition SCADA platform (running Java on top of the Azul JVM).
(It's on my list to try loading the Python 2 version of dnspython and see if that works. Yeah, Ignition's internal scripting layer is running Jython, at version 2.)
Edit: that's not to say that some middlebox isn't dropping them in the name of "securitah".
> are limited by convention to a subset of ASCII,
My hostnames with emojis in them might disagree.
are your hostnames with emoji using punycode?
Your hostnames with emojis are violating RFC 1123 as modified by RFC 2181. But as I said, it is a convention and, of course, RFCs aren't laws of physics, you can violate them at the risk of potential interoperability failure (e.g., maybe what this disclosure stumbled on?)
I thought they have accidentally "responsibly disclosed" the vulnerability directly into a public mailing list, but the attached pdf is dated >3 months ago.
So assume it's a bit of an inaccurate phrasing.
EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.
dnsmasq has no security contact
Sure, but the author publishes their email address on the main dnsmasq page:
Oops, accidentally posted to public mailing list?
google's dns resolver 8.8.8.8 correctly resolves the "special character" domains btw; so if you have 8.8.8.8 as your recursive resolver in dnsmasq, this doesn't seem to be an issue.
See https://news.ycombinator.com/item?id=44954517
They're giving Google Public DNS as example of a failure here. Whereas what happens in my testing is that it's a cache miss for Google Public DNS, which takes a little over 1 second to look everything up from cold in my part of the world for ~.www.example.com .
And in that second they have more than enough time, at LAN speeds (since they are injecting the forged responses from the dnsmasq client machine), to send a tonne of forged DNS/UDP responses which are only around a hundred bytes long each.
so the special characters are a red herring? and all they are doing is sending UDP responses locally faster than the recursive resolver?
I cannot believe this is true because that would be too dumb
edit: I don't see how is the avunit github related to the report. I don't think it is?
Same for 1.1.1.1 and 9.9.9.9. My ISP's resolver also returns NXDOMAIN immediately. Quick way to test:
A bit surprising that the transaction ID is only 16 bits. Presumably the source port doesn't even need to be guessed if someone is on the path between dnsmasq and the upstream DNS server.
Correct. And this isn't surprising to those of us who have been involved in this stuff for years. This is a very well known problem, is not specific to dnsmasq, and not a novel discovery by these people in any way.
This is why DNSSEC was created.
DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Transport security like dnscrypt and DoH were created to solve this problem. DNS cookies are also strong mitigations.
> 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.
Transport security decisively addresses query ID prediction attacks, without requiring forklift upgrades of the entire DNS infrastructure of the Internet, and has the benefit of working for individual sites even when not widely deployed elsewhere. If the concern is transactional attacks like this dnsmasq thing, advocating for DNSSEC instead of DoH/DoT seems like engineering malpractice.
Transport security protects the channel, not the data. DNSSEC protects the data so that the channel doesn't matter. Given how the DNS is deployed particularly in enterprise environments, there have been too many times when protecting the channel simply meant data corruption crept in someplace in the sometimes ridiculous chains of forwarders and caches.
Oh, and it doesn't appear dnsmasq supports DoH/DoT forwarding (not positive as I don't use it and haven't looked at the code). It does support DNSSEC.
At multiple points on this thread you tell other people here that DNSSEC is the correct solution both for this dnsmasq security issue and for query ID prediction attacks generally. All of those are channel attacks that have nothing to do with the authenticity of DNS records.
I happen to think DNSSEC, writ large, is also engineering malpractice, but when I use that term just upthread, I was referring to your insistence that people deploy a top-down data authentication mechanism in order to resolve a trivial transaction spoofing attack, given the availability of multiple existing tools that decisively address those kinds of problems without any of the expense and coordination required for DNSSEC.
You're all over this thread and every other DNS thread, even the ones that don't have much to do with DNSSEC, constantly complaining about DNSSEC. Why?
Last time you were arguing DNSSEC wouldn't solve BGP hijacks because whoever was hijacking the DNS server would just hijack the web server instead.
I'm unclear there is a security issue with dnsmasq -- maybe leaving a transaction alive too long (but then again, what does "too long" mean these days?). However, I haven't looked into the "vulnerability" referenced to be sure (the "malformed name" aspect of the report doesn't fill me with confidence).
I contend that creating signatures over the data at the sending side and then validating those signatures at the receiving end is superior protection to encrypting the channel over which the data is transmitted. Protecting the data is end-to-end. Protecting the channel is hop-by-hop. If you could ensure that the client speaks directly to the authoritative(s), the protection would be equivalent. But that's not how the DNS is operationally deployed (dnsmasq is a perfect example: forwarders really shouldn't exist).
I would agree with you that operationally, DNSSEC deployment is lacking (i.e., water is wet) and the requirement for both the authoritative side and resolving side to simultaneously implement is a (very) heavy lift. However, even your Tranco stats show that there are pockets of non-trivial deployment (e.g., governments) and I believe the trend is increased deployment over the long term globally.
Fortunately, it's not either/or. I personally prefer DoT/DoH to a trusted (i.e., that I run) resolver that DNSSEC validates. Unfortunately, as dnsmasq doesn't appear to implement forwarding to DoT/DoH resolvers, you're left with DNSSEC or not using dnsmasq (which is what I gather you're recommending).
DNSSEC most certainly does _not_ protect any data that an end user cares about.
So you're saying the end user does not care about the data (IP addresses, mail servers, etc.) for the domain names they're trying to reach and they'd be perfectly happy (say) going to the IP address of an attacker controlled website instead of their bank? Interesting position.
They're being contrarian and pedantic for the sake of being contrarian and pedantic. No, DNSSEC doesn't protect anything the user cares about because it protects IP addresses and the user doesn't care about IP addresses. Yes, DNSSEC protects the user because it blocks one vector by which they can be redirected to a phishing site.
encrypted DNS goes a long way towards mitigating this as well.
Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)
there are easily 300m+ installs of dnsmasq that will never be updated, because they are buried in forked , unmaintained firmwares on consumer routers.
We truly need a "right to repair" for IOT & consumer networking devices. Any device not receiving monthly security updates should have the firmware keys & source published so the community can take over.
Many router firmwares have dnsmasq for DNS but may never be upgraded?
There are a number of other DNS servers which are not written in C, which support transport-secured DNS like DoH (DNS-over-HTTP), DoT, and DoQ; but do they correctly handle this malformed input?
From the mailing list disclosure, which doesn't yet have a CVE FWIU? https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20... :
[...] > PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearm...Would an effective mitigation be to drop inbound DNS queries that match those special characters using DPI?
Setting your upstream to 1.1.1.1 or 8.8.8.8 should mitigate this, as these appear to respond with NXDOMAIN to invalid domains rather than fail silently which would close the window for the attack.
No. The special characters thing is a red herring. All resolvers must handle a lack of response via timeout (particularly since DNS mostly uses UDP).
The correct mitigation is turning on DNSSEC. This sort of attack, known since 1993, is why DNSSEC was created.
Better solution that doesn't rely on DNSSEC is use stub resolver that can forward requests on DoH; like unbound or dnsdist.
dnsmasq cannot do this and just forwards UDP to UDP and TCP to TCP. (and doesn't know DoT or DoH)
DoH (and DoT, DNS over TLS) doesn't have this problem, as the whole thing is secured. (Well, this concrete problem might actually be prevented just by using plain old DNS over TCP, but I am not sure about that.)