DNSSEC uses PKI and a train of trust to ensure that recursive name servers are getting the correct/unmodified records when doing a query for a domain name.
It will be help full for you to know a bit about PKI and hashing. At the very least you should know that PKI uses two certificates. If you encrypt data using one certificate then the only way to decrypt the data is to use the other certificate. This means you encrypt data with your private certificate, once encrypted you hand your public certificate to anyone who you want to be able to unencrypt your data. It uses large prime numbers and lots of complex maths that I won’t go into.
The next is hashing, if you pass data through a hash algorithm then it comes out looking like random data however if you put the same data through it you will always get the same result. It is used heavily to protect your password in applications and websites that need you to login.
DNSSEC is not an encrypted protocol, the keys are used to sign the records and build a chain of trust not to encrypt the communication. The packets are all unencrypted.
DNSSEC uses a chain of trust and that chain has to start somewhere. In DNSSEC that is the root “.” name servers. DNSEC enabled recursive name servers hold a copy of the root public key, from there the root servers form a trust with the tld (top level domain) servers and so forth. In our case the domain 1metric.com the recursive servers trust the root, the root trusts the .com zone and the .com zone trusts the 1metric zone.
DNSSEC requires a few additional record types:
- DNSKEY Resource Record – A DNSKEY stores a public key used to sign a record or zone. There are two types of DNSKEY:
- Zone Signing Key (ZSK) – A Zone key is used to sign the individual records within a zone
- Key Signing Key (KSK) – A Key Signing Key is used to create the trust. It is used to sign the Zone Signing Key and create the chain of trust with the level above it
- RRSIG (resource record digital signature) – A RRSIG record contains the signed record. As an example when you do a query for an A record on a signed zone not only do you get the result for the A record returned but also an RRSIG record that contains a copy of signature used to verify the A record
- DS (Delegation of Signing) Record – Is stored in the parent zone and is used to verify the results returned when querying the child zone. i.e. for 1metric.com the DS record exists in the .com zone much like a glue record.
- NSEC/NSEC3 – NSEC records are used when no record exists. It is designed to prevent a man in the middle replacing what would be a signed response with a NXDOMAIN response stating there is no record. For example if you requested 1metric.com and a valid signed response was sent a person intercepting that could change it to be an NXDOMAIN response saying there is no record and prevent me from accessing the resource. NSEC does create a couple of security concerns though and NSEC3 is the replacement to fix the issues.
For most people all the above is just a bunch of mumbo jumbo so I will use a real life example to explain how it all works.
Lets imagine a person does a query for the A record 1metric.com. This zone is DNSSEC signed and the recursive name server support DNSSEC, the order of operations that happen may vary from DNS resolver to DNS resolver but the process is all the same.
- The recursive name server does a query for the domain at one of the root name servers. To get a DNSSEC enabled response it set the DO (DNSSEC OK) flag in the request. The root name server doesn’t know about the A record 1metric.com but it does know about the name servers for .com so it returns a list of DNS servers responsible for the .com zone. As the request has the DO flag set it also returns a DS Record that we can use to verify the response from the .com name servers. As well as the DS record it contains an RRSIG record that we can use to validate the DS record with based on us already trusting the root.
[root@fs1 ~]# dig +dnssec @h.root-servers.net. 1metric.com ;; AUTHORITY SECTION: com. 172800 IN NS l.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20130523000000 20130515230000 20580 . HnVLHHq0a5nbpqX1VcuZryvvkhIbqcJoWzuYj19rivyZCkTyamK8ZsrL SYRWbOxnyQMBqQppGKvvQnQEspayREkNd5TqU0168ZXvdCDOp+DUP7ff D9fNUvuVYrpBR3IjFAT5dFQ0QNcYWhHeTo7dZ2OrdKKeoPmX4d649MLE bXs=
- The recursive server then asks the same query to the .com name servers. They don’t know about the A record 1metric.com but they do know about the name servers for 1metric.com are ns1/ns2.1metric.com and the IP address of them. Like the root servers as the 1metric.com zone has been signed it returns the DS records for the 1metric.com. zone and the RRSIG used to validate the result with the root name servers.
[root@fs1 ~]# dig +dnssec @l.gtld-servers.net. 1metric.com ;; AUTHORITY SECTION: 1metric.com. 172800 IN NS ns1.1metric.com. 1metric.com. 172800 IN NS ns2.1metric.com. 1metric.com. 86400 IN DS 2836 5 2 5B9FF3598D53112D52FE1D4F33BBD73DC262946DED2D1BA2C5120085 B45BF2E5 1metric.com. 86400 IN DS 2836 5 1 5A6B31BEEFE106EEBBA4337F9451A3D3AEF199C5 1metric.com. 86400 IN RRSIG DS 8 2 86400 20130523042846 20130516031846 35519 com. QnwWSfJ6udxyNVavg9IAf4GzKzBvb31CQ/OwTLkt0nVJdcUmfkccmfWi uLp5CyjpoV52vIEf9ygZ073wcrl1tv0/YzRH1zDUJxQ5+MoCkqlmxWXc fiajK9UyK0axMjvsfB7wXnHJhSIYN23KE1VcrobhDAEfvxD6L428A76L Bsg= ;; ADDITIONAL SECTION: ns1.1metric.com. 172800 IN A 126.96.36.199 ns2.1metric.com. 172800 IN A 188.8.131.52
- Next we query one of the name servers for 1metric.com. As ns1.1metric.com is an authoritative name server for the 1metric.com zone it does know the A record for 1metric.com. But not only does it return the A record holding the answer it also returns a RRSIG record. It tells us that the result is 184.108.40.206 but now we need to verify that that is actually correct.
[root@fs1 ~]# dig +dnssec @ns1.1metric.com. 1metric.com ;; ANSWER SECTION: 1metric.com. 86400 IN A 220.127.116.11 1metric.com. 86400 IN RRSIG A 5 2 86400 20130620011431 20130516011431 45888 1metric.com. Zf6MqTwivaVl2KYnBOZU0VHKA8u3UyeODv26TpTT9VfGMSNYJe2xw1sY GkpN/Z0CBnP14bj0+RvmnAm9H6r08adiHwRCrkm9dZZnbQCrkExvTIDk sCxX5YXPF8oTyP4veHEHO8zRVx7RleaWmbaXJU/1td1GzhNcbrfIg53I zsM=
- The RRSIG (as below) has a few fields. The fields in order are:
- The record Type
- The algorith used. In this case RSA/SHA1
- The number of labels. A complex subject in its own right. Due to the nature of DNSSEC it requires that all records be signed, however a wildcard introduces an infinite number of possible records to sign. The way around this is that the number of labels are used to work where the wildcard record is. For instance the wildcard test.1metric.com would have the number of labels set at 2 so that it knows that the wildcard is *.1metric.com. If you do a query for say test.1metric.com and test2.1metric.com both would return the same RRSIG record and the server would use the number of labels field to determine that the wildcard is *.1metric.com
- The TTL (Time to Live) of the record
- The expiry date for this record. Once this expiry date is meet this record is no longer valid.
- The inception date for the record. This record isn’t valid until this date.
- The Key Tag. As records come close to expiry the zone needs to be resigned and therefore a new key and RRSIG record created. The Key Tag is used to match up the RRSIG with the DNSKEY used to sign it so multiple keys and RSSIG records can coexist.
- The signers name. This is the name of the zone that has signed this record. For instance if we had an A record www.1metric.com this field would still be 1metric.com as it is in the 1metric.com zone.
- The rest of the text is the base 64 encoded signature
A 5 2 86400 20130620011431 ( 20130516011431 45888 1metric.com. Zf6MqTwivaVl2KYnBOZU0VHKA8u3UyeODv26TpTT9VfG MSNYJe2xw1sYGkpN/Z0CBnP14bj0+RvmnAm9H6r08adi HwRCrkm9dZZnbQCrkExvTIDksCxX5YXPF8oTyP4veHEH O8zRVx7RleaWmbaXJU/1td1GzhNcbrfIg53IzsM= )
- To validate the RRSIG record returned with the A record we need a copy of the public Zone Signing Key. This is stored in a DNSKEY record. If you do a query you will get at least 2 DNSKEY records returned 1 is the public key for the Zone Signing Key which we need the other is the public key for the Key Signing Key which we will worry about later. The record will also return an RRSIG record for this key. To distinguish the key a key type field is used. A key type of 256 is used for a Zone Signing Key and a key type of 257 is used for a zone signing key.
[root@fs1 ~]# dig +dnssec +multi @ns1.1metric.com. 1metric.com DNSKEY ;; ANSWER SECTION: 1metric.com. 86400 IN DNSKEY 256 3 5 ( AwEAAd0/EhkY1K0ZTPd8YW17td/+ZE4L1yYOdS4tF1Fr 7gJJgfCnisrtV0EeIGi5/IeUSVzL5EyvhzWxvrtmnWtu balAM9/cTJWBmU+7GG5p7rMWSdk/iXFr4CsOIeRO+m4e t0GXXlC82sZAa++vDXUytt69vTXwgo/5wXqjSdRr/Dfj ) ; key id = 45888 1metric.com. 86400 IN RRSIG DNSKEY 5 2 86400 20130620011431 ( 20130516011431 45888 1metric.com. gLknZHKRp3zbPNgcxLnzCDH96ndl+q4/dy5wbhdorwx0 vWniW82xZaerFsFc+AXg372djF0JZxK+MOrni9tQ9zrH 7ql4QhMFnadIpXDVQ7R2kZeK/8SkwPnb+yZ+meEbifYP UkYShtseLO8AZaNZRcncxrV6Doffh3Q/J9M0nX8= )
If we just take a look at the DNSKEY for the moment we get the following fields:
- Time to Live
- Record Type, in this case DNSKEY
- The key type, 256 for Zone Signing Key and 257 for Key Signing Key
- The fixed protocol value, not really used any more all keys will be set to 3
- The public key algorithm in this case 5 means RSA/SHA1
- The remaining text is the base 64 encoded public key.
Inside the public key is the Key Tag, in this case dig has added a comment at the bottom with the key tag. The value 45888 corresponds with the key tag of the RRSIG record returned above. If you are going through a key change stage you may have multiple ZSKs, the resolver will get the appropriate ZSK for the RRSIG record.
86400 IN DNSKEY 256 3 5 ( AwEAAd0/EhkY1K0ZTPd8YW17td/+ZE4L1yYOdS4tF1Fr 7gJJgfCnisrtV0EeIGi5/IeUSVzL5EyvhzWxvrtmnWtu balAM9/cTJWBmU+7GG5p7rMWSdk/iXFr4CsOIeRO+m4e t0GXXlC82sZAa++vDXUytt69vTXwgo/5wXqjSdRr/Dfj ) ; key id = 45888
- Now we have the public ZSK and the RRSIG to go with it the A record we can verify that the value for the A record (18.104.22.168) is correct. At a very high level the way this works is that when the zone is signed the A record is taken and hashed (in this case through SHA1) it is then encrypted by the private certificate. This encrypted hash is what is stored in the base 64 part of the RRSIG record. The recursive server takes the RRSIG record uses the public key in the DNSKEY record to get what the server thinks the hashed value should be. The recursive server then hashes the A record for itself using the same method as when the zone was signed by the server. If both hashes match then we know the A record hasn’t been tampered with.
- The problem with this is that an attacher could sign a zone with their own public key so now we need to verify that this zone is trusted by the one above it and to do that we use the Key Signing Key (KSK)
- The KSK works basically exactly the same as the ZSK the only difference is that the ZSK signs the individual records to create the RSSIG records while the KSK is used to sign the DNSKEY records. When you look at the RSSIG records for the DNSKEY these weren’t signed by the ZSK but by the KSK.
- But that doesn’t really help either does it because an attacher can create their own KSK just like they can create their own ZSK. This is where the DS record comes in. A hash of the public KSK key is created. This hash is then stored in a DS record in the parent zone. In this case the .com nameservers hold the DS key. To keep the zone files small from tld and 2ld’s only a hash is stored. This is enough to verify that the KSK key supplied is correct
- If we grab the KSK key
[root@fs1 ~]# dig +dnssec +multi 1metric.com DNSKEY 1metric.com. 52077 IN DNSKEY 257 3 5 ( AwEAAbVDRyHTk+te0mnwRP/eoA7pQfuA4T8f39pdSe5u MblqJryEJLnYJtBxoz5oUirh1NfhaWxQWel/ybuY/NAy 5hOhDLl3BvFZqmhKdS7sekHFi+vuaDweve1UiEe/v1bZ Lc+k+t30ssJINQrzHXoy0k2+9hfMPktG8hDTUsWHdiuh OH3Y4D6J8Flh5fRy07hkwzhhs73AgGN3mRCGB83reumB d1zw1jZX8jbzN0N9oJuKcsWqdvJd3XcUbW/dVGvchnLT ax7l4Uujv2mAkzI9PFT5XZuY6/cd6FuzQnXf7IldujK4 6fwwUNk4PFcl9fX11hHgUDIVoVPNzKdSQW1dxPkf4t3v F2HZ6Fy/e7qPx711BZFRHxSr1g2sSi/BniqYH8hf364U yNOqusv3RObmoAj3zmq9EygRwHNVHP484CpmHtN/MMrP vbXe3N3J9DV0JcPvl+dq1dzsgMdD9mtxCSYwopc9i3HG Z34ZiOFUhK/c2BJNfOwEJx1oVKgtNQSVZd5HGG4ISfmB Sw2FrKCMP4upNGgcMIq3tn6RynnOccst6T5RuvMovTOl mpT7BgZBhN17sv6xdfcvj+TjK8VSSUjl7tUOtghNH0XM 1o3kgL1EpTOwhowC/IazSV82TcDe0rS7AMH0fJedx/5d nv6vYBTi9PR+AprFrECE8efC9ekh ) ; key id = 2836
The key type is 257 so this is the KSK, it also has a key tag of 2836. Now grab a copy of the DS keys for this domain from the .com name servers
[root@fs1 ~]# dig +dnssec +multi @e.gtld-servers.net. 1metric.com DS ;; ANSWER SECTION: 1metric.com. 86400 IN DS 2836 5 2 ( 5B9FF3598D53112D52FE1D4F33BBD73DC262946DED2D 1BA2C5120085B45BF2E5 ) 1metric.com. 86400 IN DS 2836 5 1 ( 5A6B31BEEFE106EEBBA4337F9451A3D3AEF199C5 ) 1metric.com. 86400 IN RRSIG DS 8 2 86400 20130523042846 ( 20130516031846 35519 com. QnwWSfJ6udxyNVavg9IAf4GzKzBvb31CQ/OwTLkt0nVJ dcUmfkccmfWiuLp5CyjpoV52vIEf9ygZ073wcrl1tv0/ YzRH1zDUJxQ5+MoCkqlmxWXcfiajK9UyK0axMjvsfB7w XnHJhSIYN23KE1VcrobhDAEfvxD6L428A76LBsg= )
As you can see it has a couple of DS records using difference hashing methods but both with a key tag of 2836. By hashing the KSK public key the recursive name server can compare the hash in the DS record and if they match we know that zone is trusted by the parent.
- Now the ZSK has been verified by the KSK and the KSK has been verified by the DS in the .com zone we follow the chain of trust. As you can see the DS record also has an RSSIG record. This record is signed by the ZSK of the .com zone. This is how the chain of trust is followed. Now the recursive name servers must follow the same steps as above to verify the .com zone and keep following the chain until every level is verified.