DNSSec Explained!

DNSSec is yet neither widely deployed nor well understood, but there is already clear and present need for its use. Just like HTTPS, DNSSec is becoming more common, and will eventually become required.

In this video tutorial I diagrammatically show how DNSSec works. We’ll look at DNS functionality, DNS referrals, spoofing and man-in-the-middle attacks, asymmetric key cryptography (public key cryptography), digital signatures, zone signing keys, key signing keys, DS records, and more.

 

DNSSec Explained

 

 

DNSSec Explained

 

DNSSec references

 
 

Tags:

Posted in Instructional

5 Responses to “DNSSec Explained!”

  • Chris says:

    Daniel,
    Great walk through. I have 1 question around verification of the rrset for the record. The rrset is calculated for all records of that type in the zone. To verify against the rrsig wouldn’t you need all records in the rrset to do this calculation? e.g. If we have say 1000 type A records, wouldn’t all these need to be retrieved so the rrset could be calculated, and then verified by the rrsig?

    Thanks

    • Chris says:

      Daniel,
      It’s fine I can see where I was going wrong. It’s not all A records, a rrset would be on A records of the same name.
      Correct?

      Thanks

      • Daniel L. Benway says:

        Chris,

        It’s my understanding that an RRSet contains all records of a particular type (A, MX, TXT, etc.) from the entire domain/zone. For an external domain/zone (vs. an internal domain/zone, like Active Directory) this RRSet will not be terribly large.

        Daniel

  • Daniel,

    I noticed dnssec unsigned on my domain and looked into this further resulting in finding your video. Thanks for the explanation. I checked further and found Amazon and Citibank for examples have not implemented DNSSEC, why not? It there performance issues or other issues? Given Citibank concern with security why would they not implement DNSSEC? Thoughts? John

    • Daniel L. Benway says:

      DNSSec is slow to be implemented for the same reasons HTTPS was and is; it adds small but inconvenient amounts of complexity, cost, and overhead. I think it’ll catch on, just like HTTPS slowly is. It’s almost 2017, can you believe there are still sites without HTTPS??? That’s my point.




Share via
Copy link