What Is DNSSEC?
Posted by Shaker B. on 08 January 2015 11:04 AM
To understand DNSSEC (DNS Security Extensions), it's important to understand why it was created in the first place.
DNS was never designed for security. It was created back when there was no reason to even consider that anyone would try and spoof DNS information. For reasons of speed and distribution, the system was designed so that local resolvers would accept the first response they received to a request for information on a given host. Now that phishing has become such a huge reality on the internet, this has been tightened up significantly through various methods, but it still remains possible for responses to be spoofed (faked) and end-users tricked into treating fake sites as real.
DNSSEC was designed as a means of verifying a) whether a response was actually what was sent out by the replying server (eliminating the possibility of man in the middle attacks) and b) whether the server sending it is really who they claim to be.
How Does It Work?
DNSSEC depends not only on the zone being signed, but on the local resolver (usually that of your ISP) being enabled for DNSSEC enabled (or 'security aware'). If a resolver is not security aware, then DNSSEC is not relevant.
When a zone is DNSSEC signed, the creator of the zone generates what are called key-pairs. These form the basis of what is usually called Public Key encryption, or assymetrical encryption. In PK, the private key is used to encrypt a message, and it can only be decrypted by the public key. This is performed in such a way that the private key cannot be derived from the public key. The public key is listed in the zone file under the DNSKEY record. The private key is stored securely on the authoritative nameserver. The fact that the zone has been signed is registered at the root for that zone.
Every time the zone is updated, each resource record (A, MX, Cname, etc...) is digitally signed with a new type of resource record created for DNSSEC called an RRSIG (resource record signature).
The RRSIG is created by making a digest (or hash) of the resource record, and then encrypting the result. This is sent along with the response to any DNS query. When the resolving server receives the response and RRSIG, it sends back to the nameserver for the public key to decrypt the signature. As it does, it makes a hash of the resource record it requested, and when it receives the public key, decrypts the signature, and the two digests. If they match, it knows the signature is valid.
But how does it know that whoever spoofed through the response (with the A record and RRSIG) didn't also spoof through the public key to their OWN keypair?
This is where we move from digital signatures to the chain of trust.
When a zone is signed, this information is 'published' along with the digest for the zone key, in what are called DS records. The fact that the zone is signed is published as part of the basic whois information for the domain at the root servers.
When a security aware DNS resolver queries the root servers for a domain's authoritative nameservers, it now also receives the information of whether or not a domain is signed. If it is, then it will only accept digitally signed responses for it, and refuse any others. It will also receive a digest copy of the key for the next servers down the line.
Now, as the resolver works its way down the chain, it will receive the information for the next set of authorized servers with a digital signature, as well as the key to validate the next piece of information it get.
The start of this system is called a Trust Anchor. Trust anchors function as a secure entry point into the chain-of-trust DNSSEC depends on. The signatures for the root server are included in the actual configuration of the resolver when it is set up, and since these cannot be changed automatically, they are therefor considered secure. As DNSSEC is a new protocol, and implementation at some root servers may not occur for some time, there is a special process called Domain Lookaside Validation (DLV), which will be discussed below.
In the example where we are looking up foo.example.org, for instance, the resolving server would first query the root servers for the location of the .org servers. The root server sends back a signed response for the location of the .org servers with the accompanying digest for the key used by the .org zone,
The .org servers are then queried for the authoritative nameservers for example.org, which sends back (for example) a signed response designating dns1.easydns.com as authoritative, along with the key for the zone example.org.
Finally, dns1.easydns.com is queried, and it sends back the signed response for foo.example.org, which is validated and checked against the key received before.
In each case, verification of the signature requires receiving the signed key from the responding server, and being able to check that key against the key received from the server above. In this manner, the signature proves the data is correct, and that the information is being received by a trusted sender.
Domain Lookaside Validation
For various reasons, it is important to be able to determine Trust Anchors which allow a zone to be signed without following the chain up to the root for that domain type. This allows zone managers to create what are called 'islands of trust'. This can be because the top level servers for that domain type are not yet signed (at the moment, for example, only a few TLDs are signed), or because the managers are creating an internal chain of trust for their systems.
For this reason, DLV was created, to allow a zone to specially designate that they qualify another chain of trust as trusted to secure their zone. A special record is created in the signed zone, stating that the security aware server should confirm the signature against another system entirely. This external system will be established in an existing chain of trust, and serve as the secure entry point.
Setting up DLV requires that the signed zone be registered with the DLV server, and that the special records be inserted into the zone itself. This has not yet been implemented at easyDNS as of April 4th, 2011, but is expected shortly.
There are two types of keys : the zone signing key and the key signing key. Both of these are stored as 'DNSKEY' records in the zone file. The DNSKEY records always appear at the end of the RRSET for the zone owner (the apex of the zone).
The zone signing key (ZSK) is used to sign and validate the individual record sets within the zone.
The DS key is the matching part to the zone signing key, which is stored at the level above, which confirms that the zone below it IS signed, as well as providing the digest to verify that the key is correct.
The key signing key is (KSK) is used to sign the DNSKEY records in the zone.
The RRSIG (resource record signature) record contains information such as the type of resource record it is signing, the host (owner) for which it is configured, the type of algorithm used in its encryption, and the encrypted resource record it is signing. RRSIGs follow directly after the resource record they are signing. RRSIGs do not get digitally signed themselves (that way lies infinite recursion!!).
Eg an A record for easydnstestdomain.com followed by its RRSIG:
10800 A 22.214.171.124 10800 RRSIG A 5 2 10800 20110723145149 ( 20110405135149 26157 easydnstestdomain.com. Y/Eom6R1M0VW7yDHaGbrRt9mf6K4QyEEq+Qd 81bkvn1WiDxnmpbsIgGd9DRvYyDMmfFTC6PO 0+KFBU8rsZYw7TqLGhJhGwYWwJ3VIy7fNh6U 9TQ7KOUETCxTiQVrymNWDrWvfbpOf+8ks0ui GQ4gdADBfWkn0oD47mQp1B0YbGM= )
The NSEC record appears at the end of each RR set. It lists what types of records have been specified and signed for its owner (the specific host the RR set references), and lists the owner (host) for the next RR set.
Here, for example, is the NSEC that would appear for the owner easydnstestdomain.com
10800 NSEC www.easydnstestdomain.com. A NS SOA MX RRSIG NSEC DNSKEY
This tells us that the next owner will be the host www.easydnstestdomain.com, and that the current owner – easydnstestdomain.com – should return values for those kinds of records ONLY, and anything else is verifiably false.