<title>DNSSEC</title>

      <indexterm>

        <primary>BIND</primary>

        <secondary>DNS security extensions</secondary>

      </indexterm>

      <para>Domain Name System Security Extensions, or <acronym>DNSSEC</acronym>

	for short, is a suite of specifications to protect the 

	<acronym>DNS</acronym> clients, i.e. Internet resolvers, from forged

	<acronym>DNS</acronym> data, such as spoofed <acronym>DNS</acronym>

	records.  By using digital signatures, a resolver can verify the

	integrity and authenticity of the record.  It is worth noticing that

	<acronym>DNSSEC</acronym> does only provide integrity, it does not

	provide either confidentiality nor protection against false assumptions,

	meaning that it cannot protect against people going to 

	<hostid role="domainname">example.com</hostid> instead of 

	<hostid role="domainname">example.net</hostid> and similar.  The only 

	thing <acronym>DNSSEC</acronym> does is authenticate that the data is 

	from the domain owner and that it has not been compromised in transit. 

	The security of <acronym>DNS</acronym> is believed to be an important 

	step in securing the Internet in general.  For a more in-depth 

	knowledge of how <acronym>DNSSEC</acronym> works, the relevant

	<acronym>RFC</acronym>s is a good place to start.  See the list at the

	end of this chapter.</para>

      <para>The next two sections will demonstrate how to enable

	<acronym>DNSSEC</acronym> for an authorative <acronym>DNS</acronym>

	server and a recursive (or cashing) <acronym>DNS</acronym> server

	running <acronym>BIND</acronym>9.  While all versions of

	<acronym>BIND</acronym>9 supports <acronym>DNSSEC</acronym>, it is

	necessary to have at least version 9.6.2 in order to be able to use the

	signed root zone when validating <acronym>DNS</acronym> queries.  This is

	because earlier versions lack the required algorithms to enable

	validation using the root zone key.  It is strongly recommended to use

	<acronym>BIND</acronym> 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.</para>

      <sect3>

	<title>Recursive <acronym>DNS</acronym> server configuration</title>

	<para>To enable <acronym>DNSSEC</acronym> validation of queries done by

	  a recursive <acronym>DNS</acronym> server, a few changes to

	  <filename>named.conf</filename> are needed.  However, before changing

	  <filename>named.conf</filename> the root zone key, or trust anchor,

	  must be aquired.  Currently the root zone key is not available in a

	  file format <acronym>BIND</acronym> understands, so this has to be

	  manually generated.  The key itself can be obtained by querying the

	  root zone for it, using <appication>dig</application>.  By running 

	  <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY .

	  &gt; root.dnskey</userinput></screen> the key will end up in

	  <filename>root.dnskey</filename>. The contents should look something

	  like this:<programlisting>

. 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

          </programlisting>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 (<acronym role="Key Signing Key">KSK</acronym>).

          The second key, with value 256, is a subordinate key, commonly 

          called a Zone Signing Key

          (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the

          different key types later in the section <xref

          linkend="dns-dnssec-auth">.</para>

        <para>Now that the key is obtained, it has to be verified to be

          correct, and then made into a format <acronym>BIND</acronym> can

          use.  The next step is to generate a

          <acronym role="Delegation signer">DS</acronym> 

          <acronym role="Resource Record">RR</acronym> set.  This is done by

          running <screen>&propmt.user; <userinput>dnssec-dsfromkey -f

          root-dnskey . &gt; root.ds</userinput></screen>, which will emit two

          <acronym>RR</acronyms>s into <filename>root.ds</filename>.  These

          records are using SHA-1 and SHA-256 respectively, and should look

          similar to this, where the longer is using SHA-256.<programlisting>

. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

	  </programlisting>The SHA-256 <acronym>RR</acronym> can now be

	  compared to the digest in <ulink

	  url="https://data.iana.org/root-anchors/root-anchors.xml">

	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be

	  absolutely sure that the key has not been tampered with, the data in

	  the <acronym>XML</acronym> file can be verified using the

	  <acronym>PGP</acronym> signature in <ulink

	  url="https://data.iana.org/root-anchors/root-anchors.asc">

	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>

	<para>The last step is to format the key to a format

	  <acronym>BIND</acronym> understand. This differs a little between

	  version 9.6.2 and 9.7 and later.  Both uses a

	  <literal>managed-keys</literal> clause, but support for

	  <literal>initial-key</literal> was added in 9.7.

	  <literal>initial-key</literal> tells <acronym>BIND</acronym>

	  automatic tracking of the key. With <acronym>BIND</acronym> 9.6.2

	  it is necessary to update the key manually when it is changed. The

	  format should look like, for <acronym>BIND</acronym> 9.6.2:

	  <programlisting>

managed-keys {

	"." 257 3 8

	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF

	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX

	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD

	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz

	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS

	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq

	QxA+Uk1ihz0=";

};

	  </programlisting>For 9.7 the format will instead be:

	  <programlisting>

managed-keys {

        "." initial-key 257 3 8

	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF

	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX

	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD

	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz

	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS

	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq

	QxA+Uk1ihz0=";

};

	  </programlisting>The <literal>managed-keys</literal> directive can

	  now be added to <filename>named.conf</filename> either directly or

	  by including a file containing the key.  After all this is done it

	  is just to tell <acronym>BIND</acronym> to do

	  <acronym>DNSSEC</acronym> validation on queries.  This is achieved by

	  editing <filename>named.conf</filename> and add the following to the

	  <literal>options</literal> directive:<programlisting>

dnssec-enable yes;

dnssec-validation yes;

            </programlisting></para>

	<para>To verify that it is actually working, use

	  <application>dig</application> to make a query for a signed zone

	  using the resolver just set up.  A successful reply will contain

	  the <literal><acronym role="Authenticated Data">AD</acronym>

	  </literal> flag to indicate the data was authenticated.  Running a

	  query such as <screen>&prompt.user; <userinput>dig @resolver +dnssec

	  se ds</userinput><screen> should return the <acronym>DS</acronym>

	  <acronym>RR</acronyms> for the .se zone.  In the

	  <literal>flags:</literal> section the

	  <literal><acronym>AD</acronym></literal> flag should be set, as seen

	  in:<programlisting>

...

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

...

	  </programlisting>.  This means that the resolver is now capable of

	  authenticate made <acronym>DNS</acronym>queries.</para>

      </sect3>

      <sect3 id="dns-dnssec-auth">

        <title>Authorative <acronym>DNS</acronym> server configuration</title>

        <para>In order to get an authorative nameserver to serve a

          <acronym>DNSSEC</acronym> 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

          (<acronym role="Key Signing Key">KSK</acronym>) and Zone Signing Key

          (<acronym role="Zone Signing Key">ZSK</acronym>) respectively.  The

          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain

          of authority to the data in need of validation and as such also called

          a Secure Entry Point (<acronym role="Secure Entry

          Point">SEP</acronym>) 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 <acronym role="Zone

          Signing Key">ZSK</acronym> is used to sign the zone, and only needs to

          be published there.</para>

        <para>To enable <acronym>DNSSEC</acronym> for the <hostid

          role="domainname">example.com</hostid> zone depicted in previous

          examples, the first step is to use

          <application>dnssec-keygen</application> to generate the

          <acronym>KSK</acronym> and <acronym>ZSK</acronym> keypair.  This keypair

          can utilize different cryptograhic algorithms.  Currently the mandatory

          algorithm is <literal>RSA/SHA-1</literal>.  In the examples the key

          length used is 2048 bits for the <acronym>KSK</acronym> and 1024 bits

          for the <acronym>ZSK</acronym>.  To generate the

          <acronym>KSK</acronym> for <hostid

          role="domainname">example.com</hostid>, run <screen>&promt.user;

          <userinput>dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE

          example.com</userinput></screen> and to generate the

          <acronym>ZSK</acronym>, run <screen>&promt.user;

          <userinput>dnssec-keygen -a RSASHA1 -b 1024 -n ZONE

          example.com</userinput></screen>.

          <application>dnssec-keygen</application> outputs two files, the public

          and the private keys in files named similar to

          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and

          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The

          <literal>nnnnn</literal> 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

          <literal>$include</literal> statement. It should look something like

          this:<programlisting>

$include Kexample.net.+005+nnnnn.key    ; ZSK

$include Kexample.net.+005+nnnnn.key    ; KSK

	  </programlisting></para>

	<para>The only steps left is to sign the zone and tell

	  <acronym>BIND</acronym> to use the signed zonefile.  To sign a zone

	  <application>dnssec-signzone</application> is used.  The command to

	  sign the zone <hostid role="domainname">example.com</hostid>, located in

	  <filename>example.com.db</filename> would look similar to

	  <screen>&promt.user; <userinput>dnssec-signzone -o example.com -k

	  Kexample.com+005+nnnnn example.com.db

	  Kexample.com+005+nnnnn.key</userinput></screen>. The key supplied to

	  the <literal>-k</literal> argument is the <acronym>KSK</acronym> and

	  the other key file is the <acronym>ZSK</acronym> that should be used

	  in the signing.  It is possible to supply more than one

	  <acronym>KSK</acronym> and <acronym>ZSK</acronym>, 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 <application>dnssec-signzone</application> is a zone file with all

	  <acronym>RR</acronym>s signed.  This output will end up in a file with

	  the extension <literal>.signed</literal>, such as

	  <filename>example.com.db.signed</filename>.  To use this signed zone

	  just modify the zone directive in <filename>named.conf</filename> 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.</para>

	<para>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 <acronym>DNS</acronym> data

	  unavailable for a time, untill the new key has propagated through the

	  <acronym>DNS</acronym> hierarchy.  For more information on key

	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see

	  <ulink

	  url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> 4641:

	  <acronym>DNSSEC</acronym> Operational practices</ulink>.</para>

      </sect3>

      <sect3>

        <title>Automation using <acronym>BIND</acronym>9.7 or later</title>

        <para>Beginning with <acronym>BIND</acronym> version 9.7, a new feature

          called <emphasis>Smart Signing</emphasis> 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

          <literal>auto-dnssec</literal> it is possible to create a dynamic zone

          which will be resigned as needed.  To update this zone the tool

          <application>nsupdate</application> with the new option

          <literal>-l</literal> is used. <application>rndc</application> has

          also grown the ability to sign zones with keys in the key repository,

          using the option <literal>sign</literal>.  To make this work, put

          something similar to what is shown below into

          <filename>named.conf</filename>.<programlisting>

zone example.com {

	type master;

	key-directory "keys";

	update-policy local;

	auto-dnssec maintain;

	file "dynamic/example.com.zone";

};

	  </programlisting>This will tell named to use automatic signing and

	  updating of the zone <hostid role="domainname">example.com</hostid>.

	  After this is done just generate keys for the zone as explained in

	  <xref linkened="dns-dnssec-auth">, put these in the key repository

	  denoted by <literal>key-directory</literal> in the zone configuration

	  and sign the zone using <application>rndc</application>.  Updates to

	  the zone is done using <application>nsupdate</application> which will

	  take care of resigning the zone with the new data added.  For further

	  details, see <xref linkened="dns-read"> and the

	  <acronym>BIND</acronym> documentation.</para>

	</sect3>

    </sect2>

    <sect2>

	<listitem>

	  <para><ulink

	      url="http://tools.ietf.org/html/rfc4033">RFC4033

	      - DNS Security Introduction and Requirements</ulink></para>

	</listitem>

	<listitem>

	  <para><ulink

	      url="http://tools.ietf.org/html/rfc4034">RFC4034

	      - Recource Records for the DNS Security Extensions</ulink></para>

	</listitem>

	<listitem>

	  <para><ulink

	      url="http://tools.ietf.org/html/rfc4035">RFC4035

	      - Protocol Modifications for the DNS Security Extensions</ulink></para>

	</listitem>

	<listitem>

	  <para><ulink

	      url="http://tools.ietf.org/html/rfc4641">RFC4641

	      - DNSSEC Operational Practices</ulink></para>

	</listitem>

	<listitem>

	  <para><ulink

	      url="http://tools.ietf.org/html/rfc5011">RFC 5011

	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>

	      Trust Anchors</ulink></para>

	</listitem>