7 ms·

Sorry, the point I was trying to make is that this isn't a problem operationally. Hyperscalers go to crazy lengths because they can measure monetary losses due

Sorry, the point I was trying to make is that this isn't a problem operationally. Hyperscalers go to crazy lengths because they can measure monetary losses due to milliseconds of less view time and it's much easier when they have distributed cloud infrastructure anyway. But it's not really solving a problem for their customers. At least when I worked in DNS land ... latency micro-benchmarking was something of a joke. Like, sure, you can shave off a few tens of milliseconds, but it's super expensive. If you want to reduce latency, just up your TTL times and/or enable pre-fetching. As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. DoH also introduces latency, yet people aren't worried about that being a deal killer.

ekr____ 6mo ago
> As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. So I'm not sure this is as strong an argument as you seem to think it is. > DoH also introduces latency, yet people aren't worried about that being a deal killer. Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH. https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/?_gl=1*n426bm*_ga*MTM3MDA3NjU1My4xNzYyMzgyNzQ1*_ga_2VC139B3XV*czE3NzM2OTc0OTIkbzUkZzAkdDE3NzM2OTc0OTIkajYwJGwwJGgw https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... And here are some measurements from Hounsel et al. https://arxiv.org/abs/1907.08089 https://arxiv.org/abs/1907.08089
- indolering 6mo ago
  > They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. But if it's worth doing for HTTP, why not for DNS? > Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH. Oh fun!
  - ekr____ 6mo ago
    > But if it's worth doing for HTTP, why not for DNS? I'm sorry I don't understand your question.
    - indolering 6mo ago
      The engineering effort! ECC solves the theoretical concerns around latency anyway yet we have people arguing that it shouldn't be done. But if it was worth making HTTPS faster to secure HTTP, why not DNS?
      - akerl_ 6mo ago
        HTTPS solved a bunch of real world threat models that were causing massive security issues. So we collectively put a bunch of engineering time into making it performant so that we could deploy it everywhere with minimal impact on UX and performance.
        indolering 6mo ago
        DNSSEC also solves a bunch of real world threat models that do cause massive security issues. I think we should put that effort into DNS as well.
        tptacek 6mo ago
        Somehow they cause these massive security issues without impacting the 95%+ of sites that haven't used the protocol since it became viable to adopt a decade and a half ago. It's just a very difficult statistic to get around! Whenever you make a claim like this, you're going to have address the fact that basically ~every high-security organization on the Internet has chosen not to adopt the protocol, and there are basically zero stories about how this has bit any of them.
        akerl_ 6mo ago
        Does it? I run a bunch of websites personally. I have ACME-issued TLS certificates from LetsEncrypt. I monitor the Certificate Transparency logs, and have CAA records set. What's the threat model that should worry me, where DNSSEC is the right improvement?

ekr____ 6mo ago

> As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. So I'm not sure this is as strong an argument as you seem to think it is. > DoH also introduces latency, yet people aren't worried about that being a deal killer. Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH. https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/?_gl=1*n426bm*_ga*MTM3MDA3NjU1My4xNzYyMzgyNzQ1*_ga_2VC139B3XV*czE3NzM2OTc0OTIkbzUkZzAkdDE3NzM2OTc0OTIkajYwJGwwJGgw https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... And here are some measurements from Hounsel et al. https://arxiv.org/abs/1907.08089 https://arxiv.org/abs/1907.08089

indolering 6mo ago
> They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. But if it's worth doing for HTTP, why not for DNS? > Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH. Oh fun!
- ekr____ 6mo ago
  > But if it's worth doing for HTTP, why not for DNS? I'm sorry I don't understand your question.
  - indolering 6mo ago
    The engineering effort! ECC solves the theoretical concerns around latency anyway yet we have people arguing that it shouldn't be done. But if it was worth making HTTPS faster to secure HTTP, why not DNS?
    - akerl_ 6mo ago
      HTTPS solved a bunch of real world threat models that were causing massive security issues. So we collectively put a bunch of engineering time into making it performant so that we could deploy it everywhere with minimal impact on UX and performance.
      - indolering 6mo ago
        DNSSEC also solves a bunch of real world threat models that do cause massive security issues. I think we should put that effort into DNS as well.
        tptacek 6mo ago
        Somehow they cause these massive security issues without impacting the 95%+ of sites that haven't used the protocol since it became viable to adopt a decade and a half ago. It's just a very difficult statistic to get around! Whenever you make a claim like this, you're going to have address the fact that basically ~every high-security organization on the Internet has chosen not to adopt the protocol, and there are basically zero stories about how this has bit any of them.
        akerl_ 6mo ago
        Does it? I run a bunch of websites personally. I have ACME-issued TLS certificates from LetsEncrypt. I monitor the Certificate Transparency logs, and have CAA records set. What's the threat model that should worry me, where DNSSEC is the right improvement?