DNSSEC Root Key Rollover Redux

The Internet Corporation for Assigned Names and Numbers (ICANN) just published their review of the recent domain name system (DNS) root zone key rollover. The rollover occurred on October 11, 2018. Please read my prior post for background on DNSSEC and role of the root zone key.

ICANN's summary report concludes that the rollover was indeed an "overwhelming success" given the very small number of disruptions detected during the rollover process. The report provides a logical and thorough timeline of the planning leading up to and encompassing the rollover. The report also highlighted several observations of the rollover process, summarized following:

  • The vast diversity of resolver software implementations and configurations on the global Internet renders impossible the ability to predict general resolver behavior leading up to and during a rollover. And the lack of measurement capability prevents assured readiness assessment for major DNS changes. So ICANN and the DNS technical community at large was pleasantly surprised with the relatively tiny level of DNS disruptions due to the rollover and subsequent revocation of the prior key in January, 2019. 
  • Given the design principle recommending longer keys (2048 bits in this case) for key signing keys, there was concern that the DNSKEY resource record set would exceed packet transmission sizing and necessitate DNS packet fragmentation. This concern was largely unfounded.
  • Signalling trust anchor knowledge tactics specified in RFC 8145 proved minimally useful.
  • Some resolver operators are not well versed on DNSSEC configuration specifics, so operator surveys proved unreliable.
  • Resolver vendors on the other hand proved knowledgeable and responsive in addressing detected issues.
  • The lengthy rollover process between announcement of the rollover and its execution reduced the sense of urgency on the process and ICANN communiques related to the process.
  • While ICANN utilized various forms of outreach to inform the Internet community of the forthcoming rollover, the lack of feedback on each mode makes it difficult to measure effectiveness of each approach.
  • The ICANN testbed was not helpful in helping users understand and test the impact of the rollover.
The bottom line is that DNSSEC key singing key rollover was incredibly successful, for which all in the ICANN and the Internet community, the DNS community in particular deserve hearty congratulations. Observations from this inaugural rollover will serve to improve the process for the next rollover. Please read the full report for full details.



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