3 ms·

It also has the option to tunnel your DNS over TCP/443, avoiding all the dumb things wifi hotspots try to do with your DNS.

• tptacek 15y ago
  If you're going to run DNS over TLS, you probably don't need DNSCurve anymore.
  • dsl 15y ago
    It's not TLS.
    • tptacek 15y ago
      It should be!
      • SoftwareMaven 15y ago
        (Serious questions) What benefit does TLS provide over the elliptical-curve cryptography it uses? Would it be possible for somebody to filter the DNS queries by identifying the use of elliptical-curve cryptography instead of TLS (obviously they couldn't read them, but could they stop them)?
        • tptacek 15y ago
          None. The advantage to DNSCurve is that it's optimized for the DNS service model (it's tighter and faster). The advantage to TLS is that you already have it. The advantage of DNSCurve over DNSSEC isn't really the ECC (DNSCurve's ECC is better than DNSSEC's crypto by a mile, but neither DNSSEC nor DNSCurve have known practical crypto attacks). The advantage of DNSCurve is that its security model is much more realistic. Instead of trying to make every DNS record a secure document that can be verified in isolation, DNSCurve simply ensures that your browser can make a secure request do a DNS server somewhere (and, by implication, that the DNS server can itself make secure requests to other DNS servers, and on and on incrementally until the whole DNS is secure). Think of it this way: DNSSEC is what web security would be if it worked by signing web pages. DNSCurve works roughly the way web security works now, with a drastically streamlined and (probably) improved crypto protocol.
          • makomk 15y ago
            Of course, the downside of DNSCurve is that you have to trust your upstream name server completely because they have the ability to arbitrarily tamper with the responses they send. This is quite convenient for OpenDNS - they do things like redirecting requests for non-existent domains to search pages with ads that make them money. The other downside is that I don't think there's any way to securely implement the second stage of that process where your DNS server makes secure requests to other DNS servers, because the root name servers don't support DNSCurve and are unlikely to for the foreseeable future.
            • tptacek 15y ago
              Last objection first: The same chicken-egg problem is even more deeply embedded into DNSSEC, where, in order to provide any security, every DNS record you care about requires administrative intervention to upgrade to DNSSEC. DNSCurve is far easier for service providers to adopt than DNSSEC; its security model holds even if you just have it proxy to BIND. Meanwhile, I think "trusting your upstream nameserver" is a bit of a red herring. The DNS security greybeard cabal absolutely does have stories to tell about poisoned servers, but the on-the-ground reality of DNS security attacks today isn't about compromised authority servers --- or, when it is, it's about attacks on authorities that no security protocol was ever going to address. Candidly, I don't believe securing the DNS is really a goal worthy of a lot of effort. The HTTPS/TLS CA model as implemented today is broken, but we're a peer-to-peer validation scheme away from fixing that. Given the choice between DNSCurve and DNSSEC, the one that costs the least to implement (DNSCurve, by miles and miles) is a no-brainer; the fact that it actually does something on day one is just icing on the cake.
        • deleted 15y ago
          [deleted]