Version 4.1 - 2.0 DNSSEC
In the "good old days" - back before "everyone" got on the Internet - there was a protocol named DNS. It was a good protocol and very trusting. Many of the original protocols were based on a trust system. That's because the people on the Internet knew that if something broke, they would have to fix it. So they didn't go around breaking stuff - and assumed everyone else was like them. Then the Internet got popular and bad people broke stuff on purpose. So then there were good people who made it their job to break - and then fix stuff so that the other bad people couldn't break it again. And thus was created the Circle of Protocol Life that exists to this day. Okay - so now I'm at the point where I'm telling pseudo-fairy tales. Just a little something to spice it up. This is the last topic of section 2.0 and I'm a little sick of Security Protocols at this point. But I have to push myself for just one more.
Once this section is done, I will have completed 28% of the blueprint. It has taken a lot of time and energy to do this, but I feel it has been worthwhile. I have already gone through much of this material two or three times, and these posts are a good review. I am remembering a lot of things I saw in videos and read in the study materials. I am also doing searches and getting familiar with where this material is in the Cisco Documentation (which will be very important on the lab section). The material is so vast on the blueprint that you really need to go over it a couple of times so that you don't forget the beginning once you reach the end. And most of all, it is giving me confidence on these topics - which is helpful once you sit in front of that $400 test screen. That said, let's talk about DNSSEC.
Notice that this is DNSSEC and not dnssec or DNSsec. [This is a break from the normal naming convention of IPsec and MACsec.] The Cisco doc on DNSSEC covers a good overview, best practices and tips for successful implementation.
"DNSSEC supplements the hierarchical nature of the DNS with cryptographic characteristics that make it possible to verify the authenticity of information stored in the DNS. This validation makes it possible for resolvers to be assured that when they request a particular piece of information from the DNS, that they do in fact receive the correct information as published by the authoritative source. This assurance is made possible using cryptographic signatures included in the DNS by a source organization. These signatures are calculated on a complete Resource Record set, not individual Resource Records. The signatures are published in a DNSSEC-specific resource record type called RRSIG."
"The networking-specific challenges from DNSSEC (versus DNS) are largely the result of the differences: increased packet sizes, EDNS requirements and the more frequent use of TCP." Remember when DNS goes over a certain size, it switches to TCP - are your firewall rules ready for that?
Also interesting is RFC 3833 which covers "Threat Analysis of DNS." It covers the threats to DNS that DNSSEC was designed to solve and even the weaknesses of DNSSEC as currently implemented. "The authors believe that deploying DNSSEC will help to address some, but not all, of the known threats to the DNS."
Think about this for a while and remember what DNS itself does - and what DNSSEC does. "DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted." Exactly. You just want to know that the query response is correct and from an authentic source. The information is not "secret" in any way. "DNSSEC works by digitally signing records for DNS lookup using public-key cryptography." Right there - your mind map should explode into little branches that remember the PKI stuff. All that applies. And you should remember the part of a "chain of trust" - so Internet-facing records should be using a public certificate that is signed by a root CA that everyone trusts (or else they're not going to trust your record/sig). Also look at the algorithms and hashes supported for this. It will be DSA / ECDSA (Elliptic Curve DSA) / RSA. MD5 is "MUST NOT IMPLEMENT" and SHA-1 and the SHA-2 family is either required or recommended. You may not need to know the specifics, but know that DNSSEC is NOT going to be using EAP or 3DES for the encryption. (Wouldn't that be a really good 'tricky' question?)
One of the other things to note is that DNSSEC records are larger than DNS records. So if someone is trying to do a DoS attack by sending a bunch of queries, the larger records may be more helpful in completing this attack.
And with that, I am ending this section and Section 2.0.