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.

1. 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. 
   

   ---

   Add this page to your favorite Social Bookmarking websites

   

   Read more... Add new comment

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:

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 
• dnssec-keygen -C - Compatibility Mode for suppressing metadata in the DNSSEC keys 
• dnssec-keygen -P, -A, -R, -I, -D date/[+-]offset - These options are used to set DNSSEC key lifecycle metadata
• dnssec-signzone -S - this option is used for performing "Smart Signing"

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.

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

Bind 9.7.0 can be freely downloaded from https://www.isc.org 

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
 

When the SQL is executed, the output will look like this:

This article contains eight (8) of my most frequently used Log::Log4perl recipes. The Log::Log4perl is a Perl logging API port of the Log4J Java logging API. It's very comprehensive and is used in a large number of the scripts, tools, and applications that have been developed by Netlinx, Inc. In this article, we provide recipes for the following:

1. Initializing Log4perl with a config file vs in-line
2. Output messages to file and screen using appenders
3. Log events and messages to a database
4. Logging messages to Syslog
5. Have different applications log to the same file
6. Outputting stacktrace in logging messages
7. Implementing rotating log files
8. Applying log filtering

In this fifth article on Anycast DNS, we provide some examples of deploying Anycast using Border Gateway Protocol or BGP, the core routing protocol of the Internet. While BGP is mostly used by Internet Service Providers (ISPs), it is also used in some of the larger enterprise environments that must interconnect networks that span geographical and/or administrative regions and boundaries. Since BGP is a very complex routing protocol, we will provide only a basic recipe using Cisco and Quagga host-based routing software. A detailed discussion of the BGP protocol is beyond the scope of this article.

BGP is an Exterior Gateway Protocol (EGP), which means that it exchanges routing information between Autonomous Systems (AS). BGP is quite different from other IGPs, such as RIP and OSPF. BGP uses a different routing algorithm that uses a path vector algorithm, causing it to keep a list of every AS that the path passes through.

Our recipe will demonstrate how to configure Quagga to peer with a Cisco router using BGP. Suppose our Anycast design consists of an Autonomous System 65500 and AS 64555 as shown below. AS 64555 will contain our Anycast DNS servers and we'll establish peering between the two as shown below:

In this continuation of the fourth article, we improve the design with enhanced security, performance, and efficiency. Our configuration consists of two OSPF areas 51 and 52, containing an Anycast DNS server, and pair of Cisco Routers connected to the backbone area 0.0.0.0. The Anycast DNS servers are configured with Quagga, running the OSPF routing protocol engine, this is used to advertise our two (2) Anycast DNS VIPs, 192.168.0.1/32 and 192.168.1.1/32 into the OSPF routed network. The diagram below focuses on our "fictitious" area 51:

As mentioned, we'll provide additional "recipes" for improving our Anycast DNS design to achieve faster convergence and failover, added security, and better efficiency.

The fourth article in our Anycast DNS series covers Anycast DNS using Open Shortest Path First or OSPF routing protocol. OSPF is a dynamic routing protocol used to build larger scale IP networks. It differs from RIP, because it is a link-state routing protocol and falls into the group of Interior Gateway Protocols that operate within a single Autonomous System or AS.

OSPF is a link-state routing protocol that runs Dijkstra's algorithm to calculate the shortest path to other networks. Taking the bandwidth of the network links into account, it uses cost as its metric. OSPF works by developing adjacencies with its neighbors, periodically sending hello packets to neighbors, flooding changes to neighbors when a link's status changes, updating its neighbors of all recent link state changes every 30 minutes. The use of this algorithm makes OSPF much faster at network convergence, which is why it makes a better selection for building Anycast DNS solutions for enterprise environments.

Our OSPF network will consist of a two different OSPF areas 0.0.0.51 and 0.0.0.52 that are connected to a thrid area, backbone area 0.0.0.0. This is shown in the figure below:

Each router, will have one interface directly connected to backbone area 0.0.0.0. Their other interface(s) will connect into their own respective OSPF routing areas. We do not dive into the details of OSPF networking because it is beyond the scope of this article. Our goal is to provide a working recipe for using OSPF, Cisco routers, and Quagga Open Source host-based routing software.

This article is a continuation of our third article in our series on Anycast DNS. In this next recipe, two Anycast VIPs will be advertised on two (2) DNS servers that are multi-homed on different subnets by different routers using RIP v2. In this recipe, we'll review the commands that will be needed to add the additional interfaces to our Quagga configuration, as well as, briefly discuss how to handle multiple default gateways on multi-homed hosts. The figure below depicts our configuration for this recipe:

This third article in our series on Anycast DNS, focuses on deploying Anycast DNS using RIP v2 routing protocol. In this article we'll be using Quagga, Open Source host-based routing software, to originate our Anycast IP address. Our upstream routers are Cisco routers, so we'll also be providing all routing configurations that are needed for the recipes. The goal of the recipe is to be efficient, secure, and simple.

In this recipe we configure a single Anycast VIP on two name servers, using host-based routing software to originate the routes Anycast VIPs to their upstream routers via the RIP v2 routing protocol. The following figure shows our configuration for this exercise:

Two Linux-based DNS servers running Quagga's ripd routing protocol, are configured with an Anycast VIP of 192.168.0.1/32. But first, a quick refresher on RIP v2 is in order.