How many DNSSEC validators are you missing?

On the heels of my most recent post asking, "How many IPv6 eyeballs are you missing?," I now pose the analogous question for DNSSEC. Do your DNS servers receive queries requesting authenticated resource record data for your namespace? If so, and you have not signed your zones, then DNSSEC validators' requests for authentication will go unfulfilled. And their DNS caches they are attempting to protect from poisoning will go unprotected, not to mention the integrity of your DNS namespace. An attacker "impersonating" your namespace could redirect browsers to the attackers' website for example by providing DNS resolvers with falsified query answers using cache poisoning attacks such as those publicized by Dan Kaminsky.

On the other hand, if hardly any resolvers (i.e., caching servers) initiating queries on the Internet even perform DNSSEC validation, signing your zones will offer value only to a small number of deployed validators and no value to non-validating resolvers that ignore DNSSEC signatures. Is it worth the effort of implementing and maintaining signed zones?

In an attempt to quantify the number of DNNSEC validators issuing queries on the Internet over time, the Internet Society is asking for help on behalf of Verisign Labs. They are asking webmasters to add one line of code in their HTML files which causes each web browser visiting your site to initiate a DNS query to Verisign Labs' DNS servers authoritative for validatorsearch.verisgnlabs.com. The Verisign Labs DNS servers then attempt to determine if the querying server is configured for DNSSEC validation. In this manner, Verisign Labs hopes to gather a measure of the relative quanitity of DNSSEC validating resolvers making Internet queries.

This data should help DNS administrators decide when DNSSEC zone signing makes sense for them. The preliminary results indicate that 3.66% of resolvers are DNSSEC-validating resolvers. Your participation in this analysis through the addition of one line of HTML can help Verisign Labs and the Internet Society to enlarge the sample size and provide robust measurements over time. These measurements will encourage DNS administrators to implement DNSSEC to secure their namespaces with the assurance that a given percentage of resolvers are utilizing and counting on their published DNSSEC signature data.

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