dnscurve and DNS hardening, was Re: Dan Kaminsky

Ben Scott mailvortex at gmail.com
Thu Aug 6 03:01:15 UTC 2009


On Wed, Aug 5, 2009 at 10:05 PM, Naveen Nathan<naveen at calpop.com> wrote:
> I might misunderstand how dnscurve works, but it appears that dnscurve
> is far easier to deploy and get running.

  My understanding:

  They really do different things.  They also have different behaviors.

  DNSCurve aims to secure the transaction between resolver (client)
and the nameserver it queries.  It encrypts both question and answer.
It authenticates that the answer came from the nameserver queried.

  DNSSEC authenticates resource records as coming from the "official"
delegated zone.

  Both allow the client to detect a forged answer, and allow the
implementation to keep waiting for a non-forged answer.  (DJB keeps
saying that DNSSEC doesn't allow that, but I don't see why.  An
implementation of either could respond by giving up on the first
invalid packet.  Don't do that, then.  Keep waiting, like DJB's
DNSCurve implementation does.)

  DNSCurve keeps a sniffer from monitoring DNS queries.  DNSSEC leaves
those open to any sniffer.

  DNSSEC authenticates answers to the "zone owner".  DNSCurve only
protects the "local loop".  If a cache is compromised and forged data
inserted, a DNSSEC client can detect that; a DNSCurve client cannot.

  With DNSCurve, to protect against upstream attacks, every upstream
cache must implement DNSCurve *and* be trusted by the end-user person.
 DNSSEC will work even if intermediate caches do not support DNSSEC.

  Neither is an "easy" implementation; both require changes to DNS
infrastructure at both client and server ends to be effective.

  DNSCurve requires more CPU power on nameservers (for the more
extensive crypto); DNSSEC requires more memory (for the additional
DNSSEC payload).

  DNSCurve requires nameservers to have a particular name.  DNSSEC does not.

  I'm told DNSCurve doesn't need any new record types, while DNSSEC
does, and that can be a problem for firewalls and intermediate caches
which assumed no new record types would ever be defined.  There's lots
of crappy implementations deployed in the world, so I have no idea how
big a problem that might be.

  I think that's most of it.

  From a security perspective, I see DNSSEC as having the advantage if
you're more worried about someone forging responses (since it
authenticates the zone, and not the transaction), and DNSCurve as
having the advantage if you're more worried about someone sniffing
your DNS traffic.

  From my chair:

  I really don't care if someone knows what DNS records I'm looking
up.  Almost certainly I'll only be looking up records to connect to
the associated server.  The sniffer can then just look at the IP
address.

  I do care quite a bit if an Internet provider running the local
cache starts lying to me about what domain names are what.  Say, to
redirect things to their "sponsored" sites instead.

  YMMV.  I reserve the right to be wrong.

-- Ben




More information about the NANOG mailing list