Sign up to save your podcasts
Or
Share Episode 106 - What Can Maesters Teach Us About DNSSEC
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 106 - What Can Maesters Teach Us About DNSSEC
Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. 2005. RFC 4033: DNS Security Introduction and Requirements. RFC 4033. IETF. https://doi.org/10.17487/RFC4033
Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. 2005. RFC 4034: Resource Records for the DNS Security Extensions. RFC 4034. IETF. https://doi.org/10.17487/RFC4034
Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. 2005. RFC 4035: Protocol Modifications for the DNS Security Extensions. RFC 4035. IETF. https://doi.org/10.17487/RFC4035
There are three foundational Request For Comment (RFC) documents that create Domain Name System Security Extension (DNSSEC). They outline the concept of the problem and the proposed solution (RFC 4033), define key terms (RFC 4034), and describe how to implement the solution (RFC 4035). These three documents were published together and are to be read together to understand the foundation of DNSSEC implementation. Things have changed in the twenty years since formal start. However, these three are the foundation of DNSSEC and the natural starting point for research into the topic.
Ben Laurie, Geoff Sisson, Roy Arends, and David Blacka. 2008. RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. RFC 5155. IETF. https://doi.org/10.17487/RFC5155
This is not backwards compatible, but it does stop NSEC enumeration. NSEC functions by providing a response to DNS queries for names that are not secure with the “Next SECure” name. In the initial implementation this wasn’t seen as an issue. However, with usage it was determined that this enabled enumerations by chasing NSECs across the entire subdomain until being pointed back to the Apex. While not directly damaging, giving away the naming scope was determined to be a bad call. Beyond the paranoid it also had a significantly unbounded cost associated with it, thus NSEC3 (the third iteration of attempting to solve the enumeration walking) was created. NSEC3 uses a hash value which conceals names and is a smaller compute value.
Eric Osterweil, Dan Massey, and Lixia Zhang. 2009. Deploying and Monitoring DNS Security (DNSSEC). In Proceedings of the 2009 Annual Computer Security Applications Conference (ACSAC '09). IEEE Computer Society, 429-438. https://doi.org/10.1109/ACSAC.2009.47
This paper dives into the double problem set of a distributed core system plus a cryptographic system four years into DNSSEC’s existence. Either one is difficult. Combining them along with the voluntary implementation doesn’t bode well for global compliance. United States Federal Government mandated the use of DNSSEC for Federal sites within the .gov domain. And a majority of ccTLD (country code Top Level Domains) begin implementing. Article also talks at length about the difficulty that RFC 5155 and NSEC3 attempts to solve. Also discussed their belief that a DNSSEC monitoring platform should be established and showed off their version SecSpider.
Wilson Lian, Eric Rescorla, Hovav Shacham, and Stefan Savage. 2013. Measuring the Practical Impact of DNSSEC Deployment. In Proceedings of the 22nd USENIX Security Symposium (USENIX Security '13). USENIX Association, 573-587.
Eight years after DNSSEC and only 0.15% of .com TLD are using it. These authors also traced significant delays and in-effect denial of service caused by DNSSEC. Interestingly, they indicate it is statistically significant in the Asian Regional Internet Registry (RIR). The authors created a web browser based iframe extension to study these issues over 529,294 clients’ weeklong internet usage. The iframe used 27 tests per usage (1 no DNSSEC, 1 with DNSSEC, 25 improper DNSSEC), to obtain the data for their report. They also dive into the size of the DNSSEC packet, the failover to TCP or resizing via EDNS0. Comcast as an ISP completely implementing DNSSEC in 2012 which radically changed the percentage of adoption for North America. Added perk, this article talked about SecSpider which was interesting to see they were still relevant and provided more meaning to the earlier article.
Adnath Hemanthindra, Amreesh Phokeer, Visham Ramsurrun, Panagiota Katsina, Sumit Anantwar, and Amar Kumar Seeam. 2021. DNSSEC as a service - A prototype implementation. In Proceedings of the 2020 32nd International Conference on Microelectronics (ICM). IEEE 1-6. https://doi.org/10.1109/ICM50269.2020.9331810
Sixteen years after DNSSEC and even with ICANN publishing warning about DNS vector cyber attacks significant portions of the internet are still not fully implementing DNSSEC. APNIC (Asia Pacific Network Information Centre) specifically cited with less than 25% DNSSEC confirmations. One thing that is noted, is even though adoption has slowly grown, outages caused by misconfigurations have grown in step. A specific example was when the ccTLD .nl key roll over didn’t happen correctly the ~5million sub-domains were impacted. In a sample of 1,456 signed zones 194 were misconfigured in some manner (13.32%). Doing a managed DNSSEC as a service was tested and found to be viable, a quick google search shows that this is a very practical commercial service in 2025.
Marek Bator, Jakub Przystasz, and Miłosz Serafin. 2023. Security of the DNSSEC Protocol and Its Impact on Online Privacy Protection. Advances in Web Development Journal 1, 2 (2023), 43-63. https://doi.org/10.5281/zenodo.10050033
Eighteen years after publishing and adoption is 51.64%(Europe) at the high end and 36.07% at the low end (Asia). One issue that is recurring is distrust from rest of world and the United States. Of the 13 root server clusters 10 are managed by American elements. An additional part of the concern is tied into an interesting factoid brought up in this article, the Key Signing Ceremony. As defined in the initial RFCs the DNS roots have to get the initial trust out-of-band. This is accomplished four times a year in a ceremony that is designed to keep the systems protected, even from malicious actors present in the ceremony. It physically occurs at two sites within the continental United States and that also leads to concerns with some foreign nations.
Music by Sam Green Media: http://samgreenmedia.com/subscribe
View all episodes
By Matthew MinnemanScott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. 2005. RFC 4033: DNS Security Introduction and Requirements. RFC 4033. IETF. https://doi.org/10.17487/RFC4033
Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. 2005. RFC 4034: Resource Records for the DNS Security Extensions. RFC 4034. IETF. https://doi.org/10.17487/RFC4034
Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. 2005. RFC 4035: Protocol Modifications for the DNS Security Extensions. RFC 4035. IETF. https://doi.org/10.17487/RFC4035
There are three foundational Request For Comment (RFC) documents that create Domain Name System Security Extension (DNSSEC). They outline the concept of the problem and the proposed solution (RFC 4033), define key terms (RFC 4034), and describe how to implement the solution (RFC 4035). These three documents were published together and are to be read together to understand the foundation of DNSSEC implementation. Things have changed in the twenty years since formal start. However, these three are the foundation of DNSSEC and the natural starting point for research into the topic.
Ben Laurie, Geoff Sisson, Roy Arends, and David Blacka. 2008. RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. RFC 5155. IETF. https://doi.org/10.17487/RFC5155
This is not backwards compatible, but it does stop NSEC enumeration. NSEC functions by providing a response to DNS queries for names that are not secure with the “Next SECure” name. In the initial implementation this wasn’t seen as an issue. However, with usage it was determined that this enabled enumerations by chasing NSECs across the entire subdomain until being pointed back to the Apex. While not directly damaging, giving away the naming scope was determined to be a bad call. Beyond the paranoid it also had a significantly unbounded cost associated with it, thus NSEC3 (the third iteration of attempting to solve the enumeration walking) was created. NSEC3 uses a hash value which conceals names and is a smaller compute value.
Eric Osterweil, Dan Massey, and Lixia Zhang. 2009. Deploying and Monitoring DNS Security (DNSSEC). In Proceedings of the 2009 Annual Computer Security Applications Conference (ACSAC '09). IEEE Computer Society, 429-438. https://doi.org/10.1109/ACSAC.2009.47
This paper dives into the double problem set of a distributed core system plus a cryptographic system four years into DNSSEC’s existence. Either one is difficult. Combining them along with the voluntary implementation doesn’t bode well for global compliance. United States Federal Government mandated the use of DNSSEC for Federal sites within the .gov domain. And a majority of ccTLD (country code Top Level Domains) begin implementing. Article also talks at length about the difficulty that RFC 5155 and NSEC3 attempts to solve. Also discussed their belief that a DNSSEC monitoring platform should be established and showed off their version SecSpider.
Wilson Lian, Eric Rescorla, Hovav Shacham, and Stefan Savage. 2013. Measuring the Practical Impact of DNSSEC Deployment. In Proceedings of the 22nd USENIX Security Symposium (USENIX Security '13). USENIX Association, 573-587.
Eight years after DNSSEC and only 0.15% of .com TLD are using it. These authors also traced significant delays and in-effect denial of service caused by DNSSEC. Interestingly, they indicate it is statistically significant in the Asian Regional Internet Registry (RIR). The authors created a web browser based iframe extension to study these issues over 529,294 clients’ weeklong internet usage. The iframe used 27 tests per usage (1 no DNSSEC, 1 with DNSSEC, 25 improper DNSSEC), to obtain the data for their report. They also dive into the size of the DNSSEC packet, the failover to TCP or resizing via EDNS0. Comcast as an ISP completely implementing DNSSEC in 2012 which radically changed the percentage of adoption for North America. Added perk, this article talked about SecSpider which was interesting to see they were still relevant and provided more meaning to the earlier article.
Adnath Hemanthindra, Amreesh Phokeer, Visham Ramsurrun, Panagiota Katsina, Sumit Anantwar, and Amar Kumar Seeam. 2021. DNSSEC as a service - A prototype implementation. In Proceedings of the 2020 32nd International Conference on Microelectronics (ICM). IEEE 1-6. https://doi.org/10.1109/ICM50269.2020.9331810
Sixteen years after DNSSEC and even with ICANN publishing warning about DNS vector cyber attacks significant portions of the internet are still not fully implementing DNSSEC. APNIC (Asia Pacific Network Information Centre) specifically cited with less than 25% DNSSEC confirmations. One thing that is noted, is even though adoption has slowly grown, outages caused by misconfigurations have grown in step. A specific example was when the ccTLD .nl key roll over didn’t happen correctly the ~5million sub-domains were impacted. In a sample of 1,456 signed zones 194 were misconfigured in some manner (13.32%). Doing a managed DNSSEC as a service was tested and found to be viable, a quick google search shows that this is a very practical commercial service in 2025.
Marek Bator, Jakub Przystasz, and Miłosz Serafin. 2023. Security of the DNSSEC Protocol and Its Impact on Online Privacy Protection. Advances in Web Development Journal 1, 2 (2023), 43-63. https://doi.org/10.5281/zenodo.10050033
Eighteen years after publishing and adoption is 51.64%(Europe) at the high end and 36.07% at the low end (Asia). One issue that is recurring is distrust from rest of world and the United States. Of the 13 root server clusters 10 are managed by American elements. An additional part of the concern is tied into an interesting factoid brought up in this article, the Key Signing Ceremony. As defined in the initial RFCs the DNS roots have to get the initial trust out-of-band. This is accomplished four times a year in a ceremony that is designed to keep the systems protected, even from malicious actors present in the ceremony. It physically occurs at two sites within the continental United States and that also leads to concerns with some foreign nations.
Music by Sam Green Media: http://samgreenmedia.com/subscribe