Domain Name System Security Extensions: Difference between revisions

Revision as of 02:43, 15 May 2023

Revision as of 02:57, 15 May 2023

Line 12:

Other standards (not DNSSEC) are used to secure bulk data (such as a [[DNS zone transfer]]) sent between DNS servers. As documented in IETF RFC 4367, some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its ___domain name. DNSSEC cannot protect against false assumptions; it can only authenticate that the data is truly from or not available from the ___domain owner.{{citation needed|date=February 2013}}

The DNSSEC specifications (called ''DNSSEC-bis'') describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete. The full set of RFCs that specify DNSSEC are collected in {{IETF RFC|9364}}, which is alsalso [[Request_for_Comments#Best_Current_Practice|BCP]] 237.

It is widely believed<ref>Interview with Dan Kaminsky on DNSSEC (25 Jun 2009) [https://web.archive.org/web/20090628074022/http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1360143,00.html# Kaminsky interview: DNSSEC addresses cross-organizational trust and security]</ref> that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered ({{As of|2010|January|22}}) by several difficulties:

Line 37:

====Algorithms====

DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can be introduced in a [[backward-compatible]] fashion as described in {{IETF RFC|8624}}. The following table defines, as of June 2019, the security algorithms that are or were most often used:<ref>{{cite web

| url = https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

| title = Domain Name System Security (DNSSEC) Algorithm Numbers | date = 2010-07-12 | access-date = 2010-07-17

Line 49:

! Source

! DNSSEC Signing

! DNSSEC Validation<ref>{{cite IETF

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

| title = RFC-8624

| date = June 2019

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

| last1 = Wouters

| first1 = Paul

| last2 = Surý

| first2 = Ondřej

| doi = 10.17487/RFC8624

| s2cid = 195856691

}}</ref>

|-

| 1 || [[RSA (algorithm)|RSA]]/[[MD5]] || || {{no|Must Not Implement}} || {{no|Must Not Implement}}

Line 66 ⟶ 55:

| 3 || [[Digital Signature Algorithm|DSA]]/[[SHA-1]] || || {{no|Must Not Implement}} || {{no|Must Not Implement}}

|-

| 5 || RSA/SHA-1 || {{IETF RFC | 3110}}|| {{no2|Not Recommended}} || {{yes|Required}}

|-

| 6 || DSA-NSEC3-SHA1 || || {{no|Must Not Implement}} || {{no|Must Not Implement}}

|-

| 7 || RSASHA1-NSEC3-SHA1 || {{IETF RFC | 5155}}|| {{no2|Not Recommended}} || {{yes|Required}}

|-

| 8 || RSA/[[SHA-2|SHA-256]] || rowspan="2" | {{IETF RFC| 5702}}|| {{yes|Required}} || {{yes|Required}}

|-

| 10 || RSA/[[SHA-2|SHA-512]] || {{no2|Not Recommended}} || {{yes|Required}}

|-

| 12 || [[GOST]] [[GOST (hash function)|R 34.10-2001]] || {{IETF RFC |5933}}|| {{no|Must Not Implement}} || {{Okay|Optional}}

|-

| 13 || [[Elliptic Curve DSA|ECDSA]]/[[SHA-2|SHA-256]] || rowspan="2" | {{ IETF RFC | 6605}}|| {{yes|Required}} || {{yes|Required}}

|-

| 14 || ECDSA/[[SHA-2|SHA-384]] || {{Okay|Optional}} || {{partial|Recommended}}

|-

| 15 || [[Ed25519]] || rowspan="2" | {{IETF RFC |8080 }}|| {{partial|Recommended}} || {{partial|Recommended}}

|-

| 16 || [[Curve448|Ed448]] || {{Okay|Optional}} || {{partial|Recommended}}

Line 93 ⟶ 82:

! Source

! DNSSEC Delegation

! DNSSEC Validation<ref>{{cite IETF

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

| title = RFC-8624

| date = June 2019

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

| doi = 10.17487/RFC8624

| last1 = Wouters

| first1 = P.

| last2 = Sury

| first2 = O.

| s2cid = 195856691

}}</ref>

|-

| 1 || [[SHA-1]] || IETF RFC | 3658}}|| {{no|Must Not Implement}} || {{yes|Required}}

|-

| 2 || [[SHA-256]] || {{ IETF RFC |4509 }}|| {{yes|Required}} || {{yes|Required}}

|-

| 3 || [[GOST]] [[GOST (hash function)|R 34.10-2001]] || {{ IETF RFC | 5933 }}|| {{no|Must Not Implement}} || {{okay|Optional}}

|-

| 4 || [[SHA-384]] || {{ IETF RFC |6605}}|| {{okay|Optional}} || {{partial|Recommended}}

|}

Line 121 ⟶ 99:

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 IETF|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)]], {{ IETF RFC |6891}}, 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".