DNSSEC Operational HOWTO. Contents. Olaf M. Kolkman. RIPE NCC November 12, 2002 Revision : 1.3. I DNSSEC Tutorial 4

Transcription

1 DNSSEC Operational HOWTO. Olaf M. RIPE NCC November 12, 2002 Revision : 1.3 Contents 1 Introduction On this document State of DNSSEC I DNSSEC Tutorial 4 2 Securing Zone Transfers Task at hand Configuring TSIG Keys Primary servers configuration of TSIG Secondary servers configuration of TSIG Troubleshooting TSIG configuration TSIG signing of Notifies Possible problems Configuring a caching forwarder as verifier Task at hand Configuring the caching forwarder Troubleshooting a verifier Setting up a locally secured zone Task at hand Creating a key pair Zone signing Caching forwarder configuration (O@ripe.net) DNSSEC operations HOWTO Page 1

2 4.5 Zone resigning Troubleshooting zone signing Possible problems Delegating of Signing authority; becoming globally secure Task at Hand Key exchange, signing and securing Possible problems Rolling over keys 22 7 Emergency Rollover 24 8 How to proceed Information Development Tools lwres Net::DNS::SEC II Demo Specifics 26 9 The DEMO environment Domain name setup example files named.conf example zone file References, Acknowledgments and Copyright 30 III Appendix 31 A The RIPE NCC and DNSSEC 31 A.1 The RIPE NCC DISI project A.2 DNSSEC DNSSEC operations HOWTO Page 2

3 1 Introduction 1.1 On this document This document has been produced as part of the RIPE NCC DNSSEC course. The DNSSEC course consist of two parts. An Introduction to DNSSEC and an real-life demonstration. The demonstration is presented by means of a slide show and is accompanied by this document. The Introduction is presented using slides only. For this document it is assumed that the reader is familiar with the basic principles of DNSSEC, as presented in The Introduction. This document is tailored towards the course, but we have tried to write it in such a way that it can also be useful as a HOWTO when setting up DNSSEC in ones own environment. In this HOWTO we will concentrate on the following tasks: Securing Zone Transfers. (section 2) Securing Zones for local use; how to secure your organization (section 4). When you learned and implemented this, you can be sure that DNS data in your organization is not tampered with. If you have a locally secured zone it is a small step to become part of a chain of trust. Delegating Signing authority; building a chain of trust (section 5). You will learn how to exchange keys with your parent and with your children. Rolling over keys. (section 6) In every section we describe the task at hand, the tools that are needed, some troubleshooting techniques and possible problems one might encounter. We have used BIND version 9.3.0s during the production of this document, there will be minimal differences with respect to newer versions of BIND since the availability and functionality of tools may differ. In the text we will refer to zone and system administrators. A zone administrator is the person that is responsible for zone data maintenance. A system administrator is responsible for maintaining the nameserver system. These 2 functions may be united in one person. The examples given here are based on an example environment (section 9) from one of our workshops setup. In the workshop network (isolated from the Internet) we run our own root with one top level domain: tld. The tld top level domain does not exist on the Internet. The material for the DNSSEC course is available from We are trying to improve the material wherever we can, so, comments or suggestions for format of the HOWTO, the slides or this text are welcomed by the author. DNSSEC operational procedures are a moving target and tools for key management and rollover are not yet available. Therefore updates of this document may be expected in the near future. (See 1 Bleading edge technology at the time of writing. DNSSEC operations HOWTO Page 3

4 1.2 State of DNSSEC DNSSEC[rfc2535] is on the IETF standards track and has been implemented in the BIND nameserver software (versions 9.0 to 9.2). The operational experience by early deployers, among which the RIPE NCC, has indicated that the DNSSEC protocol needs to be modified to be able to cope with operational problems that occur with delegation of authority. Solutions for these scaling problems have been proposed and have been implemented in snapshot versions of BIND 9.3. This document follows the assumes DNSSEC as in RFC2535 but with DS. Issues like NXT, OPT-IN and the exact semantics of the AD bit are still under discussion. As soon as IETF concensus on these issues is reached and supporting software is available, we ll update this HOWTO. Part I DNSSEC Tutorial 2 Securing Zone Transfers 2.1 Task at hand Secure zone transfers are achieved by providing authentication of the servers and by providing data integrity during transfer. The mechanism used to enable this is referred to as TSIG [rfc2845] and is based on a shared secret. The shared secret is used to sign the content of each DNS packet. The signature can be used for both authentication and for integrity checking of the data. In order to prevent a malicious third party to retransmit captured data (replay attack) a time stamp is included in the data. The TSIG mechanism can also be used to prevent unauthorized zone transfers; only owners of the secret key are able to do a zone transfer 2 We will describe how primary server pri.ws.disi and secondary server sec.ws.disi need to be configured to enable TSIG for zone transfers. To configure TSIG one has to perform the following steps: Synchronize clocks. Create and distribute a shared secret. At the primary server, create an access list specifying which keys are allowed transfer. At the secondary server, tell which keys to use when contacting which primary servers 2 The data in the DNS is public data; disabling zone transfers does not guarantee your DNS data to become invisible. DNSSEC operations HOWTO Page 4

5 The first item is a pre-requisite for DNSSEC. If you do DNSSEC you should be in sync with the rest of the world: Use NTP. Time zones can be confusing. Use date -u to verify if your machine has the proper UTC time. TSIG configuration is a task for system administrators. 2.2 Configuring TSIG Keys To secure a zone transfer the primary server and the secondary server administrators have to configure a TSIG key in named.conf. The TSIG key consists of a secret and a hashing algorithm and are identified by domain names. We recomend that you maintain the list of secret keys in a separate file which is readable by root only and included in the named.conf file (e.g. by include /var/named/shared.keys). The key statement has the following syntax: key key_id { algorithm string; secret string; This statement needs to be exactly the same for the two parties involved. The key id is a domain name uniquely identifying the key. If you have a large number of secret keys to maintain you should use a fully qualified domain name to avoid name clashes. We recommend you use a key id that identifies both ends such as pri-sec.ws.disi.. For the algorithm string you have no choice; Currently the only supported algorithm in the TSIG specification is hmac-md5. The secret string is the shared secret in a base-64 encoded string. One can use dnssec-keygen to generate a truly random secret or use a pass-phrase - we describe both methods below. Generating a TSIG secret with dnssec-keygen dnssec-keygen is the tool that we use to generate keys (see figure 1, page 13 for the syntax and arguments). We will use dnssec-keygen to generate a base64 encoded random number that will be used as the secret string. The arguments that we have to provide dnssec-keygen to generate a TSIG key are: DNSSEC operations HOWTO Page 5

6 -a HMAC-MD5 the algorithm used -b bitsize The length of the key generated, 128 bit is recommended in [rfc2845] -n HOST The nametype, HOST is used for this purpose. The nametype is not really relevant when generating shared secrets. name the domain name you will be using to identify this key. Optional Arguments -r /dev/urandom This option is needed if /dev/random is not provided with sufficient entropy. Use /dev/urandom on FreeBSD systems (4.4-STABLE and before) or when experience time-outs without this option. The command produces two files 3 as output. The name of the files contain relevant information: Kdomain name+algorithm id +key id.extension. The domain name is the name specified as the name of the key. The algorithm id identifies the algorithm used: 5 for HMAC-MD5 (1 and 3 are for RSA and DSA respectively see section??). The key id is an identifier for the key material, it is not of relevance for symmetric keys. The extension is either key or private, the first one is the public key and the second one is the private key. The format of these files differs a bit but they contain exactly the same information; a base64 encoded random number that you are going to use as a shared secret. Do not be misdirected by the extensions private and key, both the files should be kept secure 4! Note that the -n HOST and the name are not used for the generation of the base64 encoded random number. It is a convention to use the unique domainname label that is used to identify the key as the name. # dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 \\ -n HOST pri-sec.ws.disi Kpri-sec.ws.disi # cat Kpri-sec.ws.disi key pri-sec.ws.disi. IN KEY gqoqmja/lghwja8vtd7u6w== # cat Kpri-sec.ws.disi private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: gqoqmja/lghwja8vtd7u6w== 3 Two files are overkill if one only needs one random number. 4 Since the secret material is copied to the configuration files and these files are not used in production, you may consider to delete them. DNSSEC operations HOWTO Page 6

7 The base64 encoded random number is: gqoqmja/lghwja8vtd7u6w==, it should be inserted in the secret of the key definition: key pri-sec.ws.disi.{ algorithm hmac-md5; secret "gqoqmja/lghwja8vtd7u6w=="; This key definition should be included in both primary and secondary nameserver configuration file. It is recommended to generate a secret for every different party you are involved with and you will need to maintain as many secrets as zones you are secondary for. Other ways to generate secrets The dnssec-keygen command provides you with a truly random bit sequence. It might be difficult to communicate the secret to your colleague running a secondary server on the other side of the world. In those cases you may want to choose to fall back to a pass-phrase that can be communicated over the telephone. You can use any base64 encoder to convert the pass-phrase to a valid string in the key-definition. # echo "Crypto Rules" mmencode Q3J5cHRvIFJ1bGVzCg== or if mmencode is not available maybe this perl script can assist you. #!/usr/bin/perl use MIME::Base64; print encode_base64("@argv") ; Actually any string that can be base64 decoded will do. ThisIsAValidBase64String can also be used as secret string. 2.3 Primary servers configuration of TSIG Also see section and of the online BIND documentation Both the primary and secondary server should have shared secret configured by using the key definition in a file included in named.conf (see above). The primary server can now use the key in what BIND calls an address match list. These lists appear in the allow-notify, allow-query, allow-transfer and allow-recursion statements which controls access to the server. Relevant at this point is the allow-transfer in the zone definition. Using the key generated above the primary server for ws.disi would have the following statement in named.conf: DNSSEC operations HOWTO Page 7

8 zone "ws.disi" { type master; file db.ws.disi; \\ allow transfer only from secondary server that has \\ key pri-sec.ws.disi. allow-transfer { key pri-sec.ws.disi. ; notify yes; 2.4 Secondary servers configuration of TSIG Both the primary and secondary serve should have shared secret configured by using the key definition in named.conf (see above). The server definition in named.conf is used to instruct the nameserver to use a specific key when contacting another nameserver. \\ secondary for ws.disi \\ primary server pri.ws.disi is on server { keys { pri-sec.ws.disi.; 2.5 Troubleshooting TSIG configuration You can check the format of your named.conf using the named-checkconf program. This program reads the configuration file using the same routines as named itself. To troubleshoot your configuration you have the log file and dig at your disposal. Before adding the allow-transfer { key pri-sec.ws.disi. ; you should be able to transfer the domain from any machine. ws.disi AXFR should be successful. After key configuration the same command should give you output similar to: ; <<>> DiG 9.2.0rc1 ws.disi AXFR ;; global options: printcmd ; Transfer failed. You can test if the key is configured correctly in two ways. 1. You ask the zone administrator to increase the SOA serial and to have the zone reloaded on the primary server. The secondary server should pick up the changes. The log file of the secondary server will have entries like:... general: info: zone ws.disi/in: transfered serial xfer-in: info: transfer of ws.disi/in from #53: end of transfer DNSSEC operations HOWTO Page 8

9 2. You use dig to test the key by using dig with the -k file: ws.disi AXFR -k Kpri-sec.ws.disi key Alternatively you can use the -y switch and specify the key-name and the secret 5 with the -y switch; ws.disi AXFR -y pri-sec.ws.disi.:gqoqmja/lghwja8vtd7u6w== should do the trick. The log file of the primary server you tried this against will have entries similar to the following if the key did not match... security: error: client #1379: zone transfer ws.disi/in denied 2.6 TSIG signing of Notifies TODO: add server directive for master, add allow-notify directive for slave. 2.7 Possible problems Timing problems Machines that are involved in a TSIG signed transaction need to have their clocks synchronized within a few 6 minutes. Use NTP to synchronize the machines and make sure the time zones are properly configured. A wrong time-zone configuration can lead to hard to spot problems; use date -u to check what your machine thinks is the UTC time. Multiple server directives TSIG is a mechanism to protect communication on a per machine basis. Having multiple server directives for the same server or multiple keys in one server directive might lead to unexpected results... as a matter of fact it most certainly will lead to unexpected results. 3 Configuring a caching forwarder as verifier 3.1 Task at hand We want to configure a caching server as a verifying cache. Users that use this cache as their nameserver will in this way only receive data that is either verifiable secure or verifiable insecure any spoofed data (marked bad ) will not find it s way to the the users. By configuring a public key for a specific zone we tell the caching forwarder that all data coming from that zone should be signed with the private key of that key pair. The zone acts as a secure entry point of the DNS tree and the key configured in the verifiable caching nameserver acts as the start for a chain of trust. In an ideal situation you have only one key configured as a secure entry point: the key of the root zone. 5 Take care when using secrets on the command line of multi-user systems: on most Unix system command line arguments are visible on the output of ps -auxwww or via the /proc/ file system 6 BIND has 5 minutes hard coded DNSSEC operations HOWTO Page 9

10 We assume you have a nameserver that has been configured as a cachingonly nameserver and that another nameserver in your organization has been configured to run as an authoritative server for a secured zone called sub.tld.. Notes on how to setup a secured zone can be found below in section Configuring the caching forwarder First you have to get hold of the public key that you want to configure. It is possible to get it from the DNS, but you will need to verify the key you obtained by an off-line mechanism. There are several possible ways that this can be done and it all depends on the policy of the zone administrator. The key could be published in the national newspaper, it can be published on a website that can be authenticated by a (trusted) 3rd party certificate. Make sure that you do not use the DNS to verify the key and you will be OK. Besides that you have to verify the keys you obtaied out of band you have to make sure that the key you configure is the so called key signing key. If the zone maintainer so decides he or she may make a destinction between keys. Some of them may be used to only sign key RR sets, others may be used to sign all the data in the zone. This distinction can only be communicated off-band since the KEY RR data provides no information on the operational use of the keys. We assume you have obtained the key-signing key of sub.tld.. Once you obtained the key you have to include the following statement in the named.conf of the caching forwarder. trusted-keys { "sub.tld CLGc9Re9I3pg7QAqx... VL24iYygAbSu3 The format lookes like an entry in a zone file but note the quotes around the label and the public key material, they are not to be forgotten. There is no CLASS and TTL. As soon as a trusted-key has been configured, data from that zone or its sub zones will be verified by the caching forwarder. If data is verified by the caching forwarder the ad-bit 7 will be set by the forwarder (see the flags in the following example). ; <<>> DiG 9.3.0s <<>> +dnssec sub.tld SOA ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: The ad bit is defined in [rfc2535] section 6.1, the semantics of the AD bit are being fine tuned and may be subject to change in the near future[wg]. DNSSEC operations HOWTO Page 10

11 3.3 Troubleshooting a verifier It is important that you check on the proper working of the verifyer. This can be done by turning on the logging for the veryfining nameserver by using a channel (dnssec log in the example below) to which the errors of the dnssec category are directed. Make sure you log at least at severity debug 3 that way you will be able to see the chains of trust being validated. logging{ channel dnssec_log { file "log/dnssec" size 20m; print-time yes; print-category yes; print-severity yes; severity debug 3; // a DNSSEC log channel // timestamp the entries // add category name to entries // add severity level to entries // print debug message <= 3 t } category dnssec { dnssec_log; The output in the logfile will look similar to the output below. The attempt for positive response validation shows how the verifyer tries to prove that the RR set is trusted by following the chain of trust to the appropriate secure entry point, your trusted-key statement. debug 3: client #1164: request is not signed debug 3: client #1164: recursion available debug 3: client #1164: query (cache) approved debug 3: validating sub.tld SOA: starting debug 3: validating sub.tld SOA: attempting positive response validation debug 3: validating sub.tld KEY: starting debug 3: validating sub.tld KEY: attempting positive response validation debug 3: validating sub.tld KEY: verify rdataset: success debug 3: validating sub.tld KEY: signed by trusted key; marking as secure debug 3: dns_validator_destroy debug 3: validating sub.tld SOA: in fetch_callback_validator debug 3: validating sub.tld SOA: keyset with trust 7 debug 3: validating sub.tld SOA: resuming validate debug 3: validating sub.tld SOA: verify rdataset: success debug 3: validating sub.tld SOA: marking as secure debug 3: dns_validator_destroy 4 Setting up a locally secured zone 4.1 Task at hand The purpose of this exercise is to protect the DNS data as published by the zone administrator. Once we have configured the organization s resolvers and signed the zones DNS data, we can be sure that data is not tampered with; not while the DNS data is on the wire, not while the data lives on the master or slave servers disks. DNSSEC operations HOWTO Page 11

12 We will configure a caching forwarder to verify the DNS data that exists within our organization. If somebody tampered with that data the forwarder will notice this. Resolvers using this caching forwarder (it sits in /etc/resolv.conf) will only receive secure or verifiable unsecured data. We want to sign the zone data for our own organization (say sub.tld.) and configure the caching forwarders on our organizations network to verify data against the public key of our organization. In terms of [rfc3090] this is called a locally secured zone. Note that in the text below, the assumption holds that your organization s domain names are maintained in one zone. If domain name administration is delegated to sub zones things get more complicated, see section 5. At this moment the caching forwarder is the only architectural element for which DNSSEC verification is implemented. There are no applications that will do their own verification yet, nor are there stub-resolvers that are able of retrieving and verifying SIG resource records. To establish this we need to create a public key pair, sign our zones and publish the data. We also need to configure the caching forwarders with the public key. Signing the zone data is the task of the zone administrator, configuring the caching forwarder is a task of system administrators. The examples are based on the example zone in section 10.2 on page Creating a key pair dnssec-keygen is the tool that we use to generate keys (see figure 1, page 13 for the syntax and arguments). We will use dnssec-keygen to generate a private-public key pair. The arguments that we have to provide dnssec-keygen are: -a RSA, RSAMD5, the algorithm used DH, DSA, RSASHA1 -b bitsize The length of the key generated, seizes between 512 and 4096 bits depending on the algorithm. -n ZONE The nametype, ZONE is used for DNSSEC. name the domain name of the zone you will sign with this key. Optional Arguments -r /dev/urandom This option is needed if /dev/random is not provided with sufficient entropy. Use this option on FreeBSD systems (4.6-Stable and before) or when experience time-outs without this option. DNSSEC operations HOWTO Page 12

13 Usage: dnssec-keygen -a alg -b bits -n type [options] name Amsterdam-Wash. DC August-Sep, 2002 Required options: -a algorithm: RSA RSAMD5 DH DSA RSASHA1 HMAC-MD5 -b key size, in bits: RSAMD5: [ ] RSASHA1: [ ] DH: [ ] DSA: [ ] and divisible by 64 HMAC-MD5: [1..512] -n nametype: ZONE HOST ENTITY USER name: owner of the key Other options: -c <class> (default: IN) -e use large exponent (RSAMD5/RSASHA1 only) -g <generator> use specified generator (DH only) -t <type>: AUTHCONF NOAUTHCONF NOAUTH NOCONF (default: AUTHCONF) -p <protocol>: default: 3 [dnssec] -s <strength> strength value this key signs DNS records with (default: 0) -r <randomdev>: a file containing random data -v <verbose level> Output: K<name>+<alg>+<id>.key, K<name>+<alg>+<id>.private Figure 1: dnssec-keygen arguments The output resides in two files. The name of the files contain relevant information: Kdomain name+algorithm id +key id.extension. The domain name is the name you specified on the command line, it is used by other BIND DNSSEC tools, if you use a name different from the domain name you might confuse those tools. The algorithm id identifies the algorithm used: 1 for RSA, 3 for DSA, and 5 for HMAC-MD5 (TSIG only). The key id is an identifier for the key material. This key id is used by the SIG Resource Record. The extension is either key or private the first one is the public key, the second one is the private key. We create an RSASHA1 keyset for sub.tld: # dnssec-keygen -r/dev/urandom -a RSASHA1 -b n ZONE sub.tld Ksub.tld Lets have a look at the content of these file (we truncated the base64 key material): cat Ksub.tld key sub.tld. IN KEY AQO9+CFJ7j... The public key (.key extension) is exactly as it would appear in your zone file. Note that the TTL value is not specified. The private key (.private extension) contains all the parameters that make an RSASHA1 private key. DNSSEC operations HOWTO Page 13

14 Usage: dnssec-signzone [options] zonefile [keys] Options: (default value in parenthesis) -c class (IN) -d directory directory to find keyset files (.) -s YYYYMMDDHHMMSS +offset: SIG start time - absolute offset (now) -e YYYYMMDDHHMMSS +offset "now"+offset]: SIG end time - absolute from start from now (now + 30 days) -i interval: cycle interval - resign if < interval from end ( (end-start)/4 ) -v debuglevel (0) -o origin: zone origin (name of zonefile) -f outfile: file the signed zone is written in (zonefile +.signed) -r randomdev: a file containing random data -a: verify generated signatures -p: use pseudorandom data (faster but less secure) -t: print statistics -n ncpus (number of cpus present) -k key_signing_key Signing Keys: (default: all zone keys that have private keys) keyfile (Kname+alg+tag) Figure 2: dnssec-signzone arguments The private key of a RSA key contains different parameters then DSA. Here is the private key (with base64 material truncated): # cat Ksub.tld private Private-key-format: v1.2 Algorithm: 5 (RSASHA1) Modulus: vfghse400lvrii83v4mzboa2paeugvhu1oi... PublicExponent: Aw== PrivateExponent: fqvrhp7n4h1hsxtpj7eq9fv5fmt... Prime1: 9/TIUIQQTfAEbKNNlHQPWjZSKYuAAs5iunEG... Prime2: xchhpfj8lexlz9arlub5w8o+egqxakrcawfs... Exponent1: pu3a4fgk3qac8xejdak05s7hcqeqrimxj... Exponent2: gsevwux9ct2h3+ryy4bq59wppzgpvtg9v... Coefficient: lakljrakvqxoxmdynjya1nvzkivzvnc... This private key should be kept secure 8 i.e.the file permissions should be set so that the zone administrator will be able to access them when a zone needs 8 At the RIPE NCC we are working on a dedicated signing server that has SSH based access control. Based on which key is used to login a dedicated shell is opened; Zone maintenance shell that allows signing of zones; A key maintenance shell for key maintenance. Only system administrators have privileges to access the key-material itself. DNSSEC operations HOWTO Page 14

15 to be signed. Besides, the BIND tools will, by default 9, look for the keys in the directory where signing is performed, and that might not be the most secure place on your OS. 4.3 Zone signing A locally secured tree must have a it s apex KEY RRs included[rfc3090] so before you sign your zone you have to add the public keys to your zone. You can do this by simply including the keys into your zone file. Include the public keys (.key extension) in your zone file. Taking the example file from 10.2 we use the $INCLUDE directive to include the key. Of course, we do not forget to increase the serial number in the SOA. Note that in the example we include 3 keys. One RSAMD5 key (algorithm 1) one DSA (algorithm 3) and one RSASHA1 key (algorithm 5). In the example below we will use the DSA key as the key signing key and the RSA keys as zone signing keys. In practice you will probably not use different algorithms but stick to only one (RSASHA1 is the preferred algorithm) and you will probably only have 3 keys in your zone at key-rollover time. $TTL 100 $ORIGIN 100 IN SOA ns.registry.tld. ( olaf.ripe.net ) ; In this example zone we have include 3 keys. ; The DSA key is designated key-signing keys. ; the other two are designated zone signing keys. $include Ksub.tld key $include Ksub.tld key $include Ksub.tld key ;...$snip... Once the key is included in the zone file we are ready to sign the zone using the dnssec-signzone tool, see figure 2 for all the arguments. We use the -o flag to specify the origin of the zone; normally the origin is deduce from the zone file s name. With the -k <KEY> we specify which key is to be used as the Key signing key. That key will only sign the KEY RR set in the apex of the zone. The keys that come as arguments at the end of the command are used to sign all the RR data for which the zone is authoritative. /usr/local/sbin/dnssec-signzone -r /dev/urandom \ -k Ksub.tld key \ sub.tld Ksub.tld key Ksub.tld \ db.ws.disi.signed 9 It is possible to fully specify the path to the keys DNSSEC operations HOWTO Page 15

16 In the example above the DSA key with ID is the key signing key. The RSA/MD5 key with ID and the RSA/SHA1 key with ID28124 are zone signing keys. The signed zone file is reproduced in figure 3. We ve truncated all base64 representations and modified the output of dnssec-keygen a little bit to compact the presentation somewhat. (It s hard to make it really readable). Note that the apex KEY RRset is the only RRset with 3 signatures, made with the zone and key signing keys. The other RRsets are only signed with the zone signing keys. The signing process did the following: It sorted the zone in canonical order. Inserted NXT records for every label. Added the key-id as a comment to each KEY-record. Signed the KEY RR set with 3 keys; the key signing key and the zone signing keys. Signed the other RRs with the two zone signing keys (algorithm 1 and algorithm 5) The signatures where created with a (default) lifetime of 30 days from the moment of signing. If signatures have expired data can not be verified and your zone will go bad. Therefore you will have to resign your zone every 30 days. Zone resigning is discussed below. 4.4 Caching forwarder configuration Now that the DNS servers publish signed data we need to configure the clients to verify the data. The clients in this context are caching forwarders. To do this just configure your caching forwarder with the public key you just generated for the zone. How to do this is described in section 3 above. 4.5 Zone resigning When the signature is almost expired or when you have added a few records to your zone there are two ways to resign your zone data. You may choose whichever option depending on the level of automation and the zone file you have to sign and frequency you have to regenerate SIG records.. You can regenerate the signed zone from the unsigned zone file. The signer will need to sort the zone again, generate all the NXT records and generate all SIG records. If you generate your zone file from a back-end database this is probably the preferred mechanism. DNSSEC operations HOWTO Page 16

17 ; File written on Sun Aug 25 15:35: ; dnssec_signzone version 9.3.0s sub.tld. 100 IN SOA ns.registry.tld. olaf.ripe.net. ( ; serial 100 ; refresh (1 minute 40 seconds) 200 ; retry (3 minutes 20 seconds) ; expire (1 week) 100 ; minimum (1 minute 40 seconds) ) 100 SIG SOA sub.tld. T0K+XczqhuVjaQI9Jj7NUGiLqoBKXH SIG SOA sub.tld. ffmslmju1mptgnirxuetetpruste27p NS ns.sub.tld. 100 SIG NS sub.tld. p/3goncmj7xs9xduecftwuvjwhpbn6d KEY AQPw02b9MnR8aJplOyI1CB0u1zBGi9x... ; key id = KEY ( CLGc9Re9I3pg7QAqxPebTpbokbYb5nZ...; key id = KEY (AQO9+CFJ7jTQu+uKLzdXiZlugDY9oRSC...; key id = SIG KEY sub.tld. TjpdtpH9g2fBHAxY4uKcAZjBp5qEIklu4Bqg XPxdXDCDzQzWm4hG5yVb7Wq1Zqo SIG KEY sub.tld. CCfyqvBBycBfy+7e5n/ckKS9bGnunP SIG KEY sub.tld. RdSsIVKjX16LOCeGGBARdludKZPI94N NXT b1.sub.tld. NS SOA SIG KEY NXT 100 SIG NXT sub.tld. NRHRUSRZO6WRUq5RFQzYPPRmPWmsDPT SIG NXT sub.tld. OE2ZV/7aGk3pRU+7BFSpgAPodD2dLbQ... b1.sub.tld. 100 IN A SIG A sub.tld. Hgn+P4sySKPeH3k5UXtf18Em9NxWnBd SIG A sub.tld. sbzmre3s4hppozywwboggfmh+ssv61j NXT b2.sub.tld. A SIG NXT 100 SIG NXT sub.tld. NAWacUhKEDNKXAI8auoLTefJ1Cef2v SIG NXT sub.tld. jsf/vyyw0+o+iroq0rowigxv7mzpneu... b2.sub.tld. 100 IN A SIG A sub.tld. T7T1BNl16UC6guBzon9f04siJ90li SIG A sub.tld. mgmbvlhltzt0xtqyb1hpwdbintuxu NXT b3.sub.tld. A SIG NXT 100 SIG NXT sub.tld. 68Gtt2KvIy1CIlOpmyNZCAU6HOK3bT SIG NXT sub.tld. JJjaCoX3N3a5sHteULZmxTitp7adfLn... b3.sub.tld. 100 IN A SIG A sub.tld. S4WbwAC537mymQamv9IB58qF/R5l SIG A sub.tld. Lff5HcyvvZomZPDQ0g3BAaPvvFGmO NXT b4.sub.tld. A SIG NXT 100 SIG NXT sub.tld. 48sFT+OWOPFNmRtiPP9tjeZDbACZ9pM SIG NXT sub.tld. hx2e6rx4hf1gbt9/chc6ewl2e7c+rww... b4.sub.tld. 100 IN A SIG A sub.tld. XB93jhZciRUsyqItmlkBfYlFzbbVf SIG A sub.tld. XTGUKGbm9F7Fj8rJ3FpL+HgQS2f7r NXT corrupt.sub.tld. A SIG NXT 100 SIG NXT sub.tld. sga83avu7tcjyutzls90a2olhxh1zu SIG NXT sub.tld. rlvjtlh7ylvqfaiv8h/guffvfmb4mau... corrupt.sub.tld. 100 IN A SIG A sub.tld. P6c+Fz3Xyd4S7BrtcLV9ZpBDdLZF5gd SIG A sub.tld. P6IZYe8LI1ttZE1LQfovtYPgrO1SBwR NXT e.sub.tld. A SIG NXT 100 SIG NXT sub.tld. YXPzAQLFWB7Je13Zxltzjk3O1YFrIaLy SIG NXT sub.tld. DF1nf536tCzcEJ7sg5wr+no75wnLhdfo... e.sub.tld. 100 IN A SIG A sub.tld. t6yodih8pn0ljobxg96cc+mpduaca SIG A sub.tld. if1cnqier9dpvwko0+ysfo1dfrvyz NXT d.e.sub.tld. A SIG NXT 100 SIG NXT sub.tld. ep+zdsglqelpeh9dszqhzonzmmllkco SIG NXT sub.tld. HwWcau8MgUbGwFHrSqW9EOJ/qtzDzdb... d.e.sub.tld. 100 IN A SIG A sub.tld. us8sloyekr7lcx9quygbyyxja3fma SIG A sub.tld. KNrQRvogTiFF+W0NdYHq3cmdiGDUw NXT c.d.e.sub.tld. A SIG NXT 100 SIG NXT sub.tld. JnX3x/CTNfuAD26pQ4tVZ3OsKdLhsye SIG NXT sub.tld. UNp4mGRrzW+22WmqIYNxVGruIuJH3Cp... c.d.e.sub.tld. 100 IN A SIG A sub.tld. LIYCqFOBPZ5GwoXV9DzczD0R6776u SIG A sub.tld. ZMvxWA7u0gLdlbCD1YarJt6j2ZpGY NXT b.c.d.e.sub.tld. A SIG NXT 100 SIG NXT sub.tld. sb3g5/5/1if7zo6hzvxfmgahmvjom0y SIG NXT sub.tld. hv/d3wadknzygt+o3uhtaiweonwb/2h... b.c.d.e.sub.tld. 100 IN A SIG A sub.tld. rnvbrwsdu7jmr0ukta4aru3ih5jc SIG A sub.tld. TGsJ6Anpmjc6lYwRcspHGwZUW2aJK NXT ns.sub.tld. A SIG NXT 100 SIG NXT sub.tld. DtkxAFY8npe6oNhoPygG+SrC4wUuiaf SIG NXT sub.tld. pc2xpnwmzkhjyrhgxm1pdn6qdeacn88... ns.sub.tld. 100 IN A SIG A sub.tld. bk1ro9uaq3ikkmjih9batbebpab SIG A sub.tld. dt/8ivka5qhkuoya/urzvglrogxub NXT sub.tld. A SIG NXT 100 SIG NXT sub.tld. ccuwrgjl9esfr6stzoxr2ceeoqkyzoh SIG NXT sub.tld. J+iYWN5pi0fP8BWDvHdlaVbZefIWYEA... Figure 3: Example of signed zonefile DNSSEC operations HOWTO Page 17

18 You can add the new records to the already signed zone file and then run that zone file through the signer. The signer will insert the new records and associate NXTs in the already sorted zone file and will only sign the new records and the records for which the signatures are reaching the end of their validity period. You should build tools to maintain your signed zones, cron, perl and make are your friends. We are planning to build a repository of DNSSEC maintenance tools at the RIPE NCC, please also make your tools publicly available. 4.6 Troubleshooting zone signing You can check the format of your named.conf using the named-checkconf program. The named-checkzone program can be used to check zone files. These programs use the same routines as named itself. One can use dig and a nameserver configured with a trusted-key to verify your setup. If data cannot be cryptographically verified the forwarder will return with a SERVFAIL status. You can test this by intentionally corrupting a resource record in the signed zone file. This is typical output of dig when querying for corrupted data 10 : ; <<>> DiG 9.3.0s <<>> corrupt.sub.tld ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;corrupt.sub.tld. IN A ;; Query time: 14 msec ;; SERVER: #53(verifyer) ;; WHEN: Sun Aug 25 16:22: ;; MSG SIZE rcvd: 44 Note that a caching forwarder will not do cryptographic verification of zones it is authoritative for. So if your caching forwarder is primary or secondary for a particular zone you will always get an answer, it is assumed that data from disk is secure. Further troubleshooting would need to be done on a verifier. Below is an example of the log output of the verifier when we queried for corrupted data. debug 3: client #1206: request is not signed debug 3: client #1206: recursion available debug 3: client #1206: query (cache) approved 10 We corrupted the data by modifying rdata in the signed zone-file DNSSEC operations HOWTO Page 18

19 debug 3: validating corrupt.sub.tld A: starting debug 3: validating corrupt.sub.tld A: attempting positive response validation debug 3: validating sub.tld KEY: starting debug 3: validating sub.tld KEY: attempting positive response validation debug 3: validating sub.tld KEY: verify rdataset: success debug 3: validating sub.tld KEY: signed by trusted key; marking as secure debug 3: dns_validator_destroy debug 3: validating corrupt.sub.tld A: in fetch_callback_validator debug 3: validating corrupt.sub.tld A: keyset with trust 7 debug 3: validating corrupt.sub.tld A: resuming validate debug 3: validating corrupt.sub.tld A: verify rdataset: SIG failed to verify debug 3: validating corrupt.sub.tld A: failed to verify rdataset debug 3: validating corrupt.sub.tld A: verify failure: SIG failed to verify debug 3: validating corrupt.sub.tld A: keyset with trust 7 debug 3: validating corrupt.sub.tld A: verify rdataset: SIG failed to verify debug 3: validating corrupt.sub.tld A: failed to verify rdataset debug 3: validating corrupt.sub.tld A: verify failure: SIG failed to verify info: validating corrupt.sub.tld A: no valid signature found debug 3: dns_validator_destroy 4.7 Possible problems SOA serial If you forget to increase the serial number before resigning your zone, secondary servers may not pick up the new signatures in time. Some resolvers will be able to verify your signature while others will not. Zone signing key rollover If a zone administrator makes a distinction between zone and key signing keys then the rollover of a zone signing key will not involve any action of the administrators of the verifiers. If a key signing key is to be changed care should be taken that all resolvers in the organization have been supplied with a new trusted-key. If the zone is only locally secured (i.e. is not part of a chain of trust) then the rollover of a key signing key is relatively simple. Remember that to verify data there has to be at least one signature that can be verified with the trusted-keys in resolvers; During a limited time you use two key signing keys to sign your zone: the old and new key. During that time you start reconfiguring the resolvers in your organization with new trusted-keys. Once all resolvers have the new key configured in their trusted-key statement, the zones should be signed with the new key only. Rollovers are described in more detail in section 6 5 Delegating of Signing authority; becoming globally secure. This section is subject to change as the tools needed for this are being modified/developed. DNSSEC operations HOWTO Page 19

20 5.1 Task at Hand We have covered how to deploy DNSSEC in a single zone. We now want to build a chain of trust so that once a client has securely obtained a public key high in the DNS hierarchy, it can follow the chain to verify data in your or your children s zone. To be able to delegate authority the parent has to sign data that securely indicates which child key is to be used as the next step in the chain of trust. [Gud] describes how this can be established by having the parent generate a signature over the DS record that is generated from the childs KEY. Below we will describe how to setup a zone that is globally secured based on the parental signature over the DS record pointing to the child s key signing key. In the example we use tld as parent and sub.tld as child. We assume that the parent zone is already locally secure as described in the previous section. This means that the parent has no DS RR for sub.tld. and that resolvers that follow the chain of trust via tld will treat the sub.tld. zone as verifiable insecure. The sub.tld. zone assumed not to be secure, much of the procedure will be as described section 4, but, since keysets are used, some details are different. Apex data is data that has the same name as the origin of a zone. Some resource records in the apex can appear at both the parent and the child. The only data that is allowed at the parent and child side of the apex are NS, NXT, KEY and SIG. In [rfc1034, rfc1035] it is stated that the child is authoritative for data in the apex of a zone. The DS RR is the only RR record that may only be published at the parent s apex and for which the parent is authoritative. Therefore the key set signing keys, generated by the child, need to be exchanged with the parent to get the DS records generated from. Although you could build tools to have the child generate DS records so that the parent can include them in their zone file, the current tools use so called keysets. Note that there is a command called dnssec-makekeyset available in most BIND 9 versions. The command is used to generate a keyset. However, the use of keyset has changed with the introduction of DS and the dnssec-makekeyset command has been removed from the BIND 9.3s distribution. Although the dnssec-makekeyset may reappear in later versions we describe the procedure as if the tool is not available. The sequence of events will be: 1. The child gets it s key signing key to the parent. 2. The parent creates a keyset file in a special directory. 3. The dnssec-signzone command finds the keysets and automatically generates and signs DS records. We will describe the steps in more detail below. DNSSEC operations HOWTO Page 20

21 5.2 Key exchange, signing and securing. Amsterdam-Wash. DC August-Sep, 2002 We assume the child is secured and works locally. So we have created zone signing and key signing keys as described in section 4.2 and signed our zones as described in 4.3. The parent will now need to obtain our key signing key. The easiest way to upload the key is tho have the child cut and paste the key into an and sending it to the parent. In an operational environment it is extremely important that the authenticity and the integrity of the KEY is established 11. The zone administrator 12 of the parent will need to verify that the key came from the zone administrator of the child zone. If possible this should be confirmed by an out-of-dns mechanism. The parent could use it s customers database to verify if key was actually sent by the zone administrator. If a wrong key is signed the child zone will be vulnerable for attacks; signing the wrong key breaks DNSSEC. The parent will need to create a keyset file. This is done by putting the key material in a file called keyset-<child-domainname>. The parent stores the keysets in a directory that is to be specified with the -d flag of dnssec-signzone. The signzone tool will automatically generate the appropriate DS records if a keyset-<child-domainname>. file is found containing one or more KEY RRs for the <child-domain>. Note that although the keyset generated by the child contains signatures the SIG RRs do not need to be available in the keyset-<child-domain>. file at the parent, the sign tool will not do signature verification. Below is an example on how you could ivoke the command: dnssec-signzone -r /dev/urandom -d /registry/tld-zone/child-keys -o tld -f tld.signed db.tld 5.3 Possible problems Public Key Algorithm To be globally secure one needs to use at least one key of an algorithm that is mandatory to implement. Mandatory to implement are RSA/SHA1 and DSA keys. We recomend the use of RSA/SHA1 keys only 13. Parent indicating child security It is important that the KEY with that is sent to the parent is in use as key signing key (or as zone and key signing key if there is no distinction made) before the parent includes a signed DS RR for that key. If the parent includes a DS RR while the child has not yet signed with the key then the child will go bad ; By not having a DS RR for the child the parent indicates the child to be in-secure. 11 Tools to for verification of selfsigned keys are not yet available. There is work done in this area. 12 The person who is responsible for publishing the zone data 13 This document is not consistent with respect to that advise. We will update the document in a later version DNSSEC operations HOWTO Page 21

22 As a parent you should always verify that the child publishes signed KEY before including a DS RR. 6 Rolling over keys Roll over is the process where a zone decides to change their key. Since keys have a limited lifetime If only because of Moore s law they will need to be changed occasionally. Care needs to be taken that existing chains of trust are not broken during the change of key. In general this means that during a limited period two keys, the old and the new key are being used. If the rollover is planned we refer to it as scheduled rollover. If the rollover is the result of a (suspected) compromise or loss of private key it is called a unscheduled or emergency key rollover. If a zone rolls over a key it will need to contact it s it s parents. The children will not notice a rollover. The middle-zone sub.tld wants to change its key signing key. The old key has tag=1, the new key has tag=2. The sub.tld zone uses key 10 as zone signing key. These are the steps that need to be taken. The parent s key has tag=123 and the child key has tag=789. These two keys do not change during the process. step 0 The initial situation is the following: The middle-zone has key 1 published signed by itself and the parent. The child has it s key signed by key 1 and publishes the signature over it s key made by the middle zone. ; published by the parent sub.tld sub.tld DS <tag=1> SIG (DS) <signkey=tld tag=123> ; Published in middle zone: sub.tld. KEY <tag=1> ; key signing key sub.tld. KEY <tag=10> ; zone signing key sub.tld. SIG(KEY) <signkey=sub.tld, tag=1> sub.tld. SIG(KEY) <signkey=sub.tld tag=10> child.sub.tld DS <tag=789> child.sub.tld SIG(DS) <signkey=sub.tld tag=10> ; Published in child zone: child.sub.tld.. KEY <tag=789> child.sub.tld. SIG(KEY) <signkey=child.sub.tld tag=789> The child should query one of the authoritative servers for it s DS RR and store the TTL it commes in handy in step 3. DNSSEC operations HOWTO Page 22

23 step 1 The middle-zone now starts the rollover by uploading key 2 to it s parent and by publishing all keys in the DNS. ; published by the parent sub.tld sub.tld DS <tag=1> SIG (DS) <signkey=tld tag=123> ; published by the middle zone sub.tld. KEY <tag=1> sub.tld. KEY <tag=2> sub.tld. KEY <tag=10> sub.tld. SIG(KEY) <signkey=sub.tld, tag=1> sub.tld. SIG(KEY) <signkey=sub.tld, tag=2> sub.tld. SIG(KEY) <signkey=sub.tld, tag=10> child.sub.tld DS <tag=789> child.sub.tld SIG(DS) <signkey=sub.tld tag=10> step 2 Key 2 has been received by the parent. The parent now knows which key to use as secure entrypoint. They will be able to verify the new key against the existing chain of trust by using the KEY RR set from the DNS and know that key 2 is uploaded by the child because it is signed with key 2 alone, something that only the child can do. The parent generates a new DS RR for pointing to key 2 of the middle zone. ; published by the parent sub.tld. sub.tld. DS <tag=2> SIG (DS) <signkey=tld tag=123> ; Published by middle zone sub.tld KEY <tag=1> sub.tld KEY <tag=2> sub.tld SIG(KEY) <signkey=sub.tld, tag=2> sub.tld SIG(KEY) <signkey=parent, tag=123> child.sub.tld DS <tag=789> child.sub.tld SIG(DS) <signkey=sub.tld tag=10> If there are any resolvers with trusted-keys set to 1 than they should be replaced by key 2. step 3 After a given time the middle zone needs to remove the old key. It does that by creating a key RR set with only the new key: DNSSEC operations HOWTO Page 23