CSD 5928

TOOL GUIDE
TOOL GUIDE SERIES ON DNSSEC

VERSION 1 - FEBRUARY 2010
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
COPYRIGHT NOTIFICATION
Copyright 2010 VeriSign, Inc. All rights reserved.
DISCLAIMER AND LIMITATION OF LIABILITY

VeriSign, Inc. has made eorts to ensure the accuracy and completeness of the information in this document. However, VeriSign, Inc. makes no warranties of any kind (whether express, implied or statutory) with respect to the information contained herein. VeriSign, Inc. assumes no liability to any party for any loss or damage (whether direct or indirect) caused by any errors, omissions or statements of any kind contained in this document. Further, VeriSign, Inc. assumes no liability arising from the application or use of the product or service described herein and specically disclaims any representation that the products or services described herein do not infringe upon any existing or future intellectual property rights. Nothing herein grants the reader any license to make, use, or sell equipment or products constructed in accordance with this document. Finally, all rights and privileges related to any intellectual property right described herein are vested in the patent, trademark, or service mark owner, and no other person may exercise such rights without express permission, authority, or license secured from the patent, trademark, or service mark owner. VeriSign Inc. reserves the right to make changes to any information herein without further notice. No rights or ownership interest is claimed with respect to any Open Source or other third party software described herein.
NOTICE AND CAUTION CONCERNING U.S. PATENT OR TRADEMARK RIGHTS

VeriSign, and other trademarks, service marks and logos are registered or unregistered trademarks of VeriSign and its subsidiaries in the United States and in foreign countries. The inclusion in this document, the associated on-line le, or the associated software of any information covered by any other patent, trademark, or service mark rights does not constitute nor imply a grant of, or authority to exercise, any right or privilege protected by such patent, trademark, or service mark. All such rights and privileges are vested in the patent, trademark, or service mark owner, and no other person may exercise such rights without express permission, authority, or license secured from the patent, trademark, or service mark owner.
ii
Tool Guide Series on DNSSEC | Version 1
REFERENCES
AUTHOR(S)
John Dickinson, Nominet
TITLE
REVISION
1.0
Key and Signing Policy (KASP) (https://www.dns-oarc.net/les/dnsops-2007/Dickinson-KASP.pdf ) OpenDNSSEC (PDF formatted presentation) (http://www.iis.se/docs/OpenDNSSEC_20080213.pdf ) Step-by-Step DNSSEC-Tools Operator Guidance Document Using the DNSSEC-Tools v1.0 distribution (http://www.dnssec-tools.org/docs/step-by-step-dnssec-tools/sbs-dt.pdf ) DNSSEC or How to secure your (reverse) zone (http://www.hznet.de/dns/dnssec-decix050916.pdf ) Zone Key Tool, A signing and key admin tool for DNSSEC (http://www.hznet.de/dns/zkt-iis080530a.pdf ) Secure Domain Name System (DNS) Deployment Guide Recommendations of the National Institute of Standards and Technology (http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf ) DNSSEC Operational Practices (http://tools.ietf.org/id/draft-ietf-dnsop-dnssec-operational-practices-06.txt) A Review of Administrative Tools for DNSSEC (http://www.iis.se/docs/DNSSEC-Admin-tools-review-1.01.pdf ) DNSSEC HOWTO, a tutorial in disguise (http://www.nlnetlabs.nl/publications/dnssec_howto/dnssec_howto.pdf ) DNS SECURITY TROUBLESHOOTING GUIDE (http://www.dnssec-tools.org/docs/troubleshooting/ DNS-Security-Troubleshooting-Guide.pdf )
Rickard Bondesson
1.0
SPARTA, Inc.
1.0
Holger Zuleger
1.0
Holger Zuleger
1.0
Ramaswamy Chandramouli & Scott Rose
1.0
NLnet Labs O. Kolkman & R. Gieben Joakim hlund, Certezza AB Olaf Kolkman
6.0
1.0
134
SPARTA, Inc.
1.0
iii
DEFINITIONS, ACRONYMS, & ABBREVIATIONS

TERM
Authoritative name server
DESCRIPTION
A name server that is the base source of information about a certain domain; the fact that a name server is authoritative for a certain domain is indicated in the so-called start-of-authority (SOA) resource record. A cryptographic library used by softHSM. Version 1.8.0 or later is required. A command-line interface (CLI) is a mechanism for interacting with a computer operating system or software by typing commands to perform specic tasks via a text-only interface. CPAN, the Comprehensive Perl Archive Network, is an archive of over 18,000 modules of software written in Perl, as well as documentation for it. It has a presence on the World Wide Web at www.cpan.org and is mirrored worldwide on more than 200 locations. CPAN can denote either the archive network itself, or the Perl program that acts as an interface to the network and as an automated software installer (somewhat like a package manager). Most software on CPAN is free and open source software. A cryptographic operation based on public key cryptography used to uniquely prove that a given piece of information is trusted by the owner of a given private key; the authenticity of a digital signature can be veried using the corresponding public key. Domain Name System distributed database used to resolve domain names to IP addresses. DNSEC RR type extension used for publishing the public key(s) used within a zone for creating a digital signature. A third-party DNS library used by the OpenDNSSEC Auditor. Version 1.32 or later is required. DNS Security Extensions The OpenDNSSEC implementation, expected to run on top of a PKCS #11 implementation, like an HSM. DNSEC RR type extension used to publish the digest of the public key used to sign the child zone. Should match the digest of the DNSKEY record in the child zone.
botan CLI
CPAN
Digital signature
DNS DNSKEY
DNSRuby
DNSSEC DNSSEC Signer
DS
iv
TERM
FTP
DESCRIPTION
File Transfer Protocol (FTP) is a standard network protocol used to exchange and manipulate les over a TCP/IP based network, such as the Internet. FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server applications. GnuPG, also known as GPG, is the GNU project's complete and free implementation of the OpenPGP standard as dened by RFC4880. GnuPG allows encrypting and signing your data and communication, features a versatile key management system as well as access modules for all kind of public key directories. GnuPG, is a command line tool with features for easy integration with other applications. Hardware Security Module (external cryptographic hardware). A comparison between several available HSM devices on the market. This is intended to give a rough idea about the kinds of devices available on the market, in terms of speed, price, and conguration details. Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. Its use for retrieving inter-linked resources, called hypertext documents (HTML), led to the establishment of the World Wide Web (WWW). This is the standard protocol used for communication between a Web browser (like Firefox) and a Web server (like Apache). Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS protocol to provide encryption and secure identication of the server. HTTPS connections are often used for payment transactions on the World Wide Web and for sensitive transactions in corporate information systems. The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certicate is veried and trusted. IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and used for communicating data across a packet-switched internetwork. It has the task of delivering distinguished protocol datagrams (packets) from the source host to the destination host solely based on their addresses. For this purpose the Internet Protocol denes addressing methods and structures for datagram encapsulation. IP Address Management (IPAM) refers to the management of allocation, administration, reporting and tracking of public and private IP space, IP devices and associated data. Enterprises typically deploy systems and processes that interact with the DNS and DHCP infrastructure in order to provide IPAM capabilities.
GPG
HSM HSM market selection
HTTP
HTTPS
IP
IPAM
TERM
KASP KSK
DESCRIPTION
Key And Signature Policy (used by OpenDNSSEC) Key Signing Key used to sign DNSKEY records (zone signing public pkey) in a zone creates the Secure Entry Point (SEP) for a zone. A DNS programming library used in the signer component. OpenDNSSEC requires ldns 1.6.0 or later. A C-library for handling XML. It is used in all parts of OpenDNSSEC, which requires version 2.6.16 or later. Network File System (NFS) is a network le system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access les over a network in a manner similar to how local storage is accessed. A DNS resource record type used to show what the next available name in a zone is. All authentic names in the zone (signed or unsigned) are added to the NSEC chain. Requires the zone to be walked. Alternative to NSEC which uses a hashed owner name to form a chain. Only identies signed authentic names in the zone zone walking NOT needed. Open Source software that manages the security of domain names on the Internet. The project intends to drive adoption of Domain Name System Security Extensions (DNSSEC) to further enhance Internet security. The most widely used email encryption standard in the world. An open source implementation of the SSL and TLS protocols. The core library (written in the C programming language) implements the basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. Versions are available for most Unix-like operating systems. One of the family of standards called Public-Key Cryptography Standards (PKCS), published by RSA Laboratories. It denes a platform-independent API to cryptographic tokens, such as Hardware Security Modules (HSM). Private-Key Information Syntax Standard. Used to carry private certicate keypairs (encrypted or unencrypted).
ldns
libxml2
NFS
NSEC
NSEC3
OpenDNSSEC
OpenPGP openSSL
PKCS11
PKCS8
vi
TERM
Public key cryptography
DESCRIPTION
An asymmetric cryptographic scheme with two complementary keys: the public and the private key. A signature computed using the private key can be validated using the public key; conversely a piece of data can be encrypted using the public key and decrypted using the private key. See also: http://en.wikipedia.org/wiki/Public-key_cryptography A name server that can be used by clients to perform DNS resolving tasks; a caching server will store all the answers it receives to queries and re-use these when appropriate. A piece of software that uses DNS servers to map a DNS name to an IP-address. A Linux package management system and software package format. DNS Resource Record is an entry in the Domain Name System. There are several types of resource record. The most commonly used ones are A records for mapping a name to an (IP-) address. See also: http://en.wikipedia.org/wiki/List_of_DNS_record_types DNSEC RR type extension used to publish the digital signature associated with a specic name, class, and type. The standard way of installing Ruby packages. It is only used for the installation of the DNSRuby package. SFTP, or secure FTP, is a program that uses SSH to transfer les. Unlike standard FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted in the clear over the network. It is functionally similar to FTP, but because it uses a dierent protocol, you can't use a standard FTP client to talk to an SFTP server, nor can you connect to an FTP server with a client that supports only SFTP. Server Message Block (SMB, also known as Common Internet File System, CIFS) operates as an application-layer network protocol mainly used to provide shared access to les, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows, where it is often known as "Microsoft Windows Network."
Recursive (caching) name server Resolver RPM RR
RRSIG
rubygems
SFTP
SMB
vii
TERM
SNMP
DESCRIPTION
Simple Network Management Protocol (SNMP) is a UDP-based network protocol. It is used mostly in network management systems to monitor network-attached devices for conditions that warrant administrative attention. SNMP is a component of the Internet Protocol Suite as dened by the Internet Engineering Task Force (IETF). It consists of a set of standards for network management, including an application layer protocol, a database schema, and a set of data objects SNMP exposes management data in the form of variables on the managed systems, which describe the system conguration. These variables can then be queried (and sometimes set) by managing applications. A software-only implementation of an HSM (virtual HSM), made available through the industry standard PKCS #11 interface. This software is compatible with the DNSSEC Signer. A cut-down SQL database system used by the KASP and softHSM components of OpenDNSSEC. Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux- and Unix-based systems to access shell accounts, SSH was designed as a replacement for Telnet and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet. SSL uses a cryptographic system that uses two keys to encrypt data a public key known to everyone and a private or secret key known only to the recipient of the message. The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. In particular, TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. The Internet Protocol Suite (commonly known as TCP/IP) is the set of communication protocols used for the Internet and other similar networks. It is named from two of the most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were the rst two networking protocols dened in this standard. Like many protocol suites, TCP/IP may be viewed as a set of layers. Each layer solves a set of problems involving the transmission of data.
SoftHSM
SQLite
SSH
SSL
TCP
TCP/IP
viii
TERM
Time-to-live
DESCRIPTION
The time period during which an answer to a DNS query remains valid and can thus be cached. Transport Layer Security (TLS) is a cryptographic protocol that provides security for communications over networks such as the Internet and allows client/server applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications condentiality. The top of a trust chain that can be used by validators as a starting point to validate the authenticity of a signed DNS record at any point in the trust chain. The User Datagram Protocol (UDP) is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. UDP is sometimes called the Universal Datagram Protocol. UDP uses a simple transmission model without implicit hand-shaking dialogues for guaranteeing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. A resolver that validates the DNSSEC signatures on the answers it receives to DNS queries. A piece of software that veries the authenticity of a digital signature using the public key that was used to create the signature. An OpenSource computer program that retrieves content from Web servers, and is part of the GNU Project. Its name is derived from World Wide Web and get, connotative of its primary function. It currently supports downloading via HTTP, HTTPS, and FTP protocols, the most popular TCP/IP-based protocols used for Web browsing. Its features include recursive download, conversion of links for oine viewing of local HTML, support for proxies, and many others. The Yellowdog Updater, Modied - is an open-source command-line package management utility for RPM-compatible Linux Operating Systems. A collection of related resource records that is served as a unit by a name server. See also: http://en.wikipedia.org/wiki/DNS_zone Zone Signing Key - used to sign all data in a zone.
TLS
Trust anchor
UDP
Validating resolver Validator
wget
YUM
Zone
ZSK
ix
CONTENTS
1 INTRODUCTION
1.1 INTRODUCTION TO DNSSEC 1.2 FEATURES COMPARISON MATRIX FOR DNSSEC SOLUTIONS 1.3 OTHER DNSSEC TOOLS 1.4 HARDWARE SECURITY MODULES (HSMS) 1.5 DNSSEC APPLIANCES
1
2 3 5 5 6
2 BIND 9
2.1 OVERVIEW 2.1.1 BACKGROUND 2.1.2 KEY GENERATION 2.1.2.1 DNSSEC-KEYGEN (FILE-BASED) 2.1.2.2 DNSSEC-KEYFROMLABEL (HSM-BASED) 2.1.3 ZONE SIGNING 2.1.3.1 HOW TO DO IT, INCLUDING CONFIGURATION AND COMMAND-LINE PARAMETERS 2.1.3.2 NSEC/NSEC3 2.1.3.3 LOADING SIGNED ZONE INTO NAME SERVER 2.1.3.4 RE-SIGNING 2.1.4 KEY ROLLOVERS 2.1.4.1 HOW TO ROLL ZSK 2.1.4.2 HOW TO ROLL KSK 2.1.5 PUBLISHING OF DS DATA TO PARENT ZONE 2.2 SETUP 2.2.1 INSTALLATION STEPS 2.2.1.1 PREREQUISITES 2.2.1.2 INSTALLATION 2.2.1.3 CONFIGURATION 2.3 RUNNING APPLICATION 2.3.1 DAEMONS 2.3.2 COMMAND LINE UTILITIES 2.3.2.1 MAINTENANCE UTILITIES 2.3.3 ADD-ONS 2.4 TIPS/TRICKS/GOTCHAS
7
7 7 8 8 9 9 9 12 12 13 14 14 16 17 18 18 18 18 18 21 21 22 22 23 23
3 OPENDNSSEC
3.1 OVERVIEW 3.1.1 3.1.2 3.1.3 BACKGROUND TECHNOLOGIES & ARCHITECTURE OVERVIEW KEY GENERATION
25
25 25 26 29 30 31 32 32 32 33 33 34 34 35 35 45 48 49 49 50 50 50 50 51 52 53 57
3.1.4 ZONE SIGNING 3.1.5 KEY ROLLOVERS
3.1.6 PUBLISHING OF DS DATA TO PARENT ZONE 3.2 SETUP 3.2.1 INSTALLATION STEPS 3.2.1.1 SUBVERSION CLIENT 3.2.1.2 PREREQUISITE SOFTWARE 3.2.1.3 OPENDNSSEC 3.2.1.4 SOFTHSM 3.2.1.5 POST-INSTALL (LINUX SYSTEMS ONLY) 3.2.2 CONFIGURATION 3.2.3 INITIALIZATION 3.2.4 PROCESSING INPUT/OUTPUT 3.3 RUNNING APPLICATION 3.3.1 DAEMONS 3.3.1.1 SIGNER ENGINE 3.3.1.2 ODS-ENFORCERD 3.3.2 COMMAND LINE UTILITIES 3.3.2.1 SIGNER ENGINE 3.3.2.2 KASP ENFORCER 3.3.2.3 HSMS 3.3.2.4 MISCELLANEOUS 3.4 TIPS/TRICKS/GOTCHAS
4 DNSSEC-TOOLS
4.1 OVERVIEW 4.1.1 BACKGROUND
59
59 59 59 61
4.1.2 TECHNOLOGIES AND ARCHITECTURE 4.1.3 KEY GENERATION
xi
4.1.4 ZONE SIGNING 4.1.5 KEY ROLLOVERS 4.1.6 PUBLISHING OF DS DATA TO PARENT ZONE 4.2 SETUP 4.2.1 INSTALLATION STEPS 4.2.2 CONFIGURATION 4.3 RUNNING APPLICATION 4.3.1 DAEMONS 4.3.2 COMMAND LINE UTILITIES 4.4 TIPS/TRICKS/GOTCHAS
62 62 64 65 65 66 70 70 70 74
5 DNSSEC ZONE KEY TOOL (ZKT)

5.1 OVERVIEW 5.1.1 5.1.2 5.1.3 BACKGROUND TECHNOLOGIES & ARCHITECTURE KEY GENERATION
75
75 75 76 76 78 85 87 87 88 88 88 90 90
5.1.4 ZONE SIGNING 5.1.5 KEY ROLLOVERS
5.1.6 PUBLISHING OF DS DATA TO PARENT ZONE 5.2 SETUP 5.2.1 INSTALLATION STEPS
5.2.2 INITIALIZATION 5.2.3 CONFIGURATION 5.3 RUNNING APPLICATION 5.4 TIPS/TRICKS/GOTCHAS
6 TROUBLESHOOTING DNSSEC
6.1 FAILURE MODES 6.2 TOOLS 6.2.1 BIND SERVER LOGS
92
92 94 94 95 96 96 97 110
6.2.2 DIG 6.2.3 TRUSTMAN 6.2.4 LOGWATCH 6.2.5 DONUTS 6.2.6 DRILL
xii
6.2.7 AUTOTRUST 6.2.8 VERISIGN JDNSSEC TOOLS 6.2.9 VALIDATE 6.2.10 MAPPER 6.2.11 DNSPKTFLOW 6.3 EXAMPLE SESSION
117 117 119 119 120 121
APPENDIX
A B C D E F G H I J K L M N O P OPENDNSSEC INSTALLATION NOTES FOR RHEL 5.3 ADDITIONAL OPENDNSSEC UTILITIES LDNS PROJECT UTILITIES USING SQLITE SAMPLE SCRIPT FOR OPENDNSSEC <NOTIFYCOMMAND> SAMPLE OPENDNSSEC SIGNED ZONE KNOWN ISSUES CONVERT DNSKEY RECORD INTO CANONICAL FORM BIND DNSSEC-SIGNZONE OUPUT FILES CONFIGURING AND SERVING A SIGNED ZONE MIGRATING FROM BIND TO DNSSEC-TOOLS BINDS NSUPDATE COMMAND FORMATS OTHER DNSSEC-RELATED TOOLS SAMPLE ZKT ZONE SIGNER CRON JOB ALGORITHMS FOR KEY ROLLOVER MAN PAGES FOR DNSSEC-SIGNER AND DNSSEC-ZKT 126 131 133 136 138 139 144 145 147 155 156 157 160 170 171 172
xiii
1. Introduction
The intent of this document is to provide an overview of the DNSSEC-related Open Source tools and automation suites available in the industry to DNS operators who wish to DNSSEC-enable their operations and not as an endorsement of any particular tool. While the overview cannot be comprehensive due to the constant arrival of new tools and the ongoing improvement of existing tools, it still can serve as a general guide to the DNSSEC landscape at this time. It is meant to help DNS operators get a head start on implementing DNSSEC. In addition to providing a list of tools, this document will provide a deeper review of the information on the use of the Open Source tools. The tools that receive a deeper review have been chosen based on their popularity, levels of community involvement, and other distinguishing characteristics. Certainly any tools that help with DNSSEC have merits of their own and DNS operators are fortunate to have so many choices, benefiting from the hard work of others that has gone into providing these valuable tools and the assistance that goes with the tools. The closer review will make clear (1) what the tool does for the DNS operator and (2) what remains as the responsibility of the DNS operator. After reading this document, an organization adopting DNSSEC should have a solid idea of what tools are available and also additional information on deciding which tool, or suite of tools, best matches that organizations technical and business visions. It should be noted that the software tools discussed in Sections 2, 3, 4, and 5 are Open Source tools developed by software consortiums outside of VeriSign. VeriSign has not authored the enclosed tools. Contributing authors can be found on the Web site for each specific tool. This tool guide provides a review of the information associated with each tool. The guide is not meant to certify or endorse a specific tool, but to provide an overview of the tools currently available in the DNSSEC arena. This guide also provides the references to other DNSSEC solutions in Appendix M for completeness of the overview. VeriSign is not endorsing or promoting any specific solution. Any references to the capabilities of the tools are disclaimed on their Web sites. Any references to the capabilities of the hardware appliance are advertised capabilities from the vendor.
1.1 Introduction to DNSSEC This document assumes that the reader has some basic knowledge of DNSSEC and therefore it will not describe DNSSEC in detail. However, the reader may benefit from a bit of high-level background on DNSSEC. For more information regarding DNSSEC, please see the Web pages at http://www.dnssec.net/ and http://verisign.com/dnssec. DNSSEC introduces some security into the DNS infrastructure. For those DNS operators who implement it, it ensures that when DNS clients resolve domain names managed by those DNS operators, the clients have the assurance that DNS responses came from trusted sources and that the data in those responses have not been tampered with en route. In other words, these features of DNSSEC prevent what are called man in the middle attacks and cache poisoning. Furthermore, DNSSEC provides for authenticated denial of existence responses when DNS clients ask about domains that do not exist. DNSSEC necessarily involves cooperation between DNS operators, registrars (oftentimes DNS operators themselves), and registries. The process begins when a DNS operator implements DNSSEC by signing a zone and then communicating certain DNSSEC information from the signed zone to the operator of the parent zone (often a domain-name registry). This communication of DNSSEC data builds a chain of trust between the zones so that during DNS resolution all DNS referrals and delegations can be made securely. DNSSEC augments traditional DNS in terms of added security and yet does so without affecting any non-DNSSEC referrals and delegations. In other words, no party is obliged to implement DNSSEC and standard DNS still operates in the same way that it always has for zones that have not been DNSSEC-signed. The DNS community expects to see increased adoption of DNSSEC as the months and years go by. More and more top-level domains have implemented DNSSEC and many more are planning to do so.
1.2 Features Comparison Matrix for DNSSEC Solutions The following table compares the various features of the DNSSEC software solution offerings discussed in this document: Features BIND9.6
Support PKCS#11 interface with an HSM Automatic key generation Denial of existence using NSEC or NSEC3 Automatic key rollover
Software Based Solutions OpenDNSSEC ZKT DNSSEC-Tools

(ZSK only)

(ZSK only)
Automatic zone signing Manual key rollover
Supported on Windows-based operating systems Supported on *nix-based operating systems Extraction of Delegation Signer (DS) records for publishing KSK to parent zone Sign zones received from transfer (AXFR)
The following table describes the DNSSEC specific features listed in the matrix above and their importance: Features
Support PKCS#11 interface with an HSM Automatic key generation Denial of existence using NSEC or NSEC3
Description
When both the DNSSEC solution and a HSM supports the PKCS#11 interface, the key generation occurs directly within the HSM thereby minimizing the likelihood of a key being compromised or tampered with. When zone signing is performed, the signing keys are obtained securely from the respective HSM. Automatic key generation is very useful in that it does not require user interaction. This is especially useful during a key rollover. Denial of existence is critical in determining that a domain does not exist in a zone. This aspect of DNSSEC was designed to report a signed message that indicates that a given range of names does not exist. This was initially accomplished via the introduction of the NSEC RR which is used to list two names that are ordered canonically in order to show that nothing exists between the two names. The NSEC RR made it trivial to enumerate the content of a zone by querying for names that do not exist. Unfortunately, this introduces enough information to enable an attacker to quickly gather all the names in a zone, and then through targeted queries on the names to reconstruct all or most of a zone's data. An additional issue with NSEC is that the cost to cryptographically secure delegations to unsigned zones is high especially when there are many insecure delegations which will be updated rapidly. In these cases, the costs of maintaining the NSEC RR chain may be extremely high. The NSEC3 RR was introduced to solve these problems. An NSEC3 RR lists the RR types present at the original owner name of the NSEC3 RR and includes the next hashed owner name in the hash order of the zone. The complete set of NSEC3 RRs in a zone indicates which RRSets exist for the original owner name of the RR and form a chain of hashed owner names in the zone. To provide protection against zone enumeration, the owner names used in the NSEC3 RR are cryptographic hashes of the original owner name pre-pended as a single label to the name of the zone. In addition to this, hashed owner names of unsigned delegations may be excluded from the chain thereby reducing the number of records needing to be signed and reducing the overall size of a signed zone. DNSSEC keys do not have a permanent lifetime. The chances a key will be compromised, whether through accident, espionage, or cryptanalysis, increase the longer the key is used. Key rollover is the process by which a key is replaced with a new key and the associated signatures are updated. Manual key rollover requires user interaction and is critical during an emergency rollover in the event of a key compromise. When automated, the key rollover occurs unassisted without the need for user
Manual key rollover
Automatic key
rollover Automatic zone signing Extraction of Delegation Signer (DS) records for publishing KSK to parent zone Sign zones received from transfer (AXFR)
interaction thereby reducing the burden for a DNS operator. Automatic zone signing occurs unassisted without the need for user interaction thereby reducing the burden for a DNS operator. If a zone includes delegations, then a Delegation Signer (DS) RR must be added in the parent zone for a given child. So a zone that contains children must include DS records for all the children. The DS RR is related to a DNSKEY RR for a KSK as generated by the child (the DS RR contains a cryptographic hash over data in the DNSKEY RR) and may be extracted accordingly.
DNS zone transfer, also sometimes known by its (most common) opcode mnemonic AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to employ for replicating DNS zone data across a set of DNS servers. The automatic signing of zone data received via AXFR is a convenience for supporting DNSSEC without the need for user interaction or assistance.
1.3 Other DNSSEC Tools It would be nearly impossible to list all of the other DNSSEC-related tools available to DNS operators because there are many of them and new ones come along all the time. Please see Appendix M for a list of some of the other available DNSSEC-related tools along with a description of each. 1.4 Hardware Security Modules (HSMs) A HSM is a physical device that is designed to generate and store cryptographic keys. Without a HSM, cryptographic key material is easy to find by hackers with malicious intent. When stored on a general purpose computer, key material can be readily copied by a legitimate user or stolen by an attacker in a wide range of ways. HSMs are a critical component of any encryption-based security solution because they safeguard cryptographic keys and protect applications, transactions, and information assets. In DNSSEC, HSMs are used to generate, store and manage the cryptographic keys that sign DNS records and zones. HSMs typically can do this much faster than a software based security module. To see an example of using an HSM with DNSSEC (using the OpenDNSSEC tools), please see Section 3.1.3, Key Generation below.
A HSM can come in various shapes and forms; there are smart cards, PCI cards to plug into a PC, USB tokens, separate boxes that communicate over channels like TCP/IP, USB or rs-232, etc. Regardless of shape or package, the main purpose of these modules is usually either:

Speeding up cryptographic operations Keeping keys safe
On the downside, HSMs can be very expensive. For more information on HSMs, please see http://en.wikipedia.org/wiki/Hardware_security_module.
1.5 DNSSEC Appliances To make the deployment of DNSSEC easier, one can also buy a dedicated "DNSSEC Appliance" which acts as an automated DNS signer for DNS zones. Several vendors are already offering commercial and non-commercial solutions for signing DNS in real time, some of them using external cryptographic hardware such as HSMs. For a very current comparison of features supported by a few of these appliance based products, see A Review of Administrative Tools for DNSSEC at http://www.iis.se/docs/DNSSEC-Admin-tools-review-1.01.pdf.
2. BIND 9
The write-up on this tool is organized in the following way in order to expedite your understanding of how the software helps you with DNSSEC operations. First, youll be given a background on the tool and a summary of how it supports the most important aspects of DNSSEC. Following that, youll be given an idea of what it takes to install, configure, and use the tool in a bit more depth. 2.1 Overview This section is a compact write-up of the features youll find in this software. After a summary and background of the tool, youll find sections on the important aspects of DNSSEC as supported by this tool, including key-management features, zone signing, and Delegation-Signer (DS) data extraction. 2.1.1 Background BIND, the Berkeley Internet Name Domain, is the most commonly used Domain Name Server on the Internet. It is maintained by the Internet Systems Consortium. The current production version is 9.6.1-P1; there is a 9.7 release in alpha at this time, and work has begun on version 10, which should be a full rewrite. DNSSEC has been gradually implemented over the life of release 9, with NSEC3 support introduced with release 9.6. Please note that a minimum version of 9.6.1P1 of BIND is required to support DNSSEC. For details, see https://www.isc.org/software/bind. BIND 9.6.1-P1 provides the following features: De-facto standard DNS on *nix systems. Freely available on most operating systems; binary releases are downloadable for Windows. Key generation (manual) using OpenSSL. Zone signing (manual). In-flight addition and removal of keys with automatic re-signing, supporting key rollovers. Automatic RR resigning. Denial of existence using NSEC or NSEC3 Automatic export of DS records to a flat file to support publishing to the parent zone.
Command-line utilities suitable for scripting custom logic. Zone storage in relational databases instead of flat files as of BIND 9.4, the BIND-DLZ (Dynamically Loaded Zones) sourceforge project has been incorporated into BIND.
2.1.2 Key Generation BIND 9 comes with two utilities for key generation: dnssec-keygen and dnssec-keyfromlabel. 2.1.2.1 dnssec-keygen (file-based) This utility can generate keys for DNSSEC or TSIG. Command-line options allow specification of the key type (Key Signing Key or Zone Signing Key), the algorithm to use, and the key size. Supported algorithms are RSAMD5 (RSA) or RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, DH (Diffie Hellman), and HMAC-MD5. RSASHA1 is mandatory for DNSSEC, and dnssec-keygen can create RSASHA1 keys from 512 to 4096 bits. Note: if the intent is to use NSEC3 instead of NSEC, the algorithm specified should be NSEC3RSASHA1 instead of RSASHA1. The following commands will create a 2048-bit Key Signing Key for the zone acme.com using algorithm RSASHA1 (NSEC) or NSEC3RSASHA1 (NSEC3):
# cd /var/named # /usr/local/sbin/dnssec-keygen -f KSK -a RSASHA1 -b 2048 acme.com.
OR (if using NSEC3)

# /usr/local/sbin/dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 2048 acme.com.
Output:
Kacme.com.+007+19560
The following files are generated under the /var/named folder:

-rw------- 1 root root 1695 Nov 19 20:12 Kacme.com.+007+19560.private -rw-r--r-- 1 root root 382 Nov 19 20:12 Kacme.com.+007+19560.key
The following commands will create a 1024-bit Zone Signing Key for the zone acme.com using algorithm RSASHA1 (NSEC) or NSEC3RSASHA1 (NSEC3):
# cd /var/named
# /usr/local/sbin/dnssec-keygen -a RSASHA1 -b 1024 acme.com.
OR (if using NSEC3)

# /usr/local/sbin/dnssec-keygen -a NSEC3RSASHA1 -b 1024 acme.com.
Output:
Kacme.com.+007+63959
The following files are generated under the /var/named folder:

-rw------- 1 root root 931 Nov 19 20:18 /var/named/Kacme.com.+007+63959.private -rw-r--r-- 1 root root 207 Nov 19 20:18 /var/named/Kacme.com.+007+63959.key
In each case, a public and private key will be generated in separate files. The private key file will have its file permissions set to only allow it to be read by the owner. For details on dnsseckeygen, see http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#id2550308 or https://www.isc.org/software/bind/documentation/arm95#man.dnssec-keygen.
2.1.2.2 dnssec-keyfromlabel (HSM-based) Since DNSSEC in BIND9 is dependent on OpenSSL, the HSM / PKCS#11 support in BIND9 is based on the configuration of the HSM as an OpenSSL engine, and requires a patch to be applied to the OpenSSL code, followed by a rebuild. BIND 9.7 is expected to have enhanced PKCS#11 support, but as of 9.7.0a3 this still seems to involve patching and rebuilding OpenSSL and currently does not appear to work. Investigation into this is still ongoing. For details on dnssec-keyfromlabel, see http://oldwww.isc.org/sw/bind/arm97/man.dnsseckeyfromlabel.html. 2.1.3 Zone Signing
2.1.3.1 How to do it, including configuration and command-line parameters (RRSIG lifetime, ZSK vs. KSK, specifying keys to use) Bind comes with a dnssec-signzone utility that generates the NSEC (or NSEC3) and RRSIG records, and produces a signed version of the zone file. Generate a KSK and a ZSK using dnssec-keygen or dnssec-keyfromlabel. $INCLUDE the KSK and ZSK public keys in the unsigned zone file:
# vi acme.com.zone
Go to the end of the file and add the two lines below:
$INCLUDE Kacme.com.+007+19560.key $INCLUDE Kacme.com.+007+63959.key
Sign the acme.com zone (using NSEC or NSEC3) with the dnssec-signzone command: Inputs: An existing zone (signed or unsigned) file, edited to $INCLUDE the public ZSK and KSK. Public and private KSK and ZSK. Outputs: A signed zone file. Example:
# cd /var/named
# /usr/local/sbin/dnssec-signzone -o acme.com db.greeks
OR (if using NSEC3)

# /usr/local/sbin/dnssec-signzone -o acme.com -3
db.greeks
Output:
acme.com.zone.signed
The following 3 files are generated under the /var/named folder:

-rw-r--r--rw-r--r--rw-r--r-1 root root 1 root root 1 root root 8938 Nov 19 20:48 acme.com.zone.signed 477 Nov 19 20:48 keyset-acme.com. 159 Nov 19 20:48 dsset-acme.com.
Please refer to Appendix I for the details of these output files created by dnssecsignzone. For more details on zone signing, see http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#id2550375 or https://www.isc.org/software/bind/documentation/arm95#man.dnssec-signzone.
10
2.1.3.1.1
Dynamic Update Support
Dynamic update involves DNS clients making changes to zone data in an authoritative name server in real time. The Dynamic update facility provides operations for addition and deletion of Resource Records (RRs) in a zone file. When DNSSEC is enabled, the RRs corresponding to an update are automatically resigned when the update is received. By default, the dynamic update facility of BIND is disabled. Dynamic updates are enabled or restricted by using one of the following two statements in BIND: allow-update update-policy (available only in BIND 9 versions) These statements can be specified only at the zone level, not at the server level. For update-policy, the following statements should be added to the zone options block in named.conf. The simplest configuration is to add:
update-policy { ( grant | deny ) <keyname> name <hostname> A TXT; }; e.g. zone "example.com" { type master; file "master/example.com"; update-policy { grant foo.example.com. name foo.example.com. A TXT; }; };
The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended. The configuration in the zone options block in named.conf for allow-update is as follows:
allow-update { key <keyname>; };
where <keyname> is the name of the key chosen when the key was generated. The nsupdate command can be used for making dynamic updates (see http://linux.yyz.us/nsupdate/). For an example usage, please refer to Section 2.1.4.1.2, Partially Automated Process below.
11
When dynamic update is enabled for a zone, the zone can no longer be manually edited as normal. Attempting to do so may work in some cases, but will usually result in a name server error. The DNS server keeps a journal file of incoming updates. The file is not automatically synchronized with the zone file, but can be forced with the "rndc freeze" command. Extreme care has to be exercised when manually updating a zone subject to dynamic updates. The following steps must be done to edit a master file of a zone maintained by dynamic update:
rndc freeze zone Edit the zone file rndc unfreeze zone
For more information on configuring dynamic updates in BIND, please refer to the BIND Administrator Reference Manual at https://www.isc.org/software/bind/documentation/arm95#dynamic_update. As of 9.6.0 you could actually add DNSKEY records dynamically to a zone, and named would sign the zone but this no longer works as of 9.6.1 there is a new restriction against dynamically going from not-signed to signed. According to a thread in the bind-users list titled "DNSKEY dynamic update: unexpected change 9.6.0-P1 -> 9.6.1", this feature will be restored in the 9.7 release, and in the meantime can be re-enabled by compiling BIND with
CFLAGS="-DALLOW_SECURE_TO_INSECURE -DALLOW_INSECURE_TO_SECURE"
Please note that this should be specified in the Makefile. 2.1.3.2 NSEC/NSEC3 Both are supported. NSEC is the default; in order to use NSEC3, different algorithms need to be used in creating the ZSK and KSKs as indicated in Section 2.1.2.1, and additional flags (-3 <salt>, -H <iterations>, and A (which will use opt-out)) to be passed to the dnssec-signzone command. 2.1.3.3 Loading Signed Zone into Name Server First, the named.conf file needs to be updated to refer to the signed zone file and specify dnssecenable yes; line in the options{} section as shown in Section 2.2.1.3, Configuration below. Thereafter the signed zone will be used when reloading in named. After named.conf has been updated to refer to the signed version of the zone, execute the following command to reload the signed zone:
12
#/usr/local/sbin/rndc reload acme.com
Please note that named should be properly configured per section 2.2.1.3, Configuration below to be able to load the specific signed zone and to successfully use the rndc utility. 2.1.3.4 Re-signing dnssec-signzone can be used again to resign the zone. Additionally, any records changed via nsupdate will be automatically re-signed. Sample nsupdate session and re-signing:
# > > > > > > nsupdate server 127.0.0.1 zone acme.com. update add acme.com. 3600 IN NS ns3.acme.com. send update add ns3.acme.com. 3600 IN A 128.8.76.3 send
# dig @127.0.0.1 acme.com. RRSIG ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.1-P1 <<>> @127.0.0.1 acme.com. RRSIG ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20988 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 5, ADDITIONAL: 4 ;; QUESTION SECTION: ;acme.com. IN RRSIG
;; ANSWER SECTION: acme.com. 3600 IN RRSIG SOA 7 2 3600 20091220181259 20091120171259 63959 acme.com. T3+1VV78IQWU8ZcmGN8aKuBPlohS8ZRH06R1gWo4DK+FrHwX3cz15tqx otJAoEdKkqpuQNoR4r5d0Wqd1vnOt8rukPZg0IFfQIWrwXataYSMnS4Z 3THsxAfzpC57oPfZ5T27MPTVQ1Fk7fBKuW1oHNXST0MbF2+zyx+dt47L vy0= acme.com. 3600 IN RRSIG NS 7 2 3600 20091220181259 20091120171259 63959 acme.com. Z9W97y9B0dPoAxYFeDodE8z9FcchBV4Dp+4gmWSfEZfZ+ofkzpClQG4P WFchlk+GLjbegjVwC6EqSBK95i36JV/DyzyO07QfL9F1s3indVk+P5H5 K5ncp/vpbWlVsQDCDX3DPY0Rg2wSvaiKQJZy41s8QVf4Kn4LMD7oSalP 518= acme.com. 3600 IN RRSIG MX 7 2 3600 20091219194852 20091119194852 63959 acme.com. DU8ZQvhGB5SiYxLZt2ICKxTAnTYYZI+3nR3xj6gWBgUXKNbfll+OSOAt 4OlhLePCyyn9P9Jy7z3VCnFsKf5ZkijErUN9/dA1MRPIWuVWrYurXBHC HJfnwOpPumA1uoA2cY6Ef8JoecMt4XZsyl+XBpj92pb/rjD2hZmdcJit fzI= acme.com. 3600 IN RRSIG DNSKEY 7 2 3600 20091219194852 20091119194852 19560 acme.com. sEbNh/HAqnZNXil1rnc5r3KRPHc5SCcTxzuH3jQPH6Uu4p90rJ2RFrvK ky1IG4FeQS9E/Ape/et72+bM4xQh/2y+6K9zFvgnFH8MLzwmZX2hFfF3 w2JMiInLKinn0pZUb3AeXE5WEcmqdbvbKi3dYOJ28nYNwvdF7KmbxQHp MKlgtgGx+a2DTrWEkPEmuBf1dEdWMV8yDTXYt8/fph6tK1s0rvM6naYr ITXDTIEYPE2eKluQRvhgUABw/iYSUy2jjcjXfIweW8s+5BydpJ56soYU +ERO6JgUtGy+djnJ6R0XoMn39QJV4kDiLGuchf6q0KnUNGIRSEEMt/Qu NxW3+A== acme.com. 3600 IN RRSIG DNSKEY 7 2 3600 20091219194852 20091119194852 63959 acme.com. j6c5a09gD2Spp4BwjA2HYg8IQYltko7jzKGY7CFPKF9FR0YpH3ZdNbhc
13
8MG9Eh5mSyyU3z6tqb/f4u1rryOZwrkVNHW9SGTW91pkgdblyYAMB4ya Ok9u6ulfxYgAx7wTV6NplPbas+j5nJEvnNWwm6W1ZM8iVp5Txbwcsoyc zCw= acme.com. 0 IN RRSIG NSEC3PARAM 7 2 0 20091219194852 20091119194852 63959 acme.com. jBWIlrcaAvqQsK2Nm5saVJkyT/wNZEwHBzZ8huhKM+PhzAcHRqjtOUwr 9XUdujrnV0hxYH/L9G4K/YRw41ZRy/ETXkKhjPwptmg2nXdIOoetwNxM oYdOu9I3lAt0IKB/iJCLF3L8HHnWqfO2c4JJouHS7Y6eo3nZxeWIu44l URo= ;; AUTHORITY SECTION: acme.com. acme.com. acme.com. acme.com. ;; ADDITIONAL SECTION: noc.acme.com. ns1.acme.com. ns2.acme.com. ns3.acme.com. 3600 3600 3600 3600 3600 3600 3600 3600 IN IN IN IN IN IN IN IN NS NS NS NS A A A A ns1.acme.com. noc.acme.com. ns2.acme.com. ns3.acme.com. 128.8.5.2 128.8.74.2 128.8.76.2 128.8.76.3
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Nov 20 18:21:17 2009
The private keys should be kept at the /var/named directory in order for named to dynamically sign records via nsupdate. Failing to do so, will generate an error as follows:
Nov 20 18:11:00 qavm-dnssec-studyguide named[19308]: client 127.0.0.1#26477: updating zone 'acme.com/IN': found no private keys, unable to generate any signatures Nov 20 18:11:00 qavm-dnssec-studyguide named[19308]: client 127.0.0.1#26477: updating zone 'acme.com/IN': RRSIG/NSEC/NSEC3 update failed: not found
Each time a successful dynamic update occurs, the serial number of the signed zone is incremented:
Nov 20 18:12:59 qavm-dnssec-studyguide named[19308]: zone acme.com/IN: sending notifies (serial 2009111904)
2.1.4 2.1.4.1 2.1.4.1.1
Key Rollovers How to Roll ZSK Manual process
Generate the key pair

# dnssec-keygen -v 8 -a RSASHA1 -b 1024 -n ZONE acme.com.
Add the new ZSK DNSKEY record to the zone

# cat Kacme.com.+005+28350.key >> db.greeks.signed
Sign the zone with both keys
14
# dnssec-signzone -o acme.com -k Kacme.com.+005+19341 db.greeks.signed
This results in a db.greeks.signed.signed file, which can be diffed with and then swapped for the db.greeks.signed file. This can be done alternatively (described in RFC 4641 at http://www.ietf.org/rfc/rfc4641.txt ) as follows: 1. Add the new ZSK to the zone file 2. Publish the new ZSK 3. Wait until the associating DNSKEY TTL has elapsed. For more details on DNSSEC key timing considerations, refer to the IETF Internet Draft at http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01. 4. Sign the zone with the new ZSK (only). Remove the old key This involves manually removing the old ZSK DNSKEY record from the file. 2.1.4.1.2 Partially Automated Process
Generate the key pair Add the new ZSK DNSKEY record to the zone using nsupdate. It will start a command line which will accumulate messages until either a blank line or a send command is entered, and then sends all the messages to the server.
# nsupdate >server 127.0.0.1 >ttl 3600 >update add acme.com. IN DNSKEY 256 3 7 AwEAAckJrLIn3IlGDeFg62aO8Cr/Dmi8S3/juBGj+TfxzLxFVN8C0of5 H2u8PytlaT8zbHAX83dnXeheUSSxsVjKif11VYciHzDMawmL2Z2mSWKD zBCq70NpjojauO0Q0dW9w3c/PoIQRnEOMrtMVMVoOcPmA3Bsp0NNPSGA 3pqgYp2P >send
Alternately, the messages can be added to a flat file and passed to nsupdate in a single command.
# cat newzsk.ddns server 127.0.0.1 ttl 3600 update add acme.com. IN DNSKEY 256 3 7
15
AwEAAckJrLIn3IlGDeFg62aO8Cr/Dmi8S3/juBGj+TfxzLxFVN8C0of5 H2u8PytlaT8zbHAX83dnXeheUSSxsVjKif11VYciHzDMawmL2Z2mSWKD zBCq70NpjojauO0Q0dW9w3c/PoIQRnEOMrtMVMVoOcPmA3Bsp0NNPSGA 3pqgYp2P send # nsupdate newzsk.ddns
For the different available command formats to use with nsupdate, refer to Appendix L. For more details on nsupdate, please see the following URLs: http://linux.yyz.us/nsupdate/ http://www.debianadministration.org/article/Using_the_dynamic_DNS_editor_nsupdate http://linux.about.com/library/cmd/blcmdl8_nsupdate.htm The zone is automatically signed with the new key. Only the RRSIGs from the first key are returned as part of a resolution. Both DNSKEYs are returned when DNSKEY is requested for the zone. Remove the old key using nsupdate:
# cat delete.ddns server 127.0.0.1 update delete acme.com. IN DNSKEY 256 3 7 AwEAAcHgl4tvG4mX05lIgcqyV/4QaG+LVMmAxelwxgs/J8o6vtTLtzH1 7/gweDaukaGrdJLMEO8kibCh8lTirzgCn5XxvjMnTOidqB0IqEt1GhRt qTN5rq4z1V4OlbbvKRIr2arC5qDAzvgK7vhOn1Y66pLsaYJGAW+Rp/I6 Xy9eQJcb send
# nsupdate delete.ddns
The old key has been removed from the zone. The new RRSIGs are returned as part of a resolution, and the new DNSKEY is returned when DNSKEY is requested. 2.1.4.2 2.1.4.2.1 How to Roll KSK Manual process
Generate the key pair

# dnssec-keygen -v 8 -f KSK -a RSASHA1 -b 2048 -n ZONE acme.com
16
Add the new KSK DNSKEY record to the zone

# cat Kacme.com.+005+51997.key >> db.greeks.signed
Sign the zone with both keys (Double Signature method)

# dnssec-signzone -o acme.com -k Kacme.com.+005+19341 -k Kacme.com.+005+51997 db.greeks.signed
This results in a db.greeks.signed.signed file, which can be diffed with and then swapped for the db.greeks.signed file. Please see Section 2.1.4.1.1, Manual process above for an alternative way of doing this. Please note that the Double Signature method for signing is not the only option available though it is typically the strategy used when rolling a KSK.
Send the DS record for the new KSK to the parent domain.
For instance, with an EPP message. When the zone is signed, the dsset-acme.com. file will be generated containing the DS records.
Wait for the associating DNSKEY TTL to expire counting from when the new KSK DS record ends up being first published by the parent. For more details on DNSSEC key timing considerations, refer to the IETF Internet Draft at http://tools.ietf.org/html/draftmorris-dnsop-dnssec-key-timing-01. Remove the old key This involves manually removing the old KSK DNSKEY record from the file.
2.1.5 Publishing of DS Data to Parent Zone Extracting DS data from signed zone As part of the zone-signing process, dnssec-signzone creates an additional file named dsset-<domain-name> which contains the DS records. Interfacing w/parent registry There is no explicit support for this. The DS records need to be communicated to the parent registry manually, or using a different tool.
17
2.2
Setup
2.2.1 Installation Steps BIND v 9.6.1-P1 can be downloaded as source freely from Internet Systems Consortium, at http://www.isc.org. Extract the tar file to a temporary directory for installation. 2.2.1.1 Prerequisites The following are prerequisites for installation of BIND v 9.6.1-P1 with DNSSEC support (Check the README file in the source tar-ball for complete details; yum or the analogous tool for your platform makes installing prerequisites very easy): OpenSSL version 0.9.8e and openssl-devel version 0.9.8e packages. the supported ANSI C compiler (gcc version 4.1.2-44 on linux)
2.2.1.2 Installation BIND needs to be built with OpenSSL support in order to support DNSSEC. If you install from a packaged version of BIND, make sure it has this support. Otherwise just download the source and build locally as described below. 2.2.1.2.1 Building BIND (Note that there are binary downloads available for Windows.) Once the prerequisites are installed, then cd to the expanded tar-ball folder and perform this command to prepare the Makefile used to compile from the source (again, see the README for additional details and more options):
# ./configure --with-openssl
Assuming this step completes successfully, execute the make script, followed by make install.
# make # make install
Having followed these steps, BIND 9 should be installed on your system. For details regarding to building BIND and viewing release notes, see http://oldwww.isc.org/sw/bind/view/?release=9.6.1-P1&noframes=1. 2.2.1.3 Configuration Bind uses the named.conf and rndc.conf file to store its configuration, located by default in /etc.
18
NOTE: The named.conf and rndc.conf files need to be manually created. Before creating these configuration files, we need to create a secret key that is used by both configuration files to allow rndc to communicate with named. This can easily be done by using the rndc-confgen utility which comes with the BIND distribution. The following command will create a secret key file called rndc.key located in /etc by default:
# /usr/local/sbin/rndc-confgen a # cat /etc/rndc.key key "rndc-key" { algorithm hmac-md5; secret "a6AX6g9ztiiwsqsa1mTXFA=="; };
Now, when we create the named.conf and rndc.conf configuration files, we will add the following line to each to include this secret key file: include "/etc/rndc.key"; Here is a fairly minimal sample /etc/named.conf file which is nevertheless sufficient to support DNSSEC in the loading of signed zone at start time, reload of signed zone using rndc:
options { directory "/var/named"; allow-update { 10.131.69.131;127.0.0.1; }; dnssec-enable yes; }; # -----------------------include "/etc/rndc.key";
controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };
# ZONEs
19
# ----------------------------------zone "0.0.127.in-addr.arpa" zone "acme.com" zone "5.168.192.in-addr.arpa" { type master; { type master; { type master; file "db.127.0.0"; }; file "db.greeks.signed"; }; file "db.192.168.5"; };
It is required to include the dnssec-enable yes; line in the options{} section in order to enable DNSSEC. Here is a fairly minimal sample of a /etc/rndc.conf file:
# Start of rndc.conf include "/etc/rndc.key";
options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; # End of rndc.conf
At this point, it should be possible to start named, and to successfully retrieve data from it via dig. Use the following named command to start named:
# /usr/local/sbin/named c /etc/named.conf
Use the following rndc command to reload the signed zone:

# /usr/local/sbin/rndc reload
Use the following dig command to verify some records of the signed zone:
# dig @127.0.0.1 acme.com SOA
; <<>> DiG 9.6.1-P1 <<>> @127.0.0.1 acme.com SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18708
20
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION: ;acme.com. IN SOA
;; ANSWER SECTION: acme.com. 86400 10800 3600 604800 86400 IN SOA dev-ng-core4.acme.com. dnsuser.acme.com. 4
;; AUTHORITY SECTION: acme.com. 86400 IN NS dev-ng-core4.acme.com.
;; ADDITIONAL SECTION: dev-ng-core4.acme.com. 86400 IN A 192.168.5.1
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Dec 28 15:34:26 2009 ;; MSG SIZE rcvd: 115
Other dig commands:

# dig @127.0.0.1 +dnssec acme.com <recordtype>
where <recordtype> can be DNSKEY, RRSIG, NSEC3, NS, A or other records that exist in the signed zone. For more sample configurations, see http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch03.html#sample_configuration. For configuration details, see https://www.isc.org/software/bind/documentation/arm95#Bv9ARM.ch06.
2.3
Running Application
2.3.1 Daemons named Internet domain name server
21
This is the daemon process that actually services DNS requests. For details, see http://oldwww.isc.org/sw/bind/arm97/man.named.html.
2.3.2
Command Line Utilities
2.3.2.1 Maintenance Utilities The following maintenance utilities come with BIND 9. Those with the annotation (9.7) are introduced as of (or prior to) BIND 9.7a3. dnssec-dsfromkey DNSSEC DS RR generation tool
This utility generates the Delegation Signer (DS) record for a given key. For details, see http://oldwww.isc.org/sw/bind/arm97/man.dnssec-dsfromkey.html.
dnssec-keyfromlabel DNSSEC key generation tool

This utility retrieves a key from PKCS#11-compliant crypto hardware. For details, see http://oldwww.isc.org/index.pl?/sw/bind/arm97/.
dnssec-keygen DNSSEC key generation tool

This utility generates keys using software-based cryptography. For details, see http://oldwww.isc.org/sw/bind/arm97/man.dnssec-keygen.html.
dnssec-revoke (9.7) Set the REVOKED bit on a DNSSEC key

For details, see http://oldwww.isc.org/sw/bind/arm97/man.dnssec-revoke.html.
dnssec-settime (9.7) Set the key timing metadata for a DNSSEC key
For details, see http://oldwww.isc.org/sw/bind/arm97/man.dnssec-settime.html.
dnssec-signzone DNSSEC zone signing tool

This utility signs the designated zone, and can generate DS records as a secondary output. For details, see http://oldwww.isc.org/sw/bind/arm97/man.dnssec-signzone.html.
nsupdate Dynamic DNS update utility

This utility is used to perform zone maintenance without interrupting named. For details, see http://oldwww.isc.org/sw/bind/arm97/man.nsupdate.html.
rndc name server control utility

For details, see http://oldwww.isc.org/sw/bind/arm97/man.rndc.html.
rndc-confgen rndc key generation tool

For details, see http://oldwww.isc.org/sw/bind/arm97/man.rndc-confgen.html.
22
ddns-confgen (9.7) ddns key generation tool

Generates a key for use in securing communications between nsupdate and named. For details, see http://oldwww.isc.org/sw/bind/arm97/man.ddns-confgen.html.
2.3.2.1.1
Test / Analysis Utilities
dig DNS lookup utility

Sends requests to named and displays responses. For details, see http://oldwww.isc.org/sw/bind/arm97/man.dig.html.
host DNS lookup utility.

For details, see http://oldwww.isc.org/sw/bind/arm97/man.host.html.
named-checkconf named configuration file syntax checking tool

For details, see http://oldwww.isc.org/sw/bind/arm97/man.named-checkconf.html.
named-checkzone zone file validity checking or converting tool

For details, see http://oldwww.isc.org/sw/bind/arm97/man.named-checkzone.html.
2.3.3 Add-ons One result of having been the de facto Unix standard for domain name servers for so long is that there are numerous extensions and enhancements that are available for BIND. One of these is DNSSEC-Tools (http://www.dnssec-tools.org/) which is described in detail in Section 4, DNSSEC-Tools, of this document. 2.4 Tips/Tricks/Gotchas The ./doc/arm subdirectory in the BIND installation tarball contains HTML and pdf format copies of the Administrator Reference Manual, which gives some high-level descriptions, as well as the man- pages for all the utilities. The ISC maintains archives of their mailing lists at http://lists.isc.org/pipermail/. These include bind-users, bind-announce, bind-bugs, and a series of lists dedicated to the BIND 10 rewrite. There is additionally a list archive pertaining specifically to the BIND Dynamically Loadable Zones (DLZ) patch at http://news.gmane.org/gmane.network.dns.bind9.dlz. DLZ is a patch for BIND version 9 that simplifies BIND administration and reduces memory usage and startup time. DLZ allows you to store your zone data in a database. Unlike using scripts, the changes in your database are immediately reflected in BIND's
23
response to DNS queries, so there is no need to reload or restart BIND. Please refer to http://bind-dlz.sourceforge.net for more information on the BIND DLZ patch.
24
3. OPENDNSSEC
The write-up on this tool is organized in the following way in order to expedite your understanding of how the software helps you with DNSSEC operations. First, youll be given a background on the tool and a summary of how it supports the most important aspects of DNSSEC. Following that, youll be given an idea of what it takes to install, configure, and use the tool in a bit more depth. OpenDNSSEC is currently available only as a beta release. 3.1 Overview This section is a compact write-up of the features youll find in this software. After a summary and background of the tool, youll find sections on the important aspects of DNSSEC as supported by this tool, including key-management features, zone signing, and Delegation-Signer (DS) data extraction. 3.1.1 Background The OpenDNSSEC (http://www.opendnssec.org) project developed Open Source software that manages the security of domain names on the Internet. The project intends to drive adoption of Domain Name System Security Extensions (DNSSEC) to further enhance Internet security and to make the DNSSEC handling as automated as possible. OpenDNSSEC provides the following features: No manual management is needed (after first configuration) Works with all different versions of the Unix operating system Multiple zones with shared or individual policies Each policy specifies a set of key and signature settings Handle zone sizes ranging from a few RRs to millions of RRs Unsigned zone file in and signed zone file out. Supports RSA/SHA1 signatures ready for future algorithms (e.g.RSA/SHA2, GOST) Denial of existence using NSEC or NSEC3 Automatic key generation in HSMs via the PKCS#11 interface Option support for sharing keys between zones Automatic key rollover Possibility of manual key rollover (emergency key rollover)
25
Automatic zone signing using HSMs via the PKCS#11 interface Auditing of the signing process and result BSD license
3.1.2 Technologies & Architecture Overview The OpenDNSSEC software incorporates many disparate programming languages and Open Source software packages/tools. The various components are implemented via the following programming languages: C/C++ Perl Python Ruby Java (used by various pre-requisites like OpenSSL and ldns) (used by the KASP Enforcer component) (used by the Signer Engine component) (used for the KASP Auditor component) (required only for building OpenDNSSEC)
The following diagram identifies the architecture for the OpenDNSSEC components including zone input/output:
26
The following briefly describe the four major components above: 1. Security Module This component identifies a PKCS11 compliant repository for storing cryptographic keys (a keystore) via the libhsm subcomponent. Either a Hardware Security Module or the softHSM (http://trac.opendnssec.org/wiki/SoftHSM) software-based virtual HSM (from OpenDNSSEC) can be used. The <RepositoryList> tag in the conf.xml configuration file (discussed in detail in Section 3.2.2, Configuration below) is used to list all used keystore repositories whereas the <Repository> tag is used to define each specific repository in this list. 2. Signer It drives the whole signing process by continuously keeping all zones signed as specified in the signer configuration received from the KASP Enforcer.
27
The signer is responsible for:

resigning before signatures expire resigning when the keys have changed creating a new NSEC3 chain, update NSEC3PARAM, wait for dist, remove old chain updating the SOA serial when changing keys
The DNSEC signing of zone files are based on configurations defined in the kasp.xml and any zone specific signer configuration files (discussed in detail in section 3.2.2, Configuration below). The list of zones to be signed is defined in the zonelist.xml configuration file which itself is pointed to from within the <Signer> tag in the conf.xml configuration file (also discussed in detail in Section 3.2.2, Configuration below). The signer itself consists of multiple components: The "Signer Engine" schedules all signing operations. This is provided by the ods-signerd daemon program. The RRset Signer signs a single RRset with one or more keys using the Security module. The NSEC-ifier maintains the NSEC and NSEC3 chains in zone and is also responsible for sorting the zone unless it is already sorted.
3. KASP Enforcer KASP stands for "Key and Signature Policy and defines the policies used to sign zones. The KASP Enforcer component primarily deals with key rollover and key generation based on the policies defined within the kasp.xml configuration file. A separate section in the conf.xml configuration file is used to configure the Enforcer component (via the <Enforcer> tag). The KASP Enforcer reads and implements the policy, i.e. creating keys (using the security module) that is needed, removing keys no longer needed, handles pre- and post publishing timers etc. The output from the KASP Enforcer is: a set of keys created in the Security Module a signer configuration passed on to the Signer
28
The KASP Enforcer itself consists of multiple components: The KASP Importer is responsible for reading the kasp.xml and zonelist.xml configuration files and populating to a SQLite or MySQL database. The Communicator component is implemented by a daemon program (odsenforcerd) which maintains keys according to policy (using libksm) for the Signer. It also creates signer configuration XML-files that the signer uses when signing. It also creates keys if needed by the KASP Enforcer.
4. KASP Auditor This component does checks on the signed zone files to verify that the signing conforms to the policies given in KASP. Specifically, it runs an audit of the zones in the system to see if the signer complies with what the policy mandates. It can be issued automatically after each resigning of a zone and will stop the signed zone file from being distributed. This component is still under development and is implemented by the ods-auditor command. These components will be discussed later in more detail. Several prerequisite software packages are required by OpenDNSSEC. Please see Section 3.2.1.2, Prerequisite Software below for a listing of these. For more details, please refer to the available documentation at http://www.opendnssec.org/documentation/.
3.1.3 Key Generation Please see Section 3.2.3, Initialization on how to pre-generate the file based KSK and ZSK keys for softHSM (optional). When key rollover occurs, new keys are automatically generated by the ods-enforcerd daemon. Create and import keys into a hardware based HSM: Integration of OpenDNSSEC and an HSM is seamless thanks to the use of the PCKS11 interface (as supported by the softHSM software based HSM). The creation of keys within an HSM can be done using the ods-hsmutil command line utility. Heres a simple example where the configured repository associated with the HSM is named myHSM:
29
# ods-hsmutil generate myHSM rsa 1024 Generating 1024 bit RSA key in repository: myHSM Key generation successful. key: module: 0x1a00dc80 privkey handle: 146 pubkey handle: 145 repository: myHSM algorithm: RSA size: 1024 id: 9de4e6782cc18e7ed394681a744b3059
When OpenDNSSEC performs automatic key generation, it is uses the same PKCS11 interface as ods-hsmutil for seamless integration with a configured HSM. The importing of keys into a hardware based HSM is strictly HSM specific. With that said, the Mozilla project (http://www.mozilla.org) provides a set of libraries, designed to support cross-platform development of security-enabled client and server applications, called Network Security Services (NSS). Specifically, NSS includes a utility called pk12util (http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html) which supports the import of PKCS#12 (http://en.wikipedia.org/wiki/PKCS12) formatted files into a PKCS#11 compliant HSM. The following is an example which shows the use of the pk12util in order to import a public/private key pair from a PKCS #12 formatted file called key-pairs.p12 into an HSM with a slot name called myHSM:
# pk12util -i key-pairs.p12 -d . -h myHSM Enter Password or Pin for " myHSM ":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL
Please note that importing keys into an HSM is typically used only for debugging purposes. 3.1.4 Zone Signing How to do it, including configuration and command-line parameters (RRSIG lifetime, ZSK vs. KSK, specifying keys to use) Zones may be signed manually or else scheduled for signing at a later time. For details on how to sign a zone, use the ods-signer command as described in Section 3.3.2.1, Signer Engine below. Please also see Section 3.2.2, Configuration below for the details on configuring the policies to use for zone signing.
30
Inputs/outputs Unsigned input zone files are placed in the /var/opendnssec/unsigned folder. Signed output zone files are created in the /var/opendnssec/signed folder. Please see Section 3.2.4, Processing Input/Output below for the details of configuring these.
NSEC/NSEC3 This is configured in a zone specific Signer configuration file via the <NSEC> or <NSEC3> tags within the <Denial> tagged block. The zone specific configuration files are placed in the /var/opendnssec/signconf folder. Although these files can be created manually, a default is generated at signing time if one does not pre-exist. See Section 3.2.2, Configuration below for more details.
Loading Signed Zone Into Name Server A name server can be notified to load a signed zone, by OpenDNSSEC, when a zone is signed. This is configured in the conf.xml configuration file via the <NotifyCommand> tag within the <Signer> tagged block. This tag configures the OS level command to use to notify a DNS name server when a zone is signed. Please refer to Appendix E for an example specific to the BIND DNS name server.
Re-signing For zone re-signing, you will use the ods-signer command as described in Section 3.3.2.1, Signer Engine below.
3.1.5 Key Rollovers Keys may be rolled over either manually (for an emergency) or else scheduled to rollover at set time period intervals. For example, the National Institute of Standards and Technology (NIST) recommends rolling the ZSK every 30 to 90 days whereas they recommend rolling the KSK every 2 years (please see http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf for more details). To manually roll the ZSKs for a zone, you use the following command like this:
# ods-ksmutil key rollover --zone zonefile --keytype ZSK
To manually roll the KSKs for a zone, you use the following command like this:
# ods-ksmutil key rollover --zone zonefile --keytype KSK
Pre- and post-publish considerations & timing?
31
These can be configured via the zone signer specific configuration file and the kasp.xml configuration file. Please see Section 3.2.2, Configuration below for the details of configuring these files. 3.1.6 Publishing of DS Data to Parent Zone Extracting DS data from signed zone Please refer to the usage of ods-hsmutil to see an example on how to publish a key. You only need to publish a key (to the parent or to interested parties) when you create a new KSK. To extract all DS records for a signed zone, you can use the following command:
# ods-ksmutil key export -z zoneFileName d
To extract DS records for all signed zones, leave off the z option as follows:
# ods-ksmutil key export -d
Versions of OpenDNSSEC prior to the Beta releases do not provide a mechanism for the extraction of DS data to a parent zone. Please see Appendix G for a workaround for this. Interfacing w/parent registry OpenDNSSEC does NOT provide any mechanisms for interfacing with a parent registry. Currently, manual intervention is required for a KSK rollover. This intervention is a three-stage process that is described on the page http://www.opendnssec.org/documentation/using-opendnssec in the Key rollovers section. For future versions of OpenDNSSEC (tentatively version 1.1), this process will be automated as much as possible, including integration points for interfacing with a parent registry via an EPP client plugin.
3.2
Setup
3.2.1 Installation Steps While many of the needed pre-requisite software components can be downloaded and installed manually, it is highly recommended that a package manager such as YUM (http://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified) be used to take care of
32
downloading/installing additional dependencies needed by these packages. Please see the installation notes in Appendix A for more details on configuring YUM. 3.2.1.1 Subversion Client The development (unstable) version and most recent version (at the time of writing, version 1.0.0b2) of OpenDNSSEC and a PKCS11 compliant software based virtual HSM are available from the following Subversion repository locations: http://svn.opendnssec.org/tags/OpenDNSSEC-1.0.0b2 http://svn.opendnssec.org/trunk http://svn.opendnssec.org/tags/softHSM-1.0.0 These distributions may be obtained by downloading and using a Subversion client software product such as Aqua Data Studio (http://www.aquafold.com/downloads.html) or TortoiseSVN (http://tortoisesvn.tigris.org/). Please see http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients for a good comparison of free and commercially available Subversion clients. Tarballs containing several of the OpenDNSSEC distributions may be downloaded instead of obtaining via Subversion from the following URL: http://www.opendnssec.org/files/source/ 3.2.1.2 Prerequisite Software The following software tools/packages are required by OpenDNSSEC for building and executing the software: SQLite3 OpenSSL and OpenSSL Development package (openssl-devel) Make GNU AutoConf 2.6.4 or later GNU M4 C compiler (gcc on Linux) C++ compiler (g++ on Linux) GNU Libtool
33
ldns 1.6.0 or later libxml2 and libxml2-devel Botan 1.8.0 or later ruby, rubygems, dnsruby and openssl for ruby (for the auditor) Java (only for building) Perl the Python XML library, python-4suite-xml or source from 4suite.org DNSSEC supported DNS server such as BIND9 (for name server integration and loading signed zones and DS records)
For detailed instructions on installing these software distributions/packages, please refer to the OpenDNSSEC project WIKI at http://trac.opendnssec.org/wiki/Signer/Using/Installation/Dependencies and the installation notes listed in Appendix A of this document. 3.2.1.3 OpenDNSSEC Once all prerequisite software is installed we are ready to install the OpenDNSSEC software itself.
# sh autogen.sh # ./configure
(use ONLY if configure script not present)
You may also need some other options to configure (system dependent) - use the following command to find out which:
# ./configure --help
Once configured, build and install OpenDNSSEC using:

# make # make install
A detailed installation guide including the dependencies can be found here: http://trac.opendnssec.org/wiki/Signer/Using/Installation. Please also refer to the installation notes in Appendix A for installation details. 3.2.1.4 softHSM If an HSM is not available, the OpenDNSSEC project provides a software-based virtual HSM called softHSM. This may be installed as follows:
34
# sh autogen.sh
(use ONLY if configure script not present)
# ./configure (+ flags) # make # make install
For more details, please refer to the installation notes in Appendix A. 3.2.1.5 Post-Install (Linux Systems ONLY)
Linux users need to rebuild the dynamic linker caches. To do this, issue the command:
# sudo ldconfig [library-path [library-path ...]]
You will want to make sure to include the paths for all installed libraries. Please see the installation notes in Appendix A for an example. 3.2.2 Configuration For details regarding to each of the configuration files supported by OpenDNSSEC, please see the WIKI at: http://trac.opendnssec.org/wiki/Signer/Using/Configuration. The following table identifies the primary OpenDNSSEC configuration files: File /etc/softhsm.conf Description Configuration for the virtual software-based HSM. Defines numbered slot to be associated with sqlite3 database instances for storing HSM based configurations. Overall configuration for OpenDNSSEC. Zone specific Signer configuration file for the example-zone.com zone. Configuration file which defines the Key and Signature Policy used for zone signing a key management. List of all zones managed by OpenDNSSEC
/etc/opendnssec/conf.xml /var/opendnssec/signconf/examplezone.com.xml /etc/opendnssec/kasp.xml
/etc/opendnssec/zonelist.xml
The following detailed steps discuss how to create/configure these key files: 1. Edit softhsm.conf (optional)
35
The file softhsm.conf lists all the slots in the virtualized HSM (softHSM) and can be edited via:
# vi /etc/softhsm.conf
The default location for this file can be overridden by using the environment variable SOFTHSM_CONF as such:
# export SOFTHSM_CONF=/etc/softhsm.conf
The format of this file with a single slot looks like the following:
# softHSM configuration file 0:/var/opendnssec/slot0.db
2. Edit conf.xml The overall configuration of OpenDNSSEC is defined by the contents of the file /etc/opendnssec/conf.xml (resides in /etc/opendnssec by default). It defines such information as paths and database connections, and also includes a list of configured security modules. As you will see below, most of the default values are ready to use. Those that were modified are shown below as bold underlined. Editing this file and its contents look like as follows:
# vi /etc/opendnssec/conf.xml <Configuration> <RepositoryList> <Repository name="softHSM"> <Module>/usr/local/lib/libsofthsm.so</Module> <TokenLabel>OpenDNSSEC</TokenLabel> <PIN>secure!</PIN> </Repository> </RepositoryList>
<Common> <Logging> <Syslog><Facility>local0</Facility></Syslog> </Logging>
<PolicyFile>
36
/etc/opendnssec/kasp.xml </PolicyFile>
<ZoneListFile> /etc/opendnssec/zonelist.xml </ZoneListFile> <! Contains the configuration for Inbound AXFR <ZoneFetchFile>/etc/opendnssec/zonefetch.xml</ZoneFetchFile> --> </Common> <Enforcer> <Datastore><SQLite>/var/opendnssec/kasp.db</SQLite></Datastore> <Interval>PT3600S</Interval> <KeygenInterval>PT3M</KeygenInterval> <BackupDelay>P3D</BackupDelay> </Enforcer> <Signer> <WorkingDirectory> /var/opendnssec/tmp </WorkingDirectory> <WorkerThreads>8</WorkerThreads> <SignerThreads>1</SignerThreads>
 <!-<NotifyCommand> my_nameserver_reload_command ex: /var/opendnssec/bin/install-zone.sh %zone %zonefile </NotifyCommand> --> </Signer> the name of the zone that was signed the filename of the signed zone
<Auditor>
37
<WorkingDirectory> /var/opendnssec/tmp </WorkingDirectory> </Auditor> </Configuration>
Please note that the <PIN> and <TokenLabel> tags are configured with the HSM repository PIN and label (which is defined above when initializing libsofthsm). To integrate with a hardware based HSM, the <Repository> tag should be configured accordingly. For example, the following shows the configuration needed for integrating with a hardware-based HSM (repository arbitrarily named myHSM):
<Repository name="myHSM"> <Module>/usr/hsm/lib/libCryptoki2_64.so</Module> <TokenLabel>MyHSM</TokenLabel> <PIN>securepin</PIN> <Capacity>1000</Capacity> <RequireBackup/> </Repository>
This <NotifyCommand> tag configures the OS level command to use to notify a DNS name server when a zone is signed. Please refer to Appendix E for an example specific to the BIND DNS name server. The XSD definition for this file can be found at: http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/conf/conf.rnc A full annotation for this configuration file can be found at: http://trac.opendnssec.org/wiki/Signer/Using/Configuration/conf. 3. Edit Zone Fetcher Configuration (optional) This configuration file (new for Beta version) enables OpenDNSSEC to also sign zones received from transfer (AXFR). If you configure a zone fetcher configuration, the Signer Engine will kick off the zone fetcher that will listen to NOTIFY messages from the parent and store AXFR messages on disk. The messages will be stored as the input file adapter plus an additional ".axfr"
38
extension. If the transfer was successful, the zone fetcher kicks the Signer Engine so that the incoming zone will be signed. The default for this file looks as follows:
<?xml version="1.0" encoding="UTF-8"?>

<ZoneFetch>   <NotifyListen><Port>53</Port></NotifyListen>
 <Default>   <TSIG> <Name>secret.example.com.</Name>
 <Algorithm>hmac-sha256</Algorithm>
 <Secret>sw0nMPCswVbes1tmQTm1pcMmpNRK+oGMYN+qKNR/BwQ=</Secret> </TSIG>
   <RequestTransfer> <IPv4>192.0.2.2</IPv4><Port>53</Port> </RequestTransfer> </Default> </ZoneFetch>
39
For more details of this configuration file, please see http://trac.opendnssec.org/wiki/Signer/Using/Configuration/zonefetch. The XSD definition for this file can be found at: http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/conf/zonefetch.rnc. 4. Edit Zone Signer Configuration (optional) If this file is not created manually then a default version will be generated at the time of zone signing (one per zone). Since we have pre-created our ZSK and KSK keys, we will want to refer to the locator IDs for these keys. To obtain the correct locator IDs for the ZSK and KSK keys which are created in Section 3.2.3, Initialization below or else generated by ods-enforcerd, you will need to use the following command:
# ods-hsmutil list Listing keys in all repositories. 2 keys found.
Repository ---------softHSM softHSM
ID -a2b2 a1b1
Type ---RSA/2048 RSA/1024
Next, you will want to create the zone signer configuration file by specifying the locator IDs from the command above (bold underlined) as follows:
# vi /var/opendnssec/signconf/example-zone.com.xml <?xml version="1.0" encoding="UTF-8"?>
<SignerConfiguration> <Zone name="example-zone.com"> <Signatures> <Resign>PT2H</Resign> <Refresh>P3D</Refresh> <Validity> <Default>P7D</Default> <Denial>P14D</Denial>
40
</Validity> <Jitter>PT12H</Jitter> <InceptionOffset>PT300S</InceptionOffset> </Signatures>
<Denial> <NSEC/> </Denial>
<Keys> <TTL>PT3600S</TTL> <Key> <Flags>257</Flags> <Algorithm>5</Algorithm> <Locator>a2b2</Locator> <KSK/> <Publish/> </Key> <Key> <Flags>256</Flags> <Algorithm>5</Algorithm> <Locator>a1b1</Locator> <ZSK/> <Publish/> </Key> </Keys> <SOA> <TTL>PT3600S</TTL> <Minimum>PT3600S</Minimum> <Serial>unixtime</Serial> </SOA> </Zone> </SignerConfiguration>
See http://trac.opendnssec.org/wiki/Signer/Policy for more details on the configuration parameters.
41
The XSD definition for this file can be found at http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/conf/signconf.rnc 5. Edit zonelist.xml (optional) This configuration file lists all of the zones needing to be signed. While this file is required to run OpenDNSSEC, the zones may either be added to this file manually or else via the ksmutil command (see below). This file may be edited as follows:
# vi /etc/opendnssec/zonelist.xml <?xml version="1.0" encoding="UTF-8"?>
<ZoneList> <Zone name="example-zone.com"> <Policy>default</Policy> <SignerConfiguration>/var/opendnssec/signconf/examplezone.com.xml</SignerConfiguration> <Adapters> <Input> <File>/var/opendnssec/unsigned/example-zone.com</File> </Input> <Output> <File>/var/opendnssec/signed/example-zone.com</File> </Output> </Adapters> </Zone> </ZoneList>
The XSD definition for this file can be found at http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/xml/zonelist.rnc For more details on this configuration file, see: http://trac.opendnssec.org/wiki/Signer/Using/Configuration/zonelist.
42
Interaction via the ods-ksmutil command to add/delete zones from OpenDNSSEC will cause an updated version of this file to be automatically written to the /etc/opendnssec/zonelist.xml file. Zones MUST be added to OpenDNSSEC for management either via the ods-ksmutil command (see Section 3.3.2.2, KASP Enforcer) or else via manually editing the zonelist.xml file accordingly (as shown in this section). 6. Edit kasp.xml This configuration file defines the policies used to sign zones. A default version will be created during installation and should be sufficient as is if using the softHSM repository. It may be edited as follows:
# vi /etc/opendnssec/kasp.xml <?xml version="1.0" encoding="UTF-8"?>
<KASP> <Policy name="default"> <Description>A default policy</Description> <Signatures> <Resign>PT2H</Resign> <Refresh>P3D</Refresh> <Validity> <Default>P7D</Default> <Denial>P14D</Denial> </Validity> <Jitter>PT12H</Jitter> <InceptionOffset>PT300S</InceptionOffset> </Signatures>
<Denial> <NSEC/> </Denial>
<Keys>  <TTL>PT3600S</TTL>
43
<RetireSafety>PT3600S</RetireSafety> <PublishSafety>PT3600S</PublishSafety> <Purge>P14D</Purge> 
 <KSK> <Algorithm length="2048">7</Algorithm> <Lifetime>P1Y</Lifetime> <Repository>softHSM</Repository> <Standby>1</Standby> <RFC5011/> </KSK>  <ZSK> <Algorithm length="1024">7</Algorithm> <Lifetime>P14D</Lifetime> <Repository>softHSM</Repository> <Standby>1</Standby> </ZSK> </Keys>
<Zone> <PropagationDelay>PT9999S</PropagationDelay> <SOA> <TTL>PT3600S</TTL> <Minimum>PT3600S</Minimum> <Serial>unixtime</Serial> </SOA> </Zone>
<Parent> <PropagationDelay>PT9999S</PropagationDelay> <DS> <TTL>PT3600S</TTL> </DS>
44
<SOA> <TTL>PT3600S</TTL> <Minimum>PT3600S</Minimum> </SOA> </Parent> </Policy> </KASP>
Note: If NSEC3 should be used instead of NSEC, then include the following within the <Denial> block above (instead of <NSEC/>):
<NSEC3> <OptOut/> <Resalt>P100D</Resalt> <Hash> <Algorithm>1</Algorithm> <Iterations>5</Iterations> <Salt>656d6d6b7469736169646f677461</Salt> </Hash> </NSEC3>
The XSD definition for this file can be found at http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/conf/kasp.rnc See http://trac.opendnssec.org/wiki/Signer/Policy for more information on the Key and Signing Policy Requirements. A full annotation for this configuration file can be found at http://trac.opendnssec.org/wiki/Signer/Using/Configuration/kasp.
3.2.3 Initialization The following table identifies the SQLite databases which are required by OpenDNSSEC: File Description
45
/var/opendnssec/kasp.db
SQLite database which stores the Key and Signature Policies used for signing zones as defined by the kasp.xml configuration file. SQLite database instance for storing HSM based configurations (this specific instance is used for softHSM) and as a storage repository/database for ZSK and KSK keys.
/var/opendnssec/slot0.db
The following detailed steps discuss how to perform all necessary initializations (including the creation of the SQLite databases above) required by OpenDNSSEC: 1. Initialize libsofthsm (optional) Note: Please skip to the following section if using a hardware based HSM. libsofthsm provides a cryptographic software token with a PKCS #11 interface which may be used with OpenDNSSEC if a hardware based HSM is not available. Initialize libsofthsm as follows:
# softhsm --init-token --slot 0 --label "OpenDNSSEC" The token has been initialized. --so-pin 'secure!' --pin 'secure!'
The command above will create a SQLite database with name and location as specified by Step 1 from Section 3.2.2, Configuration above. The database schema diagram for this database can be found at http://trac.opendnssec.org/browser/docs/DB.pdf. Please refer to Appendix D for more information on using SQLite. For a good tutorial on SQLite, refer to http://freshmeat.net/articles/sqlite-tutorial. 2. Setup KASP Database This step sets up the KASP SQLite database which stores the policies defined in the kasp.xml configuration. Initialize the KASP database as follows:
# cd /var/opendnssec # ods-ksmutil setup *WARNING* This will erase all data in the database; are you sure? [y/N] (enter y) SQLite database set to: /var/opendnssec/kasp.db File /var/opendnssec/kasp.db does not exist, nothing to backup Repository softHSM found No Maximum Capacity set. RequireBackup NOT set; please make sure that you know the potential problems of using keys which are not recoverable zonelist filename set to /etc/opendnssec/zonelist.xml. kasp filename set to /etc/opendnssec/kasp.xml.
46
Policy default found Warning: converting P1Y to seconds may not give what you expect
3. Create Initial ZSK and KSK Keys For Import (optional) Use OpenSSL to create the initial ZSK and KSK keys to import into softHSM:
# mkdir -p /etc/opendnssec/keys # chmod 700 /etc/opendnssec/keys # cd /etc/opendnssec/keys # openssl genrsa -out openssl_rsa_ZSK.pem 1024 Generating RSA private key, 1024 bit long modulus ...............++++++ .........................++++++ e is 65537 (0x10001) # openssl genrsa -out openssl_rsa_KSK.pem 2048 Generating RSA private key, 2048 bit long modulus .................................+++ ....+++ e is 65537 (0x10001) # openssl pkcs8 -topk8 -in openssl_rsa_ZSK.pem -inform pem -out openssl_pkcs8_ZSK.pem outform pem Enter Encryption Password: zsk-secure! Verifying - Enter Encryption Password: zsk-secure! # openssl pkcs8 -topk8 -in openssl_rsa_KSK.pem -inform pem -out openssl_pkcs8_KSK.pem outform pem Enter Encryption Password: ksk-secure! Verifying - Enter Encryption Password: ksk-secure!
Created files:
openssl_pkcs8_KSK.pem openssl_pkcs8_ZSK.pem openssl_rsa_KSK.pem openssl_rsa_ZSK.pem
Please note that the PKCS8 format is required for use with softHSM. Refer to the documentation for your hardware based HSM for details on key formats supported for HSM import. OpenDNSSEC will automatically generate initial ZSK and KSK keys within the configured HSM upon starting ods-enforcerd. 4. Import Key Pairs (optional) The created key pairs (if any) may be imported to libsofthsm so that they are available to the virtual HSM (softHSM). The softhsm command can be used as follows:
47
# softhsm 'secure!' # softhsm 'secure!'
--import --so-pin --import --so-pin
openssl_pkcs8_ZSK.pem --slot 0 --label OpenDNSSEC --id A1B1 --pin 'secure!' --file-pin 'zsk-secure!' --force openssl_pkcs8_KSK.pem --slot 0 --label OpenDNSSEC --id A2B2 --pin 'secure!' --file-pin 'ksk-secure!' force
If you are using a hardware based HSM, please refer to the product specific documentation for details on importing keys into the HSM. Please note that importing keys into an HSM is typically used only for debugging purposes. As an alternative to externally creating a key and importing, please note that the ods-hsmutil command may be used to directly generate a key for storage within a configured HSM as follows:
# ods-hsmutil generate repositoryName rsa 1024
5. Run ods-ksmutil update The Enforcer (ods-enforcerd) should generate a number of keys according to the policy and then should send a new zone configuration to the Signer Engine (ods-signerd). The Signer Engine should sign the zone (if there are zones to sign). The command to use:
# /usr/local/bin/ods-ksmutil setup
(Enter y followed by Enter Key)
Please note that ods-enforcerd MUST be running in order to use this command. 3.2.4 Processing Input/Output The following table identifies the OpenDNSSEC input/output folders/files for zone signing and log messages: File /var/opendnssec/unsigned/ Description Folder containing unsigned zone input files which require signing. Any name may be used for a zone file so long as the file syntax conforms to the standard BIND zone file format. Folder containing the output signed zones for any defined unsigned input zone files. System console logger used by all daemons and CLIs
/var/opendnssec/signed/ /var/log/messages
48
A sample unsigned input zone file can be created as follows:

# vi /var/opendnssec/unsigned/example-zone.com @ IN SOA IN NS localhost ajax dev-ng-core4 dnsuser ( 4 10800 3600 604800 86400 ) dev-ng-core4 A A MX odysseus A MX achilles A MX diomedes A MX dev-ng-core4 A MX menelaeus A MX agamemnon A MX 127.0.0.1 192.168.5.24 10 ajax 192.168.5.23 10 odysseus 192.168.5.20 10 achilles 192.168.5.22 10 diomedes 192.168.5.1 10 dev-ng-core4 192.168.5.28 10 menelaeus 192.168.5.21 10 agamemnon
After starting up the application (see Section 3.3, Running Application below) and choosing to sign the zone above, OpenDNSSEC will sign the zone and create a corresponding signed zone file (/var/opendnssec/signed/example-zone.com). Please see Appendix F for the contents of the corresponding signed zone file. 3.3 Running Application The following sub-sections describe how to start the various subcomponents of OpenDNSSEC. For more details on using any of these subcomponents, please refer to the OpenDNSSEC WIKI at http://trac.opendnssec.org/wiki/Signer/Using. Before continuing, make sure that all configuration and initialization steps from Section 3.2.2, Configuration and Section 3.2.3, Initialization have first been completed. 3.3.1 Daemons The following subsections discuss starting the three OpenDNSSEC daemon processes.
49
3.3.1.1 Signer Engine This is the component that performs all of the zone signing. Once started, it reads the zonelist.xml file and goes through all configured zones to sign them if needed. The following shows how to start the signer_engine:
# /usr/local/sbin/ods-signerd OpenDNSSEC signer engine version 1.0.0b2 Zone list updated: 0 removed, 1 added, 0 updated running as pid 6145
3.3.1.2 ods-enforcerd The ods-enforcerd daemon program maintains keys according to policy (using libksm) for the Signer and will create keys if needed by the KASP Enforcer sub-system. It also creates signer configuration XML-files in the /var/opendnssec/signconf folder that the signer uses when signing the zones.
# /usr/local/sbin/ods-enforcerd
3.3.2 Command Line Utilities The following subsections discuss using the available OpenDNSSEC command line utility programs. 3.3.2.1 Signer Engine The ods-signer command provides a command line interface to the signer engine. The command line options and an example can be found below:
# /usr/local/bin/ods-signer cmd> help Commands: zones sign <zone> show the currently known zones schedule zone for immediate (re-)signing --all schedules all zones clear <zone> delete the internal storage of the given zone name. All signatures will be regenerated on the next re-sign. queue flush update <zone> show the current task queue execute all scheduled tasks immediately check for changed zone conf xml file, if <zone> is not given all zones are checked stop stop the engine
50
restart verbosity <nr> cmd> zones
restart the engine set verbosity (notimpl)
name: test-zone.nl last config file read: 2009-09-17 11:53:12.764959 name: example-zone.com last config file read: 2009-09-17 10:53:12.561705
In short, the sign commands tell the signer to immediately queue up a zone for resigning. This is useful if you have made changes to your zone file and you immediately want it signed for further distribution to your name servers. Clear tells the signer to renew all signatures on the given zone. The queue command lists all the upcoming tasks currently in the queue. 3.3.2.2 KASP Enforcer The ksmutil command utility provides a number of commands for interacting with the KASP enforcer. Some of these include adding and removing zones to be handled by OpenDNSSEC and manual rollover of KSK and ZSK keys. The available command line options and an example of adding a zone to be managed by OpenDNSSEC can be found below:
# /usr/local/bin/ods-ksmutil usage: ods-ksmutil [-f config] command [options] setup update Import config into a database (deletes current contents)
Update database from config zone add --zone <zone> [--policy <policy>] [--signerconf <signerconf.xml>] [--input <input>] [--output <output>] zone delete --zone <zone> | --all zone list repository list policy export --policy [policy_name] | --all policy list key list [--verbose] --zone <zone> | --all key export --zone <zone> | --all [--keystate <state>] [--keytype <type>] [--ds] key import --cka_id <CKA_ID> --repository <repository> --zone <zone> --bits <size>
aka aka aka aka aka
-z -p -s -i -o
aka -z / -a
aka -z / -a aka aka aka aka aka aka aka aka -z / -a -e -t -d -k -r -z -b
51
--algorithm <algorithm> aka -g --keystate <state> aka -e --keytype <type> aka -t --time <time> aka -w [--retire <retire>] aka -y key rollover --zone zone [--keytype <type>] key rollover --policy policy [--keytype <type>] key purge --zone <zone> aka -z key purge --policy <policy> aka -p key generate --policy <policy> --interval <interval> backup done --repository <repository> aka -r backup list --repository <repository> aka -r rollover list [--zone <zone>]
If the zonelist.xml file is NOT manually edited before signing a zone, you must first use the ods-ksmutil zone add command to add the previously created zone file (example-zone.com) to be managed by OpenDNSSEC as follows:
# /usr/local/bin/ods-ksmutil zone add -z example-zone.com -p default -s /var/opendnssec/signconf/example-zone.com.xml i /var/opendnssec/unsigned/example-zone.com -o /var/opendnssec/signed/example-zone.com zonelist filename set to /etc/opendnssec/zonelist.xml. SQLite database set to: /var/opendnssec/kasp.db Imported zone: example-zone.com
3.3.2.3 HSMs The ods-hsmutil utility is designed to interact with your HSM (including softHSM). With it you can list all keys in a given repository, and you can also use it to create or delete keys. The command line options and some examples can be found below:
# ods-hsmutil usage: hsmutil [-c config] command [options] list [repository] generate <repository> rsa <keysize> remove <id> dnskey <id> <name> test <repository> # ods-hsmutil list Listing keys in all repositories. 10 keys found. Repository ID Type
52
---------softHSM softHSM softHSM softHSM softHSM softHSM softHSM softHSM softHSM softHSM
-f7fe51cdea5d1d507ba5f579d5769fc0 60d371ebdea20f251a8673d0f62589a6 407b20e1326e13019a3ef680682033c1 7d472301941fe93e561366be2d1d692b c98518b7ff91ed3e98d918dc7aad6044 f51b40d2b3a59b9c842806d6ac750a75 539e7df0af7740c22370fad0910bf7db abac2b518d3cf1821c1b543ca37c702b a2b2 a1b1
---RSA/1024 RSA/1024 RSA/2048 RSA/2048 RSA/1024 RSA/1024 RSA/2048 RSA/2048 RSA/2048 RSA/1024
# hsmutil dnskey f7fe51cdea5d1d507ba5f579d5769fc0 example-zone.com example-zone.com. 3600 IN DNSKEY 256 3 5 AwEAAbyrKAQYlkqBUoYcflB8VMy0gvNcvCRAP54Yc30eQGr6jRre04M5A9XrhhwKahvDaI449Driobfnh1v1W5jVX 9SPfx0mAG9J3oO1gZwDftEpsv728qSOSFIew5NIHnDFn9kAhDXo9zYUOws9vJ9RrfJYnSVkrlcaOCc/BCooEEb3 ;{id = 32203 (zsk), size = 1024b}
The softhsm utility, as discussed in Section 3.2.3, Initialization above, can be used to import keys into the storage repository for the softHSM virtual HSM. 3.3.2.4 Miscellaneous The following table describes some of the additional utilities that are provided with the OpenDNSSEC distribution: Utility ods-control Description A very useful command line utility which may be used as a wrapper to the ods-hsmutil, ods-ksmutil, and the ods-signer command line utilities including options to start/stop all daemon processes:
usage: ods-control ksm|hsm|signer|start|stop ...
softhsm-keyconv
Converting between BIND .private-key format and PKCS#8 key file format:
Usage: softhsm-keyconv [OPTIONS] Options: --topkcs8 Convert from BIND .private-key format to PKCS#8. Use with --in, --out, and --pin. --tobind -algorithm. --algorithm <alg> Specifies which DNSSEC algorithm to use in file. RSAMD5 DSA RSASHA1 Convert from PKCS#8 to BIND .private-key format. Use with --in, --pin, --name, --ttl, --ksk, and -
53
Utility
Description
RSASHA1-NSEC3-SHA1 DSA-NSEC3-SHA1 RSASHA256 RSASHA512 -h --help --in <path> --ksk --name <name> "example.com." --out <path> --pin <PIN> --ttl <ttl> Shows this help screen. Shows this help screen. The path to the input file. Set the flag to 257. Key Signing Key. Optional. The owner name. Do not forget the trailing dot, e.g. The path to the output file. To encrypt/decrypt PKCS#8 file. Optional. The TTL to use for the DNSKEY RR. Optional.
The following files will be created: K<name>+<alg id>+<key tag>.key K<name>+<alg id>+<key tag>.private E.g. Kexample.com.+007+05474.private Public key in RR format Private key in key format
ods-auditor
The Auditor (ods-auditor) part of the systems runs an audit of the zones in the system to see if the signer complies to what the policy mandates. It is issued automatically (unless disabled) after each resigning of a zone and will stop the signed zone file from being distributed. Any errors found by the ods-auditor will be logged to the configured syslog utility. This should be checked for debug if you have issues:
Usage: ods-auditor [options]
Specific options: -c, --conf [PATH_TO_CONF_FILE] /etc/opendnssec/conf.xml) -k, --kasp [PATH_TO_KASP_FILE] configuration file) -z, --zone [ZONE_NAME] Single zone to audit Path to KASP policy file (defaults to the path given in the Path to OpenDNSSEC configuration file (defaults to
54
Utility
Description
(defaults to audit all zones) -s [PATH_TO_SIGNED_FILE] this option may override --signed another. This is for use by If a single zone is specified, then the specified signed file with the signer. (defaults to the path given in the zone list) -d, --daemonize -v, --version Run the auditor as a daemon Display version information
Common options: -h, -?, --help Show this message
ods-kaspcheck
Check that the configuration files (conf.xml and kasp.xml) are semantically sane and contain no inconsistencies. It is advisable to use this tool to check your configuration before starting to use OpenDNSSEC:
Usage: ods-kaspcheck [options] Specific options: -c, --conf [PATH_TO_CONF_FILE] /etc/opendnssec/conf.xml) -k, --kasp [PATH_TO_KASP_FILE] configuration file) -v, --version Display version information Path to KASP policy file (defaults to the path given in the Path to OpenDNSSEC configuration file (defaults to
Common options: -h, -?, --help Show this message
softhsm
A support tool for libsofthsm and interacting with the softHSM virtual HSM:
Usage: softhsm [OPTIONS] Options: --show-slots --init-token Display all the available slots. Initialize the token at a given slot. Use with --slot, --label, --so-pin, and --pin. WARNING: Any content in token token will be erased.
55
Utility
Description
--import <path> Import a key pair from the given path. The file must be in PKCS#8-format. Use with --file-pin, --slot, --label, --id and --pin. --export <path> Export a key pair to the given path. The file will be written in PKCS#8-format. Use with --file-pin (will encrypt file), --slot, --id and --pin. --file-pin <PIN> --force -h --help --id <hex> Supply a PIN if the file is encrypted. Override some warnings. Shows this help screen. Shows this help screen. Defines the ID of the object. Hexadecimal characters. Use with --force if multiple key pairs may share the same ID. --label <text> --pin <PIN> --slot <number> --so-pin <PIN> Defines the label of the object or the token. The PIN for the normal user. The slot where the token is located. The PIN for the Security Officer (SO).
You also need to have a configuration file to specify path to the token databases (default location: /etc/softhsm.conf). The path to the configuration file can be changed by the SOFTHSM_CONF environment variable, e.g.: export SOFTHSM_CONF=/home/user/config.file
An example of a configuration file: 0:/home/user/my.db # Comments can be added # Format: # <slot number>:<path> 4:/home/user/token.database
56
3.4
Tips/Tricks/Gotchas OpenDNSSEC autogen.sh requires GNU AutoConf version 2.6.4 or greater and will not work otherwise GNU AutoConf is dependent on the GNU m4 package Install and run everything as the root user softHSM only supports the import of PKCS8 PEM formatted key files. See Section 3.2.3, Initialization above for details on using OpenSSL to create KSK and ZSK key pairs. Contact the opendnssec-user@lists.opendnssec.org email address for OpenDNSSEC questions/support needs. We have found the OpenDNSSEC team to be very responsive and timely with responses to requests via the email channel. You must use the ods-ksmutil setup (see Section 3.3.2.2, KASP Enforcer above) before you ever run any sub-system in OpenDNSSEC. The setup command deletes the current content of the kasp.db database or else creates it! The ods-control command line utility can be used to start/stop both the ods-enforcerd and ods-signerd daemons at once. The <NotifyCommand> tag in conf.xml can be used as the integration point for notifying a name server when a zone is signed by OpenDNSSEC. Beginning with the Beta 1 version of OpenDNSSEC, the MySQL RDBMS may be used as an alternative to SQLite. This is defined via the <MySQL> tag inside of the <Datastore> tagged block for the Enforcer component within the conf.xml configuration file. The <SQLite> tag should be used when using SQLite. The ldns-key2ds command from the ldns distribution (see Appendix C for a description of all supported commands) can be used to convert DNSKEY records for a KSK for a zone to DS records for publishing in a parent zone to establish a trust anchor or Secure Entry Point (SEP) with the child zone. Needed for KSK publishing with the Alpha versions of OpenDNSSEC. Needed to clear the CDPATH environment variable since OpenDNSSEC Makefiles with an embedded Unix cd command were failing:
# export CDPATH=
Use the GNU wget command to retrieve/download the installation packages from a Web server directly to the Linux system you are installing on. The ods-ksmutil command line program may be used to add/remove zones even if all daemon processes (ods-signerd & ods-enforcerd) are NOT running.
57
All date/time durations in the configuration files are specified as defined by ISO8601 (please see http://en.wikipedia.org/wiki/ISO_8601#Durations for details) To disable the Auditor component, comment out or remove the <Audit/> tag from the kasp.xml configuration file. This is useful as a workaround for avoiding Auditor related issues. When you make changes to a policy or add a new policy in kasp.xml you will need to use the ods-ksmutil update command to update the changes in the database.
ods-ksmutil
updates the zonelist.xml automatically when adding and removing zones.
Use the ods-signer update command to update a zone when changes to a zone or its signer configuration file are made. Make sure that the name of a zone inside of an unsigned zone file is consistent with the name of the zone file in order to avoid mysterious signing issues/errors. OpenDNSSEC has exhibited strange signing issues with zone files containing blank lines and trailing whitespace. If you encounter signing problems, this is one thing to check. In addition to manually removing such extraneous whitespace, the ldns-read-zone command (see Appendix C) may be used to flatten the zone file.
58
4. DNSSEC-Tools
The write-up on this tool is organized in the following way in order to expedite your understanding of how the software helps you with DNSSEC operations. First, youll be given a background on the tool and a summary of how it supports the most important aspects of DNSSEC. Following that, youll be given an idea of what it takes to install, configure, and use the tool in a bit more depth. 4.1 Overview This section is a compact write-up of the features youll find in this software. After a summary of the tool, youll find sections on the important aspects of DNSSEC as supported by this tool, including key-management features, zone signing, and Delegation-Signer (DS) data extraction. 4.1.1 Background The goal of the DNSSEC-Tools project (http://www.dnssec-tools.org) is to create a set of software tools, patches, applications, wrappers, extensions, and plug-ins that will help ease the deployment of DNSSEC related technologies. Several of the tools rely on the utilities that come with BIND. The following features are provided by the different category of tools which are available in the DNSSEC-Tools suite: Administer a zone with DNSSEC data Administer a DNSSEC supporting Domain Name Server o Authoritative Server o Recursive Server Use DNSSEC aware applications Develop DNSSEC aware applications
4.1.2 Technologies and Architecture The distribution is comprised of C and Perl source code implemented components and requires additional Perl libraries to be installed (see Section 4.2.1, Installation Steps) in addition to the BIND distribution. The architecture is comprised of the following components: Component
Zone Administration Tools
Description
Tools that are designed to help zone administrators sign and publishing DNSSEC-aware zones. Some of the tools, like donuts are helpful even with non DNSSEC-aware zones. (see http://www.dnssectools.org/wiki/index.php/Category:Zone_Administration_Tools) Tools that can be used to help maintain an authoritative Domain Name Server. They include signing tools, automatic signing tools, and notification tools.
Authoritative Server Tools
59
Component
Recursive Server Tools
Description
(see http://www.dnssec-tools.org/wiki/index.php/Category:Authoritative_Server_Tools) Tools designed to help administrate DNSSEC supporting recursive domain name servers. The majority of the maintenance related to DNSSEC on a recursive server is managing Trust Anchors (TAs). 'trustman', listed below, helps to manage the TAs on a server. (see http://www.dnssec-tools.org/wiki/index.php/Category:Recursive_Server_Tools)
Application Tools
Tools which are useful for writing DNSSEC aware applications. This generally means one of two desires for an application developer. It can be a desire for an application to parse the DNSSEC data itself and do something with it. Or it could be a desire to get DNSSEC specific error messages for the application's use, for instance, to give a user a more descriptive error message. (see http://www.dnssec-tools.org/wiki/index.php/Category:Application_Tools)
End User Tools
Application patches to enable DNSSEC validation using libval. These applications can check for validated DNS responses. The zones checked are configured according to the libval and libsres package. They also provide better DNSSSEC error handling and error descriptions for the user. As this category is not discussed any further in this document, here is a list of end user tools with patches available from the DNSSEC-Tools project to enable DNSSEC: Firefox Thunderbird ncftp Sendmail ssh proftpd Postfix lftp jabberd Libspf2 wget
(see http://www.dnssec-tools.org/wiki/index.php/Category:End_User_Tools) Error Checking Tools DNSSEC Error Checking Tools is list of all of our tools that can be used for checking DNSSEC errors. There is a large variety of tools here from checking local files, to checking on the wire data, to just plain doing command line validated lookups. Some of the them are also in other categories on this wiki. But if you are trying to find errors with your setup, this is a good category to look through to find helpful tools. (see http://www.dnssec-tools.org/wiki/index.php/Category:Error_Checking_Tools)
60
The following diagram illustrates these usages with some of the DNSSEC-Tools utilities shown in yellow boxes:
4.1.3 Key Generation Key generation is supported via the zonesigner tool by adding the -genkeys argument to generate new DNSSEC keys. This argument should ONLY be used first time this tool is used to sign a zone. This can be done as follows:
# zonesigner -genkeys -gends -zone zone-name zone-file output-file [ENTER]
In addition to signing the zone, this command will also generate several output files (see the next section for more details). Of most importance with regards to the key generation is the creation of keyset files containing public/private keys which were generated for the KSK and ZSK for the signed zone. The format for the names of these files is as follows: Output File
Kzone-name.+algid+keytag.private
Description
The private key file. This is stored in the directory specified by the configuration file. The zone-name is the name of the zone which was signed as specified by the zone command line option. The keytag is a unique identifier for this key. The algid is the numeric authentication algorithm identifier. The public key file. This is stored in the directory specified by the configuration file. The zone-name is the name of the zone which was signed as specified by the zone command line option. The keytag is a unique identifier for this key. The algid is the numeric authentication algorithm identifier.
Kzone-name.+algid+keytag.key
61
zone-name.krf
The keyrec file. This is used by zonesigner to maintain information about the keys used for the zone.
4.1.4 Zone Signing Zone signing is accomplished via the zonesigner command. When signing a zone for the first time, you will want to use the -genkeys command line option of zonesigner as discussed already (see previous Section 4.1.3, Key Generation) to generate the KSK and ZSK. For subsequent signings of the same zone, the genkeys command line option should be omitted as follows:
# zonesigner -gends -zone zone-name zone-file output-file [ENTER]
The following files are generated each time zonesigner is run to sign a zone: Output File
output-file.signed keyset-zone-name dsset-zone-name
Description
The signed zone file. The .signed is added by zonesigner. The keyset for the zone. This is stored in the directory specified by the configuration file and may have to be sent to the parent zone for signed delegation. The dsset for the zone. This is stored in the directory specified by the configuration file and may have to be sent to the parent zone for signed delegation. This file will ONLY be output when the gends command line option is used for signed delegation purposes.
Please refer to Appendix J for the steps involved in configuring and serving a signed zone for a name server. 4.1.5 Key Rollovers The DNSSEC-Tools utilities do not currently handle KSK rollover. For ZSK rollover, DNSSEC-Tools uses the Pre-Publish Rollover Scheme where multiple ZSK keys are simultaneously maintained for zone. These ZSKs are labeled the Current ZSK, the Published ZSK, and the New ZSK. The Current and Published ZSKs are used to sign the zone, while the New ZSK will be used in the future. When the Current ZSK expires, the following steps will be taken: The Current ZSK becomes obsolete The Current ZSK becomes obsolete The Published ZSK becomes the Current ZSK The New ZSK becomes the Published ZSK
62
A new New ZSK is generated
Before you can start with key rollovers, you must first make sure that you use the zonesigner command to generate ZSK keys and sign the target zones. The following steps show how to get started with automatic ZSK key rollover: Create The Rollrec File A rollrec file gives information to the DNSSEC-Tools rollover daemon about the zones it is managing. The rollinit command may be used to create a rollrec file for a number of zones at once, though the zones entries will all have the same type of data. The following command will generate a rollrec file for two zones:
# rollinit -o examples.rrf example1.com example2.com [ENTER] # cat examples.rrf roll "example1.com" zonefile "example1.com.signed" keyrec "example1.com.krf" curphase "0" maxttl "0" display "1" phasestart "new" roll "example2.com" zonefile "example2.com.signed" keyrec "example2.com.krf" curphase "0" maxttl "0" display "1" phasestart "new"
Run the DNSSEC-Tools Rollover Daemon The following command will manually start rollerd. It is assumed that rollerd is started in the same directory that holds the rollrec file, keyrec files, zone files, and authentication keys created in previous steps. rollerd should be run as root:
# rollerd -dir . -logfile log-rollerd -loglevel info -rrf examples.rrf
Controlling the Rollover Process The rollerd daemon can be controlled using the rollctl command. This command has a number of options that will modify rollerd's operating parameters, such as the zones being managed (by changing the rollrec file), log level, and log file. It may also be used to start or stop a GUI interface to rollerd and to halt rollerd's execution. The following rollctl command retrieves status on each zone managed by rollerd. The zone name, roll/ skip status, and rollover phase are displayed for each zone:
# rollctl -zonestatus example1.com roll 0 example2.com roll 3
The following rollctl command sets rollerd's logging status to only record errors and fatal problems:
# rollctl -loglevel error
63
rollerd log level set to error
The following rollctl command changes the rollrec file in use by rollerd:
# rollctl -rollrec new.rrf rollerd now using rollrec file new.rrf
The following rollctl command causes rollerd to stop execution:

# rollctl -halt rollerd shutting down
4.1.6 Publishing of DS Data to Parent Zone Child Zone Activity The following steps are required by a child zone for creating a signed delegation: Securely Transfer the Keyset to the Parent
If any of the zone's KSKs have changed since the last time this file was sent to the parent, then the keyset must also be transferred to the parent in a secure fashion. If none of the zone's KSKs have changed, this step may be skipped.
Wait for the Parent to Publish the DS Record

This may be found by using the dig command to retrieve the zone's DS record. The aa flag in the result must be set and the ANSWER section must not be empty:
# dig @server-IP-address DS zone-name [ENTER] ; <<>> DiG 9.3.0 <<>> ... ... ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ... ;;ANSWER SECTION: zone-name 600 IN DS 12960 5 1 5B10E822B935BC64DBEC2872A553EAA290443064 ; This value must match the data in your dsset-zone-name file.
Parent Zone Activity The following steps are required by a parent zone for creating a signed delegation: Ensure that the Child Keysets were Received Over a Secure Channel Ensure that Each Received Keyset is for a Delegated Zone
The owner name for the DNSKEY record in the received keyset must correspond to a valid delegation:
# grep DNSKEY keyset-child-zone-file [ENTER] child-zone-name. 3600 IN DNSKEY 256 3 5 ( ... ); key id = keytag
child-zone-name must exist in the parent-zone-file as a valid delegation:

# grep NS parent-zone-file [ENTER] ... child-zone-name NS server A ... ...
Re-sign the Parent Zone

# zonesigner -gends -zone parent-zone-name parent-zone-file parent-output-file [ENTER]
64
Reload the Zone

The rndc command will reload the name server configuration files and zone contents. The name server process is assumed to be already running:
# rndc reload zone-name [ENTER]
Please note that the secure transfer of the childs keyset to a parent registry is a manual process which occurs out of band. This transfer should be secured as necessary to ensure that no key information is divulged or compromised. 4.2 Setup DNSSEC-Tools and all prerequisite software installed on a RHEL 5.3 system. The following subsections discuss the installation and configuration details which are required before running any of the tools. 4.2.1 Installation Steps Install CPAN Perl modules To install these needed modules, run the following commands as root:
# perl -MCPAN -e "install 'Date::Parse'" # perl -MCPAN -e "install 'Net::DNS'" # perl -MCPAN -e "install 'Net::DNS::SEC'"
Build and Install DNSSEC-Tools To compile the DNSSEC-Tools package from source, you'll need to perform the following steps:
# wget http://www.dnssec-tools.org/download/dnssec-tools-1.5.tar.gz # tar xzf dnssec-tools-*.tar.gz # cd dnssec-tools-* # ./configure --------------------------------------------------------DNSSEC-Tool Validator configuration summary: ---------------------------------------------------------
system configuration directory : /usr/local/etc Validator configuration file: /usr/local/etc/dnssec-tools/dnsval.conf NSEC3 support DLV support IPv6 support : No : No : No
65
Thread support Developer flags libval resolver configuration libval root hints
: Yes : : /usr/local/etc/dnssec-tools/resolv.conf : /usr/local/etc/dnssec-tools/root.hints
--------------------------------------------------------# make # make install
Set Runtime Library Path To modify your run-time library loading path you may need to modify your existing system environment to ensure it contains the /usr/local/lib directory, assuming you used a default install prefix when you ran configure:
# /sbin/ldconfig /usr/local/lib
4.2.2 Configuration Check for Randomness Key generation and zone signing require random data to create strong cryptographic material. The zonesigner command defaults to using random data from /dev/random. Use this test to verify that /dev/random will provide data when requested:
# dd if=/dev/random bs=2 count=10 | od x 10+0 records in 10+0 records out 20 bytes (20 B) copied, 3.8e-05 seconds, 526 kB/s 0000000 9a32 9a0c 08a7 c3be c4b3 5b9c 23ba 5d67 0000020 d083 77db 0000024
The above command checks if /dev/random is able to provide data when queried; it does not check to see that the data provided is truly random. If this command provides data immediately, /dev/random will provide the data you need. If it hangs, then zonesigner won't be able to retrieve data, random or otherwise, from /dev/random. If this check for randomness fails, pseudorandom numbers can be used instead. However, using pseudorandom numbers negatively affects the quality of the cryptographic material to a significant degree. A more appropriate measure would be to run zonesigner on a different system that has /dev/random and the ability to generate good random data. Create the DNSSEC-Tools Configuration File
66
The DNSSEC-Tools configuration file contains many settings for customizing the DNSSEC-Tools suite of programs. The file name and default location is /usr/local/etc/dnssec-tools/dnssec-tools.conf. To create a new DNSSEC-Tools configuration file, use the following command which will prompt for entry of different configuration parameters (this assumes that no dnssec-tools.conf configuration file exits). To use a default configuration for a parameter, simply press the enter key at the prompt:
# dtinitconf
If there exists a /usr/local/etc/dnssec-tools/dnssec-tools.conf, you must rename it before running the above command. Otherwise, you will have to run the following command to overwrite the existing file:
# dtinitconf -overwrite
Command options will allow for automatic customization of the file. It is a plain text file, so any normal text editor (e.g., vi or emacs) may be used to modify the configuration file. The default configuration file looks like the following:
# # DNSSEC-Tools Configuration # # # # # # This was automatically generated by dtinitconf on Mon Oct 26 06:32:16 2009 (GMT). This file contains configuration information for DNSSEC-Tools.
# # Settings for DNSSEC-Tools administration. # admin-email
# # Paths to needed programs. # keygen /usr/local/sbin/dnssec-keygen These may need adjusting for individual hosts.
67
viewimage zonecheck zonesign zonesigner
/usr/X11R6/bin/xview /usr/local/sbin/named-checkzone /usr/local/sbin/dnssec-signzone /usr/bin/zonesigner
# # Key-related values. # algorithm ksklen zsklen random NSEC3RSASHA1 2048 1024 /dev/urandom
# # NSEC3 functionality # usensec3 nsec3iter nsec3salt nsec3optout yes 100 random:64 no
# # Settings for dnssec-signzone. # endtime +2592000 # RRSIGs good for thirty days.
# # Life-times for keys. # between rollovers. # # Sample values: # # # # # 3600 86400 604800 2592000 15768000 hour day week 30-day month half-year These defaults indicate how long a key has The values are measured in seconds.
68
# # ksklife zsklife
31536000
year
15552000 604800
# # Settings for zonesigner. # archivedir entropy_msg savekeys zskcount 1 1 1
# # Settings for rollerd. # roll_logfile roll_loglevel roll_sleeptime /usr/local/etc/dnssec-tools/log-rollerd info 3600
# # Settings for trustman # tacontact tasmtpserver
# # GUI-usage flag. # usegui 0
Make Sure That the BIND Name Server is Up and Running If the following command does not return any output, then BIND is NOT running:
# ps -edf | grep named | grep -v grep
Secure Your Files
69
o The .private portions of key files must only be readable or writable by the root user. o The DNSSEC-Tools files must only be writable by the root user. 4.3 Running Application The following sub-sections describe how to run the various DNSSEC-Tools components. For more details on using any of these components, please refer to the DNSSEC-Tools WIKI at http://www.dnssec-tools.org/wiki/index.php/DNSSEC-Tools_Components. 4.3.1 Daemons The following identifies and categorizes all daemon based components along with a description of each and a URL to the WIKI page for the respective component: Tool
rollerd
Tool Category
Key Rollover
Description
Automatic key rollover. A daemon which automatically (or manually) steps through updating Zone Signing and Key Signing Keys for a set of zones. It can be controlled while running with rollctl. A continuously running daemon that runs donuts on operational zone files on a regular basis. If the output of a call to donuts changes from a previous run, the administrator of the zone is emailed with an error summary. For signed zones, donutsd can automatically detect when parent child relationships break, zone signatures are nearing their expiration date, etc. A daemon which archives old KSK and ZSK keys. Keys are considered old if they are obsolete and are marked as either kskobs or zskobs. Archived keys are prefixed with the seconds-since-epoch as a means of distinguishing a zone's keys that have the same five digit number
WIKI Page URL

http://www.dnssectools.org/wiki/index.php/Rollerd
donutsd
Zone Troubleshooting
http://www.dnssectools.org/wiki/index.php/Donutsd
keyarch
DNSSEC-Tools Maintenance
http://www.dnssectools.org/docs/tooldescription/keyarch.html
4.3.2 Command Line Utilities The following identifies and categorizes all command line based components along with a description of each and a URL to the WIKI page for the respective component: Tool Tool Category Description WIKI Page URL
70
Tool
zonesigner
Tool Category
Zone Signing
Description
A DNS Zone File signing script that makes the process of signing DNS zones incredibly easy. With a single call to the script you can perform all the needed operations of zone signing in one call Generates a keyrec file from KSK and/or ZSK files. It generates new KSK and ZSK keys if needed. Check a DNSSEC-Tools keyrec file for problems and inconsistencies List the keyrecs in a DNSSEC-Tools keyrec file Checks a set of keyrec files to determine if the zone keyrecs are valid or expired. The type of zones displayed depends on the options chosen; if no options are given the expired zones will be listed. Fixes DNSSEC-Tools keyrec files whose encryption key files have been moved Clean a DNSSEC-Tools keyrec files of old data Provides the capability for easy management of signing sets in a GUI. A signing set contains zero or more names of key keyrec. These sets are used by other DNSSEC-Tools utilities for signing zones. The signing sets found in the given keyrec file are displayed in a new window. New signing sets may be created and existing signing sets may be modified or deleted (*nix systems require X-Window for GUI). A checking tool for analyzing DNS zone files. It reports any errors it finds, either as text output if run as a command line application or in a GUI window if an error browser interface is desired (*nix systems require X-Window for GUI).
WIKI Page URL

http://www.dnssectools.org/wiki/index.php/Zonesigner
genkrf
Zone Signing
http://www.dnssectools.org/docs/tooldescription/genkrf.html http://www.dnssectools.org/docs/tooldescription/krfcheck.html http://www.dnssectools.org/docs/tooldescription/lskrf.html http://www.dnssectools.org/docs/tooldescription/expchk.html
krfcheck
Zone Signing
lskrf
Zone Signing
expchk
Zone Signing
fixkrf
Zone Signing
http://www.dnssectools.org/docs/tooldescription/fixkrf.html http://www.dnssectools.org/docs/tooldescription/cleankrf.html http://www.dnssectools.org/docs/tooldescription/signset-editor.html
cleankrf
Zone Signing
signseteditor
Zone Signing
donuts
http://www.dnssectools.org/wiki/index.php/Donuts
71
Tool
Tool Category
Description
It is extremely flexible and local rule sets and configuration can tailor its output to define local policies.
WIKI Page URL
mapper
Graphically display the contents of your zone (for *nix systems, requires XWindow). Visually trace DNS packets being sent on the network. A popular system administration tool that collects output on a regular basis from syslog messages and summarizes them so they're easier to scan through. The DNSSEC-Tools package contains a patch to logwatch that adds support for summarizing DNSSEC related output from the bind nameserver. Send commands to the daemon rollerd without restarting it. Creates new rollrec entries for a rollrec file. This rollrec file will be used by rollerd to manage key rollover for the named domains Check a DNSSEC-Tools rollrec file for problems and inconsistencies Modifies entries in a DNSSEC-Tools rollrec file Provides the capability for easy GUIbased management of rollrec files (for *nix systems, requires X-Window) Lists the contents of the specified rollrec files DNSSEC-Tools utility to write messages to the DNSSEC rollover log file Detects key changes in trust anchors (TAs), it can update TAs and it can run as
http://www.dnssectools.org/wiki/index.php/Mapper http://www.dnssectools.org/wiki/index.php/Dnspktflow http://www.dnssectools.org/wiki/index.php/Logwatch
dnspktflow
Zone Troubleshooting Zone Troubleshooting
logwatch
rollctl
Key Rollover Key Rollover
http://www.dnssectools.org/wiki/index.php/Rollctl http://www.dnssectools.org/docs/tooldescription/rollinit.html http://www.dnssectools.org/docs/tooldescription/rollchk.html http://www.dnssectools.org/docs/tooldescription/rollset.html http://www.dnssectools.org/docs/tooldescription/rollrec-editor.html http://www.dnssectools.org/docs/tooldescription/lsroll.html http://www.dnssectools.org/docs/tooldescription/rolllog.html http://www.dnssec-
rollinit
rollchk
Key Rollover
rollset
Key Rollover
rollreceditor
Key Rollover
lsroll
Key Rollover
rolllog
Key Rollover
trustman
Trust Anchor
72
Tool
getdnskeys
Tool Category
Maintenance Trust Anchor Maintenance
Description
a daemon. Manages lists of DNSKEYs from DNS zones. It may be used to retrieve and compare DNSKEYs. The output from getdnskeys may be included (directly or indirectly) in a named.conf file Create a DS record from DNSKEYs for a particular DNS domain. It does this by converting DNSKEYs to DS records using the specified hashing algorithm. The results can then be passed to upstream DNSSEC supporting parents or to DLV registries Check the validity of the trust anchors in a named.conf file Performs validated domain lookups. It is similar to dig but can provide in depth output on the validation steps taken during a lookup. Command-line test program for the val_getaddrinfo() function Command-line test program for the val_gethostbyname() (and related) functions Command-line test program for the val_getnameinfo() function Command-line test program for the val_res_query() function Command-line test program for the val_get_rrset() function Command-line program for checking validity of the validator configuration files Generate a graphical output of validation status values encountered by the validator library
WIKI Page URL

tools.org/wiki/index.php/Trustman http://www.dnssectools.org/docs/tooldescription/getdnskeys.html
getds
Trust Anchor Maintenance
http://www.dnssectools.org/docs/tooldescription/getds.html
tachk
Trust Anchor Maintenance Validator Troubleshooting
http://www.dnssectools.org/docs/tooldescription/tachk.html http://www.dnssectools.org/wiki/index.php/Validate
validate
getaddr
Validator Troubleshooting Validator Troubleshooting Validator Troubleshooting Validator Troubleshooting Validator Troubleshooting Validator Troubleshooting Validator Troubleshooting
http://www.dnssectools.org/docs/tooldescription/getaddr.html http://www.dnssectools.org/docs/tooldescription/gethost.html http://www.dnssectools.org/docs/tooldescription/getname.html http://www.dnssectools.org/docs/tooldescription/getquery.html http://www.dnssectools.org/docs/tooldescription/getrrset.html http://www.dnssectools.org/docs/tooldescription/libval_check_conf.html http://www.dnssectools.org/docs/tool-
gethost
getname
getquery
getrrset
libval_check_ conf
drawvalmap
73
Tool
maketestzone
Tool Category
Validator Troubleshooting DNSSEC-Tools Maintenance
Description
Generates a test DNSSEC zone
WIKI Page URL

description/drawvalmap.html http://www.dnssectools.org/docs/tooldescription/maketestzone.html http://www.dnssectools.org/docs/tooldescription/dtinitconf.html
dtinitconf
Initializes the DNSSEC-Tools configuration file. By default, the actual configuration file will be created, though the created file can be specified by the user. Existing files, whether the default or one specified by the user, will not be overwritten unless specifically directed by the user Displays defaults defined for DNSSECTools Displays the key/value pairs of a DNSSEC-Tools configuration file. If a configuration file isn't specified, the system configuration file will be displayed Checks DNSSEC-Tools data files to determine if the entries are valid Checks a DNSSEC-Tools configuration file to determine if the entries are valid. If a configuration file isn't specified, the system configuration file will be verified Net::DNS::SEC::Tools::timetrans Convert an integer seconds count into text units
dtdefs
DNSSEC-Tools Maintenance DNSSEC-Tools Maintenance
http://www.dnssectools.org/docs/tooldescription/dtdefs.html http://www.dnssectools.org/docs/tooldescription/dtconf.html http://www.dnssectools.org/docs/tooldescription/dtck.html http://www.dnssectools.org/docs/tooldescription/dtconfchk.html http://www.dnssectools.org/docs/tooldescription/timetrans.html
dtconf
dtck
DNSSEC-Tools Maintenance DNSSEC-Tools Maintenance
dtconfchk
timetrans
DNSSEC-Tools Maintenance
4.4
Tips/Tricks/Gotchas Install and run everything as the root user See Appendix K for the steps required to migrate from BIND To DNSSEC-Tools for signing a zone See Appendix J for the steps involved for configuring and serving a signed zone from a name server
74
5. DNSSEC Zone Key Tool (ZKT)

The write-up on this tool is organized in the following way in order to expedite your understanding of how the software helps you with DNSSEC operations. First, youll be given a background on the tool and a summary of how it supports the most important aspects of DNSSEC. Following that, youll be given an idea of what it takes to install, configure, and use the tool in a bit more depth. 5.1 Overview This section is a compact write-up of the features youll find in this software. After a summary of the tool, youll find sections on the important aspects of DNSSEC as supported by this tool, including key-management features, zone signing, and Delegation-Signer (DS) data extraction. 5.1.1 Background DNSSEC Zone Key Tool (ZKT - http://www.hznet.de/dns/zkt/) is a tool to manage keys and signatures for DNSSEC-zones. The Zone Key Tool consists of two commands:
dnssec-zkt
to create and list DNSSEC zone keys and to sign a zone and manage the lifetime of the zone signing keys
dnssec-signer
Both commands are simple wrapper commands around the dnssec-keygen(8) and dnssecsignzone(8) commands provided by BIND. They are designed to solve some problems in maintaining a few DNSSEC aware zones. ZKT provides the following features: Full automatic ZSK rollover (pre-publish key algorithm) Full automatic re-signing of the zone Parses secure zones out of named.conf C based wrapper around the BIND tools Automatic serial number incrementation. Supports sequential serial number and YYYYmmDDxx format Best for small to medium domain hosting
75
5.1.2 Technologies & Architecture DNSSEC Zone Key Tool is a toolkit written in C for DNSSEC zone and key management. It supports automatic zone resigning and KSK and ZSK rollover according to RFC4641 (http://www.ietf.org/rfc/rfc4641.txt) and RFC5011 (http://www.ietf.org/rfc/rfc5011.txt). 5.1.3 Key Generation Key generation can be accomplished via the dnssec-zkt command. The following are examples which create a KSK and ZSK: Create a folder for the zone to generate keys for and then change folders to the new dir:
# mkdir p /var/zkt/zones/example.com. # cd /var/zkt/zones/example.com.
KSK
# /usr/local/bin/dnssec-zkt --ksk --create example.com.
ZSK
# /usr/local/bin/dnssec-zkt --zsk --create example.com.
Output files: Output File

Kexample.com.+005+15330.published Kexample.com.+005+15330.key Kexample.com.+005+40517.published Kexample.com.+005+40517.key
Description
The private portion of the generated KSK The DNSKEY RR generated from the public key for the KSK The private portion of the generated ZSK The DNSKEY RR generated from the public key for the ZSK
The following format is used for constructing the base name for each file in the table above: K<zone-name>+ <algorithm>+<key-tag> View Generated Keys:
# /usr/local/bin/dnssec-zkt Keyname Tag Typ Sta Algorit Generation Time example.com. 15330 KSK sta RSASHA1 Nov 23 2009 00:42:11 example.com. 40517 ZSK pub RSASHA1 Nov 23 2009 00:45:14
Contents of the private key file for the generated KSK:
76
# cat Kexample.com.+005+15330.published Private-key-format: v1.2 Algorithm: 5 (RSASHA1) Modulus: C5OoG6+iRh8qbAKFruji3423lJpdCxXC8LyqPq4eiMzuqgLNc+YBaVtrjMoY7kRjjAt9bna5NN9I2sfEfq3cru7+B XSeRDFHZv20lb32ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/splO4gAHdPrF0tdU1wxzVxsQpbNA/9S6IRfvHUDwOe DL6e3mdTVdgXfz9kl1NDyhOOsaThNE0oMa/AN5yw== PublicExponent: AQAAAAE= PrivateExponent: CUGLy1kXUpVIBrZE1QlzRAjGUiVosf9cKO8vWVlNxA7BHcfjhzGBsgb4vLF9wkQy66wgd15o5tIWsWChR3TLlq3z2 8PReQXE8BmeDITWZSh7R4l2hZ0JFLct7DSXFcEB4dRxQXDd4kUJDwPNCZsYz2ZQwEIB939tQ9EZO9U2J8Y7EscwGE iugfYXnCrjyHQh3+eseCyH19O27wZL+9bigXV/IQ== Prime1: A4rvMYw1smrHWT4aR8j0XfsltIRmeeqs5a7R8lcFnyfWQ9xag+cWj6E40ASVza5exxpfiqaoKIIYeEXd2OtjoXJId y5wni4eD/T0KTbPFFkXvw== Prime2: A0SM2aaDk9WcBuHYU/aA3QPGofp83M2c1PFAu9OgvK0ubDOFy1fWwwywDV20nyHQW9Bs8vsRmomMG2DVr4ZrrAxao 0vETuORvEA4a/bodzBA9Q== Exponent1: AR9D1w3M8P12mOPtfKR2yGyAvYKDczKPKTjTX9vruzay4hkVOfelPKfUssEtNClYXwX8pCM1EXanhWkAImqnlK/WD mYZr7WT/ITgcXtMzDwf/Q== Exponent2: AxegbKHZGMZBo7G5DUhMoGfkHJG5660jFYqdoCHTtPXpIKhB9T582r1zimepWDaKOFMHyug2bKVFBSzhFPdsjsDTW gZAvPV19Y/HZ1hGEmY+yQ== Coefficient: Avph4BbhbTdTcQc8sG4ltniEsoUbsLNupjUzZynL8eFYMiDhaneip5HBaj39FeOn2yc6fe/Vbb0su46X1SFdDvMFF WUaOcmSNdkCVeIRqWdm0A==
Contents of the DNSKEY file for the generated KSK:

# cat Kexample.com.+005+15330.key ;% ;% generationtime=20091123054211 lifetime=365d
example.com. IN DNSKEY 257 3 5 BQEAAAABC5OoG6+iRh8qbAKFruji3423lJpdCxXC8LyqPq4eiMzuqgLN c+YBaVtrjMoY7kRjjAt9bna5NN9I2sfEfq3cru7+BXSeRDFHZv20lb32 ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/splO4gAHdPrF0tdU1wxzVxsQ pbNA/9S6IRfvHUDwOeDL6e3mdTVdgXfz9kl1NDyhOOsaThNE0oMa/AN5 yw==
If these commands are not used to pre-generate keys, then both the ZSK and KSK will automatically be generated for you at the time of zone signing. Please note that each of these commands reference the ZKT dnssec.conf configuration file. Please see Sections 5.2.2, Initialization and 5.2.3, Configuration for the creation and configuration details for the dnssec.conf configuration file before using these commands.
77
5.1.4 Zone Signing It is assumed that the initialization and configuration steps in Section 5.2.2, Initialization and Section 5.2.3, Configuration below have been performed prior to zone signing. Here are the general steps for signing a zone named example.com. which resides in a directory folder of the same name (note that ZKT requires the actual zone file to be named consistent with what is configured in the dnssec.conf configuration file which by default is named zone.db). Change to the zone specific directory folder (assumed to already exist):
# cd /var/zkt/zones/example.com.
Look at the zone to be signed (for illustrative purposes only):

# cat zone.db $ORIGIN example.com. $TTL 1h example.com. IN 1d 4w 1h ) example.com. example.com. example.com. @ @ example.com. ns www wwwtest mail ; ;--------------------------------------------;include the DNSKEY records $INCLUDE dnskey.db NS NS MX MX MX A A ns ns.somewhere.com. 10 mail.example.com. 20 mail2.example.com. 50 mail3 10.0.0.1 10.0.0.2 SOA ns.example.com. username.example.com. ( 1d 2009113005
CNAME ns CNAME www A 10.0.0.3
Sign the zone:

# /usr/local/bin/dnssec-signer -f -v -v -o example.com. parsing zone "example.com." in dir "." Check RFC5011 status
78
->not a rfc5011 zone, looking for a regular ksk rollover Check KSK status No active KSK found: generate new one Check ZSK status No active ZSK found: generate new one Re-signing necessary: Option -f Writing key file "./dnskey.db" Incrementing serial number in file "./zone.db" Signing zone "example.com." Run cmd "cd .; /usr/local/sbin/dnssec-signzone zone.db K*.private 2>&1" Cmd dnssec-signzone return: "zone.db.signed" Signing completed after 1s. -g -o example.com. -e +864000
View Output files: Output File

keyset-example.com. Kexample.com.+005+65237.private Kexample.com.+005+65237.key
Description
Contains the DNSKEY RRs for all KSKs Contains the private portion of the generated ZSK Contains the DNSKEY RR generated from the public key for the ZSK Contains the private portion of the generated KSK Contains the DNSKEY RR generated from the public key for the KSK Contains the DS RRs associated with the DNSKEY RRs for all KSKs Contains the DNSKEY RRs for all KSKs and ZSKs The created signed version of the input zone (zone.db)
Kexample.com.+005+00126.private Kexample.com.+005+00126.key
dsset-example.com.
dnskey.db zone.db.signed
Examine the signed zone (for illustrative purposes only):

# cat zone.db.signed ; File written on Sun Nov 29 22:12:10 2009 ; dnssec_signzone version 9.6.1-P1 example.com. 3600 IN SOA ns.example.com. username.example.com. ( 2009113005 ; serial
79
86400 86400 2419200 3600 ) 3600 RRSIG
; refresh (1 day) ; retry (1 day) ; expire (4 weeks) ; minimum (1 hour)
SOA 5 2 3600 20091210021210 ( 20091130021210 65237 example.com. q1kfn4WCwuDZvxEkv+/mOTHA0dzbf6tGLEG+ uuvpC/QGMDF7ArOK/8jZAEZIP+9VGWAy7WUV RDeYLCbqTCmilg== )
3600 3600 3600
NS NS RRSIG
ns.example.com. ns.somewhere.com. NS 5 2 3600 20091210021210 ( 20091130021210 65237 example.com. ozy6OJ9grCW2i24PON+VrSymU/iB+ijDJeZ8 VFHukQIfwGKDlFnbPJZg9Tn+kQdz6I2CKTcC S6Llw2KXhIW3vg== )
3600 3600
A RRSIG
10.0.0.1 A 5 2 3600 20091210021210 ( 20091130021210 65237 example.com. Xksdd8eMIXMZCM62ulay+xOF2slRVGCt78BB 0YPvY1LKWrXcokpexi3ZSXqeWODkjcOSgZI5 YqozIkMQK2vVag== )
3600 3600 3600 3600
MX MX MX RRSIG
10 mail.example.com. 20 mail2.example.com. 50 mail3.example.com. MX 5 2 3600 20091210021210 ( 20091130021210 65237 example.com. UR3h6vMlQmNWngRV3dv7TTE0AU8AOOMBg+Df BbfBzbkIcdvpsRnfCRZCj4vaTwTULobnDiQ/ EdmyFqR9jIr6rw== )
3600 3600
NSEC RRSIG
mail.example.com. A NS SOA MX RRSIG NSEC DNSKEY NSEC 5 2 3600 20091210021210 ( 20091130021210 65237 example.com. nz6h14SK6Bxm04Tb6O0ZbbRgccgAdpTTyrzM jnw4eAGA5D+Inf4I6AtDFW1C6tyd1h9w4WmT
80
MYaoKD0YNe+Enw== ) 14400 DNSKEY 256 3 5 ( BQEAAAABuxExqi0ymhk3HkIXTU/mzEvm6Ovb CZIcOxv7HpTH8Ue1FF/9g0xKj+c0z92fZE9v EAZ0feN8HashNGO+W8tG9Q== ) ; key id = 65237 14400 DNSKEY 256 3 5 ( BQEAAAAByojmMaY1M1bD9f/ql12VJ82XRnco tUNbMBDkFHSUK9P6VDovlOT9RLJjqQiRAnzC i585Kag8HW3GydFOV3o8AQ== ) ; key id = 40517 14400 DNSKEY 257 3 5 ( BQEAAAABC5OoG6+iRh8qbAKFruji3423lJpd CxXC8LyqPq4eiMzuqgLNc+YBaVtrjMoY7kRj jAt9bna5NN9I2sfEfq3cru7+BXSeRDFHZv20 lb32ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/ splO4gAHdPrF0tdU1wxzVxsQpbNA/9S6IRfv HUDwOeDL6e3mdTVdgXfz9kl1NDyhOOsaThNE 0oMa/AN5yw== ) ; key id = 15330 14400 DNSKEY 257 3 5 ( BQEAAAABC7F8qyfEZLTzfLBtLixAq3ekKDNj SZiVuNP6ct6L98RNu/S8SVoVARr6llwxB2uP sgnjGg/maciKZqL30RPVZrcXdh1TNMVC7r/S R4mifHgFRx2/Kq/zsC/zLuQmb8xCZ9YsTmJ/ B2x721jgFHu+glo7NMUbwDzGETd+TFbacznO 9NSM8dlU3M4FOQtryWMQxZ7wtbze51DToUsY mS+yiG5jXw== ) ; key id = 126 14400 RRSIG DNSKEY 5 2 14400 20091210021210 ( 20091130021210 126 example.com. CEFddtIU2261ubFNbX79jjDC+E8hKdfD0CBI uLIpKy0GHfHbSv1CCKATawrLL7UkASJ9OaWg 2c+Fo8Mp+M2o3kLjiNdhM0fHxQJj38nLX2q0 B+427AmIeRai4O2SZQvDoXYbsEeWmezowsJJ 96BUHwsccxcDyDDMIO160eSopeGdvWi0jji/
81
+KOC57wPDK8m1yWf4+yV8W9FghcRty2pUNYk NA== ) 14400 RRSIG DNSKEY 5 2 14400 20091210021210 ( 20091130021210 65237 example.com. R1JXjYNxy5dEALcBveK+jzNaOBQM+5cqR1aS JV7pAjMfpNvko9yMOMjq1fukQkoog81uTINu 7/Uo5IZp27svfw== ) mail.example.com. 3600 3600 IN A RRSIG 10.0.0.3 A 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. SizaztxjryCBYVMw3WhYLW9Cucxe1EyCOhQS iXAL60VpsSm59sEAy8CZ2bOpKXyJKi69bcxm zjJmBdo9s/Lr/A== ) 3600 3600 NSEC RRSIG ns.example.com. A RRSIG NSEC NSEC 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. bhfPT0jmCUMLguD5CO8UFJKElel+apYNdEso 34BvL7nVVcIICVXriIWEgJoE9sRMEBjKKvUd 7dA5WkqgkcgAsw== ) ns.example.com. 3600 3600 IN A RRSIG 10.0.0.2 A 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. KL58RNrHcgs6HkgY8FlrQc7b3aLnzkAs7DMk mcpe01N4v67Kxaz3afsGkxIophxuPlPn+/WC 8Ww0G1YIoq80Sw== ) 3600 3600 NSEC RRSIG www.example.com. A RRSIG NSEC NSEC 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. UI4M4ADpJNmkOp2HUDOma0epvW0Ok6Sim4Jx cQ31t/+P+nSPvmeT66+eL+zQZ+Q4Es31VYqx kJkAoilWNXhp9A== ) www.example.com. 3600 3600 IN CNAME ns.example.com. RRSIG CNAME 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. lEZGBwDjZgCz27f0WVDTtG/syEYG3C1cnbS9 BG9iqp6ekCWOtJNOi7wSAp7ygBGJeV0hqExC
82
Of6wSfdK3Oz+3w== ) 3600 3600 NSEC RRSIG wwwtest.example.com. CNAME RRSIG NSEC NSEC 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. qd1AtOjfQMHC5ljGlESk9BrURv+4Zenmp67P 4m0UUGXDjbrQUJxj570VCCjoGA5SX2Vpg1gp DIaR7NO3yItKZA== ) wwwtest.example.com. 3600 3600 IN CNAME www.example.com. RRSIG CNAME 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. dBgB4nrREjMqrkawdfCVEtO5t+UdXLCmObPV cPi56XWu2Pc4ybfdm5nA3eZ5a7ibm7rUS3/G MNy2UvnsEFtsMw== ) 3600 3600 NSEC RRSIG example.com. CNAME RRSIG NSEC NSEC 5 3 3600 20091210021210 ( 20091130021210 65237 example.com. JSt/M0497oS27MgneXJPlJ38aehHxRxFhfNg DpVmt96qvYr4WWUM/k8EnnYQ79Z5U3fL/iyP cBR7d1wU3rt6lA== )
The following is the contents of the keyset-example.com.file:

$ORIGIN . example.com 3600 IN DNSKEY 257 3 5 ( BQEAAAABC5OoG6+iRh8qbAKFruji3423lJpd CxXC8LyqPq4eiMzuqgLNc+YBaVtrjMoY7kRj jAt9bna5NN9I2sfEfq3cru7+BXSeRDFHZv20 lb32ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/ splO4gAHdPrF0tdU1wxzVxsQpbNA/9S6IRfv HUDwOeDL6e3mdTVdgXfz9kl1NDyhOOsaThNE 0oMa/AN5yw== ) ; key id = 15330 3600 IN DNSKEY 257 3 5 ( BQEAAAABC7F8qyfEZLTzfLBtLixAq3ekKDNj SZiVuNP6ct6L98RNu/S8SVoVARr6llwxB2uP sgnjGg/maciKZqL30RPVZrcXdh1TNMVC7r/S R4mifHgFRx2/Kq/zsC/zLuQmb8xCZ9YsTmJ/ B2x721jgFHu+glo7NMUbwDzGETd+TFbacznO
83
9NSM8dlU3M4FOQtryWMQxZ7wtbze51DToUsY mS+yiG5jXw== ) ; key id = 126
The following is the contents of the dsset-example.com.file:

example.com. IN DS 126 5 1 F79ABA961D9AEB73B58ECAF4E57D124B9B7F14B8 example.com. IN DS 126 5 2 0326E463AD26C232C3D3B3B5190A06FF46E7B874661A7820C330D652 D905710E example.com. IN DS 15330 5 1 7C280644888F3EB44CBDC5B8C05A41A762AFE234
example.com. IN DS 15330 5 2 2C1BD7AC1E19C51558339D5E476C5DDD45DB631FC47DB1D469E26B1D CF722BD9
The following is the contents of the dnskey.db file:

; ; ; ; ; ; Last generation time Nov 29 2009 22:12:10 !!! Don't edit this file by hand. !!! It will be generated by dnssec-signer.
***
List of Key Signing Keys tag=15330
*** generated Nov 23 2009 00:42:11
; example.com.
algo=RSASHA1 257 3 5 (
example.com. 14400 IN DNSKEY
BQEAAAABC5OoG6+iRh8qbAKFruji3423lJpdCxXC8LyqPq4eiMzuqgLN c+YBaVtrjMoY7kRjjAt9bna5NN9I2sfEfq3cru7+BXSeRDFHZv20lb32 ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/splO4gAHdPrF0tdU1wxzVxsQ pbNA/9S6IRfvHUDwOeDL6e3mdTVdgXfz9kl1NDyhOOsaThNE0oMa/AN5 yw== ) ; key id = 15330
; example.com.
tag=126
generated Nov 29 2009 22:12:10
BQEAAAABC7F8qyfEZLTzfLBtLixAq3ekKDNjSZiVuNP6ct6L98RNu/S8 SVoVARr6llwxB2uPsgnjGg/maciKZqL30RPVZrcXdh1TNMVC7r/SR4mi fHgFRx2/Kq/zsC/zLuQmb8xCZ9YsTmJ/B2x721jgFHu+glo7NMUbwDzG ETd+TFbacznO9NSM8dlU3M4FOQtryWMQxZ7wtbze51DToUsYmS+yiG5j Xw== ) ; key id = 126
84
; ***
List of Zone Signing Keys tag=40517
*** generated Nov 23 2009 00:45:14
; example.com.
BQEAAAAByojmMaY1M1bD9f/ql12VJ82XRncotUNbMBDkFHSUK9P6VDov lOT9RLJjqQiRAnzCi585Kag8HW3GydFOV3o8AQ== ) ; key id = 40517
; example.com.
tag=65237
generated Nov 29 2009 22:12:10
BQEAAAABuxExqi0ymhk3HkIXTU/mzEvm6OvbCZIcOxv7HpTH8Ue1FF/9 g0xKj+c0z92fZE9vEAZ0feN8HashNGO+W8tG9Q== ) ; key id = 65237
Update /etc/named.conf to include the signed version of the zone:

zone "example.com." in { type master; file "/var/zkt/zones/example.com./zone.db.signed"; };
Force named to reload the new signed version of the zone:

# /usr/local/sbin/rndc reload example.com.
5.1.5 Key Rollovers Automatic key rollover is supported for ZSK rollovers. An automated KSK rollover is done if the parent zone is on the same host and a hierarchical directory structure is used. Otherwise the KSK rollover procedure is working in a semi-automated fashion. A KSK rollover is done in three phases: 1. In the first phase only the KSK is created and the file parent-example.com which contains the old KSK key. Before entering the next phase you must wait for the new KSK to propagate in DNS properly.
# cd /var/zkt/zones/example.com. # /usr/local/bin/dnssec-zkt --ksk-newkey example.com. create new ksk
If this command is attempted during an in progress key rollover, the following message will be shown:
dnssec-zkt: Can't create new ksk because there is already an ksk rollover in progress
85
2. In the second phase a file with only the DS record is created. It should immediately be sent to the parent zone for publication. After this you must what until all name servers has published the new key, which means that you have to wait for a little bit longer than the TTL for the old key.
# /usr/local/bin/dnssec-zkt --ksk-publish example.com. dnssec-zkt: ksk_rollover (phase2): you have to wait for the propagation of the new KSK (at least 14670sec or 4h4m30s)
3. In the last phase the old KSK key is removed (it changes its file name to a prefix with lowercase k) along with the DS record. This is also done after waiting for a while; the new DS record must propagate in DNS.
# /usr/local/bin/dnssec-zkt --ksk-delkey example.com. dnssec-zkt: ksk_rollover (phase3): you have to wait for DS propagation (at least 14693sec or 4h4m53s)
To see the current key status at any time, you can use this command:
# /usr/local/bin/dnssec-zkt --ksk-status example.com. ksk_rollover: domain = example.com. phase = 1 parent_file ./parent-example.com. exist age of parent_file 147 2m27s # of active key signing keys 2 parent_propagation 300 5m keys ttl 14400 4h example.com. IN DNSKEY 257 3 5 ( BQEAAAABC7F8qyfEZLTzfLBtLixAq3ekKDNjSZiVuNP6ct6L98RNu/S8 SVoVARr6llwxB2uPsgnjGg/maciKZqL30RPVZrcXdh1TNMVC7r/SR4mi fHgFRx2/Kq/zsC/zLuQmb8xCZ9YsTmJ/B2x721jgFHu+glo7NMUbwDzG ETd+TFbacznO9NSM8dlU3M4FOQtryWMQxZ7wtbze51DToUsYmS+yiG5j Xw== ) ; key id = 126 example.com. IN DNSKEY 257 3 5 ( BQEAAAABDXjUvqH0DmzI/hXdyFMXLigciiSTYvDiIgFGqtQxFK2X1NKQ ciKRzulipdKJoJPB5YlcWjZzxj9RHb4lHPDLLdH256qa9QRKHX8WbLNX VAc/+NJwZk6LZASDeVqzHKsPBxOIEBQc6Ep5CAfO3ykk7nH68hMGbvka X0m669H9RAUtA+z+s/m/Ll5c1wNroMscYUmmjm7pLSa/JWoUCidYEx2s EQ== ) ; key id = 41694 example.com. IN DNSKEY 257 3 5 ( BQEAAAABC5OoG6+iRh8qbAKFruji3423lJpdCxXC8LyqPq4eiMzuqgLN c+YBaVtrjMoY7kRjjAt9bna5NN9I2sfEfq3cru7+BXSeRDFHZv20lb32 ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/splO4gAHdPrF0tdU1wxzVxsQ pbNA/9S6IRfvHUDwOeDL6e3mdTVdgXfz9kl1NDyhOOsaThNE0oMa/AN5 yw== ) ; key id = 15330 example.com. IN DNSKEY 256 3 5 ( BQEAAAAByojmMaY1M1bD9f/ql12VJ82XRncotUNbMBDkFHSUK9P6VDov lOT9RLJjqQiRAnzCi585Kag8HW3GydFOV3o8AQ== ) ; key id = 40517
86
example.com. IN DNSKEY
256 3 5 ( BQEAAAABuxExqi0ymhk3HkIXTU/mzEvm6OvbCZIcOxv7HpTH8Ue1FF/9 g0xKj+c0z92fZE9vEAZ0feN8HashNGO+W8tG9Q== ) ; key id = 65237
5.1.6 Publishing of DS Data to Parent Zone Publishing of DS data to a parent zone is done out-of-band and is the responsibility of a DNS operator. To assist in this process, the dnssec-signer tool creates the dsset-<zonename> file as is shown in Section 5.1.4, Zone Signing above. This file contains all of the DS RRs associated with the DNSKEY RRs for all KSKs for a given zone and should be provided to the parent zone operator for inclusion in the parent zone so as to establish the chain of trust. Please note that the secure transfer of the childs keyset to a parent registry is a manual process which occurs out of band. This transfer should be secured as necessary to ensure that no key information is divulged or compromised. 5.2 Setup
5.2.1 Installation Steps NOTE: BIND 9.6.x or greater should be installed before installing ZKT. Get the current version of ZKT
# wget http://www.hznet.de/dns/zkt/zkt-0.99c.tar.gz
Unpack
# tar xzvf zkt-0.99c.tar.gz
Change to dir
# cd zkt-0.99c
Run configure script

# ./configure
Edit config.h (optional) Modify config.h so that it matches the system that ZKT is installed in. You probably have to change the constants BIND_UTIL_PATH, depending on where your BIND tools are installed (default is /usr/local/sbin/, and CONFIG_PATH depending on where your BIND configuration files are installed (default is /var/named/).
Compile
# make
87
Install
# make install # make install-man
After installation is complete, the dnssec-zkt and dnssec-signer commands will be copied to the /usr/local/bin/ folder where as the MAN pages for these will be installed in the /usr/local/share/man/man8/ folder. 5.2.2 Initialization You will need to use the dnssec-zkt command as follows to create the default ZKT configuration file dnssec.conf in the /var/named folder:
# mkdir p /var/named # /usr/local/bin/dnssec-zkt -c "" -Z > /var/named/dnssec.conf
5.2.3 Configuration The contents of the default version of the /var/named/dnssec.conf configuration file is as follows:
# # # @(#) dnssec.conf vT0.99c (c) Feb 2005 - Aug 2009 Holger Zuleger hznet.de
dnssec-zkt options "." False True False False
Zonedir: Recursive: PrintTime: PrintAge: LeftJustify:
zone specific values # (604800 seconds) # (864000 seconds) # (28800 seconds) # (300 seconds) # (14400 seconds)
ResignInterval: 1w Sigvalidity: Max_TTL: Propagation: KEY_TTL: Serialformat: 10d 8h 5m 4h
incremental
88
signing key parameters RSASHA1 # (Algorithm ID 5) 1y 1300 "/dev/urandom" 12w 512 "/dev/urandom" 24 # (7257600 seconds) # (31536000 seconds)
Key_algo: KSK_lifetime: KSK_bits: KSK_randfile: ZSK_lifetime: ZSK_bits: ZSK_randfile: SaltBits:
dnssec-signer options "" ERROR
LogFile: LogLevel:
SyslogFacility: NONE SyslogLevel: VerboseLog: Keyfile: Zonefile: DLV_Domain: NOTICE 0 "dnskey.db" "zone.db" ""
Sig_Pseudorand: False Sig_GenerateDS: True Sig_Parameter: ""
Edit the file dnssec.conf and choose the appropriate values for signing intervals, key lengths, all according to your DNSSEC policy. Create a directory for each secure zone (dirname = domainname):
# mkdir example.com. # cd example.com.
Create the zone file (default name: zone.db) and add the line $INCLUDE the DNSKEY records (if any)
# touch zone.db.signed ls -l zone.db* -rwxr-xr-x 1 root root 494 Nov 24 22:51 zone.db
dnskey.db
to include
Create a (just empty) zone.db.signed file manually for bootstrapping purposes:
89
-rw-r--r-- 1 root root
0 Nov 24 22:49 zone.db.signed
5.3 Running Application As previously discussed, the dnssec-zkt and dnssec-signer tools are the only applications required to be run (executed) in order to support DNSSEC via the ZKT tool. Refer to Appendix P for the MAN pages for these two command-line based tools. NOTE: BIND 9.6.x or greater should be installed and the BIND named daemon should be up and running prior to using any of the ZKT commands. 5.4 Tips/Tricks/Gotchas The dnssec-zkt command is not primarily designed for environments with many secure zones. However, some tests with about 12000 zones, stored in a two level directory structure (zonedir//) shows that this could be a working scenario. Do not mix the authoritative name server function and caching resolver in the same instance of BIND. A version of BIND greater than 9.4 is recommended. A signed zone requires round about 8 to 20 files. Its recommended to use a separate directory for each zone. DNSKEY RR should be added to the zone file via $INCLUDE directive. By default, all key files in the current directory will be used for signing. Pay attention to the key signing key flag. All signature records have a limited lifetime (default 30 days) settable via option -e +172800 (from now-1h to now+48h). You have to do a resigning before the signatures expire Use dnssec-signer option -r to trigger a reload of the zone (via rndc). The reload will be triggered only if its necessar y (new .signed file) Periodically re-sign your zone. Call dnssec-signer at least once a day. For a sample script for ZKT for performing zone signing via a CRON job, see Appendix N. The option -l and the ksk rollover options for the dnssec-zkt command insist on domain names ending with a dot Dynamic zone support:
90
dnssec-signer will automatically freeze/unfreeze a zone during re-signing Use dnssec-signer -d command lin option. Signed zone files are named with a .dsigned file extension.
91
6. Troubleshooting DNSSEC
DNSSEC adds some moving pieces to the DNS that can break. This section aims to explain the various ways that DNS Security can break and how to determine what has broken when a signed zone is not working properly. 6.1 Failure Modes There are a number of DNSSEC specific ways that the DNS can break. The table below lists some of the most common problems: Failure Mode Signature Expiration Description If the zone administrator does not resign the zone, which refreshes the signatures, before the signature expiration time, the signatures are considered invalid and resolvers will not use them to validate the zone data. Note: When querying an authoritative server, the dig output will show an answer containing no associated signature and the return status will be set to NOERROR. Secure Entry Point Key (KSK) Rollover Secure Entry Point Key (KSK) Deletion If the resolvers are not updated, the old trust anchors will no longer be capable of validating the signatures generated by the new KSK keys. If a zone administrator deletes the KSK keys that are configured as trust anchors in resolvers, then a similar situation as the rollover situation will occur. Only instead of the resolvers being unable to validate the signatures, there will be no signatures to validate and so the resolver will consider the zone as invalid. Note: When querying an authoritative server, the dig output will show an answer containing no associated signatures and the return status will be set to NOERROR. Broken Chain Of Trust Given a hierarchy of zones, the chain of trust breaks with an unsigned zone. E.g. root zone, .edu, umd.edu, ee.eng.umd.edu are all signed zones. Eng.umd.edu is not a signed zone and none of the resource records in this
92
zone can be validated. Unsupported DNSSEC Algorithm The resolving name server does not support the DNSSEC algorithm that was used to sign a particular zone. This type of resolver related error will show up in /var/log/messages or else in a specific log file as configured using special logging channels via the named.conf configuration file. Inconsistent versions of the third party dependencies supporting the DNSSEC extensions that are used by client software (E.g. DNSSEC plugin, dig, etc.) and resolvers/recursive servers may cause DNSSEC validation to fail. Resolver/Recursive Server: If the administrator makes a typographical error while entering the trust anchor, or does not fully enable DNSSEC support in the resolver, then the resolver will not work properly. In the first case, the zone will be considered invalid and in the second case the zone will simply appear to be unsigned. Authoritative Server: The server may be misconfigured to load the wrong zone data An unsigned zone may be misconfigured to not include signing keys or else include the wrong ones thereby causing the zone to never be successfully signed Malicious Modification An attacker can modify DNS responses while in transit on the network and if the attacker does not possess the private key that created the signatures on the response data, the signatures will be invalid due to the data modification. If the attacker does possess the private key, then there are bigger security issues with the zone than can be solved with troubleshooting.
Incompatible Third Party Dependencies
Server Misconfiguration
93
6.2 Tools The following tools/tips can be quite useful in troubleshooting/debugging DNSSEC related problems. 6.2.1 BIND Server Logs Probably the most obvious tool to use is BIND itself and the logs that it generates when performing DNS operations. In BIND messages of a certain category can be logged to separate channels. The channels determine where the messages go and to what severity level they will need to be reported. The relevant category for DNSSEC validation is the dnssec category. The following shows the relevant portions of a logging configuration in the /etc/named.conf file to support the dnssec category:
logging { channel dnssec { file "/var/log/dnssec" versions 10 size 300k; print-time yes; print-category yes; print-severity yes; severity debug 3; //severity info; }; category dnssec { dnssec; }; };
// a DNSSEC log channel // timestamp the entries // add category name to entries // add severity level to entries // print debug message <= 3 t
For the most verbose logging, severity debug 3 is recommended. For production servers, level 3 information is too voluminous; therefore, severity info is recommended. Note that the logging configuration above should be made on the machine that is configured as the validating recursive name server. The output in the log file will look similar to the output below:
validating @0x100823a00: example.net SOA: starting validating @0x100823a00: example.net SOA: attempting positive response validation validating @0x100824800: example.net DNSKEY: starting validating @0x100824800: example.net DNSKEY: attempting positive response validation validating @0x100824800: example.net DNSKEY: verify rdataset (keyid=49656): success validating @0x100824800: example.net DNSKEY: signed by trusted key; marking as secure validator @0x100824800: dns_validator_destroy validating @0x100823a00: example.net SOA: in fetch_callback_validator validating @0x100823a00: example.net SOA: keyset with trust 7 validating @0x100823a00: example.net SOA: resuming validate
94
validating @0x100823a00: example.net SOA: verify rdataset (keyid=17000): success validating @0x100823a00: example.net SOA: marking as secure validator @0x100823a00: dns_validator_destroy
The attempt for positive response validation shows how the validator 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. Chains of trust start by the validation of a signature over a DNSKEY RRset, then these keys are used to validate the DS RRset that point to DNSKEY RRs in a child zone which validates the DNSKEY RRs in the child zone, or the DNSKEYs can be used to validate the data you have queried for. The log reflects the activity of the validator following the chain of trust. 6.2.2 dig The BIND dig utility is a command-line program that sends DNS query requests to servers. The dig command is DNSSEC aware and can be used to query both authoritative and recursive servers. dig has a few command line options that come in useful when troubleshooting DNSSEC
setups. These are described in the table below:
Option +multiline +cd
Description Structures the output of dig so that it is easily readable. As a bonus the key id will be printed as a comment behind DNSKEY RRs. Sets the "checking disabled" bit on the query. You would typically use this when your validating recursive name server reports a SERVFAIL and you need to establish if the is due to DNSSEC marking this data as "bad". Forces the server being queried to include the DNSSEC related data. Use in combination with the +cd to establish if data from a zone is signed at all or if you want to determine if the validity intervals on the signatures are correct. Traces delegation chain. This option may be helpful if you trying to figure out where the delegation points are. Traces the signature chain. You will also need to have a ./trusted-keys.keys or /etc/trusted-keys.keys available that contains trusted key entries. Please note that this option requires that dig must be compiled with -DDIG_SIGCHASE. See the dig man page for more details.
+dnssec
+trace +sigchase
Note that if data is validated by a caching forwarder, then the ad-bit will be set by the name server in the flags section of the dig output response.
95
6.2.3 trustman Trustman (http://www.dnssec-tools.org/wiki/index.php/Trustman) is used as a tool to check and notify the administrator of changes in Trust Anchors (TAs) as configured in a named.conf file. An administrator can load the TA's to be managed into the named.conf file and have trustman run as a daemon and routinely check those configured zones for TA changes. When trustman is run it will notify the administrator of any changes between the local configuration files and the published TAs for one or more zones. Trustman can also be configured to add the newly found TAs to these files. By default trustman runs in daemon mode and be configured to send email to an administrator when it notices any changes in the Trust Anchors. It can also be run as a command-line utility as well with verbose output so operators can examine in detail the steps it is taking to analyze newly found keys. This tool was designed so that an operator of a validating recursive server can automatically be notified of any changes in the TAs used by an administered server. For more details on trustman, see: http://www.dnssec-tools.org/wiki/index.php/Template:Trustman_ShortTorial. 6.2.4 logwatch Logwatch can be found at http://www.logwatch.org. It is a tool that parses your system logs, analyzes specific sections and sends a summarized report to an administrator. It's already included in many Unix-based operating systems and, if not, will usually install and just work. The DNSSEC-Tools project (http://www.dnssec-tools.org/) has created a logwatch filter that parses Bind's named output. If you have v7.1+ of logwatch on your system, nothing should have to be done. The filter is already included. If you have v6, you can add the DNSSEC-Tools filter to it. The addition of the logwatch report will look similar to this,
################### LogWatch 6.0.2 (04/25/05) #################### Processing Initiated: Thu Jul 7 10:13:34 2005 Date Range Processed: all Detail Level of Output: 10 Type of Output: unformatted Logfiles for Host: host.example.com ################################################################## --------------------- DNSSEC Begin -----------------------No Valid Signature received 6 times Detail >= 5 log messages:
96
Marking as secure 97 times Verified rdataset succeeded Attempted positive response Nonexistence proof found 20 Attempted negative response Validation OK 2 times
97 times validation 96 times times validation 18 times
---------------------- DNSSEC End --------------------------------------------- Resolver Begin -----------------------Received validation completion event 171 times Validation OK 125 times Nonexistence validation OK received 46 times ---------------------- Resolver End ------------------------###################### LogWatch End #########################
For more details on using logwatch, refer to any of the following URLs: http://www.dnssec-tools.org/wiki/index.php/Logwatch http://www.logwatch.org/ http://www2.logwatch.org:81/ 6.2.5 Donuts Donuts is a lint-like checking tool, available from with the dnssec-tools (http://www.dnssectools.org/wiki/index.php/Donuts) distribution, for analyzing DNS zone files. It reports any errors it finds, either as text output if run as a command line application or in a GUI window if a browser interface is desired. It is extremely flexible and local rule sets and configuration can tailor its output to define local policies.
# donuts R
to see a list of rules. Default location of rules in /usr/local/share/dnssectools/donuts/rules/*.txt

# donuts help Usage: donuts [-h] [-H] [-v] [-l LEVEL] [-r RULEFILES] [-i IGNORELIST] [-C] [-c configfile] ZONEFILE DOMAINNAME... # donuts h Option h is ambiguous (help, help-config, help-features, help-rules)
97
# donuts --level 8
-v /var/zkt/zones/acme.com./zone.db.signed acme.com
--- loading rule file /usr/local/share/dnssec-tools/donuts/rules/check_nameservers.txt rules: MEMORIZE_NS_ADDRS DNS_SERVERS_MATCH_DATA --- loading rule file /usr/local/share/dnssec-tools/donuts/rules/dns.errors.txt rules: DNS_SOA_REQUIRED MEMORIZE_NS_CNAME_RECORDS DNS_NS_NO_CNAME --- loading rule file /usr/local/share/dnssec-tools/donuts/rules/dnssec.rules.txt rules: DNSSEC_RRSIG_TTL_MATCH_ORGTTL DNSSEC_MEMORIZE_NS_RECORDS DNSSEC_CHECK_IF_NSEC3 DNSSEC_MISSING_NSEC_RECORD DNSSEC_MISSING_RRSIG_RECORD DNSSEC_RRSIG_NOT_SIGNING_RRSIG DNSSEC_RRSIG_FOR_NS_GLUE_RECORD DNSSEC_NSEC_FOR_NS_GLUE_RECORD DNSSEC_RRSIG_SIGEXP DNSSEC_NSEC_TTL DNSSEC_NSEC3_TTL DNSSEC_DNSKEY_MUST_HAVE_SAME_NAME DNSSEC_DNSKEY_PROTOCOL_MUST_BE_3 DNSSEC_BOGUS_NS_MEMORIZE DNSSEC_MISSING_RRSIG_RECORD DNSSEC_RRSIG_TTL_MUST_MATCH_RECORD DNSSEC_MISSING_NSEC_RECORD DNSSEC_RRSIG_SIGNER_NAME_MATCHES DNSSEC_NSEC_RRSEC_MUST_NOT_BE_ALONE DNSSEC_MEMORIZE_KEYS DNSSEC_RRSIGS_VERIFY DNSSEC_TWO_ZSKS DNSSEC_OPENSSL_KEY_ISSUES --- loading rule file /usr/local/share/dnssec-tools/donuts/rules/nsec_check.rules.txt rules: DNSSEC_NSEC_MEMORIZE DNSSEC_NSEC3_MEMORIZE DNSSEC_NSEC3_CHECK DNSSEC_NSEC_CHECK --- loading rule file /usr/local/share/dnssec-tools/donuts/rules/parent_child.rules.txt rules: DNS_MULTIPLE_NS DNSSEC_SUB_NOT_SECURE DNSSEC_DNSKEY_PARENT_HAS_VALID_DS DNSSEC_DS_CHILD_HAS_MATCHING_DNSKEY --- loading rule file /usr/local/share/dnssectools/donuts/rules/recommendations.rules.txt rules: DNS_REASONABLE_TTLS DNS_NO_DOMAIN_MX_RECORDS --- Analyzing individual records in /var/zkt/zones/acme.com./zone.db.signed acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:10 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:16 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
98
achilles.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:64 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for achilles.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
achilles.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:70 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for achilles.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
achilles.acme.com: Location: Rule Name: /var/zkt/zones/acme.com./zone.db.signed:76 DNSSEC_RRSIG_SIGEXP
99
Level: Error: Details:
1 RRSIG record for achilles.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
agamemnon.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:82 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for agamemnon.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
agamemnon.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:88 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for agamemnon.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
ajax.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:94 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for ajax.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
100
dev-ng-core4.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:112 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for dev-ng-core4.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
diomedes.acme.com: Location: Rule Name: /var/zkt/zones/acme.com./zone.db.signed:130 DNSSEC_RRSIG_SIGEXP
101
1 RRSIG record for diomedes.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
diomedes.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:136 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for diomedes.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
diomedes.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:142 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for diomedes.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
localhost.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:148 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for localhost.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
localhost.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:154 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for localhost.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
102
menelaeus.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:160 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for menelaeus.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
odysseus.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:178 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for odysseus.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
odysseus.acme.com: Location: Rule Name: /var/zkt/zones/acme.com./zone.db.signed:184 DNSSEC_RRSIG_SIGEXP
103
1 RRSIG record for odysseus.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
odysseus.acme.com: Location: Rule Name: Level: Error: Details: /var/zkt/zones/acme.com./zone.db.signed:190 DNSSEC_RRSIG_SIGEXP 1 RRSIG record for odysseus.acme.com has expired Checks signature expiration time and warns or signals an error if the time is near or past.
--- Analyzing records for each name in /var/zkt/zones/acme.com./zone.db.signed menelaeus.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: menelaeus.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
menelaeus.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: menelaeus.acme.com type: MX failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
menelaeus.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: menelaeus.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are
104
signing.
odysseus.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: odysseus.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
odysseus.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: odysseus.acme.com type: MX failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
odysseus.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: odysseus.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
localhost.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: localhost.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
localhost.acme.com: Rule Name: DNSSEC_RRSIGS_VERIFY
105
Level: Error:
1 RRSIG on name: localhost.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643
Details:
RRSIGs must cryptographically verify the records they are signing.
acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: acme.com type: SOA failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: acme.com type: DNSKEY failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: acme.com type: DNSKEY failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are
106
signing.
acme.com: Rule Name: Level: Warning: Details: DNS_NO_DOMAIN_MX_RECORDS 8 At least one MX record for acme.com is suggested Checks to ensure that the zone contains at least 1 MX record.
ajax.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: ajax.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
ajax.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: ajax.acme.com type: MX failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
ajax.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: ajax.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
dev-ng-core4.acme.com: Rule Name: Level: DNSSEC_RRSIGS_VERIFY 1
107
Error:
RRSIG on name: dev-ng-core4.acme.com type: A failed to verify: Signature has expired since: 20100108153643
Details:
dev-ng-core4.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: dev-ng-core4.acme.com type: MX failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
dev-ng-core4.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: dev-ng-core4.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
agamemnon.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: agamemnon.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
agamemnon.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: agamemnon.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
108
achilles.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: achilles.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
achilles.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: achilles.acme.com type: MX failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
achilles.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: achilles.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
diomedes.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: diomedes.acme.com type: A failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
diomedes.acme.com: Rule Name: Level: DNSSEC_RRSIGS_VERIFY 1
109
Error:
RRSIG on name: diomedes.acme.com type: MX failed to verify: Signature has expired since: 20100108153643
Details:
diomedes.acme.com: Rule Name: Level: Error: DNSSEC_RRSIGS_VERIFY 1 RRSIG on name: diomedes.acme.com type: NSEC failed to verify: Signature has expired since: 20100108153643 Details: RRSIGs must cryptographically verify the records they are signing.
results on testing acme.com: rules considered: rules tested: records analyzed: names analyzed: errors found: 38 30 54 9 53
The above loads the zone.db.signed file and examines it. It must be told which zone is contained within the file, which is why there is an additional argument of acme.com on the command line. Use the --level 9 flag and argument for maximum output. 6.2.6 Drill Drill (http://www.nlnetlabs.nl/projects/ldns/) is a tool like dig from BIND. It was designed with DNSSEC in mind and should be a useful debugging/query tool for DNSSEC. Drill is part of the
ldns library available from http://www.nlnetlabs.nl/ldns/. Installation instructions are also available on that page. (It is as simple as: ./configure ; make ; make install). Assuming that you
have already obtained ldns and built it, you will need to manually build drill:
# cd ldns-1.6.1/drill # autoreconf && ./configure && make # make install
Installs in /usr/local/bin/drill by default. The following is the usage for drill:

# drill h drill version 1.6.1 (ldns version 1.6.1)
110
Written by NLnet Labs.
Copyright (c) 2004-2008 NLnet Labs. Licensed under the revised BSD license. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Usage: drill name [@server] [type] [class] <name> <type> can be a domain name or an IP address (-x lookups) defaults to A
<class> defaults to IN
arguments may be placed in random order
Options: -D -T -S -V <number> -Q enable DNSSEC (DO bit) trace from the root down to <name> chase signature(s) from <name> to a know key [*] verbosity (0-5) quiet mode (overrules -V)
-f file -i file -w file -q file -h -v
read packet from file and send it read packet from file and print it write answer packet to file write query packet to file show this help show version
Query options: -4 -6 -a -b <bufsize> -c <file> stay on ip4 stay on ip6 fallback to EDNS0 and TCP if the answer is truncated use <bufsize> as the buffer size (defaults to 512 b) use file for rescursive nameserver configuration (/etc/resolv.conf) -k <file> specify a file that contains a trusted DNSSEC key [**] used to verify any signatures in the current answer
111
-o <mnemonic>
set flags to: [QR|qr][AA|aa][TC|tc][RD|rd][CD|cd][RA|ra][AD|ad] lowercase: unset bit, uppercase: set bit
-p <port> -s -u -x -r <file> -t -d <domain>
use <port> as remote port number show the DS RR for each key in a packet send the query with udp (the default) do a reverse lookup when doing a secure trace: use file as root servers hint file send the query with tcp (connected) use domain as the start point for the trace specify named base64 tsig key, and optional an algorithm (defaults to hmac-md5.sig-alg.reg.int)
-y <name:key[:algo]>
-z
don't randomize the nameservers before use
[*] = enables/implies DNSSEC [**] = can be given more than once
ldns-team@nlnetlabs.nl | http://www.nlnetlabs.nl/ldns/
The following is an example of using drill:

# drill @127.0.0.1 -S -V 5 -D example.com. ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: rd cd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example.com. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec ;; EDNS: version 0; flags: do ; udp: 4096 ;; WHEN: Wed Dec 31 19:00:00 1969 ;; MSG SIZE rcvd: 0
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 22223
112
;; flags: qr aa rd cd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;; example.com. IN A
;; ANSWER SECTION: example.com. 3600 IN A 10.0.0.1
example.com. 3600 IN RRSIG A 5 2 3600 20100107213414 20091228213414 2300 example.com. v8a2okdkq97EucRdZTC/sA1zMKw6XcDs8Om3qQwJNcOulD2twZtorh/tH8Ds8WvPoHZ5H+5r1NYve8W2pomQFA== ;{id = 2300}
;; AUTHORITY SECTION: example.com. example.com. 3600 3600 IN IN NS NS ns.somewhere.com. ns.example.com.
example.com. 3600 IN RRSIG NS 5 2 3600 20100107213414 20091228213414 2300 example.com. hnXZuM0oHHU/4O3ArnG6CQ+w0CbL/q4e+JGoFR23HE2r/j35U4n636IMSzugc+SEV6vRzmqzZgQyqpZd4vpt3Q== ;{id = 2300}
;; ADDITIONAL SECTION: ns.example.com. 3600 IN A 10.0.0.2
ns.example.com. 3600 IN RRSIG A 5 3 3600 20100107213414 20091228213414 2300 example.com. LxOglkT17Z+PnAU2RAiq6W+72hImUiJ98lpW98XAbppTXsFtc5yr5c3aTBdAFylXPjJVq64KZ8dLa6S0U0wS5g== ;{id = 2300}
;; Query time: 0 msec ;; EDNS: version 0; flags: do ; udp: 4096 ;; SERVER: 127.0.0.1 ;; WHEN: Wed Dec 30 16:27:34 2009 ;; MSG SIZE rcvd: 437
;; Chasing: example.com. A Warning: No trusted keys specified ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: rd cd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example.com. IN DNSKEY
;; ANSWER SECTION:
113
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: rd cd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example.com. IN DS
;; ANSWER SECTION:
error: Could not send or receive, because of network error ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: rd cd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example.com. IN DNSKEY
;; ANSWER SECTION:
;; Query time: 0 msec
114
;; EDNS: version 0; flags: do ; udp: 4096 ;; WHEN: Wed Dec 31 19:00:00 1969 ;; MSG SIZE rcvd: 0
error: No nameservers defined in the resolver
DNSSEC Data Chain: ;; rcode: NOERROR ;; qtype: DNSKEY rrset: example.com. 3600 IN DNSKEY 257 3 5 BQEAAAABDwP3lQRirb4oH+byeSnjb0M80DCHlx4FKBtrsNZb8xrXZfmNPZcH5ybZWJLmy5rOFkSAe34GuHl2/BwRB cbUAvb4zNQ0DB8yiHdd00c+ipeFnBG9+SQqn88vqESsmW6aeqlo785C4K+yBTz9d7Sw43WDKc2knkV+xnlEuLN9nn GUdM7jt0c78rATfhmWUewLj6EbwE7tQ1ah5N3RzuL4iKgWcw== ;{id = 59883 (ksk), size = 1304b} example.com. 3600 IN DNSKEY 256 3 5 BQEAAAAB1fa789s0hvqjwP8duqxN6pQwaMnferrmV4Nbvy7UYWXHH25xYIprXQ23tHW+sYDjvPyWA4A5BRqLN1Pxq 7IfIw== ;{id = 2300 (zsk), size = 512b} example.com. 3600 IN DNSKEY 257 3 5 BQEAAAABDUAzwZqyxXCFqoXAIrodpPJUpol4XyaqApgZH7Y5hjp7v5kzSZtAeVJC5ApgsV8uhOc9F229L6SPZW1DO fVgouO4i7sDqeESDTFA3CC5RoCd7WgXgo/kLlYX3LMbMD1aj9LtPscAETwYXr4It/rVUFv6wGgcM8IxiFro22gubo PhMSn4j5Co4FMY6avAe/jruq6qhogQA2ZN0qLetu6Rr6+Saw== ;{id = 36213 (ksk), size = 1304b} example.com. 3600 IN DNSKEY 257 3 5 BQEAAAABDpsAq2dvksLWdQgWOMzZJ+L1VvrBB2YwqcG/WgL/Sw9xgWEdlloVO+y/mVSRZOMOVkqChUY4doXQQs3qZ mDElglh5J8rok5ubXYTvGgFzQar+uKT9ybqgmgexPhphf6JwWi0NtGvL9oJGYKKhJOrbIeKAjRlV59OQrg/FsaHGS uYLYhMMLK2vNrC5q4wsdyxi5INYmHWJabyz6kywMWZMJP1VQ== ;{id = 3906 (ksk), size = 1304b} sigs: --;; rcode: NOERROR rrset: example.com. sigs: example.com. 3600 IN RRSIG A 5 2 3600 20100107213414 20091228213414 2300 example.com. v8a2okdkq97EucRdZTC/sA1zMKw6XcDs8Om3qQwJNcOulD2twZtorh/tH8Ds8WvPoHZ5H+5r1NYve8W2pomQFA== ;{id = 2300} --3600 IN A 10.0.0.1
DNSSEC Trust tree: example.com. (A) |---example.com. (DNSKEY keytag: 2300 alg: 5 flags: 256) You have not provided any trusted keys. ;; Chase successful
115
Drill's -T and -S switches are particularly helpful when troubleshooting DNSSEC setups. Using drill with the -T option follows the chain of trust from the root to the leaves and indicates the security status as shown in the sample output below:
;; Domain: . [T] . 100 IN DNSKEY 256 3 5 ;{id = 63380 (zsk), size = 1024b} . 100 IN DNSKEY 257 3 5 ;{id = 63276 (ksk), size = 1280b} Checking if signing key is trusted: New key: . 100 IN DNSKEY 256 3 5 AQPQyahTOOaR/Pi6p+EG+JldP9wQJurw7iB8Mz+De45akisO/VeprAd0s77lA5Nxz+42XP+VcGMqSIhUVlx1WIXDl 4ZHBG8mKocfNt0mnOJhTrusted key: . 3600 IN DNSKEY 257 3 5 AQOv6tbkmW+1IrU3q2SrG+36bmJfFs1+u7XaMgytcTftdBoYBquXqYVmYt4EtI9soyZBG6jS5CtkrzWnk721/ZFgG yatkrSq80WQTrusted key: . 100 IN DNSKEY 256 3 5 AQPQyahTOOaR/Pi6p+EG+JldP9wQJurw7iB8Mz+De45akisO/VeprAd0s77lA5Nxz+42XP+VcGMqSIhUVlx1WIXDl 4ZHBG8mKocfKey is now trusted! Trusted key: . 100 IN DNSKEY 257 3 5 AQOv6tbkmW+1IrU3q2SrG+36bmJfFs1+u7XaMgytcTftdBoYBquXqYVmYt4EtI9soyZBG6jS5CtkrzWnk721/ZFgG yatkrSq80WQ[T] net. 100 IN DS 13467 5 1 de01426e08ddb9186502ccc1081390cd7da0e178 net. 100 IN DS 13467 5 2 ec9b094786b82c46aa3054c7352b59904b697119d515b4ea536ec3dd9a10ed81 ;; Domain: net. [T] net. 100 IN DNSKEY 256 3 5 ;{id = 62972 (zsk), size = 1024b} net. 100 IN DNSKEY 257 3 5 ;{id = 13467 (ksk), size = 1280b} Checking if signing key is trusted: New key: net. 100 IN DNSKEY 256 3 5 AQPVP6Jea1Lo/dU19UCmumJqR36Mx6ecjXxdwTByhyn//3S/NgDTgYbTzvFq+dmjcH1ccuCIWS9PPB9tmQ5grQ2YM wee2VLTrrtRnOPX2gm8Trusted key: . 3600 IN DNSKEY 257 3 5 AQOv6tbkmW+1IrU3q2SrG+36bmJfFs1+u7XaMgytcTftdBoYBquXqYVmYt4EtI9soyZBG6jS5CtkrzWnk721/ZFgG yatkrSq80WQTrusted key: . 100 IN DNSKEY 256 3 5 AQPQyahTOOaR/Pi6p+EG+JldP9wQJurw7iB8Mz+De45akisO/VeprAd0s77lA5Nxz+42XP+VcGMqSIhUVlx1WIXDl 4ZHBG8mKocfTrusted key: . 100 IN DNSKEY 257 3 5 AQOv6tbkmW+1IrU3q2SrG+36bmJfFs1+u7XaMgytcTftdBoYBquXqYVmYt4EtI9soyZBG6jS5CtkrzWnk721/ZFgG yatkrSq80WQTrusted key: net. 100 IN DNSKEY 256 3 5 AQPVP6Jea1Lo/dU19UCmumJqR36Mx6ecjXxdwTByhyn//3S/NgDTgYbTzvFq+dmjcH1ccuCIWS9PPB9tmQ5grQ2YM weeKey is now trusted! Trusted key: net. 100 IN DNSKEY 257 3 5 AQOsAH77fsZc53KoA9QfrXABEoXa5ZIBmUmJuXvnp36/LEgfn4ItTnOGMKHesgIV/qopgs+4dZxSIrAjGF92y3Mp3 +79[T] example.net. 100 IN DS 49656 5 2 9e06b299abe811d699e077fff990ff5a1b496c914deb22697ba22a1da31f0a6e example.net. 100 IN DS 49656 5 1 3850efb913aec66275bca53221587d445702397e ;; Domain: example.net. [T] example.net. 100 IN DNSKEY 256 3 5 ;{id = 17000 (zsk), size = 1024b} example.net. 100 IN DNSKEY 257 3 5 ;{id = 49656 (ksk), size = 1280b} [T] example.net. 100 IN SOA ns.example.net. olaf.nlnetlabs.nl. 2002050501 100 200 604800 100 ;;[S] self sig OK; [B] bogus; [T] trusted
With the S option, drill will chase the signatures from the leaves back to the root, looking for the relevant records as shown in the sample output below:
;; Chasing: example.net. SOA DNSSEC Trust tree: example.net. (SOA) |---example.net. (DNSKEY keytag: 17000) |---example.net. (DNSKEY keytag: 49656) |---example.net. (DS keytag: 49656) |---net. (DNSKEY keytag: 62972)
116
|---net. (DNSKEY keytag: 13467) |---net. (DS keytag: 13467) |---. (DNSKEY keytag: 63380) |---. (DNSKEY keytag: 63276) ;; Chase successful
6.2.7 Autotrust Once trust anchors are configured you will need to make sure they are kept in sync with the key as published by the entity responsible for the zone to which it belongs. Keeping in sync with trust anchors is incredibly important as KSKs are rolled over. Once a maintainer of a zone uses the RFC5011 mechanisms to rollover a KSK, there are a number of tools to assist in updating the corresponding trust anchors. One such tool is autotrust. Autotrust (http://www.nlnetlabs.nl/projects/autotrust/) is a standalone application that automatically updates DNSSEC trust anchors. It can be used for DNSSEC aware resolvers like Unbound or BIND9. It is compliant with RFC 5011, with the exception of query intervals and retry times. In order to follow these time recommendations, autotrust should run as a daemon. It is to be called from the command line once in a while, or from a cron job. 6.2.8 VeriSign jDNSSEC Tools This is a collection of Java-based DNSSEC command line tools. They are intended to be an addition or replacement for the DNSSEC tools that are part of BIND 9. Specifically, one such tool from this suite which can be used to verify all of the signatures in a signed zone for cryptographic validity is jdnssec-verifyzone. It is important to note that this tool does not check to see if the zone is otherwise correctly signed. NOTE: The latest version of jDNSSEC is bundled with the DNSJava (http://www.dnsjava.org/) library version 2.0.7 which has a bug that causes jdnssec-verifyzone to always fail when verifying a signed zone. While the bundled version of DNSJava 2.0.7 contains updates not present in the original 2.0.7 version, the jdnssec-verifyzone tool specifically does not require these updates. So, the following steps can be used to download the 2.0.8 version of DNSJava and compile the library:
# mkdir p /usr/src/redhat # cd /usr/src/redhat # wget http://www.dnsjava.org/download/dnsjava-2.0.8.tar.gz # tar xvfz dnsjava-2.0.8.tar.gz # cd dnsjava-2.0.8
117
At this point, make sure that the JAVA_HOME environment variable is defined and pointing to JDK1.4.2 or higher and that the ANT_HOME environment variable is pointing to an installed version of ANT. Include these in the PATH environment variable and compile:
# export JAVA_HOME=/usr/java/jdk1.6.0_11 # export ANT_HOME=/app/apache-ant # export PATH=${JAVA_HOME}/bin:${ANT_HOME}/bin:${PATH} # ant
Now, we will obtain the jDNSSEC package, patch it with the new version of DNSJava (we compiled above), and then run jdnssec-verifyzone to verify the example.com. DNSSEC enabled zone:
# cd /usr/src/redhat # wget http://www.verisignlabs.com/dnssec-tools/packages/jdnssec-tools-0.9.5.tar.gz # tar xvfz jdnssec-tools-0.9.5.tar.gz # rm jdnssec-tools-0.9.5/lib/dnsjava-2.0.7-vrsn-1.jar # cp dnsjava-2.0.8/dnsjava-2.0.8.jar jdnssec-tools-0.9.5/lib
# jdnssec-tools-0.9.5/bin/jdnssec-verifyzone -h usage: jdnssec-verifyzone [..options..] zonefile [keyfile [keyfile...]] -A,--alg-alias <alias:original:mnemonic> Define an alias for an algorithm -d,--keydir <dir> directory to find trusted key files -h,--help -m,--multiline Print this message. log DNS records using 'multiline' format -s,--strict cryptographically verified -v,--verbose <level> verbosity level -- 0 is silence, 5 is debug information, 6 is trace information. default is level 5. Zone will only be considered valid if all signatures could be
# jdnssec-tools-0.9.5/bin/jdnssec-verifyzone -d /var/zkt/zones/example.com. -v 5 -s -m /var/zkt/zones/example.com./zone.db.signed Jan 8, 2010 7:32:19 PM com.verisignlabs.dnssec.cl.VerifyZone verifyZoneSignatures INFO: Adding trusted key: example.com. 3600 IN DNSKEY 256 3 5 (
BQEAAAAB3H65j1CEi58P5X8EyP6y2emTv1lsogUVAtTkBvRVWOGAeswXdBJudfbY
118
BwMiDO56HtYJkRZIm8UXN0JRZWO+2Q== ) ; key_tag = 27242 ; keytag = 27242 Jan 8, 2010 7:32:19 PM com.verisignlabs.dnssec.cl.VerifyZone verifyZoneSignatures INFO: Adding trusted key: example.com. 3600 IN DNSKEY 257 3 5 (
BQEAAAABDo+KW9m61gR5KWQia8CsS2UcwUm12UdghX2S3pXdxJFU+9mdrvDIF2nG +VkGe1FMbq+yVT54IufamO3n8MCnL9Y/7SX4X1v37AwT2nV4PnO6ouNr8lKQmh8c qeXTDmsEEl1wrFlPytXIamNrchlc9h1tK0PRC5WuMUF+p2wEpvIyih3WIIHWZ6zS BD3D9RcyjmRBhI9/LwzP8EtB8yEEBDD4gw== ) ; key_tag = 20763 ; keytag = 20763 zone verified.
Please note that patching the bundled version of DNSJava (as we did above) will break some of the other tools in the jDNSSEC package.
6.2.9 Validate The validate (http://www.dnssec-tools.org/wiki/index.php/Validate) application is a commandline standalone DNS validation utility which performs validated domain lookups. It is similar to dig but can provide in depth output on the validation steps taken during a lookup. Some example output is given below:
# ./validate -o 6:stdout -p badsign-A.test.dnssec-tools.org Result: ****START**** Result: FAILED: Some results were not validated successfully Original query: name=badsign-A.test.dnssec-tools.org class=IN type=A fromserver= 157.185.80.32, Query-status=Q_ANSWERED:4 Result: VAL_BOGUS:130 name=badsign-A.test.dnssec-tools.org class=IN type=A fromserver= 157.185.80.32 status=VAL_AC_NOT_VERIFIED:51 name=test.dnssec-tools.org class=IN type=DNSKEY[tag=28827] fromserver= 157.185.80.32 status=VAL_AC_TRUST_KEY:88 Result: ****END**** DNSSEC status: VAL_BOGUS [130] Non-validated response: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0 ;; flags:; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; badsign-A.test.dnssec-tools.org, type = A, class = IN badsign-A.test.dnssec-tools.org. 1D IN A 168.150.236.43
For extensive debugging output, use the command line option
-o7:stderr
instead.
6.2.10 Mapper The mapper (http://www.dnssec-tools.org/wiki/index.php/Mapper) application creates a graphical map of one or more zone files. The output gives a graphical representation of a DNS zone or zones. The result can be useful for getting a more intuitive view of a zone or set of zones.
119
It is extremely useful for visualizing DNSSEC deployment within a given zone as well as to help discover problem spots. Large organizations might also find mapper useful in visualizing a DNS deployment. A small portion of the map for the zone test.dnssec-tools.org is depicted below:
6.2.11 dnspktflow The dnspktflow (http://www.dnssectools.org/wiki/index.php/Software_User_Manual#Dnspktflow) application analyzes and draws DNS flow diagrams from packet capture files made with tcpdump, or any other libpcapgenerating program. This tool is very useful for debugging DNS queries being issued to and by resolvers.
120
An example flow is:
6.3 Example Session To effectively troubleshoot DNSSEC, an administrator will need to make use of a combination of the tools mentioned above. What follows is an example session to introduce some of the tools and how a typical troubleshooting session might go. 1. dig against the recursive server returns SERVFAIL When DNSSEC problems are encountered, the status code will always be SERVFAIL. A resolver administrator using dig to query a recursive server would see output like the following:
121
# dig badsign-A.test.dnssec-tools.org ; <<>> DiG 9.3.2 <<>> badsign-A.test.dnssec-tools.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46037 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;badsign-A.test.dnssec-tools.org. IN A ;; Query time: 712 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jan 8 10:45:13 2010 ;; MSG SIZE rcvd: 49
2. Examine the recursive server log with configured dnssec category The relevant log entries in the dnssec log for this query are shown below:
8-Jan-2010 10:45:12.979 debug 3: validating @0x8249000: badsign-A.test.dnssectools.org starting 8-Jan-2010 10:45:12.979 debug 3: validating @0x8249000: badsign-A.test.dnssectools.org attempting positive response validation 8-Jan-2010 10:45:12.980 debug 3: validating @0x8249000: badsign-A.test.dnssectools.org keyset with trust 7 8-Jan-2010 10:45:12.986 debug 3: validating @0x8249000: badsign-A.test.dnssectools.org verify rdataset: RRSIG failed to verify 8-Jan-2010 10:45:12.987 debug 3: validating @0x8249000: badsign-A.test.dnssectools.org failed to verify rdataset 8-Jan-2010 10:45:12.987 debug 3: validating @0x8249000: badsign-A.test.dnssectools.org verify failure: RRSIG failed to verify 8-Jan-2010 10:45:12.988 info: validating @0x8249000: badsign-A.test.dnssectools. org A: no valid signature found 8-Jan-2010 10:45:12.988 debug 3: validator @0x8249000: dns_validator_destroy 8-Jan-2010 10:45:13.178 debug 3: validating @0x827d800: badsign-A.test.dnssectools.org starting 8-Jan-2010 10:45:13.179 debug 3: validating @0x827d800: badsign-A.test.dnssectools.org attempting positive response validation 8-Jan-2010 10:45:13.179 debug 3: validating @0x827d800: badsign-A.test.dnssectools.org keyset with trust 7 8-Jan-2010 10:45:13.185 debug 3: validating @0x827d800: badsign-A.test.dnssectools.org verify rdataset: RRSIG failed to verify 8-Jan-2010 10:45:13.186 debug 3: validating @0x827d800: badsign-A.test.dnssectools.org failed to verify rdataset 8-Jan-2010 10:45:13.186 debug 3: validating @0x827d800: badsign-A.test.dnssectools.org verify failure: RRSIG failed to verify 8-Jan-2010 10:45:13.187 info: validating @0x827d800: badsign-A.test.dnssectools. org A: no valid signature found 8-Jan-2010 10:45:13.187 debug 3: validator @0x827d800: dns_validator_destroy A: A: A: A: A: A:
A: A: A: A: A: A:
3. Confirm whether or not the recursive server can validate the queried name Inspect the server log for any entries which indicate the validation status. The things to notice about the log entries above are that all of them are at level debug 3 except for two, both of which state no valid signature found for the name under validation. Therefore,
122
we can confirm that the recursive server failed to validate the queried name. At this point, it will be very useful to know what the authoritative server is serving to further assist with the troubleshooting. 4. Find the authoritative name servers for the zone The administrator will need to use dig against the recursive server in order to find the authoritative name servers for the zone. The query and output would look like as follows:
# dig test.dnssec-tools.org ns ; <<>> DiG 9.3.2 <<>> test.dnssec-tools.org ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54654 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.dnssec-tools.org. IN NS ;; ANSWER SECTION: test.dnssec-tools.org. 84486 IN NS dns2.test.dnssec-tools.org. test.dnssec-tools.org. 84486 IN NS dns1.test.dnssec-tools.org. ;; Query time: 10 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Nov 10 11:16:37 2006 ;; MSG SIZE rcvd: 77
Once an authoritative name server is found, then you can query it directly for the data. 5. Query the authoritative name server directly The query against the authoritative name server and the output would look like as follows:
# dig @dns2.test.dnssec-tools.org badsign-A.test.dnssec-tools.org +dnssec ; <<>> DiG 9.3.2 <<>> @dns2.test.dnssec-tools.org badsign-A.test.dnssectools. org +dnssec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53334 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;badsign-A.test.dnssec-tools.org. IN A ;; ANSWER SECTION: badsign-A.test.dnssec-tools.org. 86400 IN A 168.150.236.43 badsign-A.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 20101126155159 (20101027155159 51767 test.dnssec-tools.org. cZndYlk2EdIhFfOhTCLkcaCMVlcEicX0wuDfnlnv7GBNO58JHQ3KgqaFwBHOI9JVBFUBKL6bqVJf0GC 8wyctP8MyqUe/czOaxbQvs98yy1jgIVDELG95KcNa9QG9H0TK4kJViU9br9XXJdRUlz+oTRDToaZ3M/ WtVX5IEIlaquyfpW/oDouDKfBQzcFf7GYDmP8eSrthe6ia3drOsU6Hav6Neu7GumYfMlP8cdI5r7lcs vJHLiugUnyEza8nquEYh0xNmxWGzcAYPWY4HuR3HSP3rNwLph0KNy/Yh9C4sp/4/YIMYmtc7mjyzVHR oEBzsbwoxQ68096oFKKQunRqvQ== ) ;; AUTHORITY SECTION:
123
test.dnssec-tools.org. 86400 IN NS dns2.test.dnssec-tools.org. test.dnssec-tools.org. 86400 IN NS dns1.test.dnssec-tools.org. test.dnssec-tools.org. 86400 IN RRSIG NS 5 3 86400 20101126155159 (20101027155159 51767 test.dnssec-tools.org. g3KDL9VUyQmdaSlpX/SX4Co8jkQ3sKt3SNvsIxJQzCmfPi10V3L+4RzH2xl8hFzn1yRQtO7ZIY311TB 8X0h+E1+VUpL7VCbY32rbQWt5gDh5UG1GzqOh0rMkqjuDykomolPqjjheoEsSa8B/QIZCSpEeKJgZXb LkbdBQWmPp8mXjAU5HDSmFDW/Z1bLBUvRdueeNtXXmMJrH/+rYb0le3LxdXJxaByquf02jZBu3a3DEm xErkOdk7jC8dZk2F00+E5XYVwkBxJyZqYui18SITztuNPYzvMYG968Zj4viFSEJk6fvkT3eCbtGcrmy ISWSmE2WUBiljxODt3nRCKJQ3A== ) ;; ADDITIONAL SECTION: dns1.test.dnssec-tools.org. 86400 IN A 168.150.236.43 dns2.test.dnssec-tools.org. 86400 IN A 63.195.146.66 dns1.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 20101126155159 (20101027155159 51767 test.dnssec-tools.org. GWZm9GJ0XCsBoIVvnrbhcXxi573RkWCKlN+1xIsuDHMlK1F+Dbsfe2jlnqXEEBgFijFydCSx/BztzaO jfBHV3HcTl6A3D+wNAnZkeCRExD2hZA19PmSgIVF6Lq8O2scV5ZRHr31oVUgEvPHBfNWgmioc8fQiYE gkOxl/Gck2sPKz+F2ZmZaQaIh0/qbYaUL/Q3VN+HnKgdP4KCU4S4/cIo/Y2D5tRHen+RcUe6AKZ/bjw xfu8tIVHU71eGvNXO79FjBCSgRDmGVWMTgRookoIap5sxG+150dP5+036bd0G/mUdb96QHbJS3htr8T 1ZoFhlDE1LWCiGMAUnoNCZXMlw== ) dns2.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 20101126155159 (20101027155159 51767 test.dnssec-tools.org. gRtAJpqdDMiq6JzSaBAOgXy3eI4P9NCqfF9liK86gtSgyW6ydvxx+W1FAN92G+weWEj3pp1u+6sWxLO xy36opIE9J0Rbrs69STEKgLDbpun7UG7+HcdQcY85IbIiBummCU/j+D4gApxIi+m7GLaVhteGEACmr5 1Z5Sxg9DSz77LxfVnTHKqpNYOxZBn9wMJyTrC1H4A0wQe+osjoJdOaN3BllDmTuKuak1VZmkbZw8LEh pEE6RUvSll4GJqzoH2OaTXd0Oka963oDA3wEXXV7j8dKIcnbP1qaIUGLkBnIOEkYVyGkiN1I12ZhbE6 VG5GrPHX12RkbXS7FBflxFf2hQ== ) ;; Query time: 142 msec ;; SERVER: 63.195.146.66#53(63.195.146.66) ;; WHEN: Fri Jan 8 11:19:32 2010 ;; MSG SIZE rcvd: 1382
6. Check for the existence of a signature for the queried name From the query output against the authoritative name server above, you will want to confirm that there is an RRSIG record that covers the A record for the queried name. The bolded text in the output above confirms that the signature does indeed exist. Therefore, we must continue our troubleshooting. 7. Check if the signature has expired The signature expiration date is the first date listed in the bolded RRSIG record in the output response above. Since the expiration date is confirmed to be in the future, we must continue our troubleshooting. 8. Check that the signature is from a key that is published in the zone To determine this, the key id field in the RRSIG record, which is the first field after the two date fields (in the bolded text in the output above), is checked. In this case it is 51767. To check this value, another query must be performed against the authoritative name server for the DNSKEYs published in the zone:
# dig @dns2.test.dnssec-tools.org test.dnssec-tools.org DNSKEY +dnssec
124
; <<>> DiG 9.3.2 <<>> @dns2.test.dnssec-tools.org test.dnssec-tools.org DNSKEY ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1137 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;test.dnssec-tools.org. IN DNSKEY ;; ANSWER SECTION: test.dnssec-tools.org. 86400 IN DNSKEY 256 3 5 (AQOxosf/UIhWBFufgkBYL4bx5d897k8wgMQvXNmkOU+L4uu1CB3wgHePnKCJscdDm9UXJyT0Z5Pdlq rr+05SO614HWKXij5niHWMhBbZJaZSWAFBb1N8aMTtf+SZ6niocoajBcqU0UTMtAgxsdh3siaAPiLam RFc4c/EuI3f8Z0iR0td54KPt+8u8hUkWoLRTbOOCXtSzCl+ZsUws5HyhyHjI16sodP5xtDqxzC0Xn+G xWZWxUX/10kwb4Nu/jCHjRKDAh0UZ/aFskdUouVPRCoIlTD0QIDScPgtp3hFBimChAJbraHdBI58J/g RWEVIDS5wP3ictR9n6xhLLmEUElwb) ; key id = 51767 test.dnssec-tools.org. 86400 IN DNSKEY 256 3 5 (AQPjJwI0ETCO7504DFIytx019KSZLlsXO2XeBloKihyMRz5WQjJKki7iYcYxKVrPZsdIljw+0HB+63 uuyJr1JlcJ7fwPbTXFoxpVaw22wyA6KEHitcywiuL1YU9JbTBE4iThk6dRRDm3idhIZBf7SkNbbpWbN f0GtEtL+u15fHW/YHVYXdSkEnTAwkpnhu/VSeDITbCjXhzLSylUhpbZVcS7pGlG0Mhagu2jbFW9R1Cn 7NZ155cqNGXkvHQxeQDhUpy5DNf9HTH/6hFzjMXFey5A1x5A9otCy3RduR2poX+8CQ9m3Q0MxxqbWRu EozR1eYRVS/ZHHOpdqJ8mZcT9zQiT) ; key id = 16442 test.dnssec-tools.org. 86400 IN DNSKEY 257 3 5 (AQPUlH65Otuo6toxYX2zHCwdojmAKFa9gobYWrNEojKQAWJuvGMd4okTnlOJTL0hBWKC4Uhf40ePpD R8QJayeI/eZg29UZLMBleZ96a0mSo/JU4Sq3G06X9d5Z01EVCvTkJUHHEvvmzZhBsO+43NcWYrSUoXX 1JbXs9QKuO1BLPHuS5G/UfEsyVonfl39dGrEput1gDWxIvov2UENM2eX0LE5ZIyGiX2uDdN4SVIa0Rd +F2pSCiddE1bYxIi2IlW6bpeim+mdC1BDJkEB70+ekeBR3as5D339z+9KeMyZgPs82SAQswbGdZvkWL 8mgSdbf6DiuTkkNIUzbS/6fxlQO/GOdq0NlTr28sW4Byj9gkpb2Clbqog72yJJ3s5CV4LGZ1jtpnoFc sKwMlLnOj0X+L2iY7Spe5M9D59Jqxl9cAWjATsSXG5TvCUNBT2Eh6Jw7OimThJe4pUmFxGqhplPqs2d lnDgfcuVNf9lwa36Re7pUt+FlT0A9FIWk4utfUgZO3eWnKrw1Fw8QF9wKm252iscULNzKwYvfK8NGSB OfyYRvAw7ZnAoxMKFIOLq3W8IsFjti5dLhLYWpFEGZOT+eDc/lPhyaEsmsjHQnEEyj4TmomV8n91s3H 8IbrKu0cdIH1/k5iu+sLi9EIAprOnxrxO+tHDiEZUoimBRFtETCcmsQ==) ; key id = 28827 ;; AUTHORITY SECTION: test.dnssec-tools.org. 86400 IN NS dns2.test.dnssec-tools.org. test.dnssec-tools.org. 86400 IN NS dns1.test.dnssec-tools.org. ;; ADDITIONAL SECTION: dns1.test.dnssec-tools.org. 86400 IN A 168.150.236.43 dns2.test.dnssec-tools.org. 86400 IN A 63.195.146.66 ;; Query time: 131 msec ;; SERVER: 63.195.146.66#53(63.195.146.66) ;; WHEN: Fri Jan 8 11:34:22 2010 ;; MSG SIZE rcvd: 1187
Looking at the output above, the first DNSKEY record listed has a key ID of 51767 which matches the key id in the RRSIG record. Therefore, we have confirmed that the signature is from a key that is published in the zone. If the signature was not from a key that is published in the zone, then this may indicate a zone corruption issue or possibly an attack. Note: For illustrative purposes, the issue in this troubleshooting session was deliberately caused by modifying the signature associated with the queried name so as to make it bad and to cause the validation error that we encountered.
125
Appendix A. OpenDNSSEC Installation Notes For RHEL 5.3 OpenDNSSEC and all pre-requisite software were installed on a RedHat Linux instance at 10.131.138.2 (pcie). Identified the specific RHEL distribution as Enterprise Linux AS release 5.3 (Tikanga) via the following command:
# cat /etc/redhat-release
Box already had the following packages installed in /usr/bin: yum 3.2.19 gcc 4.1.2 g++ 4.1.2 perl 5.5.5 openssl 0.9.8e-fips-rhel5 m4 5.97 automake 1.9.6 libtool 1.5.22-6.1.x86_64 java 1.4.2 The yum package manager was used for obtaining/installing software with many additional dependencies on other software packages (e.g., python, ruby). Before using yum, make sure to configure and set up some yum repositories in the /etc/yum.conf configuration file. Made the following environment settings (defined in /usr/src/redhat/env.sh):
# export PATH=/usr/local/opendnssec/bin:/usr/local/sbin:/usr/local/libexec/opendnssec:/usr/local/bin:/ usr/bin:.:$PATH # export LD_LIBRARY_PATH= /usr/local/opendnssec/lib:/usr/local/lib:/usr/lib::/lib:$LD_LIBRARY_PATH:. # export SOFTHSM_CONF=/etc/softhsm.conf # mkdir p /usr/src/redhat
Copied the following packages to /usr/src/redhat and installed as the root user: Python (2.4.3-27)
# yum update python # yum update python-devel
OpenSSL Development Package (0.9.8e-fips-rhel5)

# yum update openssl-devel
ldns-1.6.1.tar.gz (http://www.nlnetlabs.nl/downloads/ldns)
126
# # # # # # # # #
gunzip ldns-1.6.1.tar.gz tar xvf ldns-1.6.1.tar cd ldns-1.6.1 ./configure make make install cd examples && ./configure && make make install cd ../..
libxml2 (2.6.26-2.1.2.8)
# yum update libxml2
libxml2-devel (2.6.26-2.1.2.8)
# yum update libxml2-devel
Botan-1.8.7.tgz (http://botan.randombit.net/download.html)
# # # # # # # # # # gunzip Botan-1.8.7.tgz tar xvf Botan-1.8.7.tar cd Botan-1.8.7 ./configure.py make make check make install ./check validate ./check benchmark cd ..
ruby (1.8.5):
# yum install ruby # yum install ruby-devel # yum install ruby-rdoc
rubygems-1.3.5.tgz (http://rubyforge.org/projects/rubygems)
# # # # # gunzip rubygems-1.3.5.tgz tar xvf rubygems-1.3.5.tar cd rubygems-1.3.5 ruby setup.rb cd ..
dnsruby-1.36.gem
# gem install dnsruby
4Suite-XML-1.0.2.tar.gz
# # # # # gunzip 4Suite-XML-1.0.2.tar.gz tar xvf 4Suite-XML-1.0.2.tar cd 4Suite-XML-1.0.2 python setup.py install cd ..
sqlite-amalgamation-3.6.17.tar.gz (http://www.sqlite.org/download.html)
127
# # # # # # #
gunzip sqlite-amalgamation-3.6.17.tar.gz tar xvf sqlite-amalgamation-3.6.17.tar cd sqlite-3.6.17 ./configure make make install cd ..
autoconf-2.64.tar.gz (http://www.gnu.org/software/autoconf/#downloading)
# # # # # # # # gunzip autoconf-2.64.tar.gz tar xvf autoconf-2.64.tar cd autoconf-2.64 ./configure make make check make install cd ..
opendnssec-1.0.0b2 (http://www.opendnssec.org/files/source/opendnssec-1.0.0b2.tar.gz )
# cd OpenDNSSEC/OpenDNSSEC-1.0.0b2 # sh autogen.sh (ONLY if configure # ./configure --localstatedir=/var # make
is missing)
For V1.0.0b2, please see Appendix G for the workaround to a known build issue
# make install # cd ..
softHSM-1.0.0 (http://www.opendnssec.org/files/source/softhsm-1.0.0.tar.gz)
# # # # # # cd softHSM-1.0.0 sh autogen.sh ./configure make make install cd ../..
Rebuild Dynamic Linker Cache

# /sbin/ldconfig /usr/local/opendnssec/lib /usr/local/lib /usr/lib /lib
When the install/configuration/initialization is completed, the following identifies the OpenDNSSEC installation folders and files/binaries (please note that installation/working folders are either specified via the configure command for OpenDNSSEC or else defaults are used. You may also need some other options to configure. (Use the ./configure help command to find out which):
/etc/
128
softhsm.conf
(need to edit)
/usr/local/bin/ softhsm ods-hsmspeed ods-hsmutil ods-ksmutil ods-auditor ods-control ods-kaspcheck ods-signer sqlite3 ldns*
/usr/local/sbin/ ods-enforcerd ods-signerd
/usr/local/libexec/opendnssec create_dnskey finalizer get_serial nsec3er nseccer signer signer_threads sorter zone_fetcher zone_reader
/usr/local/share/opendnssec/ conf.rnc database_create.sqlite3 kasp.rnc signconf.rnc zonelist.rnc
129
conf.rng kasp2html.xsl kasp.rng signconf.rng zonelist.rng zonefetch.rnc zonefetch.rng
/var/opendnssec/ kasp.db slot0.db (need to create) (need to create)
/etc/opendnssec/ conf.xml conf.xml.sample kasp.xml kasp.xml.sample zonelist.xml zonelist.xml.sample zonefetch.xml zonefetch.xml.sample (need to edit) (need to edit) (need to edit)
/var/opendnssec/unsigned example-zone.com test-zone.nl (need to create/edit) (need to create/edit)
/var/opendnssec/signed example-zone.com test-zone.nl (generated during signing) (generated during signing)
/var/opendnssec/signconf example-zone.com.xml test-zone.nl.xml (can create or auto generated when signing) (can create or auto generated when signing)
130
Appendix B. Additional OpenDNSSEC Utilities The following additional utilities from the OpenDNSSEC trunk Subversion repository (http://trac.opendnssec.org/browser/trunk/) are not distributed with OpenDNSSEC: hsmbully to test an HSM for OpenDNSSEC compliance Available from the OpenDNSSEC trunk Subversion repository at: http://trac.opendnssec.org/browser/trunk/hsmbully The hsmbully tool is designed to verify if a token, HSM or other PKCS #11 implementation suffices to support OpenDNSSEC. It is intended to allow a test before setting up full-blown OpenDNSSEC on the token, but as a result of that it cannot give 100% certainty that a token will suffice. In most cases however, it can give ample warning if the token would give problems when running full blown OpenDNSSEC. There are two modes of operation for hsmbully; one is destructive, meaning that all the contents on the token will be wiped, and the token will be erased. The other mode of operation is non-destructive; in that mode the space left in the token is used for testing. It is up to the tester to ensure that a fair amount of space is available to increase the likelihood of testing properly, which means that at least a number of keys should be able to co-exist in the remaining space. The default mode of operation is non-destructive, but this choice of default was made for reasons of safety rather than to get the sharpest test results. The tests run by hsmbully take hours to complete. The results are reported through the CUnit framework, and dumped into an XML file. The intermediate objects created on the token for tests will be removed after successful termination of hsmbully. The tests performed by hsmbully are deterministic a second run with the same parameters and on the same initial token state should run in exactly the same way. This is ensured by an internal "random" number generator that is reset with a given seed. To build hsmbully, follow the following steps: Download CUnit-2.1-0-src.zip from: http://sourceforge.net/projects/cunit/files/CUnit/2.1-0/CUnit-2.1-0src.tar.gz/download
# cd /usr/src/redhat # gunzip CUnit-2.1-0-src.tar.gz # tar xvf CUnit-2.1-0-src.tar # cd CUnit-2.1-0 # ./configure # make
131
# make install # cd /usr/src/redhat/openDNSSEC/trunk/hsmbully # sh autogen.sh # ./configure # make # make install (installed /usr/local/bin/hsmbully)
zonegen.pl to generate zone files. Available from the OpenDNSSEC trunk Subversion repository at: http://trac.opendnssec.org/browser/trunk/testing quickstart.sh to set up a quick test environment for OpenDNSSEC. Available from the OpenDNSSEC trunk Subversion repository at: http://trac.opendnssec.org/browser/trunk/utils
ods-hsmspeed does performance testing on your HSM. This is also useful to find out at what speed you can get from SoftHSM on your CPU. Available from the OpenDNSSEC trunk Subversion repository at:
http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/libhsm
132
Appendix C. ldns Project Utilities The goal of the ldns project is to simplify DNS programming. It supports recent RFCs like the DNSSEC documents and allows developers to easily create software conforming to current RFCs, and experimental software for current Internet Drafts. A secondary benefit of using ldns is speed; ldns is written in C so it should be a lot faster than Perl or another interpreter-based language. ldns depends on OpenSSL for its cryptographic functions. The ldns library includes some examples and tools (included in the source of ldns) to show how it can be used. These include: 1. ldns-chaos - Retrieves all the addresses of a name server and then queries each address for its version.bind and hostname.bind. 2. ldns-key2ds - Creates a DS record from a DNSKEY record 3. ldns-keyfetcher - Fetches DNSSEC public keys for zones 4. ldns-keygen - Generate private/pubkey key pair for DNSSEC. 5. ldns-mx - Explained in the tutorial. Prints the mx records for a domain. 6. ldns-read-zone - Reads a zone file and prints it with 1 RR per line. 7. ldns-signzone - Used to generate a DNSSEC signed zone. When run it will create a new zone file that contains RRSIG and NSEC resource records, as specified in RFC 4033, RFC 4034 and RFC 4035. Keys must be specified by their base name (i.e. without .private). If the DNSKEY that belongs to the key in the .private file is not present in the zone, it will be read from the file <base name>.key. If that file does not exist, the DNSKEY value will be generated from the private key. Multiple keys can be specified, Key Signing Keys are used as such when they are either already present in the zone, or specified in a .key file, and have the KSK bit set. 8. ldns-version - Prints the version information of the ldns library and tools. 9. ldns-update - is used to send a dynamic update packet. 10. ldns-walk - 'Walks' a DNSSEC zone 11. ldns-zsplit - Splits a zone file in smaller parts 12. ldns-zcat - Concatenates zone file parts split with ldns-zsplit 13. ldns-compare-zones - See the differences between zones (added/removed names, added/removed rrs for names) 14. ldns-dpa - DNS Packet Analyzer. Analyze DNS packets in IP trace files 15. ldns-resolver tries to create a resolver from a resolv.conf file. This is only useful to test the library for robustness with input data. 16. ldnsd a simple daemon that answers queries for a zone. This is NOT a full-fledged authoritative name server!
133
17. ldns-notify sends a NOTIFY message to DNS servers. This tells them that an updated zone is available at the master servers. It can perform TSIG signatures and it can add a SOA serial number of the updated zone. If a server already has that serial number it will disregard the message. 18. ldns-testns can be used to provide answers to DNS queries for testing. The answers are premade, and can be tailored to testing needs. The answers can be wildly invalid or unable to parse. This program is a debugging aid. It is not efficient, especially with a long config file, but it can give any reply to any query. This can help the developer pre-script replies for queries. 19. ldns-verify-zone read a DNSSEC signed zone and verify it. RRSIG resource records are checked against the DNSKEY set at the zone apex. Each name is checked for an NSEC(3), if appropriate. 20. ldns-revoke is used to revoke a public DNSKEY RR. When run it will read file with a DNSKEY RR in it, sets the revoke bit and write back the output to a file 21. ldns-nsec3-hash is used to print out the NSEC3 hash for a given domain name. These utilities are not compiled by default. You need to explicitly build them with:
# cd ldns/examples && ./configure && make # make install
After installation, the ldns utilities will be available in the following folder:
/usr/local/bin
The man pages for these utilities are installed under the following folder:
/usr/local/share/man/man1
For example, to view the man page for the ldns-key2ds utility, use the following:
# export MANPATH=/usr/local/share/man:$MANPATH # man ldns-key2ds ldns-key2ds(1) ldns-key2ds(1)
NAME ldns-key2ds - transform a DNSKEY RR to a DS RR
SYNOPSIS
134
ldns-key2ds file
DESCRIPTION ldns-key2ds is used to transform a public DNSKEY RR to a DS RR. When run it will
read file with a DNSKEY RR in it and it will create a .ds file with the DS RR in it.
It prints out the basename for this file (K<name>+<alg>+<id>).
OPTIONS -n Write the result DS Resource Record to stdout instead of a file
-1
Use SHA1 as the hash function (default)
-2
Use SHA256 as the hash function
AUTHOR Written by the ldns team as an example for ldns usage.
REPORTING BUGS Report bugs to <ldns-team@nlnetlabs.nl>.
COPYRIGHT Copyright (C) 2005 NLnet Labs. This is free software. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
30 May 2005
ldns-key2ds(1)
135
Appendix D. Using SQLite OpenDNSSEC works with SQLite out of the box to store KASP configurations and other important information. To interact with these SQLite databases, follow the commands below:
# sqlite3 /var/opendnssec/slot0.db <enter>
sqlite> .tables <enter> Attributes KEYDATA_VIEW Objects PARAMETER_LIST PARAMETER_VIEW Token categories dnsseckeys keypairs parameters parameters_policies policies securitymodules serialmodes zones
sqlite> .databases <enter> seq --0 1 name --------------main temp file ---------------------------------------------------------/var/opendnssec/slot0.db /var/tmp/sqlite_TjURasmkfMBG560
sqlite> .help <enter> .databases .dump ?TABLE? ... .echo ON|OFF .exit .explain ON|OFF .header(s) ON|OFF .help .import FILE TABLE .indices TABLE .mode MODE ?TABLE? List names and files of attached databases Dump the database in an SQL text format Turn command echo on or off Exit this program Turn output mode suitable for EXPLAIN on or off. Turn display of headers on or off Show this message Import data from FILE into TABLE Show names of all indices on TABLE Set output mode where MODE is one of: csv column html insert line list tabs tcl Comma-separated values Left-aligned columns. HTML <table> code SQL insert statements for TABLE One value per line Values delimited by .separator string Tab-separated values TCL list elements (See .width)
136
.nullvalue STRING .output FILENAME .output stdout .prompt MAIN CONTINUE .quit .read FILENAME .schema ?TABLE? .separator STRING .show .tables ?PATTERN? .timeout MS .width NUM NUM ...
Print STRING in place of NULL values Send output to FILENAME Send output to the screen Replace the standard prompts Exit this program Execute SQL in FILENAME Show the CREATE statements Change separator used by output mode and .import Show the current values for various settings List names of tables matching a LIKE pattern Try opening locked tables for MS milliseconds Set column widths for "column" mode
sqlite> .exit <enter>
# sqlite3 /var/opendnssec/slot0.db 'select * from Token' <enter> 0|OpenDNSSEC 1|9FE5E2EABD23564BCDC65E3262B2AD5DFF7578C2FB3E0F63FB8CA41807076063 2|9FE5E2EABD23564BCDC65E3262B2AD5DFF7578C2FB3E0F63FB8CA41807076063
137
Appendix E. Sample Script For OpenDNSSEC <NotifyCommand> The following is a sample Unix shell script which may be configured via the <NotifyCommand> tag in the conf.xml configuration file for notifying BIND to load a zone file that was signed using OpenDNSSEC:
#!/bin/sh #------------------------------------------------------------# File: /usr/local/opendnssec/bin/install-zone.sh # # Two arguments should be provided: zone and zonefile # zone is the name of the zone being loaded # zonefile is the file where the new zone is contained #------------------------------------------------------------if [ $# -eq 2 ]; then ZONE=$1 SIGNED_ZONE=$2 # Configure these as needed for your BIND installation ZONE_DIR=/etc/bind BACKUP_DIR=/etc/bind/zone-backup ZONE_FILE=`basename ${SIGNED_ZONE}` CURRENT_ZONE="${ZONE_DIR}/${ZONE_FILE}" if [ $UID -ne 0 ]; then echo "Must be run as root!" exit 0 fi test ! -d ${BACKUP_DIR} && mkdir ${BACKUP_DIR} /usr/sbin/named-checkzone -i local ${ZONE} ${SIGNED_ZONE} &> /dev/null if [ $? -eq 0 ]; then # Backup the old zone SEQ=`date -u +%s` cp ${CURRENT_ZONE} ${BACKUP_DIR}/${ZONE_FILE}.${SEQ} # Copy the new zone cp ${SIGNED_ZONE} ${ZONE_DIR} # Reload zone rndc reload ${ZONE} fi fi
The corresponding <NotifyCommand> tag in the conf.xml file looks like this:
<NotifyCommand>/usr/local/opendnssec/bin/install-zone.sh %zone %zonefile</NotifyCommand>
where %zone and %zonefile are placeholders handled by the signer_engine that are replaced by the zone name and the signed zone file as indicated in the zonelist.xml file.
138
Appendix F. Sample OpenDNSSEC Signed Zone The following is the generated signed zone using NSEC for the test zone (/var/opendnssec/unsigned/example-zone.com) defined above in Section 3.2.4, Processing Input/Output:
; Signed on 2009-11-30 18:46:34 example-zone.com. 3600 IN SOA zone.com. 1259624794 10800 3600 604800 3600 example-zone.com. 3600 IN NS dev-ng-core4.example-zone.com. dnsuser.exampledev-ng-core4.example-zone.com.
example-zone.com. 3600 IN RRSIG NS 7 2 3600 20091208111617 20091130234134 25187 example-zone.com. qYCw2BoY/EEroUUXYHZDo1e8RwJ6OQvmIlMy8NA+ul/W8vKvytIC1p6dSXXq8dtgEPwQdYdf3S8MmbiaGmwYZl7TfpRcb647U +Nk/r2ZTj9awLMQSBJyIq6L7hzJYN3s7puaO91MvYJLnTScB/0zbllTDdfieOmBuHyIkXRcxo9a/463tv5ZRHFvORVSkkhEFT ifbwKzPsWtwLr/dDZPmzUmluFwt0hyz13bb2D7UJVKdbiiYZfMZXbo7mgLAxEQgfyGTjb1/46HxxaEQHHj+w5jJOjFdSLODbR 3QVXfNrFoFuwYOV3kB9VnTWHVqu0LmviDGRmllVNQES5NfkWo7A== ;{id = 25187} example-zone.com. 3600 IN RRSIG SOA 7 2 3600 20091208102120 20091130234134 25187 example-zone.com. b4AzIkcr8q63UWP8y4ga3LzMEcTg3xfJefqR1GSq5oUx6XodxYtq6jKwxdJ1l/KeSLN9ASKbCAbAF3K1UNRqnuaw3mD/CK6Wb QbQf22vXFhKNlmVccaWj+FOWs88JVQviKFyWtaqjSG1VFR4kH3baJCBZ3LfX6GxGdKZpvjyTK12IXCOvctXWEHRHGtQsbby5e UzxNwiA7bkLBklHOPpTOrv8MdkPVOaiAmzQEKFFyZ+Oiy5WpD6zYW8MUvRfJV4QVi6DEH2C/IDZ0EAmLeHa4FSLVYeJuKWpgJ JGp7C4fTS8bx/jLFi0JS9wL5btiHWmFy4mlu6B0FBOMgbMbP9ig== ;{id = 25187} example-zone.com. 3600 IN DNSKEY 256 3 7 AwEAAconKhRicPqK2NRP/r3gDvwqlM3AATnV27QBdSEB5xEtgWR3ELFP8KBGqBUf5ZedBykLS9TlFNZJUBFNp4/Muqfy3D5MD QW0C+Cd7EbV9EeQl5Z29hgftT+YT8jZc+LPOIGgECEewG2/glxI3Z739xk6YxdO+IJB9RkpfHAcN6ZVvM+jRX18f3UbBRpJ/1 FLrZMYnGJigAxVRk27EGbSmIhn7ipG8DOU24zYnzovzYgURrkK+mUWKWEFM2K05v1a7htGSFMp3jVFqRPFPCinbG5aoSHxwWi NZHKv0R4/Ced0dtbzX22SFX78UVWx47gePMFq3clv4uKoDrRZOrV9aRk= ;{id = 25187 (zsk), size = 2048b} example-zone.com. 3600 IN DNSKEY 257 3 7 AwEAAZtiVOCNTCQsMPyfukZ5Hq2ALXDjjS0bdkE2DFADX2JFGEI9f9aJIk23cpUEN8y4wRIaxa3RtOuyQhVg0RnvVmNfcd32N QArnYOQOgGIuUGrdCVg9X9fYYbPFKCvik9nczCwYpLq61Of6A4S5qwqxLLbNqjgVz4EQz3jcQpCq7sd ;{id = 26364 (ksk), size = 1024b} example-zone.com. 3600 IN RRSIG DNSKEY 7 2 3600 20091208003931 20091130234134 26364 example-zone.com. bIUS2YVD6LO/Sgz3pjGcF5ALUtCj2oxeRYKgi7YvzRvwJ0+7zgQ+T3Vd4VQdMbDfzkenoTIuQ938eHKav/rFvuqTlKIJsgfTJ IgsdsXXU9FMZIxoHOBopE9qPbF+LNIS98DHPmg/nZMzqatZpxvuc+K7PFPCXueTrJrA7mRB5pw= ;{id = 26364} example-zone.com. DNSKEY 3600 IN NSEC achilles.example-zone.com. NS SOA RRSIG NSEC
example-zone.com. 3600 IN RRSIG NSEC 7 2 3600 20091215074829 20091130234134 25187 example-zone.com. Ujp0zxMh90+VvBiJ43934nkJ/G2lJ/nLbydJp1w+HOu6uaSKsGAS5KOq1wyP3uXJGwVD8Jo34r4IFxzsle9UYZCGHoIQranN8 pBHXbODKWrrO4jNvmfQgLtjduj9NdvO+lyfVj9eiYWoC6LPiA+Q8i1AWx3C4c84cQ/lM8/jH5KKM5X15ulAgSlN4UJd5Xsa8K k0XLN8vTnmJ16rz65D8uhevF8nAHMsRKUW+q5i2D9huqCv475QuJtYEanqaygvQo70leJppCoRyOdWwbbDKcMsx96H2yAe0FD OSwlUMrLTDlb1kFUdIeJAw1ABXcLhB8r2w6JTgHoDJ8pGvmYMsQ== ;{id = 25187} achilles.example-zone.com. 3600 IN A 192.168.5.20
achilles.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208023627 20091130234134 25187 example-zone.com. CGhoKC8wgnfIqUa9Qgn4Il9MQxKoH0cwRc/XRdIMVxB03PvsT95YYPCgmgLvy0J/7MbRGbyV17ejkrvoD73WA7Dhd07dHmns3 Kxc5s5A56eR/IXnowHq6BECREUii3H1K8ERq2/T4F6px2dt4XfhMwTVlusDhTPuq+wJKgo0kXk/Pd3LOEXJvQ6Yp2H4Vt3unk
139
64EgcGs8+0oNK6+Rrj2S/Go4koA0N8O+5vi57F7a0pGuN7eTcdtsUEt073nXbEmLgm8lG4BHGp49iPtrHtG1S1+U4Zr5ZQBcg EIcjuk1c8YDvZRjc8JWNYhbYlh5ZTgixdfWQgVp1MylnGGnOQMA== ;{id = 25187} achilles.example-zone.com. 3600 IN MX 10 achilles.example-zone.com.
achilles.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208034529 20091130234134 25187 example-zone.com. GfILMnmC6YRgdmSgo6dgOgOvAkhxqlxnZJConw5OeIkMZACfP692KgYdwQAkpV1F6AScbNe5SaSQkVlGL7b2G5u+i9B1ZJR3N 3rHow53hDBF1cFgNBlROCQVk6LevtIvysxPAEo6MyW7yi8XlEMERsps9gonQ2iaZKP1ol+vf/Te/JPEKldT9abPpjxG5z/yS9 I9odvPomPdcSXczzaKR+PAFgtKHEC+B0cQPdWSRcBz5a2z3etPrL4pMqnPIOZdo7W1a9NmC0zbSKVl1MbwCM5HhccV4FqebnX 561WbA8aIfQSsKmlNeoyG8GPRoVxD1GnsQFCaeqpkPuSxqy0TWg== ;{id = 25187} achilles.example-zone.com. NSEC 3600 IN NSEC agamemnon.example-zone.com. A MX RRSIG
achilles.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091214235620 20091130234134 25187 example-zone.com. iIc52jeRvcNz6hsNtGBolyN5E0whf7jQwJEynvrFOX8KJnqbKattLJWSm3LZ6N6exyZ0g6znzcVZjw1IZ16PRfAa7mFu4neYU Xu9anPw4KylTbOyZPd44vm3GPkq91kgeYOhPi02+Epk5SeWmmCxar7mGr2O/Ka1y7cYMMlQuhDANrssLlvZUT6krmG5JFrNd8 bubdkpqz0wRp8HC3E/ec7UfscH2HCLwZGRxRio0caDNGJjF5pv/IA/KVxezZhzmOfJFOCMh1GAue/zuSi1XMpcs4ClPXSeRZk 0ZXtkTI/mg45WCUNHQtED95ojDKSVHXbZB3wlmTiWBDIiG7y0Nw== ;{id = 25187} agamemnon.example-zone.com. 3600 IN A 192.168.5.21
agamemnon.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208103446 20091130234134 25187 example-zone.com. cAnhUqrNjCw1qEyVtwoC6tcysym32NIL7K99CAC+qYOyI5BlkTJ23W8khGgIVr+rypnRll3KOCYlCh2mXNhPtJe/1oVFFE+r8 nLcwu1+b2BXKOBDwAmfu9vchnVlPAI0cLfVrLFOgqNR/e9wyAZA3Z7ketMVyBchuYsffO6tMk+de9JDoXxGZobVhWVwGxatFM qhClgin75mAtfID4Draeep1+Lr/iuRK+EOkbw5QNSflofzWiL59FERAX90q9NfQPMi6gyOJn0lFtvoHxv32y751MfkGiDcLqC dDndMZxeDUoUV47VGOTX9Jleh7UU6E9u7H0ipZoPMq4OUJQbUjA== ;{id = 25187} agamemnon.example-zone.com. 3600 IN MX 10 agamemnon.example-zone.com.
agamemnon.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208025043 20091130234134 25187 example-zone.com. RM893h0e6cMzx2MxKFEyQFJSgxMpziP5TUmvmCkHXCdAstVeq+v3v5XAB5lgRxvuz9lstcudTB9PZEuJQdzARq4oprz3QXHgn 8L66zKEHOIwvyAcX6PPkIxRQA+M7chl6maHDSveahyU2sb5Q9lZIWYxMdKfuZ8z1UDic3uJPLmuqoh6kfin+npwzVKwTE+owD PBV3o0mT76d1DnYYgyp7mmDQhHQfGCBFQMVgSzlfthpCaKxIGmLEGOIPNPxfuQuiLoaFqnQzr+8h3jhmz49f+lXZAriMBBsts M4AMwy0ob0qOmWshoZsH9Ty3pAyZAknPFudwOU3QOgGq75Wqf8w== ;{id = 25187} agamemnon.example-zone.com. 3600 IN NSEC ajax.example-zone.com. A MX RRSIG NSEC
agamemnon.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215114335 20091130234134 25187 example-zone.com. Z4ObL2stDNjsM6fGKCunb8gDZAZqon0AI5+s+1o0IxhO6Jpugu1UWVTNW7PMOgh5q44MtG1VQvJjM7QuXjVeKqRZtmffrGKqR GMohg3M5qCEDuCRiZywlKe3X2y+uQ/qgQl38OLUHiYCGHw1LSgYgiww9k31hgaLiHHVp58liLJCsPu6pnN+zZejN215sb0cxw nuHcbtmdSdMAICXfLidbyjeRoNEo275IJPeN6WZe9XRQaRLaI0HOtPbs5Oz0EYnRQJk5+huxkKdtQFsyWQ8B8qJSQ4fqTcoXd OwCfhTN39q+ERy8j4aguM742djYpDGqEQ/aTyod9/nHCenWlVkg== ;{id = 25187} ajax.example-zone.com. 3600 IN A 192.168.5.24
ajax.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208061236 20091130234134 25187 example-zone.com. IxxRm42/FPCRQKXKhFCyX7kxXQqdIKkrqiytdubGPFsPyCirn8Q2SfXVFvqFWTO2eCHWXKwhECNcmeAulM9jJWbnAR2j/9+Hr p9kZgC9f0KBAR9IGKWduYdVNc9/z+F9ykBie5fMfcaR9F8AERnY9keRXiH/Ka8l2yEXid4FMsama743cVxJ+FlKpmmd76o9O9 cWDG6r1HYOr0iaHp3mJLaIgTvBX5Nt9C6j17ucQb13R3zQWJ0PPO2MQMBtFYdNQIarT8DhGOYGvjnk3LCYYUXuz+PTyLN/U51 bewMPZTCQOZC+QcwQJ1PxO74JFWyskeOfXPdsJNcDiofEjCmbKQ== ;{id = 25187} ajax.example-zone.com. 3600 IN MX 10 ajax.example-zone.com.
ajax.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208035341 20091130234134 25187 example-zone.com. Ivv7LGKsLP8o30jFYkSisszq7IbT9Lj5YwYWLWhGNA2+GX1gzEMTwP3F+VmjSlHGBzwlrD6oBU1tRdrTMQOrB8kbTO1pA1kWy pWf1vp2FUVnBnMcIFjFYUNobqsZ7XGEglU/+7uxF1l3BDjkXLt0zGUdHnvg3/3Lri7I9uKL/1ErS3DWMuzks6q0iwiSdCd/Nu
140
3Ep67NaP/2ky+SlDqpe6aPO3wq/oDiNXzcLCIzW7re4dshKrzSPGPs3pIT9D+kHC7lKyH4LW6w8d7LcED5sB5nxd4JnhCFbzU RsjwWbJz7PND5see7yNUff3yqec+qLo0H2QqKbKHNdb5y1rm5bQ== ;{id = 25187} ajax.example-zone.com. 3600 IN NSEC dev-ng-core4.example-zone.com. A MX RRSIG NSEC
ajax.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215061124 20091130234134 25187 example-zone.com. J3hjjpBbTZbmDmMVGxNqF6hcp/561k6bRbmUa4v8MgP6esgQPJAK5YGRyWU2jDUCpYqSv4yM18jjtPtzteoF62SnQCEuAhW/G zlUv3tUIrdYGWU4DwQ2pQ8Ojq9Rpk387b+Rhm/kS0jDRBBAz4aMmivIR97PA9D0Ti8YvchSgQh66zm6kP6brb8ZGk0F0HV4tq rjlOUM96RQWAuW4KXb5E/5UF8ByoUm39A2F41lhef8ks/FlpMijm9pN5ivMnmJF8gXVkEx/eEl2L4qXFF3FY3pk8NE5ijAnR2 EBhLufst8raz8Oj+JI2qD2p0bbs3qGLApDw1+Tk1T1I6zQOveQw== ;{id = 25187} dev-ng-core4.example-zone.com. 3600 IN A 192.168.5.1
dev-ng-core4.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208032053 20091130234134 25187 example-zone.com. vnFAchlfg27VlOEHhIImMeUY5jxYIsBujmtxUEVK1TIVAuX5MgWEKgVWMwNbDamGDQBZsTy4uuSnu96VslUMFqQsbD1jwS3WJ GgjZQ+gufWxSmoImHbyD5j623vBebhJegGiSCshIC+MVxPKIk/+n/O20kak4lME7okzXLxarPO6NWgId4326VJdKMwD91jl8E cW8ZiaW12eWKd6+vniMTh6ZYIQA2uWjiSfmceGyU5f5KTFBcqf4BsRViDA7vOUR138SyIIjetMj4mAYuMN26+u1xHc6eqxxOc sWiDFnDhQkbYj0R0o0NC5oee5deQD6UURWZ0YD5Oq2Y9r10PcrQ== ;{id = 25187} dev-ng-core4.example-zone.com. 3600 IN MX 10 dev-ng-core4.example-zone.com.
dev-ng-core4.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208065557 20091130234134 25187 example-zone.com. SX9X+5/lOGd3tABtHxed00W/OgISdYOUPNY5yjgC4CuO9rKn44XyrwtLnH7/T+s0TwS/UaBGu64/KB0WwUNpDHCdclfR/VMbx Ra1RdtpOxSyhoeb6qqrSzgpqtL5UfFrYtziDjUqoGVxhB0DeYsX6JTQ45+o7ilGG4K9cP3q1WlRPPIlzO87jS23/+VANwymaj P2Tn/qJljCJ8pMbeQm7a0G21qjp1LYw9ZIGq/clq8oZ2a+pSTXOStfJ2bcd7nJB7ZYTcudw1CJL3xVxGFYuNdMhDxUhfUETtQ 1hv3Wvh6r9RwelXbqCaDg8fFJtgnwK1HCcKzzBJadJHg4Ejs2qg== ;{id = 25187} dev-ng-core4.example-zone.com. NSEC 3600 IN NSEC diomedes.example-zone.com. A MX RRSIG
dev-ng-core4.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215032520 20091130234134 25187 example-zone.com. QcTdas/zl6cJFNXkau8KRhPFD/m1a7Yyosbx9f4TcoDcxpJ4psR6zmvoql3vQjoCLiGXgLVxAyUrxrKoCQ0oUONYuqcScq/dv wJltfAvy1pN946UyOogNVuZv3dZ3WujS21DMOQjTGUYZov62NuC2LpcMDWrfruKZn0b0B0ib2LHYPNWW9qV1mv6kBB6ooS+KM jbOmC4pHEAfbioZsASxQUqcGHC4eIy1gor+581USAFFAck2gVwR8DvoXEZX3FrNgsjbXDq4NPlRzyaKm6lxGWrM+dO1wTZMdi lwleHxI9VAsiL0ajsKxAhhLZth4JiloaLWRZJNsegpHGghbMv0Q== ;{id = 25187} diomedes.example-zone.com. 3600 IN A 192.168.5.22
diomedes.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208043534 20091130234134 25187 example-zone.com. mFJu034RPsxjYC8utGvjDh/E2wXv+L8hbBM4W2PKlVb+lAMMIuUtw9xLy0dl/+UbNILJtO1IxDeRKFgVWsZS2/l1omvjc5U0t y0Q0T5Uvd4s9yHCGfoPPav+WrUgg/xzsug/JOx96BE7Yf2SInLu5lWNTG0b+Dmn5YTW9XX51ymDPojbr0f9dwGsq439fKbopo pxaRp5/t1EAjtkLnLqtyPElxEzAc3G5B0rz+29zs3SYye1kMswMKdlT2dKcXnWqciOW9/5a84UdwTO3f8ieQoMqKAfSgL5kol 0l4VBbkqN9AK351vSJpz66Sz+FRQEHiGshnpy4UUdefEnprsKCw== ;{id = 25187} diomedes.example-zone.com. 3600 IN MX 10 diomedes.example-zone.com.
diomedes.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208000340 20091130234134 25187 example-zone.com. mEbAmAn+z9gidR2uoPYAgL1510wtaIkAJ/iQ+DQRjkoBVjx9kGyAHeLEnYCB/aowezdgpnVTyDfWDSck65KRC+CZ845bMqI2f t5RcbJraej4AniEqDanfinqYAqlfroJqbcMRdc9WYwdlZKafNzrB5cRqVYGina5WYu8a0ZiON9xCLvShr3iw5k84SdQTIZqNa ROUlPbr1A1dpuGjwKa/IP1x5JocqJaaegiNxRPnzTxIA/M2xiBGyzTXlzEKBc0n71ctBOgaTpMDlf8SBNhmWKbz3bok+Fi80y C4VRj9ERhLCdiDHfqU8vTeBfJXnwFlwEL+nrvxjMhBmmSF+DPEA== ;{id = 25187} diomedes.example-zone.com. NSEC 3600 IN NSEC localhost.example-zone.com. A MX RRSIG
diomedes.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215005926 20091130234134 25187 example-zone.com. bM4nNlz4I01HGBC7TKGPlGtcDbaWCkjgFCqx646mGK8JR3g/qAW38Tsws+qiQ8yE2zBKvPJ4GIRvyoFfIpAPClgESID+tLQh4
141
loe16o13RBBUPuUQzB8Cevfj5HJ3zSnDwc2L/p7xh9vN0UygSbz5GG1NaaHBRkqb9cEeexj8ZKb78Bh1GlASQsridVm+2mWeg k3rcXpGYKCxKuNahvom8knadZ8hQbXMmSxoErceXRzSFzWoBIXbS3TQHtzEzmI/cVLVHX7BEp5qTJ64SoNFAai2tWrv3d7xty ULyVax3idPIOQt5d0yQQ+YPlX+o/vvbQw8lxUclPlVzzexngNdw== ;{id = 25187} localhost.example-zone.com. 3600 IN A 127.0.0.1
localhost.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208064850 20091130234134 25187 example-zone.com. CUgCD9lTCgeCE7Lge9ejOyzRfRX1vwu4PQOkZ0mzxuboxJKkUF/34bdBKFxVcw3spSTRwFNby+xaO+VkfJXjTaW2idW4gRoGv MLAVgd22JsGrvVFtsxlYjH1Wfv6xvmGDr/cLxmg5ceeVCbDylNG9mOM8JDonRdi3YBeAT0dqJPqLFPnj2VKS1gpVOIPXmyR2U syI0sG1Ag/sQhl0jaZfAxCRG8hTzVAJolD2Hy3N5j2OfcSMoSe32qMODLF+JohGkcM4LWr8G+CpsM28BkOEVDXFbnvTA3ojQq 0sp8MHMdKyven/DQJtGKyTCSHaWjEH2224XKn98Ns4ZnYy7aNwQ== ;{id = 25187} localhost.example-zone.com. 3600 IN NSEC menelaeus.example-zone.com. A RRSIG NSEC
localhost.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215032645 20091130234134 25187 example-zone.com. YeSj8kNM0fKk77mxZfxhkyVo+xAKIMD5apKh8Jupz3SchIVTyJ7DNQomQvauuz6CRj3nfjnzG1fbAFw36d72UH+g/yDYKO5AQ oLWYI/hayZeoaiPwvxHYiGpcAF1uFA+OfwyXIj0Ig0G0dphuyIrHv9aNhzc/Vnf0MrDpzZYDICAmuxDcb5CY5KiKFU1JqUWO4 3gyGBD2Br/GNYpkZLiHmpmWezqaDf3J9UCUNYTkzPgHjQI5vE53CIPD8kk2ZmZXNc6+H7IYMx+pvHb/yOkuvLzvLFZUSrgHQQ FupvSy9wXZ/vBXKIWmpI4Pw+6qxbbtdXVqZ+BM+K8dcKgHVUieA== ;{id = 25187} menelaeus.example-zone.com. 3600 IN A 192.168.5.28
menelaeus.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208112242 20091130234134 25187 example-zone.com. oC2BETwqaOEO/RtFtMK62ScT5jo0+qXHmoFshZLbSVyGVaGe1YNytkrVsT9jWGrrPjLkCWZs+UpZPTuBZ3QUnfOAIwcTn/S1g J6in/R4T1ujqn24J7g3iPDxhoFxNTA/FESpSbHr7cpDAFXj/bAQ9uvFK1ve89bnzHn4Mm30bIJTtbwL5W8KDjThwCPuIHr2zo j1XnXnPLSgdELbpG8bRZXw6HyfNlB47MVNgqSwGGEt68wxlJjZ0rH/LkXHh4AQPXQqkyGts+OLfMNwytvGBS6CBQaa8/h5NKu SVFtpNW8MzXGBlWi+8BqExcv3Izb/ADGGaer194SpE5FEe1uInA== ;{id = 25187} menelaeus.example-zone.com. 3600 IN MX 10 menelaeus.example-zone.com.
menelaeus.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208093601 20091130234134 25187 example-zone.com. f8wk8Ze/COFCk1cpibrXqHSob7EinPzQUvQXXHeJCCA5W9QcRqUIex2EW1277jniLeAbp/ZTUss5ygiVHJKQIGitd1BP98lZA xBFglvKrXzsL74WhMXpI//qW7FTacGIpvxrkXjVz4ZnrGs5mtDUj0rChy/pl1Z21qfVQCWvfKCx3WlBtyiwShukYc6lud8Sd2 rXNYupZmztG7MZqM7QTBPC/fVW12U/wHR/ImEj/XYXv1kKFRjcJ/rNKjQXU0PtgttaNhbfpWKwQlbYFNB5abCLmVB5q3oDkra hYYdqONsS2WV0qc/mcrnb/igC+O4uJuhwn2sUqxYfhX+RVIMzpA== ;{id = 25187} menelaeus.example-zone.com. NSEC 3600 IN NSEC odysseus.example-zone.com. A MX RRSIG
menelaeus.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215095343 20091130234134 25187 example-zone.com. xP1kDH2vl3iENxVerU7bDADnmoxLaXyPESvGuOf4UlMFinCnUTAlUkK6cL1a3Evv9u+FNnFd7zD90RjXkHscCVmGNEDltCAlP +Mj31SfUkD2nZq9HTYUk3bmEJ5v5L1DDixn82aGfJc2Y+jX38N1jROoT2XFaohf1qIWbfwrCuv43zlm3xwILT+dD6YD4k+PMQ f34s+GJKHAt8RdHO3uY3oYKrj6GGzt5QMGFnISinco6R7gKlRcGNrq3gjF+lSH65efo0Mpq9Yta3200++/0HC3+Xi9UCnYGQM vEBFkJsldQAhzSh99+VxPJMH1BG8nH6q17QDs3lKEabGoGSqmZg== ;{id = 25187} odysseus.example-zone.com. 3600 IN A 192.168.5.23
odysseus.example-zone.com. 3600 IN RRSIG A 7 3 3600 20091208062936 20091130234134 25187 example-zone.com. DEgAYKcrzm+lFF6jfR+t0ntXVEPjkq/9SJazmZahJAmwY2/99PgSIiDfrSBwqBU+If+95/orzgWfPXG9wv73vatrq/buGLeLC As5XQw1mRrWZDFQWK3p1GdgSG4jz39MP0qXKwVodXyJj7aVKtwnd6+EsY5Fo2dJg2b25IZ6QFDGmrxG0WoxKKcR8gRTXRiyP9 j0hNSVdY3D/GR0dJn5Er03mN92mdNB/1oVMcjO1c8uJuYOZ0cXNL2hVwrsF9nsJz0moFMUvznUhMmfm5cDXcwWCD7HGc7MogH LNx3LHm0mlnGyFHkTfn0PtfIrCNQXt80wwLF4sEFSOPhtmtVzwQ== ;{id = 25187} odysseus.example-zone.com. 3600 IN MX 10 odysseus.example-zone.com.
odysseus.example-zone.com. 3600 IN RRSIG MX 7 3 3600 20091208002524 20091130234134 25187 example-zone.com. UtS/6LZZVsJFMKac6gnFBhzvcVOT6nwIXz2zf/q4Oj/XYE/d2edjBEM2VoetBjnN9N6XWcl30aUcAlUjFzlCO0P9LOvHljuga
142
BvABotfTdx2p1MLf7WyA4w+/+tAWy+sWDLR5JHjlgLOgKZ2+GWyscGj0kN475XPCsv3VDOCnqZ253qm1yY1uCf61HKlBhOCBc i5hy4rZIlWNbqdkiIsjbunFS+3D7gmqtAd+qAwvnAXG7PLIw37gQlMU6guo/kCHX0YhgqlupZzJm2JPFdBl86+oGhP2vlVVeQ vC3pqtpz39En8BOG93fmDP+YABDCH/frND6GCCiqSSI5yxViA3Q== ;{id = 25187} odysseus.example-zone.com. 3600 IN NSEC example-zone.com. A MX RRSIG NSEC
odysseus.example-zone.com. 3600 IN RRSIG NSEC 7 3 3600 20091215104736 20091130234134 25187 example-zone.com. KjxuNTyRd0b3NtdYQXDlOcxXGZnGSNrErMreDR/qZNpWATdntTtJYIOzB3OIDIdE/3LNNm9DTjRZoIPszxVEMV5OhQUVTWCHJ UPnCOKDOuK8dfmS94ucIk9ETY7TNYjP2M3LjU3kvTX6vmZwPx+qVGJYvT0IzoSqDyG7Si5mU5jSyGtQ6XNewod4aBbfvflLo3 EykEckSap4/IpTjyOzDZ90XfWCVw+Rgac+tL9RuD0c3wwxd+uxCQOyyPZM1YNnBmwveM9Gcua/ec/JwYn1Co+C/v1LKditCsD FpSNos0EQOGgTFh8UqJ6iMDz/wo9RiMFnMz3moNG1DlskW6UHog== ;{id = 25187} ; Last refresh stats: existing: 0, removed 0, created 2
143
Appendix G. Known Issues OpenDNSSEC Issue

V1.0.0b2 introduced a new function in libhsm. A problem in the build script makes the build process include the installed header (from v1.0.0b1) and not the header in the srcdir, thus missing the declaration of the function. As of V1.0.0b2, LDNS is having problem with SRV records. The main effect is that these records are given non-valid RRSIGs. Versions of OpenDNSSEC prior to the Beta releases do not provide any mechanisms for publishing of DS data to a parent zone.
Workaround A quick fix is to go into the libhsm dir and do

# make;make install
and then go back to the top-level directory and do

# make;make install
This has been fixed in the ldns trunk and will eventually be released with a new version You can also use ods-hsmutil to extract the public part of a key for publishing. In order to know what key to publish you need to look in your signer configuration file for your zone. This file lists all keys used for signing and inclusion, so you need to find the right key you want to publish. Then you use the content of the Locator-tag and give it to ods-hsmutil like this:
# ods-hsmutil dnskey f7fe51cdea5d1d507ba5f579d5769fc0 example-zone.com example-zone.com. 3600 IN DNSKEY 256 3 5 AwEAAbyrKAQYlkqBUoYcflB8VMy0gvNcvCRAP54Yc30eQGr6jRr e04M5A9XrhhwKahvDaI449Driobfnh1v1W5jVX9SPfx0mAG9J3o O1gZwDftEpsv728qSOSFIew5NIHnDFn9kAhDXo9zYUOws9vJ9Rr fJYnSVkrlca OCc/BCooEEb3 ;{id = 32203 (zsk), size = 1024b}
What you get in return is the DNSKEY in BINDformat, which can be converted to a DS record and included by a parent zone. Please see the man page for the ldns-key2ds command in Appendix C on how to perform this conversion
144
Appendix H. Convert DNSKEY Record Into Canonical Form A DNSKEY record must be made into its wire-formatted/canonical form before it can be made into a message digest. Below is a Java test case that does this, relying on the DNSOutput Java class (see below) that can be downloaded with all of its related code from the DNSJava project at: http://www.dnsjava.org/ The following test case shows how the wire-formatted data are being built: adding the domain-owner name as bytes derived from that name's wire-canonical form writing the flags (aFlag variable) in its 16-bit representation writing the protocol ID in its 8-bit representation writing the algorithm ID in its 8-bit representation writing the bytes of the base64-encoded version of the public key
By looking at the Java code (below) and also looking at the DNSOutput class from the DNSJava project [specifically the methods writeU16(), writeU8(), and so on], you should have all of the logic that you need for doing this. Here's the test-case code:
public void testGenerateDsDataForKsk() throws NoSuchAlgorithmException, TextParseException { String aTldName = "dskey.example.com."; int aFlag = 256; int aProtocol = 3; int aAlgId = 5; String aPubKey = "AQOeiiR0GOMYkDshWoSKz9XzfwJr1AYtsmx3TGkJaNXVbfi/2pHm822aJ5iI9BMzNXxeYCmZDRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLUUh6DhweJBjEVv5f2wwjM9XzcnOf+EPbtG9DMBmADjFDc2w/rljwvFw=="; String hashAlg = "SHA1"; // create output in wire/canonical format DNSOutput out = new DNSOutput(); out.writeByteArray(Name.fromString(aTldName).toWireCanonical()); out.writeU16(aFlag); out.writeU8(aProtocol); out.writeU8(aAlgId); out.writeByteArray(base64.fromString(aPubKey)); // create digest from wire-format data MessageDigest md = MessageDigest.getInstance(hashAlg);
145
md.digest(out.toByteArray()); String digest = base16.toString(md.digest(out.toByteArray())); System.out.println("Digest: " + digest); }
146
Appendix I. BIND dnssec-signzone Ouput Files The following are the output files from running the dnssec-signzone command in Section 2.1.3.1, above: 1. The file acme.com.zone.signed is the signed zone file using NSEC:
; File written on Tue Dec 1 12:30:48 2009 ; dnssec_signzone version 9.6.1-P1 acme.com. 86400 IN SOA dev-ng-core4.acme.com. dnsuser.acme.com. ( 4 10800 3600 604800 86400 ) 86400 RRSIG SOA 5 2 86400 20091231163048 ( 20091201163048 62460 acme.com. eJ16eU0niaDyMCKnEbIkd0DhOViG4iwHFy+d FFJzZ5pomqn0HlaDT2hVl8iZxR7EiOhxSPq3 hg/G70CxZSQUlwNEhaZrgZiAUpqJJyT8GmVw l45dvrGD5R/b9e0mzs5Su1RigwQ2+WoC1Twa CEbUPAqo3IXqTn7hipAbniBgHvk= ) 86400 86400 NS RRSIG dev-ng-core4.acme.com. NS 5 2 86400 20091231163048 ( 20091201163048 62460 acme.com. ptqh+zrJHWlWoI6aIS5p51xG62fFcJX9Sdbs mCl4ixBMFnagf97ANm7L7qoi0s2fNcZJHCig 9PNuBGGPwNPTrM1kHjrOOHczbbVH2Nu1PIUg /xvsrs2KKydBgiTD93LwyxliBLVwXlpldC6w kVvFbzfqrRPSTyyg19189Of6KVY= ) 86400 86400 NSEC RRSIG achilles.acme.com. NS SOA RRSIG NSEC DNSKEY NSEC 5 2 86400 20091231163048 ( 20091201163048 62460 acme.com. Q0D4u5jG3H1nGKhe9FbWZJr7LX+gGF75Boim LEGgzpetMeA/h26hN1PqOLyeEu71ij/4mddl ; serial ; refresh (3 hours) ; retry (1 hour) ; expire (1 week) ; minimum (1 day)
147
tFi2alCzjV1kXM+H9WJxhn80fsGQkSoO3H2J wyNIBVAqiwvhDs5dlzIeZhZftaw+pTaGB6Of op9V9eVYUSsuvBInlEMNmKM3ywo= ) 86400 DNSKEY 256 3 5 ( AwEAAbRMFoaJ3Z2lGqiNXHhIJkEPi1BZOGB1 FmoGiclcCp0aqTGQ1vXPzvgv3rQLmkP9EtuJ 6144FtmL03/VYMs+HLuhQu6Ed9us0Bggr6We VQsM7wFn4zGia1NnC88wCIT4mQJWqIGB20AR 2ZO/4OdoVwl0lNOGA1Ae+1lkQlDQ6GnL ) ; key id = 62460 86400 DNSKEY 257 3 5 ( AwEAAb93WpMYSCdoll8+GgJLqJrrBPDzWYOU fnC2jZe0rrlxTyeXFVl4mDlUOPn3uT+qSLZO Z6XDdRLhrBXrKNwYh4IwtL6XEY3+sFlBeMiw +s4BzkXmcXxczd8zEfktQIbA+XeVt5NM3JjM f3Ms5dSJVZ3O/8111g0i+LHq9ifEXFOq/+tZ wtstpDzyVhvDY3aKprNC3XZo0ZIY5RYNi4Uf onaqysCWcEOL3CfYPdDslu1j/pRCKsgZJpGX bPBVFmHm8LfHED18BQeAztUYNDnbRiyC6RzY cnOcKIQxZ/vrFTV9Z0KA3L1Cey4A2PjbfTGd mc0fnZBbt3BDZLxP3rI8tPs= ) ; key id = 6553 86400 RRSIG DNSKEY 5 2 86400 20091231163048 ( 20091201163048 6553 acme.com. D1+4JhMXu4Hh7UxMkvx6Vb0eG8NhbOxxZamH Kc2xlomBBh4wPccicSMa58rw5xhPDrxgPIny CE4ZfxRcvCHVAaEB0rYlyD+z25Qu1Xi88vyx BWRGF4W8wRjx1Ia1jIVWiEKSX2BQI/gyQwuJ OpFgXnuoIQXCP3sg5ygSWIx3PuVaYtASbEvl rQYyeZdQHgNNAdmt0hkAwrHA2KJ6QeRurc7z QyLTyoUolQJLcDrTO9Asa0qhB+bIAiYF76O7 Z67V29/+ib1N46iid04UrXB086qCnjY3Njgd MHzKlsEJx8QgwzHeuLCCBDOejlgWyqOK/8bZ h7DpZXZ5hv+nABwM4g== ) 86400 RRSIG DNSKEY 5 2 86400 20091231163048 ( 20091201163048 62460 acme.com.
148
GQdMPACLD/Awp9X15ArnV1tvSh11sBqWbnbM v7rSA07Lx0Oaq+X/8TvU7qy7Z5nub2SyzN2F rF+0Cz4uhJJMcnNPPFuvFBf+NNW0C9QsHXVL DjJIf5VS8yARoJFUy4RK/dG2DtVSTqhutyD8 XhrgjMZNMQ10C8OewVUeaA3zs5Q= ) achilles.acme.com. 86400 86400 IN A RRSIG 192.168.5.20 A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. WJYbsEgjPXH8+qe/inQFZhvC8RNDyaAlcPwC hOt/Q0Zuk5XwOcwNlGGigawGTjsUn6pDP4WB i/9p3hyCRvRGr4GDYIOTU7iFoWOqta3TfcYc 3qHboAS7FoEqbkKfq7Viw8V/CfBtEdZGlTw0 hTP3gtmM7Nj25esrNX8KRrzgrvY= ) 86400 86400 MX RRSIG 10 achilles.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. nKjW8mg3U7GlE8HUuqzQfE8S38ZZwpmokBi1 pU7es6fGWCibaoNG0JOwiN+m+6687qDp9xTg meUqSF5VTjZlxt9DooNPPATzlqt4SNfagN2z djCWuVi+oO5zyTHT9dDTBc+WODQK2yiUZQPu vBlf+2rtIDpm3k+p5IONNXrQE5Y= ) 86400 86400 NSEC RRSIG agamemnon.acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. C19d7hOpGPkThV6ENVz8sOywn/YSqEkamliE q8FtoSTpPJxoB4ZudQBKQ+AImWjTkWOtTPDW 193ECRs5vaWS2b1Dg5o1qpsAydzW9iXKzG/k UwLFjBKKDlvMxhn9MB4bipcl/FRb9DxAZ6Nk kJw1Q1ER4pkYWZGG+cHTT+UHwFM= ) agamemnon.acme.com. 86400 86400 RRSIG IN A 192.168.5.21
A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. AzfWzZ0hbqlxLqi9gfaPzE3k0Qhok33g6MCs 389m1GlvbK5VVrU1A4qbi/wGe0959EPs8WDj q80XS87pqgSbcbf26fYUWHORhA2JiWkQ//2V HNOjkWPCyCbvM6QJt4lYj02jhRweeIw7+q5N
149
qpyrF5Hvb48yaABQYcAOvK8RdS4= ) 86400 86400 MX RRSIG 10 agamemnon.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. iLYlZa6WLbEyh/15kdOyoRA2oRbUwuYPMs0p iKD9utY1LqjBBI+1gGIvryQ+R4HbmqxNGjgQ e7wJZG7Z6E8a0wHq4gl8JROqct9mpilAtB9e VG348V5+mgj5OpopZK1FoV8GW6QCKTymry7K QVGGyTaulChd8RyT0uuIor/sZhs= ) 86400 86400 NSEC RRSIG ajax.acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. MjuplZgSzOkZm/v/HcwWGiccE94IyN4QzNM5 M+VliHei4xYU+V2jT2606vQQWD9e8Ai7y3rV RqO9RaZivbae3pfIEoRauqKD0MSxzcsc61BP 2NEgaVQ36IIzINBp6ALqYTg1uyLf3wYu6hGD BWv9YfQ0OZoJ/xm4LTPmMmQDeME= ) ajax.acme.com. 86400 86400 IN A RRSIG 192.168.5.24 A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. NanBXIbQEBMMqPpMKW5zLZJx0oxsMROjc7kb NVSa92KhEfpFiRvEMUtysxvkHS6JLib8VokH //+Hz+nZCn/P1z1o/9wm3rPESPgPvQu+2yaA H+LfPpSEdkESuunlOCxwV/aYgD+hSYKVUR5e XLgCQlQP2B4U6A8lwYOjmMPy0XM= ) 86400 86400 MX RRSIG 10 ajax.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. o3r4qi5ovJxbS9Pkoi6KnCc6IWNgCDQy9WDd Hb/T4nW13EyHA2fLRDOtZ9gpL6/LzV/d7jqv cpHzxtNhn8Jxn1rA7LxFs6lgD9qiy10cSKeg 53gwCwVKk7iic2byVe4cPrVcQznjtRPeZhDX 0DnUzwRdJkRjG1pUiP4n/PK0EmI= ) 86400 86400 NSEC RRSIG dev-ng-core4.acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com.
150
KwAOl/6UgDEldHOfgAwa7vf40ETHYvol8OOf ENcMLxnHVPCpWVeufHf1ngftil+4IjlxKGS+ TZSIwfX9EGljQ1qLnIRe3PjNgEwhgoYjVHyt lr47DUEaYtYylb1THeoYtDql6PCC5jM19m2K e05Lg4MI1UUsn1+VPRa9pIWjwZ0= ) dev-ng-core4.acme.com. 86400 86400 RRSIG IN A 192.168.5.1
A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. s4bi9yVGLMTSMS44HR1zm7KYCWCmbxdY9zNq XgOD5I1mOfzczZizApraFEbXC3ZKB5MbuBH7 3ya1EAIJwF0FHLWbw4gT5YjT7ynRu34D8LO9 xUbpj0cR5onJwq5wINRU7yqvpBPLLZs7H1tu U0N8fgdzO8VitHooUsxZPnB4Fn4= )
86400 86400
MX RRSIG
10 dev-ng-core4.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. NeM+kVhX8ibREHfAs1qVTbThq8I18B6A9OtC l36UfU0rvHQGlcK26T87GP3o+ITvrBOARDbc eiK6gGTJ5CC8txVVZ3tMJdRwEtZCE7LcRE77 okhsozvNlmB+Aw+hdfpuiC76w7etkLukJ1iy /8uo3ede8dqNNd6wuG5P8C4jm6g= )
86400 86400
NSEC RRSIG
diomedes.acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. gHBY03ASq1inB1OeYPezuc0hKRxHUXOgmQmN M8Hp6HwzSIz75BK/+XpEZUMpYAhq/WXywbAY guW6w6WPeENTfG7Y0ol3E9dvVukvDXA17q1f SxwnqlNAidLzVCG6ay1bstyfTudQvm+NHAum VpnBEclJ3pOT4SDLnj2+5WRABd4= )
diomedes.acme.com. 86400 86400
IN A RRSIG
192.168.5.22 A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. XgoAcLaNO5lqJAFlDphU5ShPaE9QDGfuRQDq +PGLaZyRHFBVmCRYX3AZCdPsfTbYffv1Q5yT YR8OFi08nU0tLDgnC265YltZkYrnxFQvObA4 qKOQqZQqprjCJJl2v4sDPlRgLUdRfCbosR45
151
MblCthQpgguZKsvXLG5Ns+gopPI= ) 86400 86400 MX RRSIG 10 diomedes.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. e71MWahlv4ivllHN/X94STCKws2wxDEZUmGg GxGtLsDR9JbEQ5a3JUiTXnXiP4nhK2GxfXo6 VnMFLRLtV+i3Z24OeKW72z+iYHFX7IByAfX2 ouGfc+uqwBdtoyVqOh9J8aF91zaqd4mm0OhN mc8QArsrMpIO6bgZMv1Rv69I+iQ= ) 86400 86400 NSEC RRSIG localhost.acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. KJwsXo44F/pRgx/F/uzBS5pvKj+2a09DumY4 9P/YkPsC2vkAfmqoYs9mVEA3htM/EXb2sena SpqWzctpnkEO97Rs2ToqHd+Xc/fEjSwUgpKb G3vo2Y9qZHAls2Ml2gx4elFth+kwvlLuy5yB OcyNZJg0co0BEi8VlR7vvMgYOPs= ) localhost.acme.com. 86400 86400 RRSIG IN A 127.0.0.1
A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. I6uc9chOPlchmlAkvMqAbVcIS4YOLEuSTk8b VHZCTzSMdkTD3u6zS+4IArp0eNoSBurC0i64 jJLvq6DOWTI6D5XLsODylCULYtMaEKe0n9nh tfwqNY3k3PNIl/YFIEu6DbOvJ1+xQkDpDABb 7anN1bX9NZ73X7sY0kW3vQBotTw= )
86400 86400
NSEC RRSIG
menelaeus.acme.com. A RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. jGwZ3teiqYfWovZu7qUXxyz18K2aYTc1Oyxn vpnmvTuL//SqB1nYEYm6bXAv1//xaaCfvWdj ORJyGbWjoXYXKkoA6I67V7o63QmAr8ylqP73 3ClvD20KrH6Z3njUMqyKgySlBl+p4KE2unJt EgZexBi/lff8lb3xEdJEd4wgLUM= )
menelaeus.acme.com. 86400
86400 RRSIG
IN A
192.168.5.28
A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com.
152
OR2di2fJzlr6W5GYmR4/LrxHSenxqvb2FTO2 +aO5kT6z6TYSw0H9/cBqFW2qKCSONeqyKFgF Xt6+irTUSa2ON2nIiqRgj9ZysbpuIjTrjt6U TAXFMpKFgY6Xj0nJky3LKsNcGv1zw2wGWpvf 60Abj4gYmDIX5YC66qL3/uPeb/s= ) 86400 86400 MX RRSIG 10 menelaeus.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. VqQMiIvGj/y1uCd+lwLY8JiCiPCMqiCd+VAg tFy+Fus5ab003fLr6FVwMEehuC4VTXEvRLSi lXN/97AwPobkVcOPkQbL76n4OWWBgJ2IXuEw X0kNXwvM0RFxE8zhKVL0bNnZYaA3q8MlstR1 uVeEQ/7FJ8aVxfOJZCqcETq67sY= ) 86400 86400 NSEC RRSIG odysseus.acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. ZiN+SksUkWDeCt46qJ1Q8DLnos+E4POlC9VN 0o84bIzELNOu2G0gTJFgJJKm+FDQw2D/mW5j pc8XdQC10U/nXX3IyNuITLldnbmRwGCMEwKD mgivtIwCwztMP1r7jJtv9RO+LtbviMLG2h7c qfTwD4rmyQ+T5AarKwyzqnttxqQ= ) odysseus.acme.com. 86400 86400 IN A RRSIG 192.168.5.23 A 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. GByIyiojC0JC/wG9fkIAv5s5z1+5tB0k/U7K SNEjsupijyaKf4mpVCjq6neFKbrFPbnVUbyd Nbdx3zi40C4XqWQynqLw30wBBf+gIdu5kNqK WLW1ZuKiQYPVIsjzQ2bqpHfdZZqGCxUfP6nK R7R+hIOv7jDbKuy5Dklq+VIJj/8= ) 86400 86400 MX RRSIG 10 odysseus.acme.com. MX 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. r2siPZWAnaZhVlfpDtSs81lHCyCQE18sRG/g BFEyJgYHyfaw/k4E+Qo8Awgsa2P+6OCg6pr2 N7uVRXBA6cuVV2OXkHq0doMPRolxQHXASZP7 A0TF+FAZJjTMK2u2YuWyRoUpEmKmSMYQFTve
153
a2EcrbLwvJAsG5STlxMcYBqc31o= ) 86400 86400 NSEC RRSIG acme.com. A MX RRSIG NSEC NSEC 5 3 86400 20091231163048 ( 20091201163048 62460 acme.com. Htv+HuYpy2X6/6F4HhvkGTQuXacXBQ/Msnrw Nkrh/mRFQ51EYmOV/bk+aCqnm9Gjxu9CXFAg gfbqLoCpcAZcuHNo32H5OC0nNEceThbu7B2k 6YhLqltv8vumwtFUToigvCdvGo2OKLpaSZW3 ZxVuer1f9JGcBx5yzK+Xb5DTjpM= )
2. The file keyset-acme.com. contains the KSK public key:

# cat keyset-acme.com. $ORIGIN . acme.com 3600 IN DNSKEY 257 3 7 ( AwEAAdQYumHB0xvrzwb3O553HRofI22HQmA4 MThgNV2HFThhJRy0nRRGahY3xCZXaVXZQ61Y ScSSB9vy0qWu4iabO0toTyWRM+RmLjUPFDLi hIPs5X3emlacbSXJ3MtVqp3/6DGzxGBrxc65 ulPxgd1NDvwAPDv62rxBj9XNf+uCAm+GFBYn dnXGaEKS/KFSVwcfD8mh+ZvOikkjzCkti95y 27Q7R43TEEd/RpLs8Bav/rbkCdMHSi3iU4bh r+gOhkQDPHOTswzfSX52/V/XHLVAJrl3zqFE N70puLLReCvaxLVYWeSlnmlOcZrvzI1Mm/q8 tKuGw1ckA765mTLxxm+Q9/E= ) ; key id = 19560
3. The file dsset-acme.com. contains the DS Record information for the acme.com. zone that the edu. zone administrator needs to insert into the edu. zone. Please note that the proper TTL value would need to be added. Also, the recommended record is the first record with digest type value = 1.
# cat dsset-acme.com. acme.com. acme.com. 0BD9AFE7 IN DS 19560 7 1 BC8E13A846594F10679E75EFC16F799284538041 IN DS 19560 7 2 9C71B5274E3F256C6E62A41DA5A90E9FEA5944DB4E9EBBD51FB17A1B
154
Appendix J. Configuring and Serving a Signed Zone Follow the steps below to configure your name server and have it start serving your signed zone. Note that named.conf is the name of the name server configuration file that is used below: Add the Signed Zone to the Name Server Configuration File For the zone whose name is zone-name, do the following:
# vi named.conf [ENTER] ... zone zone-name. { type master; file zone-file.signed; }; ...
Enable DNSSEC Add the dnssec-enable yes; option to the named.conf file:
# vi named.conf [ENTER] ... options {... dnssec-enable yes; }; ...
Check the Name Server Configuration File for Errors You must ensure that the configuration file modifications were performed correctly:
# named-checkconf named.conf [ENTER]
No output indicates success. Reload the Zone Reload the name server and configuration files and zone contents. The name server process is assumed to be already running:
# rndc reload zone-name [ENTER]
Check that the Zone Loaded Properly Confirm that the SOA serial number of the zone corresponds to the most recent value:
# dig @server-IP-address SOA zone-name [ENTER]
155
Appendix K. Migrating From BIND To DNSSEC-Tools An operator already using BIND tools to maintain a signed zone may want to transition to the DNSSECTools zonesigner utility while still retaining existing keys that are being used to sign a zone. In the examples given below, the zone example.com is currently signed, signed zone file is maintained using the dnssec-signzone command from BIND and the following files are present:
db-in.example.com db-in.example.com..signed Kexample.com.+005+47670 Kexample.com.+005+48926
Unsigned zone file Signed zone file KSK files prefix ZSK files prefix
The following steps may be used to transition to using DNSSEC-Tools: Generate the Keyrec File
# genkrf
-zone=example.com -ksk=Kexample.com.+005+47670 -zskcur=Kexample.com.+005+48926db-in.example.com. db-in.example.com..signed
The genkrf command generates a keyrec file from existing key files. It also generates any additional keys that zonesigner uses. In the above example, genkrf will generate a new key zskpub along with the keyrec file named example.com.krf. It will display the following message if successful:
genkrf: file example.com.krf created successfully.
Verify the Keyrec File

Examine the contents of the keyrec file and ensure that the original KSK and ZSK files are being used:
# grep kskdir # grep zskcur Kexample.com.+005+47670 example.com.krf [ENTER] "Kexample.com.+005+47670" Kexample.com.+005+48296 example.com.krf [ENTER] "Kexample.com.+005+48296"
Resign the Zone with zonesigner

# zonesigner -gends -zone example.com db-in.example.com db-in.example.com [ENTER]
156
Appendix L. BINDs nsupdate Command Formats nsupdate is used to make edits on a dynamic DNS without the need to edit zone files and restart the DNS server. This allows resource records to be added or removed from a zone without manually editing the zone file. A single update request can contain requests to add or remove more than one resource record. If you have declared a zone dynamic, this is the way that you should be making edits. Zones that are under dynamic control via nsupdate or a DHCP server should not be edited by hand. Manual edits could conflict with dynamic updates and cause data to be lost. The nsupdate command formats and their meaning are as follows: Command server servername [ port ] Description Sends all dynamic update requests to the name server servername. When no server statement is provided, nsupdate will send updates to the master server of the correct zone. The MNAME field of that zone's SOA record will identify the master server for that zone. port is the port number on servername where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is used. Sends all dynamic update requests using the local address. When no local statement is provided, nsupdate will send updates using an address and port choosen by the system. port can additionally be used to make requests come from a specific port. If no port number is specified, the system will assign one. Specifies that all updates are to be made to the zone zonename. If no zone statement is provided, nsupdate will attempt determine the correct zone to update based on the rest of the input. Specifies that all updates are to be TSIG
local address [ port ]
zone zonename
key name secret
157
signed using the keyname keysecret pair. The key command overrides any key specified on the command line via -y or k. Requires that no resource record of any prereq nxdomain domain-name type exists with name domain-name. Requires that domain-name exists (has as prereq yxdomain domain-name at least one resource record, of any type). prereq nxrrset domain-name [ class ] type Requires that no resource record exists of the specified type, class and domainname. If class is omitted, IN (internet) is assumed. prereq yxrrset domain-name [ class ] type This requires that a resource record of the specified type, class and domain-name must exist. If class is omitted, IN (internet) is assumed. prereq yxrrset domain-name [ class ] type The data from each set of prerequisites of this form sharing a common type, class, data... and domain-name are combined to form a set of RRs. This set of RRs must exactly match the set of RRs existing in the zone at the given type, class, and domain-name. The data are written in the standard text representation of the resource record's RDATA. update delete domain-name [ ttl ] [ class ] Deletes any resource records named domain-name. If type and data is [ type [ data... ] ] provided, only matching resource records will be removed. The internet class is assumed if class is not supplied. The ttl is ignored, and is only allowed for compatibility. update add domain-name ttl [ class ] type Adds a new resource record with the specified ttl, class and data. data... Displays the current message, containing show all of the prerequisites and updates specified since the last send.
158
send
Sends the current message. This is equivalent to entering a blank line.
For more details on nsupdate, refer to http://linux.about.com/library/cmd/blcmdl8_nsupdate.htm.
159
Appendix M. Other DNSSEC-related Tools The following table lists several of the other available DNSSEC-related tools along with a description and a URL where you can find out more information about them: Tool
NSD
Description
The NLnet Labs Name Server Daemon (NSD) is an authoritative only, high performance, simple and open source name server. It comes with DNSSEC support. NSD is developed from scratch and does not share code or design with other implementations. NSD consists of two programs: the zone compiler 'zonec' and the name server 'nsd' itself. The name server works with an intermediate database prepared by the zone compiler from standard zone files. For NSD operation this means that zones have to be compiled by zonec before NSD can use them. All this can be controlled by a simple control script called 'nsdc' which uses a simple configuration file. NSD is currently used on root servers such as k.root-servers.net and is also in use by several top-level domain registries. NSD is also used as the name server software of DNSSEC appliances. Autotrust is a command line tool to automatically update your DNSSEC trust anchors. It is intended to run from a cron job and can run next to any validating resolver. It makes use of ldns and libunbound. Unbound is a validating, recursive, and caching DNS resolver. The C implementation of Unbound is developed and maintained by NLnet Labs. It is based on ideas and algorithms taken from a java prototype developed by Verisign labs, Nominet, Kirei and ep.net. Unbound is designed as a set of modular
Author(s)
NLNet Labs
URL
http://www.nlnetlabs.nl/nsd
Autotrust (beta)
Matthijs Mekking, NLnet Labs
http://www.nlnetlabs.nl/projects/aut otrust/
UNBOUND
NLNet Labs, Verisign, Nominet, Kirei
http://unbound.net/
160
Tool
Description
components, so that also DNSSEC (secure DNS) validation and stubresolvers (that do not run as a server, but are linked into an application) are easily possible. Unbound is IPv6 compatible. NSEC3 is also supported. The source code is under a BSD License.
Author(s)
URL
dig +sigchase patch
This patch adds the +sigchase option to ISC's dig program program. When using sigchase with any regular dns query, dig(1) will try to verify SIG records that belong to the record and further will try to verify them recursively for all the keys and DS that form the chain of trust all the way up to any self signed or not signed key. NOTE: As of version 9.6.1-P1 of BIND, a compile time option of DDIG_SIGCHASE will include this feature in the built version of dig. The bind-9.6.1-P1/bin/dig/Makefile file in the BIND distribution would need to be modified to include this option prior to compiling.
Olivier Courtay (ENST Bretagne)
ftp://ftp.irisa.fr/local/idsa/code/digsigchase/
DNS Reply Size Test
Recent increases in DNSSEC deployment are exposing problems with DNS resolvers (clients) that cannot receive large responses. The maximum reply size between a DNS server and client may be limited by a number of factors: If a client does not support the Extension Mechanisms for DNS (EDNS), replies are limited to 512 bytes The client may be behind a firewall that blocks IP fragments Some DNS-aware firewalls
DNS-OARC
https://www.dnsoarc.net/oarc/services/replysizetest
161
Tool
Description
block responses larger than 512 bytes. This test helps users identify resolvers that cannot receive large DNS replies.
Author(s)
URL
DNSPython
DNS toolkit for Python. It supports almost all DNS record types. It can be used for queries, zone transfers, and dynamic updates. It supports TSIG authenticated messages and EDNS0. Dnsruby is a thread-aware DNS stub resolver library written in Ruby, with support for DNSSEC (and NSEC3). It is based on resolv.rb, the standard Ruby DNS implementation, but gives a complete DNS implementation complying with all relevant RFCs. This is a beta release of a DNSSEC key management tool that RIPE NCC has developed as part of the DISI project. This program suite was designed to ease DNSSEC key management. The suite provides a front-end to the BIND dnsseckeygen(8) and dnssec-signzone(8) tools. The suite contains, besides a number of libraries, the following programs: 1) maintkeydb: A shell in which you maintain your keys. 2) dnssigner: A signer that uses the key database to sign zones. 3) dnssecmaint-config: A tool to create an initial config. 4) dnsseccopyprivate: Copies key pairs out of the key database to a different location (Useful in combination with a dynamic zone.) Extensive documentation for this toolset is available as HTML or PDF. This is a DNSSEC smartcard utility written for NIC-SE. Any PKCS#15 smartcard supported by OpenSC can
Bob Halley (Nominum)
http://www.dnspython.org/
DNSRuby
Nominet UK
http://dnsruby.rubyforge.org/
DNSSEC Key Management Tools
Olaf Kolkman (RIPE NCC)
http://www.ripe.net/projects/disi/dn ssec_maint_tool/
DNSSEC Smartcard Utility
Jakob Schlyter, Haakan
http://opensource.iis.se/trac/dnssec/ browser
162
Tool
Description
be used. Axalto Cryptoflex was used during development. To run this software, you also need OpenSC, OpenCT, PCSC lite, and a PCSC egate driver (depending on reader). Keys can be generated externally and copied to the smartcard(s) or generated on the card itself. It's recommend that you generate the key externally since this lets you copy the key to multiple smartcards. The next step is to initialize the card, create a PIN code to protect the card, store the key on the card and (optionally) finalize the card (i.e. block the card from further initialization).
Author(s)
Olsson
URL
DNSSEC Tools (NIST.gov) DNSSEC Walker
Several DNSSEC Tools from the National Institute of Standards and Technology (NIST). This is a proof-of-concept of a utility to download DNS zone contents even when AXFR is disabled on the server, assuming DNSSEC is used. Optionally it can also verify all SIG RRs within a zone against the zone key. Requires Net::DNS::SEC. DNSSHIM is open-source software that implements the Domain Name System (DNS) protocol for the Internet. Its main feature is to work as a Hidden Master name server providing information only to authoritative slave servers. Furthermore, DNSSHIM has the ability to manage, store and automatically resign zones using the DNS Security Extensions (DNSSEC). Drill is a tool ala dig from BIND. It was designed with DNSSEC in mind and should be a useful debugging/query tool for DNSSEC.
Nist.gov
https://wwwx.antd.nist.gov:8090/dnssec/downlo ad/ http://josefsson.org/walker/
Simon Josefsson
DNSSHIM
Registro.br
http://registro.br/dnsshim/indexEN.html
Drill
Miek Gieben, Jelte Jansen (NLnet Labs)
http://www.nlnetlabs.nl/dnssec/drill .html
163
Tool
Drill Extension for Firefox
Description
This Firefox extension performs DNSSEC lookups for the main hostname of the current page. It uses Drill to chase the signatures up to a trusted key. The user can specify trusted keys by putting them in a directory of his choice. After installing the extension, the status bar shows a new icon: normally, for unverified pages, the icon will be red. If the hostname record in the DNS is signed and can be traced up to a trusted key, the icon will be green. This is a patch that implements the ipseckey RR in BIND. IPSECKEY allows storage of public IPSEC keys in DNS. When two hosts want to communicate over IPSEC, they can fetch the public keys of the third party from DNS. Keys can be attached to the FQDN, or to the reverse address records (myhost.mydomain. or 1.0.0.10.in-addr.arpa.). Obviously these RR's are so sensitive that they should first be validated by DNSSEC before being used. libresolv is a library built with the BIND toolkit. It comes as a patch over the BIND 9.3 sources. It contains a DNSSEC resolver and validator. The goal is to show anything that can be proved from a DNSSEC answer. The validator proves positive and negative answers. It can prove that a domain doesn't exist; it can also prove that some domains are empty non-terminal ones. libresolv performs bottom-up validation, it is signature oriented. This is a collection of java-based DNSSEC command line tools. They are intended to be an addition or replacement for the DNSSEC tools that are part of BIND 9. These tools
Author(s)
Miek Gieben, Jelte Jansen (NLnet Labs)
URL
http://www.nlnetlabs.nl/dnssec/drill _extension.html
IPSECKEY patch
David Fort (IRISA)
ftp://ftp.irisa.fr/local/idsa/code/patc h-bind/bind+ipseckey.patch
libresolv
David Fort (IRISA)
http://idsa.irisa.fr/index.php?page=l ibsresolv&lang=en
Java DNSSEC Tools
David Blacka (Verisign)
http://www.verisignlabs.com/dnsse c-tools/
164
Tool
Description
depend upon DNSjava, the Jakarta Commons CLI and Logging libraries, and Sun's Java Cryptography extensions. A copy of each of these libraries is included in the distribution. Currently, these tools use a custom version of the DNSjava library (for NSEC3 support), which is provided.
Author(s)
URL
SK-DNSSEC
The SK-DNSSEC project is about implementing the SK-DNSSEC protocol, with the purpose of securing the Domain Name System. Unlike the PK-DNSSEC proposal, SK-DNSSEC is an extension that makes use almost exclusively of symmetric-key cryptography. ldns is a library with the aim to simplify DNS/DNSSEC programing in C. It is heavily based upon the Net::DNS module from perl. With this library you can quickly create DNS/DNSSEC aware programs. The library has support for verifying DNSSEC material, TSIG, and all DNS operations. Signing is currently not supported, but is on the TODO list. Some example programs are included, and there's a mailing list where ldns related things are discussed.
Giuseppe Ateniese et al
http://skdnssec.isi.jhu.edu/downloa d.html
ldns
Miek Gieben, Jelte Jansen, Erik Roozendaal (NLnet Labs)
http://www.nlnetlabs.nl/ldns/
DNSSEC Toolkit
Set of primitive C functions which allow you to build any kind of DNSSEC tool or resolver. The tarball provides an example tool based on the library. Works on Linux, FreeBSD and maybe others. Note: requires openssl. OARC maintains a number of DNS zones that may be used to test DLV registries for correct operation. These zones exist only so that they will be
Olivier Courtay (ENST Bretagne)
ftp://ftp.irisa.fr/local/idsa/code/dnss ectoolkit/
DLV Test
DNS-OARC
https://www.dnsoarc.net/oarc/services/dlvtest
165
Tool
Description
published in DLV registries The zone content is intended to be very stable. The zones are signed with keys that expire in the year 2029 so that there are effectively no key rollovers.
Author(s)
URL
ANS
Nominum Authoritative Name Server (ANS) is a scalable, authoritative name server. It was designed for organizations who need an "alwayson" DNS, host large numbers of resource records, or have to support many DNS zones. ANS is a dedicated authoritative name server that has higher performance in query responses per second than any other name server product. It scales to millions of names, millions of zones, supports the latest specifications for DNSSEC as well as supporting GSSTSIG, and can be configured and managed remotely without downtime. Nominum Foundation ANS is used where DNS scalability, availability, manageability, and performance are most critical such as Top Level Domain (TLD) and other DNS registries and registrars, DNS hosting providers, large enterprises, service providers with strict service-level obligations, and any organization that has a critical dependence on the DNS. Recursive name server Standard tools provided with the ANS distribution Tools from the DNSSEC perltools distribution Tools from the DNSSEC Management Tools suite Key
Nominum, Inc.
http://www.nominum.com
CNS nom_keytool, ans_signer pdnssec-keygen, pdnssecsignzone maintkeydb, dnssigner Maintkeydb
Roy Arends
http://www.nsec3.org/cgibin/trac.cgi/browser/dnssec/perltool s/
RIPE NCC
https://www.ripe.net/projects/disi/d nssec_maint_tool/
Command line interface to a database containing DNSSEC Keys
Olaf
166
Tool
Key2ds, Net::DNS::Sec libepp-nicbr
Description
DNSKEY to DS conversion library that partially implements the Extensible Provisioning Protocol (EPP), as described in the Internet Drafts RFC3730bis to RFC3734bis and RFC3735 Trust Anchor Repository constructed through explicit zone owner registration Trust Anchor Repository populated by a crawler program Trust Anchor Repository populated by a crawler program (Currently) demo Trust Anchor Repository for SEP keys for TLDs KROd is a program that performs automatic DNSSEC keyrollover and automatic conversion from DNS to DNSSEC. Handles ZSK rollover and KSK rollover and it communicates securely with the parent server to ask for the keyset update. Most key/signing params can be specified to KROd This DNSSEC appliance from Infoblox builds support for DNSSEC on top of their already available NIOS software product which runs on their available appliances. NIOS provides a core network services platform for automating the delivery and management of critical DNS, DHCP, IPAM and other core network services. A new graphical user interface (GUI) allows administrators to deploy and manage the entire DNS, DHCP and IPAM infrastructure with mouse clicks and also manages all aspects of the infrastructure and data
Author(s)
Kolkman Registro.br
URL
http://www.net-dns.org/ http://registro.br/epp/indexEN.html
ISC DLV registry
ISC
https://secure.isc.org/index.pl?/ops/ dlv/ http://secspider.cs.ucla.edu/
Secspider
UCLA, Colorado State IKS Jena IANA Infrastructur e DNS Securise et applications (IDSA)
IKS Jena Survey IANA TAR KROd - the keyrollover daemon
http://www.iksjena.de/leistungen/dnssec.php https://ns.iana.org/dnssec/status.ht ml http://www.idsa.prd.fr/index.php?p age=kro&lang=en
Infoblox
Infoblox
http://www.infoblox.com/solutions/ dnssec.cfm
167
Tool
Description
including software updates and upgrades, backups and restores, disaster recovery and all services and data management, and DNSSEC related operations such as key generation and rollover and zone signing without resorting to clientbased or command-line interfaces.
Author(s)
URL
Secure64
DNS Signer, the appliance solution from Secure64, is a DNSSEC appliance which makes it easy to implement DNSSEC securely and correctly. DNS Signer runs on SourceT, Secure64s malwareimmune, genuinely secure micro OS, so it is able to safely keep signing keys online. This allows full automation of all of the DNSSEC key management and signing processes. Signer easily integrates into an existing infrastructure configuration. It is fully compatible with many of the available DNS servers including BIND and NSD. And no matter how large or dynamic your DNS data, Signer's high-performance and incremental-signing capabilities mean it can handle the load. Additionally, Signer supports all of the RFCs and best practices required to deploy DNSSEC. DNS Signer provides a number of features that allow you to deploy DNSSEC securely and supports scalability while reducing the risk of implementation errors
Secure64
http://www.secure64.com/automate d-DNSSEC-signer-softwareappliance
Xelerance
Xelerances DNSX Secure Signer appliance is a proactive management solution which automates most of the DNSSEC operations and includes an extensive Web-based interface and an API available for custom integration. Each command in the API is accessible via a corresponding URL
Xelerance
http://www.xelerance.com/applianc es/signer/DNSXSecureSigner.pdf
168
Tool
Description
thereby simplifying integration. DNSX Secure Signer is a drop-in solution which should integrate with all existing DNS management solutions without requiring infrastructure changes and should be able to run in parallel with any existing DNS infrastructure. The following identifies a typical DNS deployment that is seamlessly integrated with DNSX Secure Signer
Author(s)
URL
Bluecat
BlueCat Networks has been providing secure DNS solutions since 2001, and as a trusted advisor in DNS security, organizations have looked to BlueCat to help address their security concerns. As part of BlueCat Networks dedication to security, the DNS Security Extensions have been added to BlueCats award winning Proteus and Adonis appliances. Through the addition of DNSSEC, BlueCat provides organizations with the ability to easily deploy and maintain DNSSEC records and keys. BlueCats Adonis appliances are able to properly validate signed records from other DNSSEC enabled servers.
Bluecat Networks
http://www.bluecatnetworks.com/c omponent/jdownloads/?task=finish &cid=42&catid=5
More information on the tools above along with additional ones can be found at http://www.dnssec-deployment.org/tracker/ and http://www.dnssec.net/software.
169
Appendix N. Sample ZKT Zone Signer CRON Job The dnssec-cron.sh script below can be used to automate the zone signing to be performed when and as often as desired:
echo "current zone signing keys" /usr/local/bin/dnssec-zkt -z echo "dnssec re-signing process started" /usr/local/bin/dnssec-signer -v -v -r -N /var/named/named.conf
A sample crontab entry for scheduling the script would look like as follows:
# crontab -l 21 6 * * * /var/zkt/dnssec-cron.sh 2>&1 | /bin/logger -t dnssec-cron -p daemon.info 21 18 * * * /var/zkt/dnssec-cron.sh 2>&1 | /bin/logger -t dnssec-cron -p daemon.info
170
Appendix O. Algorithms for Key Rollover The DNSSEC Operational Practices from http://tools.ietf.org/id/draft-ietf-dnsop-dnssecoperational-practices-06.txt define two algorithms for key rollover: 1. ZSK Rollover (pre-publish key method): This method has advantages in the case of a key compromise. If the old key is compromised, the new key has already been distributed in the DNS. The zone administrator is then able to quickly switch to the new key and remove the compromised key from the zone. Another major advantage is that the zone size does not double, as is the case with the double signature ZSK rollover. The steps for a ZSK rollover using the pre-publish key method are as follows: a. Generate second ZSK b. Publish both (public) keys, but use only the old one for signing c. Wait at least propagation time + TTL of the DNSKEYRR d. Use new key for zone signing; leave old one published e. Wait at least propagation time + maximum TTL of the old zone f. Remove old key 2. KSK Rollover (double signature method): The drawback of this signing scheme is that during the rollover the number of signatures in your zone doubles, this may be prohibitive if you have very big zones. An advantage is that it only requires three steps. The steps for a KSK rollover using the double signature method are as follows: a. Generate new KSK b. Use both keys for key signing c. Send new DSRecord (or DNSKEYRR) to the parent d. Wait until the DS is propagated + TTL of the old DSRR e. Remove the old key
171
Appendix P. MAN Pages for dnssec-signer and dnssec-zkt dnssec-zkt:

NAME dnssec-zkt Secure DNS zone key tool SYNOPSYS dnssec-zkt [V|--view view] [c file] [l list] [adefhkLrptz] [{keyfile|dir} ...] dnssec-zkt C<label> [V|--view view] [c file] [krpz] [{keyfile|dir} ...] dnssec-zkt create=<label> [V|--view view] [c file] [krpz] [{keyfile|dir} ...] dnssec-zkt dnssec-zkt dnssec-zkt dnssec-zkt ...] dnssec-zkt {P|A|D|R}<keytag> [V|--view view] [c file] [r] [{keyfile|dir} ...] published=<keytag> [V|--view view] [c file] [r] [{keyfile|dir} ...] active=<keytag> [V|--view view] [c file] [r] [{keyfile|dir} ...] depreciate=<keytag> [V|--view view] [c file] [r] [{keyfile|dir} rename=<keytag> [V|--view view] [c file] [r] [{keyfile|dir} ...]
dnssec-zkt destroy=<keytag> [V|--view view] [c file] [r] [{keyfile|dir} ...] dnssec-zkt T [V|--view view] [c file] [l list] [hr] [{keyfile|dir} ...] dnssec-zkt list-trustedkeys [V|--view view] [c file] [l list] [hr] [{keyfile|dir} ...] dnssec-zkt K [V|--view view] [c file] [l list] [hkzr] [{keyfile|dir} ...] dnssec-zkt list-dnskeys [V|--view view] [c file] [l list] [hkzr] [{keyfile|dir} ...] dnssec-zkt Z [V|--view view] [c file] dnssec-zkt zone-config [V|--view view] [c file] dnssec-zkt dnssec-zkt dnssec-zkt dnssec-zkt dnssec-zkt DESCRIPTION The dnssec-zkt command is a wrapper around dnssec-keygen(8) to assist in dnssec zone key management. In the common usage the command prints out information about all dnssec (zone) keys found in the given (or predefined default) directory. It is also possible to specify keyfiles (K*.key) as arguments. With option r subdirectories will be searched recursively, and all dnssec keys found will be listed sorted by domain name, key type and generation time. In that mode the use of the p option may be helpful to find the location of the keyfile in the directory tree. 9 1 2 3 0 | | | | | ksk-rollover ksk-roll-phase1 do.ma.in. [V|--view view] [c file] ksk-roll-phase2 do.ma.in. [V|--view view] [c file] ksk-roll-phase3 do.ma.in. [V|--view view] [c file] ksk-roll-stat do.ma.in. [V|--view view] [c file]
172
Other forms of the command print out keys in a format suitable for a trusted-key section or as a DNSKEY resource record. The command is also useful in dns key management. It offers monitoring of key lifetime and modification of key status. GENERAL OPTIONS V view, view=view Try to read the default configuration out of a file named dnssec<view>.conf . Instead of specifying the V or --view option every time, it is also possible to create a hard or softlink to the executable file to give it an additional name like dnssec-zkt-<view> . c file, config=file Read default values from the specified config file. Otherwise the default config file is read or build in defaults will be used. O optstr, config-option=optstr Set any config file option via the commandline. Several config file options could be specified at the argument string but have to be delimited by semicolon (or newline). l list Print out information solely about domains given in the comma or space separated list. Take care of, that every domain name has a trailing dot. d, directory Skip directory arguments. This will be useful in combination with wildcard arguments to prevent dnsssec-zkt to list all keys found in subdirectories. For example "dnssec-zkt -d *" will print out a list of all keys only found in the current directory. Maybe it is easier to use "dnssec-zkt ." instead (without -r set). The option works similar to the d option of ls(1). L, left-justify Print out the domain name left justified. k, ksk Select and print key signing keys only (default depends on command mode).
173
z, zsk Select and print zone signing keys only (default depends on command mode). r, recursive Recursive mode (default is off). Also settable in the dnssec.conf file (Parameter: Recursive). p, path Print pathname in listing mode. In -C mode, dont create the new key in the same directory as (already existing) keys with the same label. a, age Print age of key in weeks, days, hours, minutes and seconds (default is off). Also settable in the dnssec.conf file (Parameter: PrintAge). f, lifetime Print the key lifetime. F, setlifetime Set the key lifetime of all the selected keys. Use option -k, -z, -l or the file and dir argument for key selection. e, exptime Print the key expiration time. t, time Print the key generation time (default is on). Also settable in the dnssec.conf file (Parameter: PrintTime). -h No header or trusted-key section header and trailer in -T mode
COMMAND OPTIONS H, help Print out the online help.
174
T, list-trustedkeys List all key signing keys as a named.conf trusted-key section. Use h to supress the section header/trailer. K, list-dnskeys List the public part of all the keys in DNSKEY resource record format. Use h to suppress comment lines. C zone, create=zone Create a new zone signing key for the given zone. Add option k to create a key signing key. The key algorithm and key length will be examined from built-in default values or from the parameter settings in the dnssec.conf file. The keyfile will be created in the current directory if the p option is specified. R keyid, revoke=keyid Revoke the key signing key with the given keyid. A revoked key has bit 8 in the flags filed set (see RFC5011). The keyid is the numeric keytag with an optionally added zone name separated by a colon. rename="keyid Rename the key files of the key with the given keyid (Look at key file names starting with an lower k). The keyid is the numeric keytag with an optionally added zone name separated by a colon. destroy=keyid Deletes the key with the given keyid. The keyid is the numeric keytag with an optionally added zone name separated by a colon. Beware that this deletes both private and public keyfiles, thus the key is unrecoverable lost. P|A|D keyid, published=keyid, active=keyid, depreciated=keyid Change the status of the given dnssec key to published (P), active (A) or depreciated (D). The keyid is the numeric keytag with an optionally added zone name separated by a colon. Setting the status to "published" or "depreciate" will change the filename of the private key file to ".published" or ".depreciated" respectivly. This prevents the usage of the key as a signing key by the use of dnssecsignzone(8). The time of status change will be stored in the mtime field of the corresponding ".key" file. Key activation via option A will restore the original timestamp and file name (".private"). Z, zone-config
175
Write all config parameters to stdout. The output is suitable as a template for the dnssec.conf file, so the easiest way to create a dnssec.conf file is to redirect the standard output of the above command. Pay attention not to overwrite an existing file. ksk-roll-phase[123] do.ma.in. Initiate a key signing key rollover of the specified domain. This feature is currently in experimental status and is mainly for the use in an hierachical environment. Use --ksk-rollover for a little more detailed description. SAMPLE USAGE dnssec-zkt r . Print out a list of all zone keys found below the current directory. dnssec-zkt Z c "" Print out the compiled in default parameters. dnssec-zkt C example.net k r ./zonedir Create a new key signing key for the zone "example.net". Store the key in the same directory below "zonedir" where the other "example.net" keys live. dnssec-zkt T ./zonedir/example.net Print out a trusted-key section containing the key signing keys of "example.net". dnssec-zkt D 123245 r . Depreciate the key with tag "12345" below the current directory, dnssec-zkt --view intern Print out a list of all zone keys found below the directory where all the zones of view intern live. There should be a seperate dnssec config file dnssec-intern.conf with a directory option to take affect of this. dnssec-zkt-intern Same as above. The binary file dnssec-zkt has another link, named dnssec-zkt-intern made, and dnssec-zkt examines argv[0] to find a view whose zones it proceeds to process.
176
ENVIRONMENT VARIABLES ZKT_CONFFILE Specifies the name of the default global configuration files. FILES /var/named/dnssec.conf Built-in default global configuration file. The name of the default global config file is settable via the environment variable ZKT_CONFFILE. /var/named/dnssec-<view>.conf View specific global configuration file. ./dnssec.conf Local configuration file (only used in C mode). BUGS Some of the general options will not be meaningful in all of the command modes. The option l and the ksk rollover options insist on domain names ending with a dot. AUTHORS Holger Zuleger, Mans Nilsson COPYRIGHT Copyright (c) 2005 2008 by Holger Zuleger. Licensed under the BSD Licences. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. SEE ALSO dnssec-keygen(8), dnssec-signzone(8), rndc(8), named.conf(5), dnssec-signer(8), RFC4641 "DNSSEC Operational Practices" by Miek Gieben and Olaf Kolkman, DNSSEC HOWTO Tutorial by Olaf Kolkman, RIPE NCC (http://www.nlnetlabs.nl/dnssec_howto/)
dnssec-signer:
NAME dnssec-signer Secure DNS zone signing tool
177
SYNOPSYS dnssec-signer [L|--logfile file] [V|--view view] [c file] [fhnr] [v [v]] N named.conf [zone ...] dnssec-signer [L|--logfile file] [V|--view view] [c file] [fhnr] [v [v]] [D directory] [zone ...] dnssec-signer [L|--logfile file] [V|--view view] [c file] [fhnr] [v [v]] o origin [zonefile] DESCRIPTION The dnssec-signer command is a wrapper around dnssec-signzone(8) and dnsseckeygen(8) to sign a zone and manage the necessary zone keys. It is able to increment the serial number before signing the zone and can trigger named(8) to reload the signed zone file. The command controls several secure zones and, if started in regular intervals via cron(8), can do all that stuff automatically. In the most useful usage scenario the command will be called with option N to read the secure zones out of the given named.conf file. If you have a configuration file with views, you have to use option -V viewname or --view viewname to specify the name of the view. Alternatively you could link the executable file to a second name like dnssec-signer-viewname and use that command to specify the name of the view. All master zone statements will be scanned for filenames ending with ".signed". These zones will be checked if the necessary zone- and key signing keys are existent and fresh enough to be used in the signing process. If one or more outdated keys are found, new keying material will be generated via the dnsseckeygen(8) command and the old keys will be marked as depreciated. So the command do anything needed for a zone key rollover as defined by [2]. If the resigning interval is reached or any new key must be announced, the serial number of the zone will be incremented and the dnssec-signzone(8) command will be evoked to sign the zone. After that, if the option r is given, the rndc(8) command will be called to reload the zone on the nameserver. In the second form of the command it is possible to specify a directory tree with the option D dir. Every secure zone found in a subdirectory below dir will be signed. However, it is also possible to reduce the signing to those zones given as arguments. In directory mode the pre-requisite is, that the directory name is exactly (including the trailing dot) the same as the zone name. In the last form of the command, the functionality is more or less the same as the dnssec-signzone (8) command. The parameter specifies the zone file name and the option o takes the name of the zone. If neither N nor D nor o is given, then the default directory specified in the dnssec.conf file by the parameter zonedir will be used as top level directory. OPTIONS L file|dir, logfile=file|dir Specify the name of a log file or a directory where logfiles are created with a name like zkt-YYYY-MM-DDThhmmssZ.log. If the argument is not an absolute path name and a zone directory is specified in the
178
config file, this will be prepended to the given name. This option is also settable in the dnssec.conf file via the parameter LogFile. The default is no file logging, but error logging to syslog with facility USER at level ERROR is enabled by default. These parameters are settable via the config file parameter SyslogFacility:, SyslogLevel:, LogFile: and Loglevel. There is an additional parameter VerboseLog: which specifies the verbosity (0|1|2) of messages that will be logged with level DEBUG to file and syslog. V view, view=view Try to read the default configuration out of a file named dnssec<view>.conf . Instead of specifying the V or --view option every time, it is also possible to create a hard- or softlink to the executable file with an additional name like dnssec-zkt-<view> . c file, config=file Read configuration values out of the specified file. Otherwise the default config file is read or build-in defaults will be used. O optstr, config-option=optstr Set any config file option via the commandline. Several config file options can be specified via the argument string but have to be delimited by semicolon (or newline). f, force Force a resigning of the zone, regardless if the resigning interval is reached, or any new keys must be announced. n, noexec Dont execute the dnssec-signzone(8) command. Currently this option is of very limited usage. r, reload Reload the zone via rndc(8) after successful signing. In a production environment it is recommended to use this option to be sure that a freshly signed zone will be immediately propagated. However, thats only feasable if named runs on the signing machine, which is not recommended. Otherwise the signed zonefile must be copied to the production server before reloading the zone. If this is the case, the parameter propagation in the dnssec.conf file must be set to a reasonable value. v, verbose
179
Verbose mode (recommended). A second v will be a little more verbose. h, help Print out the online help. SAMPLE USAGE dnssec-signer N /var/named/named.conf r v v Sign all secure zones found in the named.conf file and, if necessary, trigger a reload of the zone. Print some explanatory remarks on stdout. dnssec-signer D zonedir/example.net. f v v Force the signing of the zone found in the directory zonedir/example.net . Do not reload the zone. dnssec-signer D zonedir f v v example.net. Same as above. dnssec-signer f v v example.net. Same as above if the dnssec.conf file contains the path of the parent directory of the example.net zone. dnssec-signer f v v o example.net. zone.db Same as above if we are in the directory containing the example.net files. dnssec-signer config-option=ResignInterval 1d; Sigvalidity 28h; \ ZSK_lifetime 2d; v v o example.net. zone.db Sign the example.net zone but override some config file values with parameters given on the commandline. Zone setup and initial preparation Create a separate directory for every secure zone. This is useful because there are many additional files needed to secure a zone. Besides the zone file (zone.db), there is a signed zone file (zone.db.signed), a minimum of four files containing the keying material, a file called dnskey.db with the current used keys, and the dsset- and keyset-files created by the dnssec-signzone(8) command. So in summary there is a minimum of nine files used per
180
secure zone. For every additional key there are two extra files and every delegated subzone creates also two or three files. Name the directory just like the zone. Thats only needed if you want to use the dnssec-signer command in directory mode (D). Then the name of the zone will be parsed out of the directory name. Change the name of the zone file to zone.db Otherwise you have to set the name via the dnssec.conf parameter zonefile, or you have to use the option o to name the zone and specify the zone file as argument. Add the name of the signed zonefile to the named.conf file The filename is the name of the zone file with the extension .signed. Create an empty file with the name zonefile.signed in the zone directory. Include the keyfile in the zone. The name of the keyfile is settable by the dnssec.conf parameter keyfile . The default is dnskey.db . Control the format of the SOA-Record For automatic incrementation of the serial number, the SOA-Record must be formated, so that the serial number is on a single line and left justified in a field of at least 10 spaces! If you use BIND version 9.4 or later and use the unixtime format for the serial number (See parameter Serialformat in dnssec.conf) than this is not necessary. Try to sign the zone If the current working directory is the directory of the zone example.net, use the command $ dnssec-signer D .. v v example.net $ dnssec-signer o example.net. to create the initial keying material and a signed zone file. Then try to load the file on the name server. ENVIRONMENT VARIABLES ZKT_CONFFILE Specifies the name of the default global configuration files.
181
FILES /var/named/dnssec.conf Built-in default global configuration file. The name of the default global config file is settable via the environment variable ZKT_CONFFILE. Use dnssec-zkt(8) with option Z to create an initial config file. /var/named/dnssec-<view>.conf View specific global configuration file. ./dnssec.conf Local configuration file. dnskey.db The file contains the currently used key and zone signing keys. It will be created by dnsssec-signer(8). The name of the file is settable via the dnssec configuration file (parameter keyfile). zone.db This is the zone file. The name of the file is settable via the dnssec configuration file (parameter zonefile). BUGS The named.conf parser is a bit rudimental and not very well tested. AUTHORS Holger Zuleger, Mans Nilsson COPYRIGHT Copyright (c) 2005 2009 by Holger Zuleger. Licensed under the BSD Licence. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. SEE ALSO dnssec-keygen(8), dnssec-signzone(8), rndc(8), named.conf(5), dnssec-zkt(8) RFC4033, RFC4034, RFC4035 [1] DNSSEC HOWTO Tutorial by Olaf Kolkman, RIPE NCC (http://www.nlnetlabs.nl/dnssec_howto/) [2] RFC4641 "DNSSEC Operational Practices" by Miek Gieben and Olaf Kolkman (http://www.ietf.org/rfc/rfc4641.txt)
182
FILES /var/named/dnssec.conf Built-in default global configuration file. The name of the default global config file is settable via the environment variable ZKT_CONFFILE. Use dnssec-zkt(8) with option Z to create an initial config file. /var/named/dnssec-<view>.conf View specific global configuration file. ./dnssec.conf Local configuration file. dnskey.db The file contains the currently used key and zone signing keys. It will be created by dnsssec-signer(8). The name of the file is settable via the dnssec configuration file (parameter keyfile). zone.db This is the zone file. The name of the file is settable via the dnssec configuration file (parameter zonefile). BUGS The named.conf parser is a bit rudimental and not very well tested. AUTHORS Holger Zuleger, Mans Nilsson COPYRIGHT Copyright (c) 2005 2009 by Holger Zuleger. Licensed under the BSD Licence. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. SEE ALSO dnssec-keygen(8), dnssec-signzone(8), rndc(8), named.conf(5), dnssec-zkt(8) RFC4033, RFC4034, RFC4035 [1] DNSSEC HOWTO Tutorial by Olaf Kolkman, RIPE NCC (http://www.nlnetlabs.nl/dnssec_howto/) [2] RFC4641 "DNSSEC Operational Practices" by Miek Gieben and Olaf Kolkman (http://www.ietf.org/rfc/rfc4641.txt)
183
Visit us at www.VeriSign.com for more information.

CSD 5928

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CSD 5928

Hochgeladen von

Copyright:

Verfügbare Formate

TOOL GUIDE

TOOL GUIDE SERIES ON DNSSEC

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

DISCLAIMER AND LIMITATION OF LIABILITY

NOTICE AND CAUTION CONCERNING U.S. PATENT OR TRADEMARK RIGHTS

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

Ramaswamy Chandramouli & Scott Rose

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

DEFINITIONS, ACRONYMS, & ABBREVIATIONS

DNSSEC DNSSEC Signer

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

HSM HSM market selection

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

Recursive (caching) name server Resolver RPM RR

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

Validating resolver Validator

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

3.1.4 ZONE SIGNING 3.1.5 KEY ROLLOVERS

4.1.2 TECHNOLOGIES AND ARCHITECTURE 4.1.3 KEY GENERATION

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

5 DNSSEC ZONE KEY TOOL (ZKT)

5.1.4 ZONE SIGNING 5.1.5 KEY ROLLOVERS

5.2.2 INITIALIZATION 5.2.3 CONFIGURATION 5.3 RUNNING APPLICATION 5.4 TIPS/TRICKS/GOTCHAS

Tool Guide Series on DNSSEC | Version 1

TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010

117 117 119 119 120 121

Tool Guide Series on DNSSEC | Version 1

Tool Guide Series on DNSSEC | Version 1

Tool Guide Series on DNSSEC | Version 1

Software Based Solutions OpenDNSSEC ZKT DNSSEC-Tools

Automatic zone signing Manual key rollover

Tool Guide Series on DNSSEC | Version 1

Manual key rollover

Tool Guide Series on DNSSEC | Version 1

Tool Guide Series on DNSSEC | Version 1

Speeding up cryptographic operations Keeping keys safe

Tool Guide Series on DNSSEC | Version 1

Tool Guide Series on DNSSEC | Version 1

OR (if using NSEC3)

The following files are generated under the /var/named folder:

Tool Guide Series on DNSSEC | Version 1

# /usr/local/sbin/dnssec-keygen -a RSASHA1 -b 1024 acme.com.

OR (if using NSEC3)

The following files are generated under the /var/named folder:

Tool Guide Series on DNSSEC | Version 1

# /usr/local/sbin/dnssec-signzone -o acme.com db.greeks

OR (if using NSEC3)

The following 3 files are generated under the /var/named folder:

Tool Guide Series on DNSSEC | Version 1