From owner-freebsd-doc@FreeBSD.ORG Sun May 22 09:40:09 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1732106564A for ; Sun, 22 May 2011 09:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA9388FC0C for ; Sun, 22 May 2011 09:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4M9e8Gb016685 for ; Sun, 22 May 2011 09:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4M9e8fi016684; Sun, 22 May 2011 09:40:08 GMT (envelope-from gnats) Resent-Date: Sun, 22 May 2011 09:40:08 GMT Resent-Message-Id: <201105220940.p4M9e8fi016684@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Niclas Zeising Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C721B1065674 for ; Sun, 22 May 2011 09:34:16 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id C823D8FC0A for ; Sun, 22 May 2011 09:34:14 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 47E7540002 for ; Sun, 22 May 2011 11:34:13 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3994940006; Sun, 22 May 2011 11:34:13 +0200 (CEST) Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C869940002 for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 53392119C04 for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10]) by mail.daemonic.se (Postfix) with ESMTPS id 2011012B2DA for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: (from zeising@localhost) by vincent.daemonic.se (8.14.4/8.14.4/Submit) id p4M9Y9JL041108; Sun, 22 May 2011 11:34:09 +0200 (CEST) (envelope-from zeising) Message-Id: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> Date: Sun, 22 May 2011 11:34:09 +0200 (CEST) From: Niclas Zeising To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 09:40:09 -0000 >Number: 157245 >Category: docs >Synopsis: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun May 22 09:40:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: FreeBSD 8.2-RELEASE amd64 >Organization: >Environment: System: FreeBSD vincent.daemonic.se 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Apr 20 17:22:47 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64 >Description: DNSSEC is deemd to be very important in order to secure the Internet as a whole I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook. As a first step, I would like some review on my work, both from a technical and a linguistic point of view. >How-To-Repeat: >Fix: Attached patch contains my changes to the handbook to include information about DNSSEC. Please review it as a first step, so that I can work on getting it into the handbook. --- network-servers.chapter.sgml.diff begins here --- Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ chapter.sgml 21 May 2011 19:13:24 -0000 @@ -3872,6 +3872,293 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect the + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. It is worth noticing that + DNSSEC does only provide integrity, it does not + provide either confidentiality nor protection against false assumptions, + meaning that it cannot protect against people going to + example.com instead of + example.net and similar. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + knowledge of how DNSSEC works, the relevant + RFCs is a good place to start. See the list at the + end of this chapter. + + The next two sections will demonstrate how to enable + DNSSEC for an authorative DNS + server and a recursive (or cashing) DNS server + running BIND9. While all versions of + BIND9 supports DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use the + signed root zone when validating DNS queries. This is + because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + BIND 9.7 or later, to take advantage of the automatic + key updating function for the root key, as well as other functions to + automatically keep zones signed and signatures up to date. Where + configurations differ between 9.6.2 and 9.7 and later, differences will + be pointed out. + + + Recursive <acronym>DNS</acronym> server configuration + + To enable DNSSEC validation of queries done by + a recursive DNS server, a few changes to + named.conf are needed. However, before changing + named.conf the root zone key, or trust anchor, + must be aquired. Currently the root zone key is not available in a + file format BIND understands, so this has to be + manually generated. The key itself can be obtained by querying the + root zone for it, using dig. By running + &prompt.user; dig +multi +noall +answer DNSKEY . + > root.dnskey the key will end up in + root.dnskey. The contents should look something + like this: +. 93910 IN DNSKEY 257 3 8 ( + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + ) ; key id = 19036 +. 93910 IN DNSKEY 256 3 8 ( + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt + ) ; key id = 34525 + Do not be alarmed if the keys differ, they might + have changed since this was last updated. This output actually + contains two keys. The first key in the listing, with the value 257 + behind the DNSKEY record type, is the one needed. The value + indicates that this is a Secure Entry Point, more commonly known as + a Key Signing Key (KSK). + The second key, with value 256, is a subordinate key, commonly + called a Zone Signing Key + (ZSK). More on the + different key types later in the section . + + Now that the key is obtained, it has to be verified to be + correct, and then made into a format BIND can + use. The next step is to generate a + DS + RR set. This is done by + running &propmt.user; dnssec-dsfromkey -f + root-dnskey . > root.ds, which will emit two + RRs into root.ds. These + records are using SHA-1 and SHA-256 respectively, and should look + similar to this, where the longer is using SHA-256. +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + The SHA-256 RR can now be + compared to the digest in + https://data.iana.org/root-anchors/root-anchors.xml. To be + absolutely sure that the key has not been tampered with, the data in + the XML file can be verified using the + PGP signature in + https://data.iana.org/root-anchors/root-anchors.asc. + + The last step is to format the key to a format + BIND understand. This differs a little between + version 9.6.2 and 9.7 and later. Both uses a + managed-keys clause, but support for + initial-key was added in 9.7. + initial-key tells BIND + automatic tracking of the key. With BIND 9.6.2 + it is necessary to update the key manually when it is changed. The + format should look like, for BIND 9.6.2: + +managed-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + For 9.7 the format will instead be: + +managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + The managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After all this is done it + is just to tell BIND to do + DNSSEC validation on queries. This is achieved by + editing named.conf and add the following to the + options directive: +dnssec-enable yes; +dnssec-validation yes; + + + To verify that it is actually working, use + dig to make a query for a signed zone + using the resolver just set up. A successful reply will contain + the AD + flag to indicate the data was authenticated. Running a + query such as &prompt.user; dig @resolver +dnssec + se ds should return the DS + RR for the .se zone. In the + flags: section the + AD flag should be set, as seen + in: +... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + . This means that the resolver is now capable of + authenticate made DNSqueries. + + + + Authorative <acronym>DNS</acronym> server configuration + In order to get an authorative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. The + KSK is used to build a chain + of authority to the data in need of validation and as such also called + a Secure Entry Point (SEP) key. This key needs to be published in the + parent zone as well, to establish the trust chain. How this is + accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and only needs to + be published there. + + To enable DNSSEC for the example.com zone depicted in previous + examples, the first step is to use + dnssec-keygen to generate the + KSK and ZSK keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run &promt.user; + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE + example.com and to generate the + ZSK, run &promt.user; + dnssec-keygen -a RSASHA1 -b 1024 -n ZONE + example.com. + dnssec-keygen outputs two files, the public + and the private keys in files named similar to + Kexample.com.+005+nnnnn.key (public) and + Kexample.com.+005+nnnnn.private (private). The + nnnnn part of the file name is a five digit key ID. + Keep track of which key ID belongs to which key. This is especially + important when having more than one key in a zone. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + The only steps left is to sign the zone and tell + BIND to use the signed zonefile. To sign a zone + dnssec-signzone is used. The command to + sign the zone example.com, located in + example.com.db would look similar to + &promt.user; dnssec-signzone -o example.com -k + Kexample.com+005+nnnnn example.com.db + Kexample.com+005+nnnnn.key. The key supplied to + the -k argument is the KSK and + the other key file is the ZSK that should be used + in the signing. It is possible to supply more than one + KSK and ZSK, which will result + in the zone being signed with all supplied keys. This can be needed + to supply zone data signed using more than one algorithm. The output + of dnssec-signzone is a zone file with all + RRs signed. This output will end up in a file with + the extension .signed, such as + example.com.db.signed. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + Some cautionary words at the end. Be sure to keep private keys + confidential, as with all cryptographic keys. When changing a key it + is best to include the new key into the zone, while still signing with + the old key, and then move over to using the new key to sign. After + these steps are done the old key can be removed from the zone. + Failiure to do this might render the DNS data + unavailable for a time, untill the new key has propagated through the + DNS hierarchy. For more information on key + rollovers and other DNSSEC operational issues, see + RFC 4641: + DNSSEC Operational practices. + + + + Automation using <acronym>BIND</acronym>9.7 or later + Beginning with BIND version 9.7, a new feature + called Smart Signing was introduced. This + feature aims to make the key management and signing process simpler by + automating parts of the task. By putting the keys into a directory, + from now on called a key repository, and using the new option + auto-dnssec it is possible to create a dynamic zone + which will be resigned as needed. To update this zone the tool + nsupdate with the new option + -l is used. rndc has + also grown the ability to sign zones with keys in the key repository, + using the option sign. To make this work, put + something similar to what is shown below into + named.conf. +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "dynamic/example.com.zone"; +}; + This will tell named to use automatic signing and + updating of the zone example.com. + After this is done just generate keys for the zone as explained in + , put these in the key repository + denoted by key-directory in the zone configuration + and sign the zone using rndc. Updates to + the zone is done using nsupdate which will + take care of resigning the zone with the new data added. For further + details, see and the + BIND documentation. + + + + + Security Although BIND is the most common implementation of DNS, @@ -3897,7 +4184,7 @@ - + Further Reading BIND/named manual pages: @@ -3932,6 +4219,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource Records for the DNS Security Extensions + + + + RFC4035 + - Protocol Modifications for the DNS Security Extensions + + + + RFC4641 + - DNSSEC Operational Practices + + + + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors + + --- network-servers.chapter.sgml.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: