5 ms·

> DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Interesting assertion -- do you have anything t

by dc396 1y ago

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

tptacek 1y ago
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.
- 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).
mike_d 1y ago
> 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 https://stats.labs.apnic.net/edns

by dc396 1y ago

tptacek 1y ago

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.

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

mike_d 1y ago

> 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 https://stats.labs.apnic.net/edns