<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

	<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.  Note that

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

	provide neither confidentiality nor protection against false

	assumptions.  This meanins that it cannot protect against people going

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

	<hostid role="domainname">example.com</hostid>.  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 

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

	<acronym>RFC</acronym>s are a good place to start.  See the list in

	<xref linkened="dns-read">.

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

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

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

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

	<acronym>BIND</acronym>9 support <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 automatic

	key updating for the root key, as well as other features 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>Enabling <acronym>DNSSEC</acronym> validation of queries done by

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

	  <filename>named.conf</filename>.  Before making these changes

	  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 it has to be manually

	  converted into the proper format.  The key itself can be obtained by

	  querying the root zone for it, using <application>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 obtained keys differ from

          this example, they might have changed since these instructions were

          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. This value indicates that this is a 

          Secure Entry Point (<acronym role="Secure Entry Point">SEP</acronym>,

          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 the key must be verified verified and formatted so that

          <acronym>BIND</acronym> can use it.  To verify the key, generate a

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

          <acronym role="Resource Record">RR</acronym> set.  Create a file

          containing these <acronym role="Resource Record">RR</acronym>s with 

          <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey .

          &gt; root.ds</userinput></screen>.  These records use SHA-1 and

          SHA-256 respectively, and should look similar to the following

          example, 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>Next, the key must be formatted properly.  This differs a

	  little between <acronym>BIND</acronym> versions 9.6.2 and 9.7 and

	  later.  Both use a <literal>managed-keys</literal> clause, but

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

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

	  automatically track changes to the key and update it as necesarry.

	  Users of <acronym>BIND</acronym> 9.6.2 must do this manually.

	  For <acronym>BIND</acronym> 9.6.2 the format should look like:

	  <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 these steps, tell

	  <acronym>BIND</acronym> to do <acronym>DNSSEC</acronym> validation

	  on queries by editing <filename>named.conf</filename> and adding 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 configured.  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

	  @<replaceable>resolver</replaceable> +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

	  authenticating <acronym>DNS</acronym>queries.</para>

      </sect3>

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

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

        <para>In order to get an authoritative 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 is 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>&prompt.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>&prompt.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>Finally, 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>&prompt.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, until 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

          called a <emphasis>key repository</emphasis>, 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 use

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

          <option>-l</option>. <application>rndc</application> has

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

          using the option <option>sign</option>.  To tell

          <acronym>BIND</acronym> to use this automatic signing and zone

          updating for <hostid role="domainname">exanple.com<hostid>, add the

          following to <filename>named.conf</filename>:

zone example.com {

	type master;

	key-directory "keys";

	update-policy local;

	auto-dnssec maintain;

	file "dynamic/example.com.zone";

};

	  After making these changes, generate keys for the zone as explained in

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

	  given as the argument to the <literal>key-directory</literal> in the

	  zone configuration and sign the zone using

	  <application>rndc</application>.  Updates to a zone configured this

	  way must be done using <application>nsupdate</application>, which will

	  take care of re-signing 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>