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 efforts 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 specifically 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 file, 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
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
REFERENCES
AUTHOR(S)
TITLE
John Dickinson, Nominet
Key and Signing Policy (KASP)
(https://www.dns-oarc.net/files/dnsops-2007/Dickinson-KASP.pdf )
1.0
Rickard Bondesson
OpenDNSSEC (PDF formatted presentation)
(http://www.iis.se/docs/OpenDNSSEC_20080213.pdf )
1.0
SPARTA, Inc.
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 )
1.0
Holger Zuleger
DNSSEC or How to secure your (reverse) zone
(http://www.hznet.de/dns/dnssec-decix050916.pdf )
1.0
Holger Zuleger
Zone Key Tool, A signing and key admin tool for DNSSEC
(http://www.hznet.de/dns/zkt-iis080530a.pdf )
1.0
Ramaswamy Chandramouli
& Scott Rose
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 )
1.0
NLnet Labs —
O. Kolkman & R. Gieben
DNSSEC Operational Practices
(http://tools.ietf.org/id/draft-ietf-dnsop-dnssec-operational-practices-06.txt)
6.0
Joakim Åhlund,
Certezza AB
A Review of Administrative Tools for DNSSEC
(http://www.iis.se/docs/DNSSEC-Admin-tools-review-1.01.pdf )
1.0
Olaf Kolkman
DNSSEC HOWTO, a tutorial in disguise
(http://www.nlnetlabs.nl/publications/dnssec_howto/dnssec_howto.pdf )
134
SPARTA, Inc.
DNS SECURITY TROUBLESHOOTING GUIDE
(http://www.dnssec-tools.org/docs/troubleshooting/
DNS-Security-Troubleshooting-Guide.pdf )
1.0
iii
Tool Guide Series on DNSSEC | Version 1
REVISION
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
DEFINITIONS, ACRONYMS, & ABBREVIATIONS
TERM
DESCRIPTION
Authoritative
name server
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.
botan
A cryptographic library used by softHSM. Version 1.8.0 or later is required.
CLI
A command-line interface (CLI) is a mechanism for interacting with a computer
operating system or software by typing commands to perform specific tasks via a
text-only interface.
CPAN
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.
Digital signature
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 verified using the corresponding public key.
DNS
Domain Name System – distributed database used to resolve domain names to IP addresses.
DNSKEY
DNSEC RR type extension used for publishing the public key(s) used within a zone for
creating a digital signature.
DNSRuby
A third-party DNS library used by the OpenDNSSEC Auditor. Version 1.32 or later is
required.
DNSSEC
DNS Security Extensions
DNSSEC Signer
The OpenDNSSEC implementation, expected to run on top of a PKCS #11 implementation,
like an HSM.
DS
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.
iv
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
TERM
DESCRIPTION
FTP
File Transfer Protocol (FTP) is a standard network protocol used to exchange and manipulate
files 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.
GPG
GnuPG, also known as GPG, is the GNU project's complete and free implementation of the
OpenPGP standard as defined 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.
HSM
Hardware Security Module (external cryptographic hardware).
HSM
market selection
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
configuration details.
HTTP
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).
HTTPS
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer
Protocol (HTTP) with the SSL/TLS protocol to provide encryption and secure identification
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 certificate is verified and trusted.
IP
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 defines addressing methods and
structures for datagram encapsulation.
IPAM
IP Address Management (IPAM) refers to the management of alloca¬tion, 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
infra¬structure in order to provide IPAM capabilities.
v
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
TERM
DESCRIPTION
KASP
Key And Signature Policy (used by OpenDNSSEC)
KSK
Key Signing Key – used to sign DNSKEY records (zone signing public pkey) in a zone –
creates the “Secure Entry Point” (SEP) for a zone.
ldns
A DNS programming library used in the signer component. OpenDNSSEC requires ldns 1.6.0
or later.
libxml2
A C-library for handling XML. It is used in all parts of OpenDNSSEC, which requires version
2.6.16 or later.
NFS
Network File System (NFS) is a network file system protocol originally developed by Sun
Microsystems in 1984, allowing a user on a client computer to access files over a network in a
manner similar to how local storage is accessed.
NSEC
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”.
NSEC3
Alternative to NSEC which uses a hashed owner name to form a chain. Only identifies signed
authentic names in the zone – zone walking NOT needed.
OpenDNSSEC
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.
OpenPGP
The most widely used email encryption standard in the world.
openSSL
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.
PKCS11
One of the family of standards called Public-Key Cryptography Standards (PKCS), published
by RSA Laboratories. It defines a platform-independent API to cryptographic tokens, such as
Hardware Security Modules (HSM).
PKCS8
Private-Key Information Syntax Standard. Used to carry private certificate keypairs (encrypted
or unencrypted).
vi
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
TERM
DESCRIPTION
Public key
cryptography
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
Recursive (caching)
name server
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.
Resolver
A piece of software that uses DNS servers to map a DNS name to an IP-address.
RPM
A Linux package management system and software package format.
RR
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
RRSIG
DNSEC RR type extension used to publish the digital signature associated with a specific name,
class, and type.
rubygems
The standard way of installing Ruby packages. It is only used for the installation of the
DNSRuby package.
SFTP
SFTP, or secure FTP, is a program that uses SSH to transfer files. 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 different 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.
SMB
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 files, 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."
vii
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
TERM
DESCRIPTION
SNMP
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 defined 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 configuration. These variables can then be queried (and sometimes
set) by managing applications.
SoftHSM
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.
SQLite
A cut-down SQL database system used by the KASP and softHSM components of
OpenDNSSEC.
SSH
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.
SSL
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.
TCP
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.
TCP/IP
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 first two networking protocols defined 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.
viii
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
TERM
DESCRIPTION
Time-to-live
The time period during which an answer to a DNS query remains valid and can thus
be cached.
TLS
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 confidentiality.
Trust anchor
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.
UDP
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.
Validating resolver
A resolver that validates the DNSSEC signatures on the answers it receives to DNS queries.
Validator
A piece of software that verifies the authenticity of a digital signature using the public key that
was used to create the signature.
wget
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 offline viewing of local HTML, support for proxies, and
many others.
YUM
The Yellowdog Updater, Modified - is an open-source command-line package management
utility for RPM-compatible Linux Operating Systems.
Zone
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
ZSK
Zone Signing Key - used to sign all data in a zone.
ix
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
CONTENTS
1
INTRODUCTION
1
1.1 INTRODUCTION TO DNSSEC
2
1.2 FEATURES COMPARISON MATRIX FOR DNSSEC SOLUTIONS
3
1.3 OTHER DNSSEC TOOLS
5
1.4 HARDWARE SECURITY MODULES (HSMS)
5
1.5 DNSSEC APPLIANCES
6
2 BIND 9
2.1 OVERVIEW
7
2.1.1 BACKGROUND
7
2.1.2 KEY GENERATION
8
2.1.2.1 DNSSEC-KEYGEN (FILE-BASED)
8
2.1.2.2 DNSSEC-KEYFROMLABEL (HSM-BASED)
9
2.1.3 ZONE SIGNING
9
2.1.3.1 HOW TO DO IT, INCLUDING CONFIGURATION
AND COMMAND-LINE PARAMETERS
9
2.1.3.2 NSEC/NSEC3
12
2.1.3.3 LOADING SIGNED ZONE INTO NAME SERVER
12
2.1.3.4 RE-SIGNING
13
2.1.4 KEY ROLLOVERS
14
2.1.4.1 HOW TO ROLL ZSK
14
2.1.4.2 HOW TO ROLL KSK
16
2.1.5 PUBLISHING OF DS DATA TO PARENT ZONE
2.2 SETUP
2.2.1 INSTALLATION STEPS
17
18
18
2.2.1.1 PREREQUISITES
18
2.2.1.2 INSTALLATION
18
2.2.1.3 CONFIGURATION
2.3 RUNNING APPLICATION
18
21
2.3.1 DAEMONS
21
2.3.2 COMMAND LINE UTILITIES
22
2.3.2.1 MAINTENANCE UTILITIES
2.3.3 ADD-ONS
2.4 TIPS/TRICKS/GOTCHAS
x
7
Tool Guide Series on DNSSEC | Version 1
22
23
23
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
3 OPENDNSSEC
3.1 OVERVIEW
25
3.1.1
BACKGROUND
25
3.1.2
TECHNOLOGIES & ARCHITECTURE OVERVIEW
26
3.1.3
KEY GENERATION
29
3.1.4 ZONE SIGNING
30
3.1.5
31
KEY ROLLOVERS
3.1.6 PUBLISHING OF DS DATA TO PARENT ZONE
32
3.2 SETUP
32
3.2.1
INSTALLATION STEPS
32
3.2.1.1 SUBVERSION CLIENT
33
3.2.1.2 PREREQUISITE SOFTWARE
33
3.2.1.3 OPENDNSSEC
34
3.2.1.4 SOFTHSM
34
3.2.1.5 POST-INSTALL (LINUX SYSTEMS ONLY)
35
3.2.2 CONFIGURATION
35
3.2.3 INITIALIZATION
45
3.2.4 PROCESSING INPUT/OUTPUT
48
3.3 RUNNING APPLICATION
3.3.1
DAEMONS
49
49
3.3.1.1 SIGNER ENGINE
50
3.3.1.2 ODS-ENFORCERD
50
3.3.2 COMMAND LINE UTILITIES
50
3.3.2.1 SIGNER ENGINE
50
3.3.2.2 KASP ENFORCER
51
3.3.2.3 HSMS
52
3.3.2.4 MISCELLANEOUS
3.4 TIPS/TRICKS/GOTCHAS
4 DNSSEC-TOOLS
4.1 OVERVIEW
4.1.1
xi
25
BACKGROUND
53
57
59
59
59
4.1.2 TECHNOLOGIES AND ARCHITECTURE
59
4.1.3 KEY GENERATION
61
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
4.1.4 ZONE SIGNING
62
4.1.5 KEY ROLLOVERS
62
4.1.6 PUBLISHING OF DS DATA TO PARENT ZONE
64
4.2 SETUP
65
4.2.2 CONFIGURATION
66
4.3 RUNNING APPLICATION
70
4.3.1 DAEMONS
70
4.3.2 COMMAND LINE UTILITIES
70
4.4 TIPS/TRICKS/GOTCHAS
5 DNSSEC ZONE KEY TOOL (ZKT)
5.1 OVERVIEW
5.1.1
BACKGROUND
74
75
75
75
5.1.2
TECHNOLOGIES & ARCHITECTURE
76
5.1.3
KEY GENERATION
76
5.1.4 ZONE SIGNING
78
5.1.5
85
KEY ROLLOVERS
5.1.6 PUBLISHING OF DS DATA TO PARENT ZONE
87
5.2 SETUP
87
5.2.1
88
INSTALLATION STEPS
5.2.2 INITIALIZATION
88
5.2.3 CONFIGURATION
88
5.3 RUNNING APPLICATION
90
5.4 TIPS/TRICKS/GOTCHAS
90
6 TROUBLESHOOTING DNSSEC
6.1 FAILURE MODES
xii
65
4.2.1 INSTALLATION STEPS
92
92
6.2 TOOLS
94
6.2.1
94
BIND SERVER LOGS
6.2.2 DIG
95
6.2.3 TRUSTMAN
96
6.2.4 LOGWATCH
96
6.2.5 DONUTS
97
6.2.6 DRILL
110
Tool Guide Series on DNSSEC | Version 1
TOOL GUIDE SERIES ON DNSSEC - FEBRUARY 2010
6.2.7 AUTOTRUST
117
6.2.8 VERISIGN JDNSSEC TOOLS
117
6.2.9 VALIDATE
119
6.2.10 MAPPER
119
6.2.11 DNSPKTFLOW
120
6.3 EXAMPLE SESSION
121
APPENDIX
xiii
A
OPENDNSSEC INSTALLATION NOTES FOR RHEL 5.3
126
B
ADDITIONAL OPENDNSSEC UTILITIES
131
C
LDNS PROJECT UTILITIES
133
D
USING SQLITE
136
E
SAMPLE SCRIPT FOR OPENDNSSEC <NOTIFYCOMMAND>
138
F
SAMPLE OPENDNSSEC SIGNED ZONE
139
G
KNOWN ISSUES
144
H
CONVERT DNSKEY RECORD INTO CANONICAL FORM
145
I
BIND DNSSEC-SIGNZONE OUPUT FILES
147
J
CONFIGURING AND SERVING A SIGNED ZONE
155
K
MIGRATING FROM BIND TO DNSSEC-TOOLS
156
L
BIND’S NSUPDATE COMMAND FORMATS
157
M
OTHER DNSSEC-RELATED TOOLS
160
N
SAMPLE ZKT ZONE SIGNER CRON JOB
170
O
ALGORITHMS FOR KEY ROLLOVER
171
P
MAN PAGES FOR DNSSEC-SIGNER AND DNSSEC-ZKT
172
Tool Guide Series on DNSSEC | Version 1
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 organization‘s 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
Tool Guide Series on DNSSEC | Version 1
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.
2
Tool Guide Series on DNSSEC | Version 1
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
Software Based Solutions
BIND9.6
OpenDNSSEC
ZKT
DNSSEC-Tools
Support PKCS#11 interface with an
HSM
●
Automatic key generation
●
●
●
●
●
●
●
●
Denial of existence using NSEC or
NSEC3
●
Automatic key rollover
(ZSK only)
Automatic zone signing
Manual key rollover
●
●
●
●
●
(ZSK only)
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)
3
Tool Guide Series on DNSSEC | Version 1
●
The following table describes the DNSSEC specific features listed in the matrix above and their
importance:
Features
Description
Support
PKCS#11
interface with
an HSM
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
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
using NSEC
or NSEC3
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.
Manual key
rollover
Automatic key
4
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
Tool Guide Series on DNSSEC | Version 1
rollover
interaction thereby reducing the burden for a DNS operator.
Automatic
zone signing
Automatic zone signing occurs unassisted without the need for user interaction thereby
reducing the burden for a DNS operator.
Extraction of
Delegation
Signer (DS)
records for
publishing
KSK to parent
zone
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.
Sign zones
received from
transfer
(AXFR)
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.
5
Tool Guide Series on DNSSEC | Version 1
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.
6
Tool Guide Series on DNSSEC | Version 1
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, you‘ll be given a
background on the tool and a summary of how it supports the most important aspects of
DNSSEC. Following that, you‘ll 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 you‘ll find in this software. After a summary
and background of the tool, you‘ll 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:
7
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.
Tool Guide Series on DNSSEC | Version 1
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
8
Tool Guide Series on DNSSEC | Version 1
# /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
9
Tool Guide Series on DNSSEC | Version 1
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--
1 root root
8938 Nov 19 20:48 acme.com.zone.signed
-rw-r--r--
1 root root
477 Nov 19 20:48 keyset-acme.com.
-rw-r--r--
1 root root
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
#/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
Tool Guide Series on DNSSEC | Version 1
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.
3600
3600
3600
3600
IN
IN
IN
IN
NS
NS
NS
NS
ns1.acme.com.
noc.acme.com.
ns2.acme.com.
ns3.acme.com.
;; ADDITIONAL SECTION:
noc.acme.com.
ns1.acme.com.
ns2.acme.com.
ns3.acme.com.
3600
3600
3600
3600
IN
IN
IN
IN
A
A
A
A
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
Key Rollovers
2.1.4.1
2.1.4.1.1
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
14
Kacme.com.+005+28350.key >> db.greeks.signed
Sign the zone with both keys
Tool Guide Series on DNSSEC | Version 1
# 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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
# ----------------------------------zone "0.0.127.in-addr.arpa"
zone "acme.com"
{ type master;
{ type master;
zone "5.168.192.in-addr.arpa"
file "db.127.0.0"; };
file "db.greeks.signed"; };
{ type master;
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
Tool Guide Series on DNSSEC | Version 1
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;acme.com.
IN
SOA
IN
SOA
dev-ng-core4.acme.com. dnsuser.acme.com. 4
IN
NS
dev-ng-core4.acme.com.
IN
A
192.168.5.1
;; ANSWER SECTION:
acme.com.
86400
10800 3600 604800 86400
;; AUTHORITY SECTION:
acme.com.
86400
;; ADDITIONAL SECTION:
dev-ng-core4.acme.com. 86400
;; 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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
23
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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, you‘ll be given a
background on the tool and a summary of how it supports the most important aspects of
DNSSEC. Following that, you‘ll 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 you‘ll find in this software. After a summary
and background of the tool, you‘ll 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:
25
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)
Tool Guide Series on DNSSEC | Version 1
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++
(used by various pre-requisites like OpenSSL and ldns)
Perl
(used by the KASP Enforcer component)
Python
(used by the Signer Engine component)
Ruby
(used for the KASP Auditor component)
Java
(required only for building OpenDNSSEC)
The following diagram identifies the architecture for the OpenDNSSEC components including
zone input/output:
26
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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:
28
a set of keys created in the Security Module
a signer configuration passed on to the Signer
Tool Guide Series on DNSSEC | Version 1
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. Here‘s a simple example where the configured repository associated with the
HSM is named ―myHSM‖:
29
Tool Guide Series on DNSSEC | Version 1
# 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
Tool Guide Series on DNSSEC | Version 1
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
31
Pre- and post-publish considerations & timing?
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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:
33
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
# 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
Description
/etc/softhsm.conf
Configuration for the virtual software-based
HSM. Defines numbered slot to be associated
with sqlite3 database instances for storing HSM
based configurations.
/etc/opendnssec/conf.xml
Overall configuration for OpenDNSSEC.
/var/opendnssec/signconf/examplezone.com.xml
Zone specific Signer configuration file for the
example-zone.com zone.
/etc/opendnssec/kasp.xml
Configuration file which defines the Key and
Signature Policy used for zone signing a key
management.
/etc/opendnssec/zonelist.xml
List of all zones managed by OpenDNSSEC
The following detailed steps discuss how to create/configure these key files:
1.
35
Edit softhsm.conf (optional)
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
/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>
<!-- the <NotifyCommmand> will expand the following variables:
%zone
the name of the zone that was signed
%zonefile
the filename of the signed zone
-->
<!-<NotifyCommand>
my_nameserver_reload_command
ex: /var/opendnssec/bin/install-zone.sh %zone %zonefile
</NotifyCommand>
-->
</Signer>
<Auditor>
37
Tool Guide Series on DNSSEC | Version 1
<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
Tool Guide Series on DNSSEC | Version 1
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"?>
<!-- $Id: zonefetch.xml.in 1920 2009-09-30 07:49:39Z matthijs $ -->
<ZoneFetch>
<!-- where to listen for notifies -->
<!-- DEFAULT: do not listen to notify on specific address -->
<NotifyListen><Port>53</Port></NotifyListen>
<!-- default inbound AXFR settings
(per zone setting not yet implemented) -->
<Default>
<!-- TSIG secret for inbound AXFR -->
<!-- DEFAULT: don't use TSIG -->
<TSIG>
<Name>secret.example.com.</Name>
<!-- http://www.iana.org/assignments/tsig-algorithm-names -->
<Algorithm>hmac-sha256</Algorithm>
<!-- base64 encoded secret -->
<Secret>sw0nMPCswVbes1tmQTm1pcMmpNRK+oGMYN+qKNR/BwQ=</Secret>
</TSIG>
<!-- address of host to request AXFR from -->
<!-- incoming NOTIFY has to match this address as well -->
<!-- DEFAULT: none -->
<RequestTransfer>
<IPv4>192.0.2.2</IPv4><Port>53</Port>
</RequestTransfer>
</Default>
</ZoneFetch>
39
Tool Guide Series on DNSSEC | Version 1
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
ID
Type
----------
--
----
softHSM
a2b2
RSA/2048
softHSM
a1b1
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
Tool Guide Series on DNSSEC | Version 1
</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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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>
<!-- Parameters for both KSK and ZSK -->
<TTL>PT3600S</TTL>
43
Tool Guide Series on DNSSEC | Version 1
<RetireSafety>PT3600S</RetireSafety>
<PublishSafety>PT3600S</PublishSafety>
<Purge>P14D</Purge>
<!-- <ShareKeys/> -->
<!-- Parameters for KSK only -->
<KSK>
<Algorithm length="2048">7</Algorithm>
<Lifetime>P1Y</Lifetime>
<Repository>softHSM</Repository>
<Standby>1</Standby>
<RFC5011/>
</KSK>
<!-- Parameters for ZSK only -->
<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
Tool Guide Series on DNSSEC | Version 1
<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
45
Description
Tool Guide Series on DNSSEC | Version 1
/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.
/var/opendnssec/slot0.db
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.
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
# 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
Description
/var/opendnssec/unsigned/
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.
/var/opendnssec/signed/
Folder containing the output signed zones for any
defined unsigned input zone files.
/var/log/messages
System console logger used by all daemons and
CLIs
48
Tool Guide Series on DNSSEC | Version 1
A sample unsigned input zone file can be created as follows:
# vi /var/opendnssec/unsigned/example-zone.com
@ IN SOA
IN NS
dev-ng-core4 dnsuser ( 4 10800 3600 604800 86400 )
dev-ng-core4
localhost
A
127.0.0.1
ajax
A
192.168.5.24
MX
10 ajax
A
192.168.5.23
MX
10 odysseus
A
192.168.5.20
MX
10 achilles
A
192.168.5.22
MX
10 diomedes
A
192.168.5.1
MX
10 dev-ng-core4
A
192.168.5.28
MX
10 menelaeus
A
192.168.5.21
MX
10 agamemnon
odysseus
achilles
diomedes
dev-ng-core4
menelaeus
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
Tool Guide Series on DNSSEC | Version 1
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
show the currently known zones
sign <zone>
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
show the current task queue
flush
execute all scheduled tasks immediately
update <zone>
check for changed zone conf xml file, if
<zone> is not given all zones are checked
stop
50
stop the engine
Tool Guide Series on DNSSEC | Version 1
restart
restart the engine
verbosity <nr>
set verbosity (notimpl)
cmd> zones
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>
51
Tool Guide Series on DNSSEC | Version 1
aka
aka
aka
aka
aka
-z
-p
-s
-i
-o
aka -z / -a
aka -z / -a
aka
aka
aka
aka
-z / -a
-e
-t
-d
aka
aka
aka
aka
-k
-r
-z
-b
--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
52
ID
Tool Guide Series on DNSSEC | Version 1
Type
---------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
Description
ods-control
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
Convert from PKCS#8 to BIND .private-key format.
Use with --in, --pin, --name, --ttl, --ksk, and -
-algorithm.
--algorithm <alg>
Specifies which DNSSEC algorithm to use in file.
RSAMD5
DSA
RSASHA1
53
Tool Guide Series on DNSSEC | Version 1
Utility
Description
RSASHA1-NSEC3-SHA1
DSA-NSEC3-SHA1
RSASHA256
RSASHA512
-h
Shows this help screen.
--help
Shows this help screen.
--in <path>
The path to the input file.
--ksk
Set the flag to 257. Key Signing Key. Optional.
--name <name>
"example.com."
The owner name. Do not forget the trailing dot, e.g.
--out <path>
The path to the output file.
--pin <PIN>
To encrypt/decrypt PKCS#8 file. Optional.
--ttl <ttl>
The TTL to use for the DNSKEY RR. Optional.
The following files will be created:
K<name>+<alg id>+<key tag>.key
Public key in RR format
K<name>+<alg id>+<key tag>.private
Private key in key format
E.g.
Kexample.com.+007+05474.private
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]
Path to OpenDNSSEC configuration file
(defaults to
/etc/opendnssec/conf.xml)
-k, --kasp [PATH_TO_KASP_FILE]
Path to KASP policy file
(defaults to the path given in the
configuration file)
-z, --zone [ZONE_NAME]
54
Tool Guide Series on DNSSEC | Version 1
Single zone to audit
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
Run the auditor as a daemon
-v, --version
Display version information
Common options:
-h, -?, --help
ods-kaspcheck
Show this message
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]
Path to OpenDNSSEC configuration file
(defaults to
/etc/opendnssec/conf.xml)
-k, --kasp [PATH_TO_KASP_FILE]
Path to KASP policy file
(defaults to the path given in the
configuration file)
-v, --version
Display version information
Common options:
-h, -?, --help
softhsm
Show this message
A support tool for libsofthsm and interacting with the softHSM virtual
HSM:
Usage: softhsm [OPTIONS]
Options:
--show-slots
Display all the available slots.
--init-token
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
Tool Guide Series on DNSSEC | Version 1
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>
Supply a PIN if the file is encrypted.
--force
Override some warnings.
-h
Shows this help screen.
--help
Shows this help screen.
--id <hex>
Defines the ID of the object. Hexadecimal characters.
Use with --force if multiple key pairs may share
the same ID.
--label <text>
Defines the label of the object or the token.
--pin <PIN>
The PIN for the normal user.
--slot <number>
The slot where the token is located.
--so-pin <PIN>
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
Tool Guide Series on DNSSEC | Version 1
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=
57
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.
Tool Guide Series on DNSSEC | Version 1
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.
58
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.
Tool Guide Series on DNSSEC | Version 1
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, you‘ll be given a
background on the tool and a summary of how it supports the most important aspects of
DNSSEC. Following that, you‘ll 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 you‘ll find in this software. After a summary of
the tool, you‘ll 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
Description
Zone Administration Tools
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)
Authoritative Server Tools
Tools that can be used to help maintain an authoritative Domain Name Server. They include signing
tools, automatic signing tools, and notification tools.
59
Tool Guide Series on DNSSEC | Version 1
Component
Description
(see http://www.dnssec-tools.org/wiki/index.php/Category:Authoritative_Server_Tools)
Recursive 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
● Sendmail
● Postfix
● Libspf2
● Thunderbird
● ssh
● lftp
● wget
● ncftp
● proftpd
● jabberd
(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
Tool Guide Series on DNSSEC | Version 1
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
Description
Kzone-name.+algid+keytag.private
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.
Kzone-name.+algid+keytag.key
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.
61
Tool Guide Series on DNSSEC | Version 1
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
Description
output-file.signed
The signed zone file. The .signed is added by zonesigner.
keyset-zone-name
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.
dsset-zone-name
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:
62
The Current ZSK becomes obsolete
The Current ZSK becomes obsolete
The Published ZSK becomes the Current ZSK
The New ZSK becomes the Published ZSK
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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 child‘s 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
65
NSEC3 support
: No
DLV support
: No
IPv6 support
: No
Tool Guide Series on DNSSEC | Version 1
Thread support
: Yes
Developer flags
:
libval resolver configuration
: /usr/local/etc/dnssec-tools/resolv.conf
libval root hints
: /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.
66
Create the DNSSEC-Tools Configuration File
Tool Guide Series on DNSSEC | Version 1
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 file contains configuration information for DNSSEC-Tools.
#
#
This was automatically generated by dtinitconf on
#
Mon Oct 26 06:32:16 2009 (GMT).
#
#
# Settings for DNSSEC-Tools administration.
#
admin-email
#
# Paths to needed programs.
These may need adjusting for individual hosts.
#
keygen
67
/usr/local/sbin/dnssec-keygen
Tool Guide Series on DNSSEC | Version 1
viewimage
/usr/X11R6/bin/xview
zonecheck
/usr/local/sbin/named-checkzone
zonesign
/usr/local/sbin/dnssec-signzone
zonesigner
/usr/bin/zonesigner
#
# Key-related values.
#
algorithm
NSEC3RSASHA1
ksklen
2048
zsklen
1024
random
/dev/urandom
#
# NSEC3 functionality
#
usensec3
yes
nsec3iter
100
nsec3salt
random:64
nsec3optout
no
#
# Settings for dnssec-signzone.
#
endtime
+2592000
# RRSIGs good for thirty days.
#
# Life-times for keys.
# between rollovers.
These defaults indicate how long a key has
The values are measured in seconds.
#
# Sample values:
68
#
3600
hour
#
86400
day
#
604800
week
#
2592000
30-day month
#
15768000
half-year
Tool Guide Series on DNSSEC | Version 1
#
31536000
year
#
ksklife
15552000
zsklife
604800
#
# Settings for zonesigner.
#
archivedir
entropy_msg
1
savekeys
1
zskcount
1
#
# Settings for rollerd.
#
roll_logfile
/usr/local/etc/dnssec-tools/log-rollerd
roll_loglevel
info
roll_sleeptime
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
69
Secure Your Files
Tool Guide Series on DNSSEC | Version 1
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
Tool Category
Description
WIKI Page URL
rollerd
Key Rollover
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.
http://www.dnssectools.org/wiki/index.php/Rollerd
donutsd
Zone Troubleshooting
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.
http://www.dnssectools.org/wiki/index.php/Donutsd
keyarch
DNSSEC-Tools
Maintenance
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
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
70
Tool Category
Description
Tool Guide Series on DNSSEC | Version 1
WIKI Page URL
Tool
Tool Category
Description
WIKI Page URL
zonesigner
Zone Signing
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
http://www.dnssectools.org/wiki/index.php/Zonesigner
genkrf
Zone Signing
Generates a keyrec file from KSK and/or
ZSK files. It generates new KSK and ZSK
keys if needed.
http://www.dnssectools.org/docs/tooldescription/genkrf.html
krfcheck
Zone Signing
Check a DNSSEC-Tools keyrec file for
problems and inconsistencies
http://www.dnssectools.org/docs/tooldescription/krfcheck.html
lskrf
Zone Signing
List the keyrecs in a DNSSEC-Tools
keyrec file
http://www.dnssectools.org/docs/tooldescription/lskrf.html
expchk
Zone Signing
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.
http://www.dnssectools.org/docs/tooldescription/expchk.html
fixkrf
Zone Signing
Fixes DNSSEC-Tools keyrec files whose
encryption key files have been moved
http://www.dnssectools.org/docs/tooldescription/fixkrf.html
cleankrf
Zone Signing
Clean a DNSSEC-Tools keyrec files of old
data
http://www.dnssectools.org/docs/tooldescription/cleankrf.html
signseteditor
Zone Signing
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).
http://www.dnssectools.org/docs/tooldescription/signset-editor.html
donuts
Zone Troubleshooting
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).
http://www.dnssectools.org/wiki/index.php/Donuts
71
Tool Guide Series on DNSSEC | Version 1
Tool
Tool Category
Description
WIKI Page URL
It is extremely flexible and local rule sets
and configuration can tailor its output to
define local policies.
mapper
Zone Troubleshooting
Graphically display the contents of your
zone (for *nix systems, requires XWindow).
http://www.dnssectools.org/wiki/index.php/Mapper
dnspktflow
Zone Troubleshooting
Visually trace DNS packets being sent on
the network.
http://www.dnssectools.org/wiki/index.php/Dnspktflow
logwatch
Zone Troubleshooting
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.
http://www.dnssectools.org/wiki/index.php/Logwatch
rollctl
Key Rollover
Send commands to the daemon rollerd
without restarting it.
http://www.dnssectools.org/wiki/index.php/Rollctl
rollinit
Key Rollover
Creates new rollrec entries for a rollrec
file. This rollrec file will be used by
rollerd to manage key rollover for the
named domains
http://www.dnssectools.org/docs/tooldescription/rollinit.html
rollchk
Key Rollover
Check a DNSSEC-Tools rollrec file for
problems and inconsistencies
http://www.dnssectools.org/docs/tooldescription/rollchk.html
rollset
Key Rollover
Modifies entries in a DNSSEC-Tools
rollrec file
http://www.dnssectools.org/docs/tooldescription/rollset.html
rollreceditor
Key Rollover
Provides the capability for easy GUIbased management of rollrec files (for
*nix systems, requires X-Window)
http://www.dnssectools.org/docs/tooldescription/rollrec-editor.html
lsroll
Key Rollover
Lists the contents of the specified rollrec
files
http://www.dnssectools.org/docs/tooldescription/lsroll.html
rolllog
Key Rollover
DNSSEC-Tools utility to write messages
to the DNSSEC rollover log file
http://www.dnssectools.org/docs/tooldescription/rolllog.html
trustman
Trust Anchor
Detects key changes in trust anchors
(TAs), it can update TAs and it can run as
http://www.dnssec-
72
Tool Guide Series on DNSSEC | Version 1
Tool
Tool Category
Description
WIKI Page URL
Maintenance
a daemon.
tools.org/wiki/index.php/Trustman
getdnskeys
Trust Anchor
Maintenance
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
http://www.dnssectools.org/docs/tooldescription/getdnskeys.html
getds
Trust Anchor
Maintenance
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
http://www.dnssectools.org/docs/tooldescription/getds.html
tachk
Trust Anchor
Maintenance
Check the validity of the trust anchors in a
named.conf file
http://www.dnssectools.org/docs/tooldescription/tachk.html
validate
Validator
Troubleshooting
Performs validated domain lookups. It is
similar to dig but can provide in depth
output on the validation steps taken during
a lookup.
http://www.dnssectools.org/wiki/index.php/Validate
getaddr
Validator
Troubleshooting
Command-line test program for the
val_getaddrinfo() function
http://www.dnssectools.org/docs/tooldescription/getaddr.html
gethost
Validator
Troubleshooting
Command-line test program for the
val_gethostbyname() (and related)
functions
http://www.dnssectools.org/docs/tooldescription/gethost.html
getname
Validator
Troubleshooting
Command-line test program for the
val_getnameinfo() function
http://www.dnssectools.org/docs/tooldescription/getname.html
getquery
Validator
Troubleshooting
Command-line test program for the
val_res_query() function
http://www.dnssectools.org/docs/tooldescription/getquery.html
getrrset
Validator
Troubleshooting
Command-line test program for the
val_get_rrset() function
http://www.dnssectools.org/docs/tooldescription/getrrset.html
libval_check_
conf
Validator
Troubleshooting
Command-line program for checking
validity of the validator configuration files
http://www.dnssectools.org/docs/tooldescription/libval_check_conf.html
drawvalmap
Validator
Troubleshooting
Generate a graphical output of validation
status values encountered by the validator
library
http://www.dnssectools.org/docs/tool-
73
Tool Guide Series on DNSSEC | Version 1
Tool
Tool Category
Description
WIKI Page URL
description/drawvalmap.html
maketestzone
Validator
Troubleshooting
Generates a test DNSSEC zone
http://www.dnssectools.org/docs/tooldescription/maketestzone.html
dtinitconf
DNSSEC-Tools
Maintenance
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
http://www.dnssectools.org/docs/tooldescription/dtinitconf.html
dtdefs
DNSSEC-Tools
Maintenance
Displays defaults defined for DNSSECTools
http://www.dnssectools.org/docs/tooldescription/dtdefs.html
dtconf
DNSSEC-Tools
Maintenance
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
http://www.dnssectools.org/docs/tooldescription/dtconf.html
dtck
DNSSEC-Tools
Maintenance
Checks DNSSEC-Tools data files to
determine if the entries are valid
http://www.dnssectools.org/docs/tooldescription/dtck.html
dtconfchk
DNSSEC-Tools
Maintenance
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
http://www.dnssectools.org/docs/tooldescription/dtconfchk.html
timetrans
DNSSEC-Tools
Maintenance
Net::DNS::SEC::Tools::timetrans Convert an integer seconds count into text
units
http://www.dnssectools.org/docs/tooldescription/timetrans.html
4.4
74
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
Tool Guide Series on DNSSEC | Version 1
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, you‘ll be given a
background on the tool and a summary of how it supports the most important aspects of
DNSSEC. Following that, you‘ll 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 you‘ll find in this software. After a summary of
the tool, you‘ll 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
dnssec-signer
to create and list DNSSEC zone keys and
to sign a zone and manage the lifetime of the zone signing keys
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:
75
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
Tool Guide Series on DNSSEC | Version 1
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
Description
Kexample.com.+005+15330.published
The private portion of the generated KSK
Kexample.com.+005+15330.key
The DNSKEY RR generated from the public key for the KSK
Kexample.com.+005+40517.published
The private portion of the generated ZSK
Kexample.com.+005+40517.key
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
76
Contents of the private key file for the generated KSK:
Tool Guide Series on DNSSEC | Version 1
# 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
Tool Guide Series on DNSSEC | Version 1
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
SOA
ns.example.com. username.example.com. (
2009113005
1d
1d
4w
1h
)
example.com.
NS
ns
example.com.
NS
ns.somewhere.com.
example.com.
MX
10 mail.example.com.
@
MX
20 mail2.example.com.
@
MX
50 mail3
example.com.
A
10.0.0.1
ns
A
10.0.0.2
www
CNAME ns
wwwtest
CNAME www
mail
A
10.0.0.3
;
;--------------------------------------------;include the DNSKEY records
$INCLUDE dnskey.db
Sign the zone:
# /usr/local/bin/dnssec-signer -f -v -v -o example.com.
parsing zone "example.com." in dir "."
Check RFC5011 status
78
Tool Guide Series on DNSSEC | Version 1
->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"
-g -o example.com. -e +864000
Cmd dnssec-signzone return: "zone.db.signed"
Signing completed after 1s.
View Output files:
Output File
Description
keyset-example.com.
Contains the DNSKEY RRs for all KSKs
Kexample.com.+005+65237.private
Contains the private portion of the generated ZSK
Kexample.com.+005+65237.key
Contains the DNSKEY RR generated from the public key for the
ZSK
Kexample.com.+005+00126.private
Contains the private portion of the generated KSK
Kexample.com.+005+00126.key
Contains the DNSKEY RR generated from the public key for the
KSK
dsset-example.com.
Contains the DS RRs associated with the DNSKEY RRs for all
KSKs
dnskey.db
Contains the DNSKEY RRs for all KSKs and ZSKs
zone.db.signed
The created signed version of the input zone (zone.db)
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
Tool Guide Series on DNSSEC | Version 1
86400
; refresh (1 day)
86400
; retry (1 day)
2419200
; expire (4 weeks)
3600
; minimum (1 hour)
)
3600
RRSIG
SOA 5 2 3600 20091210021210 (
20091130021210 65237 example.com.
q1kfn4WCwuDZvxEkv+/mOTHA0dzbf6tGLEG+
uuvpC/QGMDF7ArOK/8jZAEZIP+9VGWAy7WUV
RDeYLCbqTCmilg== )
3600
NS
ns.example.com.
3600
NS
ns.somewhere.com.
3600
RRSIG
NS 5 2 3600 20091210021210 (
20091130021210 65237 example.com.
ozy6OJ9grCW2i24PON+VrSymU/iB+ijDJeZ8
VFHukQIfwGKDlFnbPJZg9Tn+kQdz6I2CKTcC
S6Llw2KXhIW3vg== )
3600
A
10.0.0.1
3600
RRSIG
A 5 2 3600 20091210021210 (
20091130021210 65237 example.com.
Xksdd8eMIXMZCM62ulay+xOF2slRVGCt78BB
0YPvY1LKWrXcokpexi3ZSXqeWODkjcOSgZI5
YqozIkMQK2vVag== )
3600
MX
10 mail.example.com.
3600
MX
20 mail2.example.com.
3600
MX
50 mail3.example.com.
3600
RRSIG
MX 5 2 3600 20091210021210 (
20091130021210 65237 example.com.
UR3h6vMlQmNWngRV3dv7TTE0AU8AOOMBg+Df
BbfBzbkIcdvpsRnfCRZCj4vaTwTULobnDiQ/
EdmyFqR9jIr6rw== )
3600
NSEC
mail.example.com. A NS SOA MX RRSIG NSEC DNSKEY
3600
RRSIG
NSEC 5 2 3600 20091210021210 (
20091130021210 65237 example.com.
nz6h14SK6Bxm04Tb6O0ZbbRgccgAdpTTyrzM
jnw4eAGA5D+Inf4I6AtDFW1C6tyd1h9w4WmT
80
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
+KOC57wPDK8m1yWf4+yV8W9FghcRty2pUNYk
NA== )
14400
RRSIG
DNSKEY 5 2 14400 20091210021210 (
20091130021210 65237 example.com.
R1JXjYNxy5dEALcBveK+jzNaOBQM+5cqR1aS
JV7pAjMfpNvko9yMOMjq1fukQkoog81uTINu
7/Uo5IZp27svfw== )
mail.example.com.
3600
IN A
10.0.0.3
3600
RRSIG
A 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
SizaztxjryCBYVMw3WhYLW9Cucxe1EyCOhQS
iXAL60VpsSm59sEAy8CZ2bOpKXyJKi69bcxm
zjJmBdo9s/Lr/A== )
3600
NSEC
ns.example.com. A RRSIG NSEC
3600
RRSIG
NSEC 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
bhfPT0jmCUMLguD5CO8UFJKElel+apYNdEso
34BvL7nVVcIICVXriIWEgJoE9sRMEBjKKvUd
7dA5WkqgkcgAsw== )
ns.example.com.
3600
IN A
10.0.0.2
3600
RRSIG
A 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
KL58RNrHcgs6HkgY8FlrQc7b3aLnzkAs7DMk
mcpe01N4v67Kxaz3afsGkxIophxuPlPn+/WC
8Ww0G1YIoq80Sw== )
3600
NSEC
www.example.com. A RRSIG NSEC
3600
RRSIG
NSEC 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
UI4M4ADpJNmkOp2HUDOma0epvW0Ok6Sim4Jx
cQ31t/+P+nSPvmeT66+eL+zQZ+Q4Es31VYqx
kJkAoilWNXhp9A== )
www.example.com.
3600
IN CNAME ns.example.com.
3600
RRSIG
CNAME 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
lEZGBwDjZgCz27f0WVDTtG/syEYG3C1cnbS9
BG9iqp6ekCWOtJNOi7wSAp7ygBGJeV0hqExC
82
Tool Guide Series on DNSSEC | Version 1
Of6wSfdK3Oz+3w== )
3600
NSEC
wwwtest.example.com. CNAME RRSIG NSEC
3600
RRSIG
NSEC 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
qd1AtOjfQMHC5ljGlESk9BrURv+4Zenmp67P
4m0UUGXDjbrQUJxj570VCCjoGA5SX2Vpg1gp
DIaR7NO3yItKZA== )
wwwtest.example.com.
3600
IN CNAME www.example.com.
3600
RRSIG
CNAME 5 3 3600 20091210021210 (
20091130021210 65237 example.com.
dBgB4nrREjMqrkawdfCVEtO5t+UdXLCmObPV
cPi56XWu2Pc4ybfdm5nA3eZ5a7ibm7rUS3/G
MNy2UvnsEFtsMw== )
3600
NSEC
example.com. CNAME RRSIG NSEC
3600
RRSIG
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
Tool Guide Series on DNSSEC | Version 1
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:
;
;
!!! Don't edit this file by hand.
;
!!! It will be generated by dnssec-signer.
;
;
Last generation time Nov 29 2009 22:12:10
;
;
***
List of Key Signing Keys
; example.com.
tag=15330
***
algo=RSASHA1
example.com. 14400 IN DNSKEY
generated Nov 23 2009 00:42:11
257 3 5 (
BQEAAAABC5OoG6+iRh8qbAKFruji3423lJpdCxXC8LyqPq4eiMzuqgLN
c+YBaVtrjMoY7kRjjAt9bna5NN9I2sfEfq3cru7+BXSeRDFHZv20lb32
ovMCk53uDZfaNdZ0bPUzw7jimLU5Xjy/splO4gAHdPrF0tdU1wxzVxsQ
pbNA/9S6IRfvHUDwOeDL6e3mdTVdgXfz9kl1NDyhOOsaThNE0oMa/AN5
yw==
) ; key id = 15330
; example.com.
tag=126
algo=RSASHA1
example.com. 14400 IN DNSKEY
generated Nov 29 2009 22:12:10
257 3 5 (
BQEAAAABC7F8qyfEZLTzfLBtLixAq3ekKDNjSZiVuNP6ct6L98RNu/S8
SVoVARr6llwxB2uPsgnjGg/maciKZqL30RPVZrcXdh1TNMVC7r/SR4mi
fHgFRx2/Kq/zsC/zLuQmb8xCZ9YsTmJ/B2x721jgFHu+glo7NMUbwDzG
ETd+TFbacznO9NSM8dlU3M4FOQtryWMQxZ7wtbze51DToUsYmS+yiG5j
Xw==
) ; key id = 126
84
Tool Guide Series on DNSSEC | Version 1
; ***
List of Zone Signing Keys
; example.com.
tag=40517
***
algo=RSASHA1
example.com. 14400 IN DNSKEY
generated Nov 23 2009 00:45:14
256 3 5 (
BQEAAAAByojmMaY1M1bD9f/ql12VJ82XRncotUNbMBDkFHSUK9P6VDov
lOT9RLJjqQiRAnzCi585Kag8HW3GydFOV3o8AQ==
) ; key id = 40517
; example.com.
tag=65237
algo=RSASHA1
example.com. 14400 IN DNSKEY
generated Nov 29 2009 22:12:10
256 3 5 (
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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 child‘s 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
Tool Guide Series on DNSSEC | Version 1
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
#
#
Zonedir:
"."
Recursive:
False
PrintTime:
True
PrintAge:
False
LeftJustify:
False
#
88
dnssec-zkt options
zone specific values
ResignInterval: 1w
# (604800 seconds)
Sigvalidity:
10d
# (864000 seconds)
Max_TTL:
8h
# (28800 seconds)
Propagation:
5m
# (300 seconds)
KEY_TTL:
4h
# (14400 seconds)
Serialformat:
incremental
Tool Guide Series on DNSSEC | Version 1
#
signing key parameters
Key_algo:
RSASHA1 # (Algorithm ID 5)
KSK_lifetime:
1y
KSK_bits:
1300
KSK_randfile:
"/dev/urandom"
ZSK_lifetime:
12w
ZSK_bits:
512
ZSK_randfile:
"/dev/urandom"
SaltBits:
24
#
# (31536000 seconds)
# (7257600 seconds)
dnssec-signer options
LogFile:
""
LogLevel:
ERROR
SyslogFacility: NONE
SyslogLevel:
NOTICE
VerboseLog:
0
Keyfile:
"dnskey.db"
Zonefile:
"zone.db"
DLV_Domain:
""
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)
Create a (just empty) zone.db.signed file manually for bootstrapping purposes:
# touch zone.db.signed
ls -l zone.db*
-rwxr-xr-x 1 root root 494 Nov 24 22:51 zone.db
89
Tool Guide Series on DNSSEC | Version 1
dnskey.db
to include
-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
90
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. It‘s 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 it‘s 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:
Tool Guide Series on DNSSEC | Version 1
91
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.
Tool Guide Series on DNSSEC | Version 1
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
Description
Signature Expiration
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
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.
Secure Entry Point Key (KSK)
Deletion
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
92
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
Tool Guide Series on DNSSEC | Version 1
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.
Incompatible Third Party
Dependencies
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:
Server Misconfiguration
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
93
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.
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Description
+multiline
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.
+cd
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".
+dnssec
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.
+trace
Traces delegation chain. This option may be helpful if you trying to figure
out where the delegation points are.
+sigchase
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.
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
# 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:
/var/zkt/zones/acme.com./zone.db.signed:10
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:16
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
98
Tool Guide Series on DNSSEC | Version 1
acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:49
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:58
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
achilles.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:64
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for achilles.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
achilles.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:70
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for achilles.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
achilles.acme.com:
99
Location:
/var/zkt/zones/acme.com./zone.db.signed:76
Rule Name:
DNSSEC_RRSIG_SIGEXP
Tool Guide Series on DNSSEC | Version 1
Level:
1
Error:
RRSIG record for achilles.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
agamemnon.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:82
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for agamemnon.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
agamemnon.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:88
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for agamemnon.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
ajax.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:94
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for ajax.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
ajax.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:100
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for ajax.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
100
Tool Guide Series on DNSSEC | Version 1
ajax.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:106
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for ajax.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
dev-ng-core4.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:112
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for dev-ng-core4.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
dev-ng-core4.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:118
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for dev-ng-core4.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
dev-ng-core4.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:124
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for dev-ng-core4.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
diomedes.acme.com:
101
Location:
/var/zkt/zones/acme.com./zone.db.signed:130
Rule Name:
DNSSEC_RRSIG_SIGEXP
Tool Guide Series on DNSSEC | Version 1
Level:
1
Error:
RRSIG record for diomedes.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
diomedes.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:136
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for diomedes.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
diomedes.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:142
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for diomedes.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
localhost.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:148
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for localhost.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
localhost.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:154
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for localhost.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
102
Tool Guide Series on DNSSEC | Version 1
menelaeus.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:160
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for menelaeus.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
menelaeus.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:166
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for menelaeus.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
menelaeus.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:172
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for menelaeus.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
odysseus.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:178
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for odysseus.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
odysseus.acme.com:
103
Location:
/var/zkt/zones/acme.com./zone.db.signed:184
Rule Name:
DNSSEC_RRSIG_SIGEXP
Tool Guide Series on DNSSEC | Version 1
Level:
1
Error:
RRSIG record for odysseus.acme.com has expired
Details:
Checks signature expiration time and warns or signals an
error if the time is near or past.
odysseus.acme.com:
Location:
/var/zkt/zones/acme.com./zone.db.signed:190
Rule Name:
DNSSEC_RRSIG_SIGEXP
Level:
1
Error:
RRSIG record for odysseus.acme.com has expired
Details:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
RRSIG on name: menelaeus.acme.com type: NSEC failed to
verify: Signature has expired since: 20100108153643
Details:
104
RRSIGs must cryptographically verify the records they are
Tool Guide Series on DNSSEC | Version 1
signing.
odysseus.acme.com:
Rule Name:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
105
DNSSEC_RRSIGS_VERIFY
Tool Guide Series on DNSSEC | Version 1
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
RRSIG on name: acme.com type: DNSKEY failed to verify:
Signature has expired since: 20100108153643
Details:
106
RRSIGs must cryptographically verify the records they are
Tool Guide Series on DNSSEC | Version 1
signing.
acme.com:
Rule Name:
DNS_NO_DOMAIN_MX_RECORDS
Level:
8
Warning:
At least one MX record for acme.com is suggested
Details:
Checks to ensure that the zone contains at least 1 MX
record.
ajax.acme.com:
Rule Name:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
107
Rule Name:
DNSSEC_RRSIGS_VERIFY
Level:
1
Tool Guide Series on DNSSEC | Version 1
Error:
RRSIG on name: dev-ng-core4.acme.com type: A 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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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
Tool Guide Series on DNSSEC | Version 1
achilles.acme.com:
Rule Name:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
109
Rule Name:
DNSSEC_RRSIGS_VERIFY
Level:
1
Tool Guide Series on DNSSEC | Version 1
Error:
RRSIG on name: diomedes.acme.com type: MX failed to
verify: Signature has expired since: 20100108153643
Details:
RRSIGs must cryptographically verify the records they are
signing.
diomedes.acme.com:
Rule Name:
DNSSEC_RRSIGS_VERIFY
Level:
1
Error:
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:
38
rules tested:
30
records analyzed:
54
names analyzed:
9
errors found:
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
Tool Guide Series on DNSSEC | Version 1
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>
can be a domain name or an IP address (-x lookups)
<type>
defaults to A
<class> defaults to IN
arguments may be placed in random order
Options:
-D
enable DNSSEC (DO bit)
-T
trace from the root down to <name>
-S
chase signature(s) from <name> to a know key [*]
-V <number>
verbosity (0-5)
-Q
quiet mode (overrules -V)
-f file
read packet from file and send it
-i file
read packet from file and print it
-w file
write answer packet to file
-q file
write query packet to file
-h
show this help
-v
show version
Query options:
-4
stay on ip4
-6
stay on ip6
-a
fallback to EDNS0 and TCP if the answer is truncated
-b <bufsize>
use <bufsize> as the buffer size (defaults to 512 b)
-c <file>
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
Tool Guide Series on DNSSEC | Version 1
-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>
use <port> as remote port number
-s
show the DS RR for each key in a packet
-u
send the query with udp (the default)
-x
do a reverse lookup when doing a secure trace:
-r <file>
use file as root servers hint file
-t
send the query with tcp (connected)
-d <domain>
use domain as the start point for the trace
-y <name:key[:algo]>
specify named base64 tsig key, and optional an
algorithm (defaults to hmac-md5.sig-alg.reg.int)
-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
Tool Guide Series on DNSSEC | Version 1
;; 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.
3600
IN
NS
ns.somewhere.com.
example.com.
3600
IN
NS
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
Tool Guide Series on DNSSEC | Version 1
;; 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: 0
;; flags: rd cd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; example.com. IN
DS
;; 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
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:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
114
Tool Guide Series on DNSSEC | Version 1
;; 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.
3600
IN
A
10.0.0.1
sigs:
example.com.
3600
IN
RRSIG
A 5 2 3600 20100107213414 20091228213414 2300
example.com.
v8a2okdkq97EucRdZTC/sA1zMKw6XcDs8Om3qQwJNcOulD2twZtorh/tH8Ds8WvPoHZ5H+5r1NYve8W2pomQFA==
;{id = 2300}
---
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
|---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
Tool Guide Series on DNSSEC | Version 1
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
Print this message.
-m,--multiline
log DNS records using
'multiline' format
-s,--strict
Zone will only be considered
valid if all signatures could be
cryptographically verified
-v,--verbose <level>
verbosity level -- 0 is
silence, 5 is debug information, 6 is trace
information. default is level 5.
# 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
BQEAAAAB3H65j1CEi58P5X8EyP6y2emTv1lsogUVAtTkBvRVWOGAeswXdBJudfbY
118
Tool Guide Series on DNSSEC | Version 1
256 3 5 (
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
# 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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
; <<>> 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
Tool Guide Series on DNSSEC | Version 1
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
126
ldns-1.6.1.tar.gz (http://www.nlnetlabs.nl/downloads/ldns)
Tool Guide Series on DNSSEC | Version 1
#
#
#
#
#
#
#
#
#
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
#
#
#
#
#
127
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)
Tool Guide Series on DNSSEC | Version 1
#
#
#
#
#
#
#
autoconf-2.64.tar.gz (http://www.gnu.org/software/autoconf/#downloading)
#
#
#
#
#
#
#
#
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 ..
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
conf.rng
kasp2html.xsl
kasp.rng
signconf.rng
zonelist.rng
zonefetch.rnc
zonefetch.rng
/var/opendnssec/
kasp.db
(need to create)
slot0.db
(need to create)
/etc/opendnssec/
conf.xml
(need to edit)
conf.xml.sample
kasp.xml
(need to edit)
kasp.xml.sample
zonelist.xml
(need to edit)
zonelist.xml.sample
zonefetch.xml
zonefetch.xml.sample
/var/opendnssec/unsigned
example-zone.com
(need to create/edit)
test-zone.nl
(need to create/edit)
/var/opendnssec/signed
example-zone.com
(generated during signing)
test-zone.nl
(generated during signing)
/var/opendnssec/signconf
130
example-zone.com.xml
(can create or auto generated when signing)
test-zone.nl.xml
(can create or auto generated when signing)
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
# 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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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)
NAME
ldns-key2ds - transform a DNSKEY RR to a DS RR
SYNOPSIS
134
Tool Guide Series on DNSSEC | Version 1
ldns-key2ds(1)
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
135
Tool Guide Series on DNSSEC | Version 1
ldns-key2ds(1)
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
Token
parameters_policies
KEYDATA_VIEW
categories
policies
Objects
dnsseckeys
securitymodules
PARAMETER_LIST
keypairs
serialmodes
PARAMETER_VIEW
parameters
zones
sqlite> .databases <enter>
seq
name
file
---
---------------
----------------------------------------------------------
0
main
/var/opendnssec/slot0.db
1
temp
/var/tmp/sqlite_TjURasmkfMBG560
sqlite> .help <enter>
136
.databases
List names and files of attached databases
.dump ?TABLE? ...
Dump the database in an SQL text format
.echo ON|OFF
Turn command echo on or off
.exit
Exit this program
.explain ON|OFF
Turn output mode suitable for EXPLAIN on or off.
.header(s) ON|OFF
Turn display of headers on or off
.help
Show this message
.import FILE TABLE
Import data from FILE into TABLE
.indices TABLE
Show names of all indices on TABLE
.mode MODE ?TABLE?
Set output mode where MODE is one of:
csv
Comma-separated values
column
Left-aligned columns.
html
HTML <table> code
insert
SQL insert statements for TABLE
line
One value per line
list
Values delimited by .separator string
tabs
Tab-separated values
tcl
TCL list elements
Tool Guide Series on DNSSEC | Version 1
(See .width)
.nullvalue STRING
Print STRING in place of NULL values
.output FILENAME
Send output to FILENAME
.output stdout
Send output to the screen
.prompt MAIN CONTINUE
Replace the standard prompts
.quit
Exit this program
.read FILENAME
Execute SQL in FILENAME
.schema ?TABLE?
Show the CREATE statements
.separator STRING
Change separator used by output mode and .import
.show
Show the current values for various settings
.tables ?PATTERN?
List names of tables matching a LIKE pattern
.timeout MS
Try opening locked tables for MS milliseconds
.width NUM NUM ...
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
dev-ng-core4.example-zone.com. dnsuser.example-
example-zone.com.
dev-ng-core4.example-zone.com.
3600
IN
NS
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
Appendix G. Known Issues
OpenDNSSEC
Issue
Workaround
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.
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
As of V1.0.0b2, LDNS is having
problem with SRV records. The main
effect is that these records are given
non-valid RRSIGs.
This has been fixed in the ldns trunk and will
eventually be released with a new version
Versions of OpenDNSSEC prior to the
Beta releases do not provide any
mechanisms for publishing of DS data
to a parent zone.
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
Tool Guide Series on DNSSEC | Version 1
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 = "SH––A1";
// 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
Tool Guide Series on DNSSEC | Version 1
md.digest(out.toByteArray());
String digest = base16.toString(md.digest(out.toByteArray()));
System.out.println("Digest: " + digest);
}
146
Tool Guide Series on DNSSEC | Version 1
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
; serial
10800
; refresh (3 hours)
3600
; retry (1 hour)
604800
; expire (1 week)
86400
; minimum (1 day)
)
86400
RRSIG
SOA 5 2 86400 20091231163048 (
20091201163048 62460 acme.com.
eJ16eU0niaDyMCKnEbIkd0DhOViG4iwHFy+d
FFJzZ5pomqn0HlaDT2hVl8iZxR7EiOhxSPq3
hg/G70CxZSQUlwNEhaZrgZiAUpqJJyT8GmVw
l45dvrGD5R/b9e0mzs5Su1RigwQ2+WoC1Twa
CEbUPAqo3IXqTn7hipAbniBgHvk= )
86400
NS
dev-ng-core4.acme.com.
86400
RRSIG
NS 5 2 86400 20091231163048 (
20091201163048 62460 acme.com.
ptqh+zrJHWlWoI6aIS5p51xG62fFcJX9Sdbs
mCl4ixBMFnagf97ANm7L7qoi0s2fNcZJHCig
9PNuBGGPwNPTrM1kHjrOOHczbbVH2Nu1PIUg
/xvsrs2KKydBgiTD93LwyxliBLVwXlpldC6w
kVvFbzfqrRPSTyyg19189Of6KVY= )
86400
NSEC
achilles.acme.com. NS SOA RRSIG NSEC DNSKEY
86400
RRSIG
NSEC 5 2 86400 20091231163048 (
20091201163048 62460 acme.com.
Q0D4u5jG3H1nGKhe9FbWZJr7LX+gGF75Boim
LEGgzpetMeA/h26hN1PqOLyeEu71ij/4mddl
147
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
GQdMPACLD/Awp9X15ArnV1tvSh11sBqWbnbM
v7rSA07Lx0Oaq+X/8TvU7qy7Z5nub2SyzN2F
rF+0Cz4uhJJMcnNPPFuvFBf+NNW0C9QsHXVL
DjJIf5VS8yARoJFUy4RK/dG2DtVSTqhutyD8
XhrgjMZNMQ10C8OewVUeaA3zs5Q= )
achilles.acme.com. 86400
86400
IN A
192.168.5.20
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
WJYbsEgjPXH8+qe/inQFZhvC8RNDyaAlcPwC
hOt/Q0Zuk5XwOcwNlGGigawGTjsUn6pDP4WB
i/9p3hyCRvRGr4GDYIOTU7iFoWOqta3TfcYc
3qHboAS7FoEqbkKfq7Viw8V/CfBtEdZGlTw0
hTP3gtmM7Nj25esrNX8KRrzgrvY= )
86400
MX
10 achilles.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
nKjW8mg3U7GlE8HUuqzQfE8S38ZZwpmokBi1
pU7es6fGWCibaoNG0JOwiN+m+6687qDp9xTg
meUqSF5VTjZlxt9DooNPPATzlqt4SNfagN2z
djCWuVi+oO5zyTHT9dDTBc+WODQK2yiUZQPu
vBlf+2rtIDpm3k+p5IONNXrQE5Y= )
86400
NSEC
agamemnon.acme.com. A MX RRSIG NSEC
86400
RRSIG
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
IN A
192.168.5.21
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
AzfWzZ0hbqlxLqi9gfaPzE3k0Qhok33g6MCs
389m1GlvbK5VVrU1A4qbi/wGe0959EPs8WDj
q80XS87pqgSbcbf26fYUWHORhA2JiWkQ//2V
HNOjkWPCyCbvM6QJt4lYj02jhRweeIw7+q5N
149
Tool Guide Series on DNSSEC | Version 1
qpyrF5Hvb48yaABQYcAOvK8RdS4= )
86400
MX
10 agamemnon.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
iLYlZa6WLbEyh/15kdOyoRA2oRbUwuYPMs0p
iKD9utY1LqjBBI+1gGIvryQ+R4HbmqxNGjgQ
e7wJZG7Z6E8a0wHq4gl8JROqct9mpilAtB9e
VG348V5+mgj5OpopZK1FoV8GW6QCKTymry7K
QVGGyTaulChd8RyT0uuIor/sZhs= )
86400
NSEC
ajax.acme.com. A MX RRSIG NSEC
86400
RRSIG
NSEC 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
MjuplZgSzOkZm/v/HcwWGiccE94IyN4QzNM5
M+VliHei4xYU+V2jT2606vQQWD9e8Ai7y3rV
RqO9RaZivbae3pfIEoRauqKD0MSxzcsc61BP
2NEgaVQ36IIzINBp6ALqYTg1uyLf3wYu6hGD
BWv9YfQ0OZoJ/xm4LTPmMmQDeME= )
ajax.acme.com.
86400
IN A
192.168.5.24
86400
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
NanBXIbQEBMMqPpMKW5zLZJx0oxsMROjc7kb
NVSa92KhEfpFiRvEMUtysxvkHS6JLib8VokH
//+Hz+nZCn/P1z1o/9wm3rPESPgPvQu+2yaA
H+LfPpSEdkESuunlOCxwV/aYgD+hSYKVUR5e
XLgCQlQP2B4U6A8lwYOjmMPy0XM= )
86400
MX
10 ajax.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
o3r4qi5ovJxbS9Pkoi6KnCc6IWNgCDQy9WDd
Hb/T4nW13EyHA2fLRDOtZ9gpL6/LzV/d7jqv
cpHzxtNhn8Jxn1rA7LxFs6lgD9qiy10cSKeg
53gwCwVKk7iic2byVe4cPrVcQznjtRPeZhDX
0DnUzwRdJkRjG1pUiP4n/PK0EmI= )
86400
NSEC
dev-ng-core4.acme.com. A MX RRSIG NSEC
86400
RRSIG
NSEC 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
150
Tool Guide Series on DNSSEC | Version 1
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
MX
10 dev-ng-core4.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
NeM+kVhX8ibREHfAs1qVTbThq8I18B6A9OtC
l36UfU0rvHQGlcK26T87GP3o+ITvrBOARDbc
eiK6gGTJ5CC8txVVZ3tMJdRwEtZCE7LcRE77
okhsozvNlmB+Aw+hdfpuiC76w7etkLukJ1iy
/8uo3ede8dqNNd6wuG5P8C4jm6g= )
86400
NSEC
diomedes.acme.com. A MX RRSIG NSEC
86400
RRSIG
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
192.168.5.22
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
XgoAcLaNO5lqJAFlDphU5ShPaE9QDGfuRQDq
+PGLaZyRHFBVmCRYX3AZCdPsfTbYffv1Q5yT
YR8OFi08nU0tLDgnC265YltZkYrnxFQvObA4
qKOQqZQqprjCJJl2v4sDPlRgLUdRfCbosR45
151
Tool Guide Series on DNSSEC | Version 1
MblCthQpgguZKsvXLG5Ns+gopPI= )
86400
MX
10 diomedes.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
e71MWahlv4ivllHN/X94STCKws2wxDEZUmGg
GxGtLsDR9JbEQ5a3JUiTXnXiP4nhK2GxfXo6
VnMFLRLtV+i3Z24OeKW72z+iYHFX7IByAfX2
ouGfc+uqwBdtoyVqOh9J8aF91zaqd4mm0OhN
mc8QArsrMpIO6bgZMv1Rv69I+iQ= )
86400
NSEC
localhost.acme.com. A MX RRSIG NSEC
86400
RRSIG
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
IN A
127.0.0.1
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
I6uc9chOPlchmlAkvMqAbVcIS4YOLEuSTk8b
VHZCTzSMdkTD3u6zS+4IArp0eNoSBurC0i64
jJLvq6DOWTI6D5XLsODylCULYtMaEKe0n9nh
tfwqNY3k3PNIl/YFIEu6DbOvJ1+xQkDpDABb
7anN1bX9NZ73X7sY0kW3vQBotTw= )
86400
NSEC
menelaeus.acme.com. A RRSIG NSEC
86400
RRSIG
NSEC 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
jGwZ3teiqYfWovZu7qUXxyz18K2aYTc1Oyxn
vpnmvTuL//SqB1nYEYm6bXAv1//xaaCfvWdj
ORJyGbWjoXYXKkoA6I67V7o63QmAr8ylqP73
3ClvD20KrH6Z3njUMqyKgySlBl+p4KE2unJt
EgZexBi/lff8lb3xEdJEd4wgLUM= )
menelaeus.acme.com.
86400
86400
IN A
192.168.5.28
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
152
Tool Guide Series on DNSSEC | Version 1
OR2di2fJzlr6W5GYmR4/LrxHSenxqvb2FTO2
+aO5kT6z6TYSw0H9/cBqFW2qKCSONeqyKFgF
Xt6+irTUSa2ON2nIiqRgj9ZysbpuIjTrjt6U
TAXFMpKFgY6Xj0nJky3LKsNcGv1zw2wGWpvf
60Abj4gYmDIX5YC66qL3/uPeb/s= )
86400
MX
10 menelaeus.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
VqQMiIvGj/y1uCd+lwLY8JiCiPCMqiCd+VAg
tFy+Fus5ab003fLr6FVwMEehuC4VTXEvRLSi
lXN/97AwPobkVcOPkQbL76n4OWWBgJ2IXuEw
X0kNXwvM0RFxE8zhKVL0bNnZYaA3q8MlstR1
uVeEQ/7FJ8aVxfOJZCqcETq67sY= )
86400
NSEC
odysseus.acme.com. A MX RRSIG NSEC
86400
RRSIG
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
192.168.5.23
RRSIG
A 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
GByIyiojC0JC/wG9fkIAv5s5z1+5tB0k/U7K
SNEjsupijyaKf4mpVCjq6neFKbrFPbnVUbyd
Nbdx3zi40C4XqWQynqLw30wBBf+gIdu5kNqK
WLW1ZuKiQYPVIsjzQ2bqpHfdZZqGCxUfP6nK
R7R+hIOv7jDbKuy5Dklq+VIJj/8= )
86400
MX
10 odysseus.acme.com.
86400
RRSIG
MX 5 3 86400 20091231163048 (
20091201163048 62460 acme.com.
r2siPZWAnaZhVlfpDtSs81lHCyCQE18sRG/g
BFEyJgYHyfaw/k4E+Qo8Awgsa2P+6OCg6pr2
N7uVRXBA6cuVV2OXkHq0doMPRolxQHXASZP7
A0TF+FAZJjTMK2u2YuWyRoUpEmKmSMYQFTve
153
Tool Guide Series on DNSSEC | Version 1
a2EcrbLwvJAsG5STlxMcYBqc31o= )
86400
NSEC
acme.com. A MX RRSIG NSEC
86400
RRSIG
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.
154
acme.com.
IN DS 19560 7 1 BC8E13A846594F10679E75EFC16F799284538041
acme.com.
0BD9AFE7
IN DS 19560 7 2 9C71B5274E3F256C6E62A41DA5A90E9FEA5944DB4E9EBBD51FB17A1B
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
-
Unsigned zone file
db-in.example.com..signed
-
Signed zone file
Kexample.com.+005+47670
-
KSK files prefix
Kexample.com.+005+48926
-
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
Tool Guide Series on DNSSEC | Version 1
Appendix L. BIND’s 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
Description
server servername [ port ]
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
Sends the current message. This is
equivalent to entering a blank line.
send
For more details on nsupdate, refer to http://linux.about.com/library/cmd/blcmdl8_nsupdate.htm.
159
Tool Guide Series on DNSSEC | Version 1
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
Description
Author(s)
URL
NSD
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.
NLNet Labs
http://www.nlnetlabs.nl/nsd
Autotrust (beta)
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.
Matthijs
Mekking,
NLnet Labs
http://www.nlnetlabs.nl/projects/aut
otrust/
UNBOUND
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
NLNet
Labs,
Verisign,
Nominet,
Kirei
http://unbound.net/
160
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
URL
Olivier
Courtay
(ENST
Bretagne)
ftp://ftp.irisa.fr/local/idsa/code/digsigchase/
DNS-OARC
https://www.dnsoarc.net/oarc/services/replysizetest
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.
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.
DNS Reply Size Test
161
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
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
URL
block responses larger than
512 bytes. This test helps
users identify resolvers that
cannot receive large DNS
replies.
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.
Bob Halley
(Nominum)
http://www.dnspython.org/
DNSRuby
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.
Nominet UK
http://dnsruby.rubyforge.org/
DNSSEC Key
Management Tools
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.
Olaf
Kolkman
(RIPE NCC)
http://www.ripe.net/projects/disi/dn
ssec_maint_tool/
DNSSEC Smartcard
Utility
This is a DNSSEC smartcard utility
written for NIC-SE. Any PKCS#15
smartcard supported by OpenSC can
Jakob
Schlyter,
Haakan
http://opensource.iis.se/trac/dnssec/
browser
162
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
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).
Olsson
DNSSEC Tools
(NIST.gov)
Several DNSSEC Tools from the
National Institute of Standards and
Technology (NIST).
Nist.gov
https://wwwx.antd.nist.gov:8090/dnssec/downlo
ad/
DNSSEC Walker
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.
Simon
Josefsson
http://josefsson.org/walker/
DNSSHIM
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).
Registro.br
http://registro.br/dnsshim/indexEN.html
Drill
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.
Miek
Gieben,
Jelte Jansen
(NLnet
Labs)
http://www.nlnetlabs.nl/dnssec/drill
.html
163
Tool Guide Series on DNSSEC | Version 1
URL
Tool
Description
Author(s)
URL
Drill Extension for
Firefox
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.
Miek
Gieben,
Jelte Jansen
(NLnet
Labs)
http://www.nlnetlabs.nl/dnssec/drill
_extension.html
IPSECKEY patch
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.
David Fort
(IRISA)
ftp://ftp.irisa.fr/local/idsa/code/patc
h-bind/bind+ipseckey.patch
libresolv
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.
David Fort
(IRISA)
http://idsa.irisa.fr/index.php?page=l
ibsresolv&lang=en
Java DNSSEC 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. These tools
David
Blacka
(Verisign)
http://www.verisignlabs.com/dnsse
c-tools/
164
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
URL
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.
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.
Giuseppe
Ateniese et
al
http://skdnssec.isi.jhu.edu/downloa
d.html
ldns
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.
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.
Olivier
Courtay
(ENST
Bretagne)
ftp://ftp.irisa.fr/local/idsa/code/dnss
ectoolkit/
DLV Test
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
DNS-OARC
https://www.dnsoarc.net/oarc/services/dlvtest
165
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
URL
Nominum,
Inc.
http://www.nominum.com
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/
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.
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.
CNS
Recursive name server
nom_keytool, ans_signer
Standard tools provided with the ANS
distribution
pdnssec-keygen, pdnssecsignzone
Tools from the DNSSEC perltools
distribution
maintkeydb, dnssigner
Tools from the DNSSEC
Management Tools suite
Maintkeydb
Command line interface to a database
containing DNSSEC Keys
166
Tool Guide Series on DNSSEC | Version 1
Key
Olaf
Tool
Description
Author(s)
URL
Key2ds, Net::DNS::Sec
DNSKEY to DS conversion
Kolkman
http://www.net-dns.org/
libepp-nicbr
library that partially implements the
Extensible Provisioning Protocol
(EPP), as described in the Internet
Drafts RFC3730bis to RFC3734bis
and RFC3735
Registro.br
http://registro.br/epp/indexEN.html
ISC DLV registry
Trust Anchor Repository constructed
through
explicit
zone
owner
registration
ISC
https://secure.isc.org/index.pl?/ops/
dlv/
Secspider
Trust Anchor Repository populated by
a crawler program
UCLA,
Colorado
State
http://secspider.cs.ucla.edu/
IKS Jena Survey
Trust Anchor Repository populated by
a crawler program
IKS Jena
http://www.iksjena.de/leistungen/dnssec.php
IANA TAR
(Currently) demo Trust Anchor
Repository for SEP keys for TLDs
IANA
https://ns.iana.org/dnssec/status.ht
ml
KROd - the keyrollover
daemon
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
Infrastructur
e DNS
Securise et
applications
(IDSA)
http://www.idsa.prd.fr/index.php?p
age=kro&lang=en
Infoblox
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 –
Infoblox
http://www.infoblox.com/solutions/
dnssec.cfm
167
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
URL
Secure64
http://www.secure64.com/automate
d-DNSSEC-signer-softwareappliance
Xelerance
http://www.xelerance.com/applianc
es/signer/DNSXSecureSigner.pdf
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.
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, Secure64‘s 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
Xelerance
168
Xelerance‘s 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
Tool Guide Series on DNSSEC | Version 1
Tool
Description
Author(s)
URL
Bluecat
Networks
http://www.bluecatnetworks.com/c
omponent/jdownloads/?task=finish
&cid=42&catid=5
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
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 BlueCat‘s 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. BlueCat‘s
Adonis appliances are able to properly
validate signed records from other
DNSSEC enabled servers.
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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 DNSKEY−RR
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 DS−Record (or DNSKEY−RR) to the parent
d. Wait until the DS is propagated + TTL of the old DS−RR
e. Remove the old key
171
Tool Guide Series on DNSSEC | Version 1
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
−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]
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.
172
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
−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, don’t 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
Tool Guide Series on DNSSEC | Version 1
−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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Don’t 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, that’s
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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.
That’s 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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
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
Tool Guide Series on DNSSEC | Version 1
Visit us at www.VeriSign.com for more information.
