Add History section to Reference

source/index.rst

@@ -104,12 +104,12 @@ license, with attribution to NLnet Labs.
    manpages/libunbound
    manpages/unbound-control
    manpages/unbound-anchor
-..
-   .. toctree::
-      :maxdepth: 2
-      :caption: Reference
 
-      reference/libunbound
+.. toctree::
+   :maxdepth: 1
+   :caption: Reference
+
+   reference/history/index
 
 
 Indices and tables

source/reference/history/book-news.rst

@@ -0,0 +1,35 @@
+Unbound Operation Explained in Book
+===================================
+
+*Authored December 2008.*
+
+We received a complimentary book by `Jan-Piet Mens <https://jpmens.net/>`_
+today, titled `Alternative DNS Servers
+<https://jpmens.net/2010/10/29/alternative-dns-servers-the-book-as-pdf/>`_. It
+covers a whole host of DNS servers, including NSD and Unbound.
+
+The book describes how to set up DNS servers and how to operate them. I found
+the section on Unbound to be fine (also NSD is fine).  I cannot comment on the
+other products.
+
+One section stood out as it has a performance comparison of the servers. The
+book has more details, below is one line of results.  Here 10 queryperf machines
+query a DNS cache, and the average queryperf performance is noted. So the cache
+is doing 10x the number noted.  The figures show similar results to what we find
+for performance comparisons in the NLnet Labs testlab. The results below have
+been found independently, and compare a greater number of products.
+
+================= ==
+Server            Queries/sec (10 clients)
+================= ==
+MaraDNS           3 068
+BIND              3 003
+dnscache          2 928
+PowerDNS Recursor 2 074
+Unbound           8 276
+================= ==
+
+The book reviews unbound version 1.0, and the config and operation is the same
+as 1.1 which was recently released. `Unbound 1.1
+</projects/unbound/download/#unbound-1-1-0>`_ has DLV support and improved
+statistics, which may be of interest.

source/reference/history/dns-cache-poisoning-vulnerability.rst

@@ -0,0 +1,113 @@
+2008 DNS Cache Poisoning Vulnerability
+======================================
+
+| *Authored April, 2008*
+| *Updated and released Jul 9, 2008*
+
+Executive Summary
+-----------------
+
+Dan Kaminsky of `IOActive <http://www.ioactive.com/>`_ has reported a DNS cache
+poisoning vulnerability to developers of DNS caching software. The details of
+this vulnerability will be explained by Kaminsky at the upcoming `Black Hat
+conference <http://blackhat.com/>`_ in August.
+
+A cache poisoning attack allows unauthorized third parties to inject data into a
+DNS cache, the injected data may cause rerouting of traffic.
+
+There is no definite solution to the form of cache poisoning described to us by
+Kaminsky. Only DNSSEC will provide the measures to detect malicious data and
+prevent cache poisoning.
+
+However in absence of DNSSEC being sufficiently deployed to benefit, methods
+exist to increase resilience against cache poisoning attacks, and Unbound has
+these implemented by design.
+
+- Unbound was designed to use the maximum amount of randomness for
+  query ports and does not need to be `upgraded to improve resilience
+  <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447>`_.
+- Unbound has also been designed with a component, called the
+  scrubber, that sanitizes query results and does not add data to the
+  cache it does not trust as being authoritative.
+
+Background
+----------
+
+Absent a reference to Dan Kaminsky's work we refer to other papers where the
+general principle of port and query ID randomization to mitigate cache poisoning
+attempts are described.
+
+Recently an article appeared in `the Register
+<http://www.theregister.co.uk/2008/04/15/dns_cache_poisoning/>`_ where a
+statement that Amit Klein made during the RSA Security conference was quoted as:
+
+    *I'm not too comfortable with the quality of the solution from the security
+    and predictability standpoint*
+
+In 2007 and 2008 Klein has `published <http://www.trusteer.com/research/>`_ a
+number of articles on port and query ID predictability on the website of his
+company. Work started within the IETF by `Hubert and van Mook
+<http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience>`_ in 2006
+already indicated that making optimal use of the full port range improves cache
+forgery resilience, and recommends the use of good sources of randomness for the
+choice of query IDs and ports.
+
+A new strategy to improve the resilience against forgery is the `work by Vixie
+and Dagon
+<http://tools.ietf.org/id/internet-drafts/draft-vixie-dnsext-dns0x20">`_, that
+uses the property that authoritative servers copy the query name, while
+preserving case, to introduce more entropy matching queries against answers.
+
+Unbound
+-------
+
+Unbound is being designed to be a modern, secure and up-to-date name server,
+that in addition to DNSSEC (the only complete solution to DNS forgery)
+implements all known mechanisms to increase the resilience to forgery of cache
+entries.
+
+Unbound version 1.0 has implemented query id and port randomization in the
+following way.
+
+For each outgoing query both the query-ID and port number are set by `routines
+<http://unbound.net/documentation/doxygen/random_8c.html>`_ based on the ARC4
+algorithm as implemented in OpenBSD. Arc4random is a pseudo random generator
+based on ARC4 that addresses the problems, as Klein mentions in one of his
+papers:
+
+    *Fortunately, OpenBSD also uses [[...]] the ARC4 algorithm. As such,
+    spoofing responses for the resolver necessitates knowing the UDP source
+    port, predicting the ARC4 algorithm's next output, or exploiting an
+    implementation bug, none of which is currently known to apply.*
+
+To allow for the maximum number of ports to pick from randomly, Unbound uses an
+advanced strategy. Ports are chosen chosen randomly from the pool of
+non-allocated ports. Ports can be excluded from this pools by means of a
+configuration parameter.
+
+There is a small penalty for recursive name servers that will have to do a lot
+of recursion. This is because there is only a limited set of slots in the socket
+cache and one may need to wait before one is available.  For this penalty there
+is a compensation by the use of a socket cache which helps the kernel run its
+select algorithm over open file descriptors.
+
+The mechanisms utilizing case preservation as described by Vixie and Dagon is
+under development and can be turned on while configuring Unbound 1.0. It should
+be noted though that the likely hood on false positives, which causes Unbound to
+ignore an answer thinking it is under attack, is fairly high. There are
+strategies to deal with these false positives that delay the response time
+somewhat and are currently under investigation. We plan an implementation of
+those in once we are satisfied with the behavior.
+
+We believe that the scrubber safeguards against the currently publicly known cache poisoning tactics.
+
+Links
+-----
+
+- `http://www.theregister.co.uk/2008/04/15/dns_cache_poisoning/ <http://www.theregister.co.uk/2008/04/15/dns_cache_poisoning/>`_
+- `http://www.trusteer.com/research/ <http://www.trusteer.com/research/>`_
+  contains various articles focused on predictability of port and query IDs
+- `http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience <http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience>`_
+- `http://tools.ietf.org/id/draft-vixie-dnsext-dns0x20 <http://tools.ietf.org/id/draft-vixie-dnsext-dns0x20>`_
+  work in progress
+- `http://unbound.net/documentation/doxygen/random_8c.html <http://unbound.net/documentation/doxygen/random_8c.html>`_

source/reference/history/index.rst

@@ -0,0 +1,30 @@
+.. _doc_background:
+
+History
+=======
+
+Unbound started out as a project to develop independent open-source DNS software
+and documentation. It was jointly funded by `VeriSign, Inc.
+<https://www.verisign.com>`_, and the `University of Southern
+California/Information Sciences Institute <http://www.isi.edu>`_. The C
+implementation was based on a prototype written in Java. It was released in May
+2008 with this :download:`press release<files/Unbound_Press_Release.pdf>`.
+
+This section contains several historic documents. There are also presentations
+about the intial Unbound design delivered at :download:`IETF 67
+<files/ietf67-design-02.pdf>` and :download:`RIPE 56
+<files/ripe56_unbound_02.pdf>`.
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents
+
+   requirements
+   prototype-resolver
+   dns-cache-poisoning-vulnerability
+   patch-announce102
+   book-news
+   info-timeout
+   info-algo
+   root-11sep-11oct
+

source/reference/history/info-algo.rst

@@ -0,0 +1,69 @@
+DNSSEC Algorithms with Unbound
+==============================
+
+
+Unbound validates DNSSEC signatures and in the case that there are
+multiple signature algorithms in use, it checks that a valid chain of
+trust exists for each algorithm separately.  Thus the algorithms that are
+in use must all be subverted before validation can be misdirected.
+
+Algorithms in the Chain of Trust
+--------------------------------
+
+The algorithms that are checked are signalled via the DS RRset.  This
+means that zones do not receive these checks until they publish multiple
+algorithms into their DS set.  Thus the set of algorithms present in
+the DS RRset must have DNSKEYs and signatures on every data element.
+
+The RFCs already mandate that for algorithms signalled to be in use for a
+domain you must have DNSKEYs and signatures on every data element, because
+a validator is allowed to continue the chain of trust if it supports one
+algorithm but not the others.  These validators that support one of the
+algorithms must find that the algorithm signalled to be present has keys
+and signatures, and if these are missing, will conclude that signatures
+have been 'stripped' away.  The extra checks that unbound performs thus
+must succeed if the domain is properly signed and all signatures are
+present.
+
+There is some leeway when signing a domain, and this leeway is useful when
+changes are phased in.  The DNSKEY may contain more algorithms, perhaps as
+part of a rollover.  The data may be signed with other algorithms as well.
+It is possible to have DS records for which no key exists, as long as
+another DS record for that algorithm has a key.  It is possible to have
+DNSKEY records that do not sign any or only part of the data (as long
+as signatures are available via other DNSKEYs).
+
+Change in algorithms is possible by introducing keys in the DNSKEY set,
+and signing with them, and once complete, introducing the DS record.
+The reverse, first with the takeown of the old algorithm DS records, for
+removal of a signing algorithm.  Older versions of unbound did not allow
+introduction of a new algorithm key in the DNSKEY set if the signatures
+on the data were not already present, but newer (since 1.4.8) versions
+allow this (and rely on the algorithms signalled in the DS RRset).
+
+Protection
+----------
+
+The check for multiple algorithms protects against not-known-today
+algorithmic weaknesses in one algorithm by using the other algorithm.
+This assumes the (mathematical) properties of the algorithms
+are dissimilar and that any deficiencies are not discovered
+simultaneously.
+
+So, for example, RSASHA1 and RSASHA1_NSEC3 is a poor choice in this
+regard, as the algorithms are identical (the algorithm identifier is used
+to signal NSEC3 support here, which was useful during the introduction
+of NSEC3).  Also the use of multiple keys only protects like the largest
+one.
+
+Trust Anchors
+=============
+
+Trust anchors can provide multiple algorithms, if a trust anchor
+contains multiple algorithms, a valid chain of trust is checked for them.
+Similar, if a RFC5011 automated key state contains VALID (or MISSING)
+keys with multiple algorithms, these algorithms are checked. For RFC5011,
+key revocation is checked and performed before the other checks in the
+RFC5011 state table when processing a DNSKEY probe, to make algorithm
+rollover possible (specifically the removal of the last key for the old
+algorithm).