>> Using DNSSEC, Domain Name System Security extensions, which were designed many years
after DNS, is the way to mitigate DNS cache poisoning attacks,
by providing integrity to the DNS responses.
If a client asks the RIT DNS server for the IP address of www.arin.net ,
the RIT DNS server will ask one of the 13 logical route name servers,
and then an authoritative dot net TLD DNS server, and then finally,
the authoritative DNS server for the arin.net domain.
If a client's DNS server supports DNSSEC, it sets the DO, DNSSEC OK flag in its DNS requests
to a route name server, an authoritative TLD DNS server,
and the authoritative DNS server of the domain in question.
In turn, each of the servers will send back extra DNS resource records,
that we'll see in a little bit.
These extra records tell the RIT DNS server that the child zones are DNSSEC enabled.
In our story, the RIT DNS server's query on the client's behalf,
will reach the arin.net authoritative DNS server.
When that server gives the answer to the RIT DNS server, it sends the answer along with a hash
of each group of resource records in the answer,
signed with arin.net's private ZSK, Zone Signing Key.
For instance, a response could have multiple A records, MX records, and NS records.
Each of these groups has a signed hash sent in a new DNS resource record type, rrsig.
Why sign resource record groups rather than individual records?
Quite simply, it's quicker.
Furthermore, there's no way to query for just one A, or MX record.
A DNS server will always return them as a group.
So, there's no point in signing each one individually
when you can sign them all together.
The arin.net DNS server also gives the RIT DNS server arin.net's public ZSK, Zone Signing Key,
in the form of another new DNS resource record type, DNSKEY.
arin.net's public KSK, is also sent in the form of a second DNSKEY record.
These DNSKEY records are hashed and encrypted with arin.net's private KSK,
producing another rrsig record, this one for the DNSKEY records.
So, the RIT DNS server will request the sets of resource records,
which also returns each group's corresponding rrsig record,
request the DNSKEY records containing the public Zone Signing Key,
and the public Key Signing Key, which also returns the rrsig
for the DNSKEY resource record set.
Verify the rrsig of the requested resource record set with the public Zone Signing Key.
Verify the rrsig of the DNSKEY resource record set with the public Key Signing Key.
DNSSEC Part 2
>> There is a zone signing key and a key signing key.
Because it's difficult to swap out an old or compromised key signing key.
Changing the zone signing key is a lot easier.
We can use a smaller zone signing key without compromising the security of the server,
minimizing the amount of data that the server has to send with each response.
Furthermore, the DNS key resource record set
and corresponding RRSIG records can be cached for future use.
The key signing key works basically like the zone signing key.
The only difference is the zone signing key signs the individual records
to create the RRSIG records for each group, while the key signing key is used
to sign the DNS key records, producing an RRSIG record for the DNS key group.
For the rest of this story, we'll just reference a single public key,
and not worry about zone signing key or key signing key for simplistic purposes.
Now, it's time for the RIT DNS server to verify the A records
for www.arin.net [assumed spelling].
The RIT DNS server takes the RRSIG for the A record group,
which is a cache of all the A records, encrypted with a private key of arin.net.
To decrypt this, the RIT DNS server, uses the public key of arin.net,
which is in the DNS key record that was sent.
If the decrypted hash matches the computed hash by the RIT DNS server,
the DNS key record validates the RRSIG record.
And, the RRSIG record validates the A records.
All is good.
But, wait a minute, wait if someone broke
into the arin.net DNS server and generated his own key pair?
Now, the attacker can modify the DNS records, point to incorrect IP addresses,
and sign the records with the attacker key pair.
To make sure this doesn't happen, arin.net's public key is certified by a higher authority.
arin.net had previously sent their public key to the .net zone administrators,
and after arin.net was validated by .net, the .net zone agreed to vouch for arin.net,
by taking arin.net's public key and hashing it.
This is in the form of another new DNS record, the DS record, stored on the .net DNS servers.
In our example, the .net zone, when giving the RIT DNS server a referral
to the authoritative DNS servers for arin.net also sent a DS record
which contains the hash of arin.net's public key.
The RIT DNS server hashes arin.net's public key, and compares the results
to the DS record sent from the .net zone.
If the hashes match, we know, that arin.net's public key is really arin.net's public key.
And, that the records they sent are legitimate.
How do we trust the DS record itself?
The DS record is in turn hashed and encrypted with .net's private key,
and presented in the form of an RRSIG record.
Now, the RIT DNS server requests that the .net zone send its public key
in the form of a DNS key record.
The RIT DNS server takes the .net public key,
decrypts the RRSIG encrypted hash, and computes its own hash.
If the two match, the .net zone has proven it is really the .net zone.
DNSSEC Part 3
>> But wait another minute now.
What if someone broke into the dot.net zone
and used a different public private key pair as described before?
Just like arin.net is certified by its higher-level parent, .net,
.net is certified by its higher-level parent, dot, or the root zone.
A hash of the .net public key was sent in a DS record
from the root zone earlier to the RIT DNS server.
The RIT DNS server hashes .nets public key and compares the results
to the DS record sent by the root zone.
If the hashes match, we know that .nets public key is really .nets public key
and that the records that they sent are legitimate.
How do we trust the DS record itself?
Along with this DS record, is the RRSIG record for the DS record which contains a hash
of the DS record encrypted with the root zone's private key and stored in the root zone.
Upon request from the RIT DNS server,
the root zone's public key will be sent in a DNS key record.
The RIT DNS server takes the root zone's public key,
decrypts the RRSIG encrypted hash and computes its own hash.
If the two match, then the root zone's public key is really the root zone's pubic key.
.Nets public key is really .nets public key.
Arin.net's public key is really arin.net's public key and the resource records sent
by arin.net's DNS servers have integrity.
Now I know what you're thinking.
What if someone broke into the root zone and switched the keys there?
Right? Well the root zone's key, sign in key, is vetted by a thorough security procedure.
This includes a root signing ceremony that alternates between the two secure facilities
that safeguard the root zone's key sign in key located in El Segundo,
California and Culpepper, Virginia.