3 ms·

What advantages do you see DNSCurve as having over DoT or DoH? (or DNS-over-Quic as that starts rolling out)

the8472 8y ago
Securely contacting the authoritative servers from a recursive resolver under my control instead of relying on some big corporation. Currently DoH or DoT are only used and designed with the goal[0] to secure stub resolver <-> recursive resolver traffic. Someone has to operate that recursive resolver and you have to trust them. So you only shift the problem from having to trust your ISP to having to trust cloudflare/google/etc. Dnscurve is intended to secure the recursive resolver <-> authoritative traffic, which means you don't have to rely on another party to secure your traffic. I guess dns over dtls could in principle fill the same role, albeit with more overhead. [0] https://tools.ietf.org/html/rfc8484#section-1 https://tools.ietf.org/html/rfc8484#section-1
- bluejekyll 8y ago
  Maybe I'm misunderstanding something, but aren't you talking about running a stub/recursive resolver with DNSCurve? You could do the same with DoT, or DoH. It sounds like DNSCurve might be easier to configure and setup from your perspective?
  - the8472 8y ago
    No, the traffic from individual machines to my recursive resolver is already secured or trusted, either because it's a trusted network or going through a tunnel. What I am missing is a way to secure the traffic from the recursive resolver to all the authoritative name servers in the world, i.e. to achieve end-to-end encryption for lookups. Yes I am aware that this would require dnscurve support in most authoritative servers around the world and that the rollout would take many years. But DoH provides a false sense of security, to me it's a distraction that just shifts us from ISPs saying "trust us" to google&co doing it.
    - bluejekyll 8y ago
      I think we're coming to DNSSEC + TLS vs. DNSCurve at this point. I'm not so convinced that the authenticity of the data you're conferring to the DNSCurve network is conferring greater security than DNSSEC and TLS. I'm not arguing one is better than the other, but I kinda see it as a wash.
      - the8472 8y ago
        DNS-over-(d)TLS approaches don't aim to secure the traffic between recursive resolvers and authoritative servers[0][1]. Is there any newer work going in that direction? [0] https://tools.ietf.org/html/rfc8094#section-1 https://tools.ietf.org/html/rfc8094#section-1 [1] https://tools.ietf.org/html/rfc7858.html https://tools.ietf.org/html/rfc7858.html
      - tptacek 8y ago
        TLS DNS and DNSCurve perform essentially the same function, so it doesn't make much sense to compare one with DNSSEC and one without. What blurs the line a little is that DNSCurve is explicit about its goal of providing bottom-up DNS security --- in a world with near-universal DNSCurve deployment, the need for DNSSEC would be minimized. But that's in fact true of TLS DNS, as well --- it's just not something the IETF is explicit about. Both DNSSEC and DNSCurve are basically dead-letter standards at this point; interestingly, the stake through both their hearts is DNS over TLS or HTTPS, but for different reasons: DNSCurve, because DoTLS essentially replaces the entire protocol, and DNSSEC because DoTLS reveals (through its rapid adoption, among other things) how marginal DNSSEC's contribution actually is.

Securely contacting the authoritative servers from a recursive resolver under my control instead of relying on some big corporation. Currently DoH or DoT are only used and designed with the goal[0] to secure stub resolver <-> recursive resolver traffic. Someone has to operate that recursive resolver and you have to trust them. So you only shift the problem from having to trust your ISP to having to trust cloudflare/google/etc. Dnscurve is intended to secure the recursive resolver <-> authoritative traffic, which means you don't have to rely on another party to secure your traffic. I guess dns over dtls could in principle fill the same role, albeit with more overhead. [0] https://tools.ietf.org/html/rfc8484#section-1 https://tools.ietf.org/html/rfc8484#section-1

bluejekyll 8y ago
Maybe I'm misunderstanding something, but aren't you talking about running a stub/recursive resolver with DNSCurve? You could do the same with DoT, or DoH. It sounds like DNSCurve might be easier to configure and setup from your perspective?
- the8472 8y ago
  No, the traffic from individual machines to my recursive resolver is already secured or trusted, either because it's a trusted network or going through a tunnel. What I am missing is a way to secure the traffic from the recursive resolver to all the authoritative name servers in the world, i.e. to achieve end-to-end encryption for lookups. Yes I am aware that this would require dnscurve support in most authoritative servers around the world and that the rollout would take many years. But DoH provides a false sense of security, to me it's a distraction that just shifts us from ISPs saying "trust us" to google&co doing it.
  - bluejekyll 8y ago
    I think we're coming to DNSSEC + TLS vs. DNSCurve at this point. I'm not so convinced that the authenticity of the data you're conferring to the DNSCurve network is conferring greater security than DNSSEC and TLS. I'm not arguing one is better than the other, but I kinda see it as a wash.
    - the8472 8y ago
      DNS-over-(d)TLS approaches don't aim to secure the traffic between recursive resolvers and authoritative servers[0][1]. Is there any newer work going in that direction? [0] https://tools.ietf.org/html/rfc8094#section-1 https://tools.ietf.org/html/rfc8094#section-1 [1] https://tools.ietf.org/html/rfc7858.html https://tools.ietf.org/html/rfc7858.html
    - tptacek 8y ago
      TLS DNS and DNSCurve perform essentially the same function, so it doesn't make much sense to compare one with DNSSEC and one without. What blurs the line a little is that DNSCurve is explicit about its goal of providing bottom-up DNS security --- in a world with near-universal DNSCurve deployment, the need for DNSSEC would be minimized. But that's in fact true of TLS DNS, as well --- it's just not something the IETF is explicit about. Both DNSSEC and DNSCurve are basically dead-letter standards at this point; interestingly, the stake through both their hearts is DNS over TLS or HTTPS, but for different reasons: DNSCurve, because DoTLS essentially replaces the entire protocol, and DNSSEC because DoTLS reveals (through its rapid adoption, among other things) how marginal DNSSEC's contribution actually is.