Blog entries for "dnssec"

Other Uses for Secure DNS

In the October 2011 issue of the Usenix Associations ";login:" newsletter, I published an article entitled "Other Uses for Secure DNS", with special attention to the IETF DANE working group and the proposed protocol for replacing the X.509 certificate authority system with a secure and scalable system based on Secure DNS.

A reprint of article is attached below.

DNSSEC Key Management Best Practices (Part 3 of 3)

Don't wait until it is too late! Secure your DNS NOW!

Internet Systems Consortium (ISC) - the industry's core drivers of DNSSEC deployment will help you step by step to secure your DNS infrastructure. Please join us for the third of a series DNSSEC talks.

Date and Time: We will present this webinar twice to maximize time zone coverage.

ISC BIND 9.9.0a1 -- feature preview

Yesterday afternoon, ISC published the first alpha release of BIND 9.9.0. This is an early technology preview, showing off some of the work we've been doing in BIND 9.

There will be more new features added in later alpha releases, but here's what's ready to debut now...

DNS forwarders

Recently, at a BIND 10 Face to face meeting, we scheduled a short slot of time to discuss the features of a DNS forwarder. As part of the development process of the BIND 10 recursive resolver, we initially implemented a basic forwarder. As we added actual recursive resolver features, the original 'forwarding' mode was left in, and got some of the features that were added for the 'resolving' mode, mostly on an ad-hoc basis.

DNSSEC and "lazy delegation"

Prior to deploying DNSSEC it has been possible to perform something I'm calling "lazy delegation." This is when a parent and direct child are served from the same name servers, so NS records in the parent are unnecessary in practice.

While consulting with various clients about how to best deploy their DNSSEC, this is a common discovery. Often times someone just forgot to add NS records, or their tools do not add them. No one notices because their DNS worked.

Preparing for a world consisting of larger DNS responses.

While many of you know ISC as the maintainer of the BIND DNS server software, we have always had our hand in the DNS operations field, including operating one of the 13 DNS root servers (F.ROOT-SERVERS.NET), as well as secondaring many ccTLD and non-commercial zones for over a decade. ISC has also been at the forefront of designing and implementing DNS Security Extensions (DNSSEC) which is a mechanism to cryptographically verify that the response given to a DNS request is correct.

Using the root DNSSEC key in BIND 9 resolvers

To use the signed root zone in DNSSEC validation in your BIND 9 resolvers, you must be running BIND 9.6.2 or higher. Earlier versions do not support the required algorithms to enable validation using the root zone's key. It is strongly recommended you run BIND 9.7 to use the automatic key updating functionality.

What's happening with DLV?

Now that the root zone has been officially signed, what happens with ISC's DNSSEC Look-aside Validation Registry? The short answer is, it gets smaller, but does not go away, at least not today.

While having the root signed is a critically important step in the DNSSEC deployment effort, it is not the final step. It's the one that enables a lot of other zones such as Top Level Domains (TLDs) to be signed usefully. It removes the need for many stop-gap measures like certain TARs, and the need for TLD entries in ISC's DLV system.

BIND 9.7.2 and automatic DNSSEC signing

BIND 9.7.0 and 9.7.1

BIND 9.7.0 introduced automatic in-server signature re-freshing and automatic key rollover.  This allows BIND 9.7, if provided with the DNSSEC private key files, to sign records as they are added to the zone, or as the signatures need to be refreshed.  This refresh happens periodically to spread out the load on the server and to even out zone transfer load.

Imminent Death of Internet Predicted. Film at 11.

The press seems to love stories of doom and gloom. And for almost as long as the Internet has been around, there have been dire predictions of some resource exhaustion, success disaster or security flaw that will destroy the internet. And who is the villain in this week's piece? DNSSEC and the signing of all the root servers.

While I love a good story as much as the next person, it seems time to actually throw a few facts on the fire.