Maintained by: NLnet Labs

[Unbound-users] unbound 1.4.6 released

Paul Wouters
Wed Aug 4 16:24:44 CEST 2010


On Wed, 4 Aug 2010, Kevin Chadwick wrote:

> TSIG just hasn't got what dnscurve offers.

Privacy? Sure. That's the only thing TSIG does not offer that dnscurve offers
(at a great expense of bypassing the intermediary dns caches)

> Dnscurve would add little overhead

How would you protect the last mile? Your ISP nameserver doing dnscurve is
nice, but it cannot tell me anything about how secure the data fetched was.
Unless all the end nodes run dnscurve themselves, in which case no ISP needs
to run a nameserver anymore because you cannot trust its contents as there
is no cryptographic signature on the content.

> you could have an off switch, the memory overhead for forking would
> make little difference. You could even optionally turn off dnssec to get
> increased performance knowing dnssec was checked by the last hop (if
> you trust that hop) thereby gaining performance you could optionally
> compile without dnssec to free up memory (many forks - depending on
> performance reasoning).

Eh? I don't understand what you are trying to do here.

> Dos against dnssec shouldn't be so easy to conduct especially against
> smaller sites, dnscurve would reduce dos effectiveness and in some
> cases prevent it.

dnscurve itself is the dos already :P

> The dnssec encryptions security is also questionable.

[citation needed]

I'd be very interested in knowing weaknesses in DNSSEC, because all of
its crypto is used elsewhere too. Of course, even if you were right (you
are not) and one of the algorithms or ciphers was sufficiently weak,
DNSSEC gives you an option to rollover to another algorithm or cipher.

Dnscurve on the other hand gives you "The one Bernsteins ECC Curve". If
that curve is ever successfully attacked, the entire house is coming down
because there is no migration path to another algorithm or cipher.

But this has been discussed to death many many times in the archives of
many DNS lists. Please look back for much longer and detailed responses.

Paul