Critical Cache Poisoning Vulnerability in Dnsmasq(lists.thekelleys.org.uk)
lists.thekelleys.org.uk
Critical Cache Poisoning Vulnerability in Dnsmasq
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2025q3/018288.html
103 comments
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?
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.
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.
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.
(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.
> 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.
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.
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.
In any event, that's a nice site that provides useful stats.
I remember tearing my hair out in the pre-2008 era as folks tried to get source-port randomization into Bind. The response was "That's what DNSSEC is for" ... which further supports your narrative. But it's still very damning.
Source port randomization, BCP38, and then the 0x20 qname capitalization trick, all turned out to be far more practical mitigations for query-id concerns and others prioritized them. "We really need this massive internet-wide jobs-program lift of the entire Internet, without even providing confidentiality, to solve this query-id issue. Never mind the easier fixes."
Source port randomization, BCP38, and then the 0x20 qname capitalization trick, all turned out to be far more practical mitigations for query-id concerns and others prioritized them. "We really need this massive internet-wide jobs-program lift of the entire Internet, without even providing confidentiality, to solve this query-id issue. Never mind the easier fixes."
Wow this brings up memories. I was at OpenDNS when Dan gave us the heads up.
I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...
I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...
Just remember that it was never a "Kaminsky Bug" in the first place, and there's a whole community of people who had spotted it years before, who had been pooh-poohed and naysayed by BIND people for years about all this.
* https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...
* https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...
I'd be interested in more reliable sourcing for this claim.
M. Anderson was not wrong in this particular case. Indeed, Bernstein xyrself was on the bind-users mailing list discussing the vulnerability to packet forgery, just after the turn of the 21st century. The reason that the famous djbdns security guarantee excluded forgery is that it was well known then that there were basic protocol problems in this area, and basically it was speed and luck that had been keeping them at bay.
It should tell you something that even I, who am and was on a different continent to all of these people, knew about this stuff well before it became an ISC press release. I'd like to say that it was Paul Jarc who went into the consequences of what one could do with response forgeries, on Bernstein's dns mailing list, but I might be remembering the wrong person. Certainly, list regulars had read Bernstein's discussion of DNS security and realized the implications.
The logical consequences of being able to forge whatever response one likes were readily apparent. Bert Hubert noted publicly at the time of the Kaminsky announcements that xe had been not only aware of this for years,
* https://mailman.powerdns.com/pipermail/pdns-users/2008-July/...
but had even been trying to get an IETF draft approved about port+ID randomization, and bailiwick checking, acknowledging the factors involved and promoting the adoption of the well-known mitigations as mandatory.
Amusingly for the instant case of researchers rediscovering the well-known, you can read M. Hubert's first draft from a year and a half before the ISC press release, and it lays out there exactly what I laid out here elsewhere in this very discussion, about a query to Google Public DNS taking a second from cold to answer for ~.www.example.com and that being more than enough time to send a tonne of forged responses at 2006 network speeds.
* https://datatracker.ietf.org/doc/html/draft-ietf-dnsext-forg...
It should tell you something that even I, who am and was on a different continent to all of these people, knew about this stuff well before it became an ISC press release. I'd like to say that it was Paul Jarc who went into the consequences of what one could do with response forgeries, on Bernstein's dns mailing list, but I might be remembering the wrong person. Certainly, list regulars had read Bernstein's discussion of DNS security and realized the implications.
The logical consequences of being able to forge whatever response one likes were readily apparent. Bert Hubert noted publicly at the time of the Kaminsky announcements that xe had been not only aware of this for years,
* https://mailman.powerdns.com/pipermail/pdns-users/2008-July/...
but had even been trying to get an IETF draft approved about port+ID randomization, and bailiwick checking, acknowledging the factors involved and promoting the adoption of the well-known mitigations as mandatory.
Amusingly for the instant case of researchers rediscovering the well-known, you can read M. Hubert's first draft from a year and a half before the ISC press release, and it lays out there exactly what I laid out here elsewhere in this very discussion, about a query to Google Public DNS taking a second from cold to answer for ~.www.example.com and that being more than enough time to send a tonne of forged responses at 2006 network speeds.
* https://datatracker.ietf.org/doc/html/draft-ietf-dnsext-forg...
I found that post so cathartic.
This whole episode reminds me of the story of the Citigroup Center in New York. Years after its completion, an architecture student uncovered that key supports for the building had been done incorrectly and unsafely. It was at risk of collapse in high winds.
The structural engineer worked with the building owner and city to repair the building in secret, before everything was eventually made public. It makes for a story of a folk hero, and it's a great narrative of recovery. Meanwhile the stories of the structural engineers and construction supervisors who weren't woefully negligent and who just quietly built safe buildings go uncelebrated.
This whole episode reminds me of the story of the Citigroup Center in New York. Years after its completion, an architecture student uncovered that key supports for the building had been done incorrectly and unsafely. It was at risk of collapse in high winds.
The structural engineer worked with the building owner and city to repair the building in secret, before everything was eventually made public. It makes for a story of a folk hero, and it's a great narrative of recovery. Meanwhile the stories of the structural engineers and construction supervisors who weren't woefully negligent and who just quietly built safe buildings go uncelebrated.
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.)
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.
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.
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.
> 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.
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.
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.
Geoff Huston at APNIC does track this!
> 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
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.
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.
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.
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.
* 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
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 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".
(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".
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.
"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 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 [email protected] 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 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.
[deleted]
> are limited by convention to a subset of ASCII,
My hostnames with emojis in them might disagree.
My hostnames with emojis in them might disagree.
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?)
are your hostnames with emoji using punycode?
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.
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:
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/[email protected]/. You can contact me at [email protected].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.
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?
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?
In the past, this has been the case. I looked and didn’t see anything on the forum about this news, but it may be too soon to hit the forum? I don’t visit it very often.
https://forum.openwrt.org/t/security-advisory-2021-01-19-1-d...
https://openwrt.org/advisory/2021-01-19-1
https://forum.openwrt.org/t/security-advisory-2021-01-19-1-d...
https://openwrt.org/advisory/2021-01-19-1
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?
What was the first?
There was like a memory corruption RCE not long ago.
I think there were two sets of 7 total vulnerabilities at the same time so they might be perceived as one event? I don’t know for sure, the wording was kind of ambiguous.
https://openwrt.org/advisory/2021-01-19-1
> Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment.
> These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq.
https://web.archive.org/web/20250121143405/https://www.jsof-...
> DNSpooq - Kaminsky attack is back!
> 7 new vulnerabilities are being disclosed in common DNS software dnsmasq, reminiscent of 2008 weaknesses in Internet DNS Architecture
Some less breathless sourcing, though I can’t blame OP for being excited in the above post:
https://www.kb.cert.org/vuls/id/434904
https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...
https://openwrt.org/advisory/2021-01-19-1
> Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment.
> These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq.
https://web.archive.org/web/20250121143405/https://www.jsof-...
> DNSpooq - Kaminsky attack is back!
> 7 new vulnerabilities are being disclosed in common DNS software dnsmasq, reminiscent of 2008 weaknesses in Internet DNS Architecture
Some less breathless sourcing, though I can’t blame OP for being excited in the above post:
https://www.kb.cert.org/vuls/id/434904
https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...
You can just use Unbound for DNS.
Unbound unfortunately has some a pair of issues ([1][2]) that in some situations (adblocking, source address based dns selection) can make it a less than optimal match for some use-cases.
[1]: https://github.com/NLnetLabs/unbound/issues/132
[2]: https://github.com/NLnetLabs/unbound/issues/210
[1]: https://github.com/NLnetLabs/unbound/issues/132
[2]: https://github.com/NLnetLabs/unbound/issues/210
From https://github.com/NLnetLabs/unbound/issues/132
"Some users of our service (NextDNS), discovered this issue since edgekey.net has been added to some anti-tracker blocklists, resulting in the blocking of large sites like apple.com, airbnb.com, ebay.com when used with unbound."
As Pi-Hole is a modified dnsmasq, NextDNS may be a modified unbound
"Some users of our service (NextDNS), discovered this issue since edgekey.net has been added to some anti-tracker blocklists, resulting in the blocking of large sites like apple.com, airbnb.com, ebay.com when used with unbound."
As Pi-Hole is a modified dnsmasq, NextDNS may be a modified unbound
I use tinydns or nsd
You can use unbound
I do not use a cache
For HTTP I use a localhost-bound TLS forward proxy that has the DNS data in memory; I gather the DNS data in bulk from various sources using various methods; there are no remote DNS queries when I make HTTP requests
Unbound is overkill for how I use DNS on the local network
You can use unbound
I do not use a cache
For HTTP I use a localhost-bound TLS forward proxy that has the DNS data in memory; I gather the DNS data in bulk from various sources using various methods; there are no remote DNS queries when I make HTTP requests
Unbound is overkill for how I use DNS on the local network
Unbound is a recursive-only resolver. NSD is an authoritative-only resolver.
Those are different use cases.
Those are different use cases.
"Unbound is a recursive-only resolver"
https://raw.githubusercontent.com/NLnetLabs/unbound/master/d...
https://raw.githubusercontent.com/NLnetLabs/unbound/master/d...
Unbound can also answer queries from data in a text file read into memory at startup, like an authoritative nameserver would; no recursion
https://raw.githubusercontent.com/NLnetLabs/unbound/master/d...
https://raw.githubusercontent.com/NLnetLabs/unbound/master/d...
Unbound can also answer queries from data in a text file read into memory at startup, like an authoritative nameserver would; no recursion
Psst! NSD isn't a "resolver" at all. Traditional DNS terminology is tricky to use (given that what is covered by "resolver" in the RFCs does not match how most people see the system as divided up) but something that does not do the resolving part at all is definitely not a resolver.
* https://jdebp.uk/FGA/dns-server-roles.html
* https://jdebp.uk/FGA/dns-server-roles.html
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.
If you can sniff traffic from the originating server, you don't need to guess either; if you are in a position to read the source port, you can read the transaction id and vice-versa.
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.
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.
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.
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.
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.
They wrote this:
https://web.archive.org/web/20250729043725/http://sockpuppet...
They clearly seem to have strong feelings about the issue. I don’t, and I don’t know much about it either, so I will not comment further.
https://web.archive.org/web/20250729043725/http://sockpuppet...
They clearly seem to have strong feelings about the issue. I don’t, and I don’t know much about it either, so I will not comment further.
Why are you archive-linking the post? It's the same place it's always been:
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
You'll notice, I didn't bring DNSSEC into this conversation. I agree: it didn't belong here; DNSSEC has nothing to do with this dnsmasq thing.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
You'll notice, I didn't bring DNSSEC into this conversation. I agree: it didn't belong here; DNSSEC has nothing to do with this dnsmasq thing.
I archive linked it because you’re in this thread, and you operate that site. I’m removing any conflict of interest by posting it as an archive. I even used IA just to remove any hint of bias I suppose. I don’t want you doing timing attacks against me for posting it here now, or against those who may visit it later, nor do I want you to poison my DNS! I don’t even know enough about these exploits to know if it’s technically possible, but I know that you almost certainly do! I don’t think you would do this, but you’re in a position to do so.
I did not mean it as a slight by doing so. I meant it as an acknowledgment of the sensitive nature of these issues, and part of my work as an amateur journalist and archivist. I say amateur because I do not do this work for personal benefit or gain, but because I like researching and learning myself, and I don’t believe in putting a light I also read by under a bushel.
Here’s another archive:
https://archive.is/UB7xN
While searching for your post on archive.today or whatever their name is, I saw that it had also been archived without a trailing “/“ which redirects to the one with a trailing slash, so depending on how I parse what you said and how you originally posted it and how the redirect is implemented, I could see how that statement might be ambiguous but that kind of thing might be handled by your webserver software. I don’t think that it’s worth mentioning, but you did say it’s always been at that URL, which I don’t dispute. I’ve never known it to be at any other URL.
I did not mean it as a slight by doing so. I meant it as an acknowledgment of the sensitive nature of these issues, and part of my work as an amateur journalist and archivist. I say amateur because I do not do this work for personal benefit or gain, but because I like researching and learning myself, and I don’t believe in putting a light I also read by under a bushel.
Here’s another archive:
https://archive.is/UB7xN
While searching for your post on archive.today or whatever their name is, I saw that it had also been archived without a trailing “/“ which redirects to the one with a trailing slash, so depending on how I parse what you said and how you originally posted it and how the redirect is implemented, I could see how that statement might be ambiguous but that kind of thing might be handled by your webserver software. I don’t think that it’s worth mentioning, but you did say it’s always been at that URL, which I don’t dispute. I’ve never known it to be at any other URL.
There’s no conflict of interest associated with pointing to your correspondent’s own website, or one referring to their own.
I'm just giving you shit. Thanks for posting it. You're not wrong: I have longstanding strong feelings (much further back than that post) about DNSSEC, both because I had to implement it, and because I remember it being used as an excuse not to randomize DNS requests. Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!
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).
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.
> 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
Honestly this statement is not at all surprising. I would love to hear your perspective on what problem they thought was being solved.
Ensuring you have received a correct copy of a zone is the one thing we did get out of DNSSEC.
> I ran ISC during the development of BIND 9.0 and participated quite heavily in DNS-related working groups
Then we must have crossed paths. I'll happily buy you a beer or three next time.
> you have to take the steps DNSSEC takes
Ehhh. We are 30 years on and the current state is: recursive resolvers can strip DNSSEC and nothing happens but if they turn on validation things occasionally break.
Transport security has solved most of the real world problems and is being rapidly adopted: https://stats.labs.apnic.net/edns
Honestly this statement is not at all surprising. I would love to hear your perspective on what problem they thought was being solved.
Ensuring you have received a correct copy of a zone is the one thing we did get out of DNSSEC.
> I ran ISC during the development of BIND 9.0 and participated quite heavily in DNS-related working groups
Then we must have crossed paths. I'll happily buy you a beer or three next time.
> you have to take the steps DNSSEC takes
Ehhh. We are 30 years on and the current state is: recursive resolvers can strip DNSSEC and nothing happens but if they turn on validation things occasionally break.
Transport security has solved most of the real world problems and is being rapidly adopted: https://stats.labs.apnic.net/edns
[deleted]
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)
Not at the moment; to achieve this, you typically put it behind something like dnsproxy [1][2].
I have done this on my router, along with a couple firewall rules to prevent plaintext DNS queries leaking out of the WAN port. dnsmasq is configured to talk to dnsproxy, and dnsproxy is configured to use DNS over TLS with 1.1.1.1 [3]
[1] https://github.com/AdguardTeam/dnsproxy
[2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq...
[3] https://news.ycombinator.com/item?id=44429118
I have done this on my router, along with a couple firewall rules to prevent plaintext DNS queries leaking out of the WAN port. dnsmasq is configured to talk to dnsproxy, and dnsproxy is configured to use DNS over TLS with 1.1.1.1 [3]
[1] https://github.com/AdguardTeam/dnsproxy
[2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq...
[3] https://news.ycombinator.com/item?id=44429118
How would this even be exploited? What software would try and use such an invalid domain? It would always fail, so such a thing would never be shipped to end users. The only thing I can think of is some kind of social engineering attack, but at that point I feel like you can just use a normal attacker controlled domain instead of trying to do something special.
I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd.
Imagine that:
* I have an evil system at 192.0.2.1
* target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq.
* foobar.com has a nameserver that silently drops any request with a ! in the first label
I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com"
192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped.
While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months.
If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.
Imagine that:
* I have an evil system at 192.0.2.1
* target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq.
* foobar.com has a nameserver that silently drops any request with a ! in the first label
I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com"
192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped.
While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months.
If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.
That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.
RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.
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.
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?
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:
dig 'test~!*_' @resolver-ipthere 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.
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.
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.
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.)
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.)
[deleted]
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...