Unbound is a validating, recursive, and caching DNS resolver. Unbound is developed and currently maintained by NLnet Labs, a non-profit, public benefit foundation. It is based on the ideas and algorithms taken from a Java prototype developed by Verisign Labs, Nominet, Kirei, and ep.net. Unbound was released to the public in May 2008 under the BSD Licensing model which allows its use in other products without any major restrictions. In this article, we’ll discuss ten (10) reasons to use Unbound as a validating, recursive, and caching DNS service part of your Core Network Services (CNS) Infrastructure.

Lightweight – Unbound was originally developed in C based from a Java prototype. Its authors wrote the source code to be very modular in design, and to be very lightweight. They wanted to design a solution that would be the smallest possible that would achieve the minimal requirements as a validator, resolver, and caching server. In addition to meeting these requirements, they wanted the server to achieve very high-performance. Unbound’s minimalistic design will be a recurring theme throughout the rest of this article.

The last article discussed the basics of the BIND 9.7.0 "Smart Sign" feature. In this article, we expose additional functionality that has been incorporated into the software to make it much simpler to sign, operate, and maintain DNSSEC signed zones. This article will help tie in some of the information provided in the previous article, Bind 9.7.0 - Part 2, New DNSSEC key metadata. Bind 9.7.0 takes an interesting approach to automating DNSSEC key lifecycle maintenance, leveraging local Dynamic DNS enabled zones in conjunction with the embedded timing metadata in DNSSEC keys. Other DNSSEC frameworks use a dedicated service or script to perform DNSSEC key rollovers.

In this article we'll focus on the following directives to achieve automated "Smart Signing" operations:

Directive

Grammar Context

Description

auto-dnssec

zone statement

Configuring zones with this directive enables varying levels of automatic DNSSEC key management. There are currently four (4) possible settings:

allow - permits keys to be updated and the zone to be re-signed whenever the user issues the rndc sign zonename command.

maintain - includes the functionality above, but will also automatically adjust the zone's DNSSEC keys according to DNSSEC key timing metadata that is supplied.

create - includes the above, but signals named to create new DNSSEC keys when needed. (NOTE: this option is not yet implemented; the syntax has been reserved for future use.)

off - which disables automatic DNSSEC functionality

Usage:

[ auto-dnssec off | allow | maintain | create; ]

dnssec-secure-to-insecure

zone statement

This directive provides the ability to "convert" a DNSSEC signed (secure) zone to an unsigned (insecure) zone. This directive takes a boolean yes | no value.

Usage:

[ dnssec-secure-to-insecure yes | no; ]

update-policy

zone statement

Sets the policy for enabling or disabling DDNS updates. When set to local, updates to the zone will be permitted for a special key "local-ddns" which gets generated by named automatically at startup.

Usage:

[ update-policy local | { update_policy_rule [...] }; ]

key-directory

zone statement

This directive sets the path to the zone's DNSSEC keys. Bind 9.7.0 auto-dnssec relies on this directive to "find" the associated keys for a given zone.

In our previous article, we covered how BIND 9.7.0 embeds timing metadata directly in DNSSEC keys as its method for DNSSEC key lifecycle management. In this article, we discuss the new BIND 9.7.0 Smart Signing feature and how it improves and simplifies the process of signing a single zone.

With all the DNSSEC related changes in BIND 9.7.0, it should come as no surprise that many of the BIND-provided utilities have been updated, and a few new ones have been added to the distribution. First two (2) new utilities have been added:

dnssec-settime - used to either get OR set DNSSEC key metadata timers of KSKs

dnssec-revoke - used to set the REVOKED bit on a DNSSEC key

Major changes to existing tools include:

rndc sign - this option is new to Bind 9.7.0 to support "Smart Signing" and one-touch signing of a zone.

dnssec-keygen -K - this option will inform dnssec-keygen where to write out DNSSEC keys

To date, implementing DNSSEC using ISC Bind was manually intensive and complicated at best. Following the general availability of Bind 9.7.0 on 02-16-2010, the task is not nearly as daunting. In this article we review at a high level, some of the new changes, features, and enhancements that have been incorporated in Bind 9.7.0 in support of DNSSEC. This several part series will cover:

New DNSSEC key metadata and lifecycle maintenance

Automatic zone signing by "named"

Simplified configuration of DNSSEC Lookaside validation (DLV)

Configuring Dynamic DNS using the ddns-confgen or the "local" update-policy option.

New CLI dnssec-settime and changes to dnssec-keygen, and dnssec-signzone.

Smart signing: overview of the tools for zone signing and key maintenance.

Improved PKCS#11 support for using Hardware Security Modules or HSM for storage and signing operations

One of the most glaring new features to Bind 9.7.0 is in the area of DNSSEC key lifecycle management, which includes the generation, publication, revocation, and eventual deletion of DNSSEC keys as it pertains to signing zones and performing DNSSEC key rollover. Presently, there are a number of different DNSSEC tools frameworks such as DNSSEC-TOOLS and OpenDNSSEC which have their own suite of scripts, services, and CLIs for handling DNSSEC Key generation, zone signing, and key rollover operations. Now, some of these operations are available in BIND 9.7.0.

A different approach has been taken by the BIND development team to implement DNSSEC key lifecycle management through the storage of metadata directly in DNSSEC keys, represented by all those K* files that get generated with the dnssec-keygen utility.

The Sybase Case statement is handy for performing conditional SQL Expressions. Recently, I needed to summarize the number of static host objects in the VitalQIP database using Sybase. I needed to summarize them by counting how many statically defined objects by:

'A' or Address only records

'PTR' or Reverse PTR only records

'A' and 'PTR' records

The easiest way to do that was to use the Sybase Case Statement. The syntax for the Case Statement is as follows:

case
when search_condition then expression
[when search_condition then expression]...
[else expression]
end
case and values syntax:
case expression
when expression then expression
[when expression then expression]...
[else expression]
end

The Case Statement used to get my data looked like this:

SELECT COUNT(obj_id),
CASE
WHEN ns_update_flags = 1 THEN 'A'
WHEN ns_update_flags = 2 THEN 'PTR'
ELSE 'BOTH'
END
FROM obj_prof
WHERE ns_usage = 1
GROUP BY ns_update_flags