DNSSEC – Part 2

Last week we took a quick overview of what DNSSEC is and what it does and does not do. As promised, this week we'll take a quick look at how DNSSEC works.

As I stated last week, DNSSEC is intended to secure the DNS query-response process. It ensures you are getting the correct answer (or verified non-existence) from the authenticated DNS server that is truly authoritative for the record requested. There is a caveat here, the querying server must be DNSSEC-enabled in addition to the answering server in order for this process to work properly. The DNSSEC authenticated reply from an authoritative server is known as a signed response.

DNSSEC is able to do so by establishing a chain-of-trust between a DNS server and it's parent servers. For example if the .gov servers hold DNSSEC records for fbi.gov, then there is a chain-of-trust established between the .gov and fbi.gov authoritative DNS servers.  When a zone is DNSSEC signed without a chain of trust, that zone is known as an island of trust since it is operating on its own as far as DNSSEC goes.

DNSSEC performs these authentication and chain-of trust actions by using two different types of asymmetric keys (asymmetric keys are those having two components; a public key and a private key) a Zone Signing Key (ZSK) and a Key Signing Key (KSK).  The ZSK is what is used to sign a zone--specifically the private component of the ZSK.  The KSK performs two functions:  the public key is sent to the parent zone DNS server to establish the chain-of-trust, the private key is used to sign DNSKEY key sets that DNSSEC generates when signing zones.

If you'd like a deeper look just google "DNSSEC", or as always check out the NIST Secure DNS Deployment Guide I have referenced in past posts.

Well, that is probably enough to keep your head spinning until next week when we'll go still deeper into the ZSK, KSK and other DNSSEC operations...