Hacker News Reader

Comment by rwmj | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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

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.

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.

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.

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'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!

> Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!

Is it largely being replaced by EDNS, or what?

Now that we have that giant out of the way, what’s the next one you’re tilting at?

Single family zoning.

I think there's a lot of reasons why DNSSEC is moribund. It was a necessary accompaniment to IPSEC back in the mid-1990s when everybody assumed we'd be all v6 all IPSEC by 2000. Then Kashpureff's bailiwick attack happened, and we got this:

https://mailman.nanog.org/pipermail/nanog/1997-July/122606.h...

... but the bailiwick caching behavior was a straight-up bug, and rand(3) was enough to make QID spoofing more annoying to exploit than it was worth. Something like 5 years later we had the birthday attack, but I don't recall anybody taking it especially seriously --- maybe because at roughly the same time, DNSSEC was going through the "typecode roll" that took us from DNSSEC to DNSSECbis, and nobody was confident about pushing DNSSEC at that point; the TLDs weren't even signed.

Then 5 years after that we got Kaminsky. There's a spark of interest in DNSSEC after that... but all the vendors who hadn't already adopted DJB's randomization immediately did, and Kaminsky's attack stopped mattering.

By this point I think it was clear to everybody that protecting transactions wasn't going to be the motivating use case for DNSSEC, so people shifted to DANE: using DNSSEC as a global PKI to replace the X.509 certificate authorities. But DANE flat-out never worked; you couldn't deploy it in a way that was resilient against downgrades, so there was simply no point.

Then Google and Mozilla killed several of the largest CAs, and used their market power to force CT on the remaining (and thoroughly cowed) CAs. And LetsEncrypt happened. So modern concern over replacing the X.509 CAs registers somewhere in seriousness alongside Linux on the Desktop.

People try to come up with increasingly exotic reasons why we'll be forced to use DNSSEC with the WebPKI; it's not so much DANE anymore as it is resilience against BGP attacks and validation of ACME DNS challenges. It's all pretty unserious.

Meanwhile: unlike DNSSEC, which has seen only marginal adoption over 30 years, DoH has caught fire. Within the next 5 years, it's not unlikely that we'll come up with some deployment scenario whereby CAs can use DoH to secure lookups all the way to authority servers. We'll see. It's a lot more likely than a global deployment of DNSSEC.

There's just no reason for it to exist anymore.

I have a lot more reasons than this not to like DNSSEC --- I actively dislike it as a protocol and as a cryptosystem. But those are just my takes, and what I've related in this comment is I think pretty much objectively verifiable.

There’s no conflict of interest associated with pointing to your correspondent’s own website, or one referring to their own.

As an amateur correspondent myself, the correspondents I’m concerned about doing right by would be other visitors to their site who click my link. I’m protecting link-clickers from my source, and my source from others. In this case, I’d view 'tptacek as both as my source, and as a potential operational security concern to me as an investigator due to not knowing them well enough to know their motives, and not knowing who is watching them and everyone who visits their site, which is the larger and more legitimate concern about doing security research, in my view.

What’s the nature of the security threat?

Site operators can serve you malware or log your IP address or any manner of other things.

> 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

Reply on news.ycombinator.com