4 ms·

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 i

by dc396 1y ago

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.

philodeon 1y ago
DNSSEC most certainly does _not_ protect any data that an end user cares about.
- dc396 1y ago
  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.
  - obvious_sock 1y ago
    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.
tptacek 1y ago
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.
- dc396 1y ago
  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).
- obvious_sock 1y ago
  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.
  - aspenmayer 1y ago
    They wrote this: https://web.archive.org/web/20250729043725/http://sockpuppet.org/blog/2015/01/15/against-dnssec/ 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.

by dc396 1y ago

philodeon 1y ago

DNSSEC most certainly does _not_ protect any data that an end user cares about.

dc396 1y ago
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.
- obvious_sock 1y ago
  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.

tptacek 1y ago

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.

dc396 1y ago
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).
obvious_sock 1y ago
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.
- aspenmayer 1y ago
  They wrote this: https://web.archive.org/web/20250729043725/http://sockpuppet.org/blog/2015/01/15/against-dnssec/ 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.