Ingredients coming together for global DNSSEC deployment - are you ready?

It's been a year since .com was signed, which was a major step forward towards Internet community support for DNSSEC implementation given that nearly 45% of all Internet domains fall within the .com branch. I was curious how other top level domains (TLDs) were doing in this regard so I checked out the ICANN Research site for TLD signing statistics. As shown in the following summary table, 22.5% of TLDs were signed a year ago, while 29.1% are signed as of today. This 31% jump in signed TLDs represents good progress, but there's still a way to go to get to DNSSEC ubiquity in chains of trust to the root zone.
March 2011March 2012
TLDs in the root zone306313
TLDs signed6991
% TLDs signed22.5%29.1%

Another boost to DNSSEC deployment was announced last week in the form of a pending FCC recommendation that promotes the deployment of DNSSEC planned by several major ISPs. These ISPs will be implementing DNSSEC validation on their recursive servers, which their customers query for DNS resolution. That is, as their customers issue DNS queries to these ISP recursive servers, the servers will resolve the query and attempt to validate the query signatures up the chain of trust to the root (or other configured trusted key).

This ISP deployment of DNSSEC should protect broadband users from website hijacking and other DNS cache poisoning style attacks. That is if the websites these users are attempting to access are signed. With growing TLD adoption of DNSSEC and an expected jump in recursive servers validating queries via DNSSEC thanks to this ISP initiative, the way forward is clear if your TLD is signed. All you have to do is sign your Internet zones and provide your parent zone registrar with your corresponding Delegation Signer (DS) records to link you into the DNSSEC chain of trust.

I believe the hesitancy with DNSSEC implementation is more deeply rooted in the complexity of DNSSEC configuration and the burden of ongoing management requirements for key rollovers and refreshing signatures than in the lack of widescale DNSSEC deployment. In many cases, this lack of deployment has served as a legitimate barrier to implementation, but this will soon cease to be the case.

As for DNSSEC complexity, BT Diamond IP offers a simple solution to signing your DNS information and ongoing maintenance: the Sapphire Sx20 appliance can be configured with your signing and rollover policies so you can set it and forget it. It will automatically roll keys, update signatures, even auto-update DS records accordingly for your subzones. The barriers to deploying DNSSEC are dwindling. Will you protect the integrity of your web resources?

Comments

Post a Comment

Popular posts from this blog

Handy AAAA filter in BIND 9.8

The ISC introduced a pair of new configuration file options in BIND 9.8 to enable administrators to easily filter who may receive AAAA record type responses even if valid responses exist. For example, clients on subnets that do not have IPv6 network access can be excluded from receiving affirmative answers for AAAA queries. This feature provides simpler administration than the alternative mechanism using views. The first option, filter-aaaa-on-v4,defines whether the server will return AAAA records to certain clients. Such clients are defined by the address match list parameter of the second option, filter-aaaa. Note that BIND must be compiled with the --enable-filter-aaaa option on the configure command line to enable AAAA filtering. The syntax of these options is as follows: filter-aaaa-on-v4 (yes | no | break-dnssec) ; filter-aaaa {addr_match_list;} ; The filter-aaaa option identifies the address match list for which the filter-aaaa-on-v4 option is to be applied as described ...
Read more

Inglorious DDI

We all know how critical DHCP/DNS/IPAM (DDI) services are. Your network cannot function without them. But like most foundational elements of anything, they are certainly not glamorous...like good luck finding a home designer who specializes in home foundations. I would not be shocked should HGTV pass on my brilliant concept for a foundation building show. I suppose most people would find a show detailing footing depths and concrete pouring techniques rather boring.  Nevertheless, there are countless shows for redesigning and remodeling homes. On most episodes the foundation is out of sight, out of mind. If it's stable, no one wants to pay it attention, they just expect it to keep doing its job, supporting the structure. Once in a while a foundational issue is brought up that unexpectedly threatens to raise the budget to heighten the drama. All work stops until the issue is addressed. And you'll notice that the owner never denies paying the extra amount to fix the issue. ...
Read more

BIND 9.8.0 Adds DNS64 Support - Part 2 - How is it configured?

BIND 9.8.0 introduced a new dns64 option statement that can be configured within the server named.conf options block or within a view options block. Recall from a prior post that DNS64 configures a recursive DNS server to issue A record queries on behalf of a client requesting AAAA records, then appends the returned IPv4 address to a defined IPv6 prefix. This manufactured IPv6 address enables the querying host to connect to a NAT64 gateway which will terminate the IPv6 connection from the client and map it to an outbound IPv4 connection to the appended IPv4 address, completing the connection! Whew! BIND offers a number of useful parameters within the dns64 statement to control this process. The statement syntax is: dns64 IPv6_prefix { [clients {address_match_list };] [mapped {address_match_list };] [exclude {address_match_list };] [suffix IPv6_addr;] [recursive-only (yes|no);] [break-dnssec (yes|no);] }; The IPv6_prefix parameter is the prefix to which returned...
Read more