Domain Name System Security Extensions: Difference between revisions

Revision as of 19:03, 14 May 2023

Revision as of 21:38, 14 May 2023

Line 6:

The original design of the Domain Name System did not include any security features. It was conceived only as a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempt to add security, while maintaining [[backward compatibility]]. Request for Comments 3833 documents some of the known threats to the DNS, and their solutions in DNSSEC.

DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by [[DNS cache poisoning]]. All answers from DNSSEC protected zones are [[digital signature|digitally signed]].<ref>{{Cite journalIETF |last1=Herzberg |first1=Amir |last2=Shulman |first2=Haya |date=2014 |title=Retrofitting Security into Network Protocols: The Case of DNSSEC |url=https://ieeexplore.ieee.org/document/6756846 |journal=IEEE Internet Computing |volume=18 |issue=1 |pages=66–71 |doi=10.1109/MIC.2014.14 |s2cid=12230888 |issn=1089-7801}}</ref> By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete) to the information published by the zone owner and served on an authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX), and can be used to bootstrap other security systems that publish references to cryptographic certificates stored in the DNS such as Certificate Records ([[CERT record]]s, RFC 4398), [[Secure Shell|SSH]] fingerprints ([[SSHFP record|SSHFP]], RFC 4255), [[IPSec]] public keys (IPSECKEY, RFC 4025), [[Transport Layer Security|TLS]] Trust Anchors ([[TLSA]], RFC 6698), or Encrypted Client Hello (SVCB/HTTPS records for ECH, <ref>{{cite webIETF | url=https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ | title=Draft-ietf-dnsop-SVCB-HTTPS-10 - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRS) }}</ref> <ref>{{cite news | url=https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ | title=Draft-ietf-TLS-esni-14 - TLS Encrypted Client Hello }}</ref>).

DNSSEC ''does not'' provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC ''does not'' protect against [[denial of service|DoS]] attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties).{{citation needed|date=February 2013}}

Line 49:

! Source

! DNSSEC Signing

! DNSSEC Validation<ref>{{cite journalIETF

| url = https://tools.ietf.org/html/rfc8624

| title = RFC-8624

Line 93:

! Source

! DNSSEC Delegation

! DNSSEC Validation<ref>{{cite journalIETF

| url = https://tools.ietf.org/html/rfc8624

| title = RFC-8624

Line 121:

Using the [[chain of trust]] model, a Delegation Signer (DS) record in a parent ___domain ([[DNS zone]]) can be used to verify a DNSKEY record in a [[subdomain]], which can then contain other DS records to verify further subdomains. Say that a recursive resolver such as an ISP name server wants to get the IP addresses ([[A record]] and/or [[AAAA record]]s) of the ___domain "www.[[example.com]]".

# The process starts when a security-aware resolver sets the "DO" ("DNSSEC OK"<ref>{{cite webIETF|last1=Conrad|first1=D.|title=Indicating Resolver Support of DNSSEC|url=https://www.ietf.org/rfc/rfc3225.txt|website=Internet Engineering Task Force|access-date=27 April 2017|ref=3. Protocol Changes}}</ref>) flag bit in a DNS query. Since the DO bit is in the extended flag bits defined by [[Extension Mechanisms for DNS|Extension Mechanisms for DNS (EDNS)]], all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require.

# When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security-aware resolver would start with verifying the DS and DNSKEY records at the [[DNS root]]. Then it would use the DS records for the "com" [[top-level ___domain]] found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example.com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example.com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www.example.com".

Line 134:

====Stub resolvers====

Stub resolvers are "minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server."<ref name="rfc4033_section7">

{{Cite journalIETF

| title= RFC 4033: DNS Security Introduction and Requirements

| publisher= [[The Internet Society]]

Line 154:

}}

An earlier definition was given in an earlier RFC:

{{Cite journalIETF

| title = RFC 1123 - Requirements for Internet Hosts -- Application and Support

| publisher= IETF ([[Internet Engineering Task Force]])

Line 170:

A ''validating stub resolver'' can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages.<ref name="rfc4033_p12"/> A validating stub resolver uses the CD bit to perform its own recursive authentication. Using such a validating stub resolver gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet service provider or the connection to them is not trusted.

Non-validating stub resolvers must rely on external DNSSEC validation services, such as those controlled by the user's [[Internet service provider]] or a [[public recursive name server]], and the communication channels between itself and those name servers, using methods such as [[DNS over TLS]].<ref name="rfc4033_p12">{{Cite journalIETF | title= RFC 4033: DNS Security Introduction and Requirements | publisher= [[The Internet Society]] | date= March 2005 | page= 12 | url= http://tools.ietf.org/html/rfc4033#page-12 | last1= Rose | first1= Scott | last2= Larson | first2= Matt | last3= Massey | first3= Dan | last4= Austein | first4= Rob | last5= Arends | first5= Roy | doi= 10.17487/RFC4033 }}</ref><ref name="practical-ipsec">{{cite book | title= Enabling Practical IPsec Authentication for the Internet | first1= Pedro J. | last1= Muñoz Merino | first2= Alberto | last2= García-Martínez | first3= Mario Muñoz | last3= Organero | first4= Carlos Delgado | last4= Kloos | year= 2006 | series= On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops | volume= 1 | editor1-first= Robert | editor1-last= Meersman | editor2-first= Zahir | editor2-last= Tari | editor3-first= Herrero Martín | editor3-last= Herrero | publisher= [[Springer Science+Business Media|Springer]] | url= http://netcom.it.uc3m.es/publications/pdf/2006/fulltext.pdf | url-status= dead | archive-url= https://web.archive.org/web/20120426065241/http://netcom.it.uc3m.es/publications/pdf/2006/fulltext.pdf | archive-date= 2012-04-26 }}</ref>

===Trust anchors and authentication chains===

Line 369:

==Further reading==

* {{cite journalIETF|author1=H. Yang|author2= E. Osterweil|author3=D. Massey|author4=S. Lu| author5=L. Zhang|author-link5=Lixia Zhang|title=Deploying Cryptography in Internet-Scale Systems: A Case Study on DNSSEC|journal=IEEE Transactions on Dependable and Secure Computing|date=8 April 2010|volume=8|issue=5|pages=656–669|doi=10.1109/TDSC.2010.10|citeseerx= 10.1.1.158.1984|s2cid= 14887477}}

==External links==