5 ms·

This is why DNSSEC was created.

by dc396 1y ago

supernetworks 1y ago
encrypted DNS goes a long way towards mitigating this as well.
- dc396 1y ago
  Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)
  - aaronmdjones 1y ago
    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 https://github.com/AdguardTeam/dnsproxy [2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_dnsproxy https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq... [3] https://news.ycombinator.com/item?id=44429118 https://news.ycombinator.com/item?id=44429118
mike_d 1y ago
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.
- deleted 1y ago
  [deleted]
- 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.

This is why DNSSEC was created.

by dc396 1y ago

This is why DNSSEC was created.

supernetworks 1y ago

encrypted DNS goes a long way towards mitigating this as well.

dc396 1y ago
Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)
- aaronmdjones 1y ago
  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 https://github.com/AdguardTeam/dnsproxy [2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_dnsproxy https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq... [3] https://news.ycombinator.com/item?id=44429118 https://news.ycombinator.com/item?id=44429118

mike_d 1y ago

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.

deleted 1y ago
[deleted]
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.