Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical Cache Poisoning Vulnerability in Dnsmasq

lists.thekelleys.org.uk

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#81

Post by tptacek »

dc396 wrote: post #71
magicalhippo wrote: post #59

Earlier quoted context omitted.

> 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…

Geoff Huston at APNIC does track this!

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#82

Post by tptacek »

teddyh wrote: post #76
furgot wrote: post #72

Earlier quoted context omitted.

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…

> 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.

Yes I very cleverly described exactly the shape of the graph you posted.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#83

Post by marcusb »

rwmj wrote: post #14

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.

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.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#84

Post by furgot »

tptacek wrote: post #82
teddyh wrote: post #76

Earlier quoted context omitted.

> 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.

Yes I very cleverly described exactly the shape of the graph you posted.

Without commenting on the "cleverness", either it doesn't match your description of the data, or their criticism that the interval was cherry picked is spot on. Only one of these can be true.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#85

Post by 1vuio0pswjnm7 »

noinsight wrote: post #79
1vuio0pswjnm7 wrote: post #55

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…

You can just use Unbound for DNS.

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

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#86

Post by stock_toaster »

noinsight wrote: post #79
1vuio0pswjnm7 wrote: post #55

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…

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

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#87

Post by throw0101c »

1vuio0pswjnm7 wrote: post #85
noinsight wrote: post #79

Earlier quoted context omitted.

You can just use Unbound for DNS.

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

Unbound is a recursive-only resolver. NSD is an authoritative-only resolver.

Those are different use cases.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#88

Post by tptacek »

furgot wrote: post #84
tptacek wrote: post #82

Earlier quoted context omitted.

Yes I very cleverly described exactly the shape of the graph you posted.

Without commenting on the "cleverness", either it doesn't match your description of the data, or their criticism that the interval was cherry picked is spot on. Only one of these can be true.

I appreciate you saying I'm commenting in good faith (I am), but I think you and 'teddyh are overthinking this a bit.

All I'm saying is that I find it remarkable that DNSSEC adoption in North America sharply dropped over the course of 2023 --- that, and the fact that the graph tops out at 7MM zones, a big-looking number that is in fact very small.

I think it's funny that the graph serves my argument better than 'teddyh's. But really, I think it's ultimately meaningless. That's because the figure of merit for DNSSEC adoption isn't arbitrary signed zones but rather popular signed zones. And that in turn is because the distribution of DNS queries is overwhelmingly biased to popular zones --- if you can sample a random DNS query occurring somewhere in the US right now, it's much more likely to be for "googlevideo.com" than for "aelcargo.site" (a name I just pulled off the certificate transparency firehose).

The Verisign graph 'teddyh keeps posting is almost entirely "aelcargo.site"-like names†. The link I posted upthread substantiates that.

† And that in turn is because DNS providers push users into enabling managed DNSSEC features, because disabling DNSSEC is terrifying and so DNSSEC is an extremely effective lock-in vector --- that's not me making it up, it's what the security team at one of the few large tech companies that actually have it enabled told me when I asked why the hell they had it enabled.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#89

Post by colmmacc »

dc396 wrote: post #51
tptacek wrote: post #41

Earlier quoted context omitted.

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…

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.

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."

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#90

Post by mike_d »

dc396 wrote: post #36
mike_d wrote: post #26

Earlier quoted context omitted.

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 modifyin…

> 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

Post reply on HN