Unbound 1.4.6 source code is at http://unbound.net/downloads/unbound-1.4.6.tar.gz
sha1 b0d7c58f173c5c80cc81345f6766555f96bde20d
sha256 9c2ce107b551dbd65d007549caea13ecba7dd30d690821f2bafa9da2d047b9de
For maintainers, this is the same as the rc1 release candidate, but for
the updated ldns tarball inside (which contains some recent bugfixes
that should not impact unbound).
Mostly bugfixes, with this release prompted by the RFC for GOST. GOST
is enabled if the SSL and ldns support it. Otherwise, unbound acts as
if GOST is not supported (it becomes insecure).
Also a fix for a corner case misconfiguration and fixes for high load
situations. It looks like num-queries-per-thread about half of the
outgoing-range is a good setting for overload situations, and the
HOWTO-optimise is adjusted for this. The defaults have changed too.
Features
* Builtin root hints contain AAAA for I.ROOT-SERVERS.NET.
* unbound.h has extern "C" statement for easier include in c++.
* added feature to print configure date, target and options with -h.
* added feature to print event backend system details with -h.
* (ports and works on Minix 3.1.7). On Minix, add /usr/gnu/bin to
PATH, use ./configure AR=/usr/gnu/bin/gar and gmake.
* GOST enabled if SSL is recent and ldns has GOST enabled too.
Bug Fixes
* Fix TCPreply on systems with no writev, if just 1 byte could be sent.
* Fix to use one pointer less for iterator query state store_parent_NS.
* Max referral count from 30 to 130, because 128 one character
domains is valid DNS.
* added documentation for the histogram printout to syslog.
* Fix assertion failure reported by Kai Storbeck from XS4ALL, the
assertion was wrong.
* updated ldns tarball.
* iana portlist updated.
* Unbound reports libev or libevent correctly in logs in verbose mode.
* Fix handling of corner case reply from lame server, follows
rfc2308. It could lead to a nodata reply getting into the cache if the
search for a non-lame server turned up other misconfigured servers.
* Fix jostle list bug found by Vince (luoce at cnnic), it caused the
qps in overload situations to be about 5 qps for the class of shortly
serviced queries. The capacity of the resolver is then about
(numqueriesperthread / 2) / (average time for such long queries) qps for
long queries. And about (numqueriesperthread / 2)/(jostletimeout in
whole seconds) qps for short queries, per thread.
* Fix the max number of reply-address count to be applied for
duplicate queries, and not for new query list entries. This raises the
memory usage to a max of (16+1)*numqueriesperthread reply addresses.
* Fix RFC4035 compliance with 2.2 statement that the DNSKEY at apex
must be signed with all algorithms from the DS rrset at the parent. This
is now checked and becomes bogus if not.
* Fix validation of qtype DNSKEY when a key-cache entry exists but
no rr-cache entry is used (it expired or prefetch), it then goes back up
to the DS or trust-anchor to validate the DNSKEY.
* log if a server is skipped because it is on the donotquery list,
at verbosity 4, to enable diagnosis why no queries to 127.0.0.1.
* failure to chown the pidfile is not fatal any more.
* Neat function prototypes, unshadowed local declarations.
* Fix integer underflow in prefetch ttl creation from cache. This
fixes a potential negative prefetch ttl.
* Changed the defaults for num-queries-per-thread/outgoing-range.
For builtin-select: 512/960, for libevent 1024/4096 and for windows
24/48 (because of win api). This makes the ratio this way to improve
resilience under heavy load. For high performance, use libevent and
possibly higher numbers.
Is it possible to add dnscurve support to the todo list?
It is currently at the IETF and if that standardization (and fix)
process is done, then we can consider adding it. Of course we also want
a lean-and-mean validator for unbound, so no unnecessary features. The
IETF process can take some time and make changes to the spec, therefore
the decision is better made at a later date.
The root was just signed with DNSSEC, a week or so ago, so I updated the
Howto DNSSEC on the unbound website for that earlier today. RFC5011
tracking of the root anchor is much easier than tracking every
topleveldomain with cron.
It's cute, but I don't think its really needed anymore. The cool thing about
re-using the NS record was not so much to just provide a pubkey in dnscurve,
but to provide privacy. Dan's NSDS record does not do that. The competitive
nature of the registry/registrar model will ensure most of them will support DS
records before any NSDS code has been written and well tested (IMHO)
Is it possible to add dnscurve support to the todo list?
It is currently at the IETF and if that standardization (and fix)
process is done, then we can consider adding it.
The IETF process can take some time and make changes to the
spec, therefore the decision is better made at a later date.
That argument, even though it makes sense, seems somewhat inconsistent
with an earlier decision to implement draft-vixie-dnsext-dns0x20-00 in
Unbound. I liked playing with the 0x20 feature though, so at least I for
one was was happy that you implemented it as an option. I suppose I
could be equally happy with fiddling around with DNScurve a bit. A
'--with-dnscurve' configure-option would work just fine for me (will
keep things leand and mean for others). So as far as I am concerned, the
'IETF standardization'-argument doesn't necessarily has to be a
showstopper here.
>
>> How about TSIG ? I think it can be used (if an stub-resolver like
>> ldns implements it) to secure 'the last mile'.
>
> I'd rather see validating resolvers using a forwarder mechanism so we
> don't
> have to trust ISP/random wifi nameservers at all.
>
>> Did you also see this idea by Dan Kaminsky ? I thought it was pretty
>> smart.
>>
>> It takes part of the idea from dnscurve and combines it with DNSSEC
>> to get faster/more DNSSEC deployment:
>>
>> http://recursion.com/chain.pdf
>
> It's cute, but I don't think its really needed anymore. The cool thing
> about
> re-using the NS record was not so much to just provide a pubkey in
> dnscurve,
> but to provide privacy. Dan's NSDS record does not do that. The
> competitive
> nature of the registry/registrar model will ensure most of them will
> support DS
> records before any NSDS code has been written and well tested (IMHO)
>
> Paul
>
I know they are both just a stopgap, but atleast now we know you don't
expect to implement it.
TSIG just hasn't got what dnscurve offers.
Dnscurve would add little overhead (less than a quarter of dnssec) and
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).
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.
The dnssec encryptions security is also questionable.
Privacy and real security for dns would be a great thing for many
reasons such as preventing business association monitoring (web and
email traffic etc. (though starttls as oppose to tls would still give
out some info) it would also prevent some attackers from knowing when
and buying time to prepare to launch an attack such as a starttls not
available response.
I'm obviously a supporter of dnscurve but I do see that if it get's
very little adoption (OpenDNS seem the only major one at present) then
adding it may be a waste of developers time, though I'm under the
impression that it's meant to be easy to implement and I'm hoping
unbound may be able to kick others into action. It would also be the
only and first one supporting dnssec and dnscurve as far as I am aware,
thereby acquiring other users like me and/or press coverage.
Is it possible to add dnscurve support to the todo list?
It is currently at the IETF and if that standardization (and fix)
process is done, then we can consider adding it.
The IETF process can take some time and make changes to the
spec, therefore the decision is better made at a later date.
That argument, even though it makes sense, seems somewhat inconsistent
with an earlier decision to implement draft-vixie-dnsext-dns0x20-00 in
Unbound. I liked playing with the 0x20 feature though, so at least I for
one was was happy that you implemented it as an option. I suppose I
could be equally happy with fiddling around with DNScurve a bit. A
'--with-dnscurve' configure-option would work just fine for me (will
keep things leand and mean for others). So as far as I am concerned, the
'IETF standardization'-argument doesn't necessarily has to be a
showstopper here.
seconded. dnscurve is a great concept, I'd love to play with it.
That argument, even though it makes sense, seems somewhat inconsistent
with an earlier decision to implement draft-vixie-dnsext-dns0x20-00 in
these two don't compare too well IMHO. First, the only issue in 0x20
that needed(?) standardization was the advice that the QNAME be copied
to the response bitwise (no casefolding involved). Whether or not
that constituted a change people have varying opinions about.
The hack itself is pretty much client side and it was fully described
in the I-D (still I'm not too happy to see this defaulted to from an
operational perspective).
one was was happy that you implemented it as an option. I suppose I
could be equally happy with fiddling around with DNScurve a bit. A
That would indeed be interesting, but DNScurve isn't as complete and
stable as 0x20 possible could be. I appreciate resolver implementers
being conservative about implementing moving targets. Resolvers, if
widely deployed, cause swarm effects on the infrastructure and some
caution is due.
I fully agree with Peter here. dnscurve is not a standard and we don't
know whether it will be adopted by IETF, or some other idea will
succeed, or if it will be kept intact once adopted by IETF.
Dnscurve has some problems, but I don't want to go into the detail
since this discussion doesn't really belong here. (And I won't discuss
it here.) But I do object to implementing such a dramatic change in
behaviour of unbound as dnscurve is.
Ondrej
P.S.: Also I would recommend to not spread FUD about DNSSEC in this
mailing list. We don't want to have a flamewar here.
We can have the discussion again why dnscurve can be a disaster on the
caching infrastructure of the net. There are many important reasons why
a lot of DNS developers do not like or want dnscurve. Why should they
implement it? DNS developers have been at the IETF for decades. There
is a reason why the end result of many bright minds was DNSSEC, not dnscurve.
People advocating dnscurve are loud. However, the manta is "concensus
and running code". Having a draft gives you some kind on concensus. You
still need to make running code. And even then, you would need to think
about operational issues. You can't take the Bernstein approach of
"I'll do whatever the hell I want" or "I don't work around operating
system bugs" if you want more then 2 people running the code.
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
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.
these two don't compare too well IMHO. First, the only issue in 0x20
that needed(?) standardization was the advice that the QNAME be copied
to the response bitwise (no casefolding involved). Whether or not
that constituted a change people have varying opinions about.
The hack itself is pretty much client side and it was fully described
in the I-D (still I'm not too happy to see this defaulted to from an
operational perspective).
The main problem 0x20 is that it was intended as a cheap way to get
more hard-to-guess bits. However, it turned out that it did not
actually achieve that goal unless you have tons of rather
non-traditional checks in your resolver (AFAIUI, Unbound has them).
This means that 0x20 wasn't that attractive for implementors in the
end.
That would indeed be interesting, but DNScurve isn't as complete and
stable as 0x20 possible could be.
Unfortunately, 0x20 tends to expose broken authoritative servers which
would otherwise work just fine (see the list archives).
I appreciate resolver implementers being conservative about
implementing moving targets.
Last time I checked, there wasn't really a target because it's
difficult to find the description of the correct cryptographic
algorithms.
I haven't seen too many since some large pdns deployments got upgraded.
We're running with it enabled, and haven't gotten any use problem with
it for months.
DJB gave a talk on 27c3 'Hacker congress' (at December 28th, 2010) in
Berlin:
"High-speed high-security cryptography encrypting and authenticating
the whole internet"
In essence, Dan
- critices DNSSec from first principles ('CIA') and explaining possible
amplification attacks, and addressing the problem of static signing
keys,
- introduces briefly DNSSec with ECC and NYM deployed Public Keys,
- outlines CurveCP, a new protocol, using UDP services while encrypting
the payload (asymmetrically) by means of ECC. This could be used for
general HTTP traffic (instead using standard TCP).
That was not a talk. That was a rant devoid of facts and filled with
unsubstantiated and by now disproven claims. Both me and Kaminsky
already spend too much time debunking his shit. Let's not reitterate
that nonsense here.
I don't think that "thinking about encrypted dns" should be named as "shit".
Nobody like onlinebanking or webmail unencrypted.
And some people dislike plaintext dns also. And this is not wrong.
Btw.:
Curvedns is no vaporware. It works, is ready for productional use
and coexist (transparent in front) with a dnssec enabled nsd.
I cant's see any drawback when using software for more security.
Discussion should be limited about the used crypto.
