31 ms·

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

by rwmj 1y ago

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.

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.
JdeBP 1y ago
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.
marcusb 1y ago
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.

by rwmj 1y ago

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.

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.

JdeBP 1y ago

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.

marcusb 1y ago

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.