4 ms·

Apparently systemd-resolved, which I think is the DNS resolver used on most modern Linux distros, defaults to DNSSEC=allow-downgrade, which means it will valida

Apparently systemd-resolved, which I think is the DNS resolver used on most modern Linux distros, defaults to DNSSEC=allow-downgrade, which means it will validate DNSSEC if it's working, and disable validation otherwise. Supposedly this still has some compatibility problems, which is why Fedora (at least) still has DNSSEC=no as the default, overriding the upstream systemd-resolved default. It would be great to identify and fix the majority of those compatibility problems so that DNSSEC validation could be enabled by default. Once a large enough mass of users would have DNSSEC validation enabled by default, the incentive would then be on the network operators to fix the remaining compatibility problems, as the users' devices would work just fine on other networks and they would perceive the fault to be on the incompatible network they were using, not on their device.

tptacek 4y ago
It's worth noting here that when 'wizeman says "enough users have DNSSEC validation enabled", he's referring to a fictitious state of "DNSSEC validation" where the clients perform full recursive validation up to the roots. No mainstream operating system does that today, so when you look at statistics about the (low but significant) percentage of DNS queries done with validation enabled, bear in mind that all of those queries are done the standard way: the stub resolver does no verification itself, and the DNS server simply communicates back to the resolver that verification was done with the `AD` bit. Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
- wizeman 4y ago
  > No mainstream operating system does that today ... by default. Doesn't mean that the software doesn't support it (by simply flipping DNSSEC=no to DNSSEC=yes in resolved.conf). It also doesn't mean they can't switch the default once most compatibility issues are solved. > Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit. ... which would be rejected by DNSSEC validation in the client. Besides, many DNSSEC queries are currently validated by trusted DNS servers like Cloudflare's and Google's which don't flip the `AD` bit and can communicate to the clients via a secure protocol like DNS-over-HTTPS (implemented in Firefox and Android) or DNS-over-TLS. So don't dismiss the value that it already has, even without client-side DNSSEC validation.
  - tptacek 4y ago
    macOS, iOS, and Windows are more than a resolv.conf change away from fully validating DNSSEC.
    - wizeman 4y ago
      > macOS, iOS, and Windows are more than a resolv.conf change away from fully validating DNSSEC. You're right, good point. Let's give up on DNSSEC then. :)
      - akerl_ 4y ago
        Given how long DNSSEC has existed, what’s your theory for why basically no endpoints actually validate DNSSSEC?
        wizeman 4y ago
        I'm not actually an expert on this, so I can't say for sure. I know of only 2 compatibility issues, by order of decreasing importance (IMHO): 1) Some DNS servers don't yet support DNSSEC (presumably including the DNS servers of some ISPs?) Presumably this could be solved by contacting the admins of the affected DNS servers and asking them to update their DNS server software. I think this is the biggest issue I know of. 2) The hostnames of NTP servers on DNSSEC domains can't be resolved when the client's clock is too out-of-sync. As another poster mentioned, this is not an inherent problem with DNSSEC, as TLS or any other similar security scheme would have the same problem. Presumably, until the issue can be solved in some better way, you'd have to have a couple of NTP servers on your config on non-DNSSEC domains or addressed by their IP addresses. For corporate networks, perhaps you could have a trusted NTP server (or servers) with stable clocks (or even GPS clocks) on your private network and address them by IP address.
        akerl_ 4y ago
        Maybe it’s not compatibility issue, and DNSSEC doesn’t provide meaningful security improvements, so deploying it increases the risk of breakage without any tangible benefit to the threat model.

tptacek 4y ago

It's worth noting here that when 'wizeman says "enough users have DNSSEC validation enabled", he's referring to a fictitious state of "DNSSEC validation" where the clients perform full recursive validation up to the roots. No mainstream operating system does that today, so when you look at statistics about the (low but significant) percentage of DNS queries done with validation enabled, bear in mind that all of those queries are done the standard way: the stub resolver does no verification itself, and the DNS server simply communicates back to the resolver that verification was done with the `AD` bit. Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.

wizeman 4y ago
> No mainstream operating system does that today ... by default. Doesn't mean that the software doesn't support it (by simply flipping DNSSEC=no to DNSSEC=yes in resolved.conf). It also doesn't mean they can't switch the default once most compatibility issues are solved. > Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit. ... which would be rejected by DNSSEC validation in the client. Besides, many DNSSEC queries are currently validated by trusted DNS servers like Cloudflare's and Google's which don't flip the `AD` bit and can communicate to the clients via a secure protocol like DNS-over-HTTPS (implemented in Firefox and Android) or DNS-over-TLS. So don't dismiss the value that it already has, even without client-side DNSSEC validation.
- tptacek 4y ago
  macOS, iOS, and Windows are more than a resolv.conf change away from fully validating DNSSEC.
  - wizeman 4y ago
    > macOS, iOS, and Windows are more than a resolv.conf change away from fully validating DNSSEC. You're right, good point. Let's give up on DNSSEC then. :)
    - akerl_ 4y ago
      Given how long DNSSEC has existed, what’s your theory for why basically no endpoints actually validate DNSSSEC?
      - wizeman 4y ago
        I'm not actually an expert on this, so I can't say for sure. I know of only 2 compatibility issues, by order of decreasing importance (IMHO): 1) Some DNS servers don't yet support DNSSEC (presumably including the DNS servers of some ISPs?) Presumably this could be solved by contacting the admins of the affected DNS servers and asking them to update their DNS server software. I think this is the biggest issue I know of. 2) The hostnames of NTP servers on DNSSEC domains can't be resolved when the client's clock is too out-of-sync. As another poster mentioned, this is not an inherent problem with DNSSEC, as TLS or any other similar security scheme would have the same problem. Presumably, until the issue can be solved in some better way, you'd have to have a couple of NTP servers on your config on non-DNSSEC domains or addressed by their IP addresses. For corporate networks, perhaps you could have a trusted NTP server (or servers) with stable clocks (or even GPS clocks) on your private network and address them by IP address.
        akerl_ 4y ago
        Maybe it’s not compatibility issue, and DNSSEC doesn’t provide meaningful security improvements, so deploying it increases the risk of breakage without any tangible benefit to the threat model.