Upcoming Milestones in Bringing DNSSEC to .com

Starting today, ICANN-accredited registrars may submit Delegation Signer (DS) records to Verisign, the .com administrator. Most organizations obtain and register their domain names with domain registrars, who may also be their ISP. Contact your registrar to determine if they are participating in this process. Verisign will include submitted DS records in a"deliberately unvalidatable" .com zone that will be published on Monday, February 28. This deliberately unvalidatable zone will contain dummy keys for testing purposes.

As recently announced , the .com zone will be signed in production on March 31, 2011. The submitted DS records will be included in the signed .com zone and the .com DS record will be published in the root zone, fully linking the chain of trust for .com zones!

This linked chain of trust vastly simplifies the management of trusted keys on validating resolvers (typically within recursive or caching DNS servers which are queried by clients or "stub resolvers"). Prior to this linkage, a validating resolver requires a copy of each .com's trusted subzone's public key (key signing key, KSK). So if a DNS administrator desired to implement DNSSEC validation to protect the cache of his/her DNS servers, a trusted key for each subzone needed to be configured on each caching server. If you think about all the .com subzones your users browse or email to, that's a lot of trusted keys! Fortunately, with a fully linked chain of trust, only the root zone's public key (KSK) need be configured for successful validation of .com subzones.

The KSK of a signed zone basically signs the zone's key records, consisting of the KSK and the zone signing key(s) (ZSKs). The ZSK signs the zone, meaning that it is used to produce a signature for each resource record set within the zone. The DS record is analogous to the NS record. The NS record provides referrals to the next subzone in the domain tree for name resolution. The DS record provides a "trust referral" to a signed subzone by incorporating a hash of the subzone's KSK. If a validating resolver does not "trust" the subzone's KSK, it can check if the parent zone links trust to this KSK via a corresponding DS record; if so the validating resolver can determine if it trusts the parent zone's KSK, and so on up the domain tree to the root!

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