Domain Name System Security Extensions: Difference between revisions

Revision as of 02:58, 15 May 2023

Revision as of 03:09, 15 May 2023

Line 108:

Next, it may be that there is not a ___domain name named "www.example.com", in which case instead of returning a RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a ___domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above.

Finally, it may be that the "example.com" zone implements DNSSEC, but either the "com" zone or the root zone do not, creating an "island of security" which needs to be validated in some other way. {{as of|2010|7|15}}, deployment of DNSSEC to root is completed.<ref>{{Cite web | url=httphttps://www.root-dnsseciana.org/dnssec/archive | title=Root DNSSEC}}</ref> The .com ___domain was signed with valid security keys and the secure delegation was added to the root zone on 1 April 2011.<ref>{{Cite web|url=http://www.v3.co.uk/v3-uk/news/2039287/verisign-adds-dnssec-com-___domain-boost-online-security/|title=Computing - the UK's leading source for the analysis of business technology}}</ref>

====Stub resolvers====

Line 233:

===Deployment at the DNS root===

DNSSEC was first deployed at the root level on July 15, 2010.<ref name="dnssec-status-live">{{cite web|title=Root DNSSEC StatusProject Update, 2010-07-16Archive|url=httphttps://www.root-dnsseciana.org/2010dnssec/07/16/status-update-2010-07-16/|date=16 July 2010archive}}</ref> This is expected to greatly simplify the deployment of DNSSEC resolvers, since the root trust anchor can be used to validate any DNSSEC zone that has a complete chain of trust from the root. Since the chain of trust must be traced back to a trusted root without interruption in order to validate, trust anchors must still be configured for secure zones if any of the zones above them are not secure. For example, if the zone "signed.example.org" was secured but the "example.org" zone was not, then, even though the ".org" zone and the root are signed, a trust anchor has to be deployed in order to validate the zone.

Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:

Line 249:

====Implementation====

On January 25, 2010, the L (ell) root server began serving a ''Deliberately Unvalidatable Root Zone'' (DURZ). The zone uses signatures of a [[SHA-2]] (SHA-256) hash created using the [[RSA (algorithm)|RSA]] algorithm, as defined in RFC 5702.<ref>{{citeIETF webRFC | title= DNSSEC Root Zone High Level Technical Architecture | url= http://www.root-dnssec.org/wp-content/uploads/2010/06/draft-icann-dnssec-arch-v1dot4.pdf 5702}}</ref><ref>RFC 5702, §2.1. "RSA public keys for use with RSA/SHA-256 are stored in DNSKEY resource records (RRs) with the algorithm number 8."</ref><ref>RFC 5702, §3.1. "RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8."</ref> As of May 2010, all thirteen root servers have begunbegan serving the DURZ.<ref name="last-puzzle-pieces"/> On July 15, 2010, the first root full production DNSSEC root zone was signed, with the SOA serial 2010071501. Root trust anchors are [https://data.iana.org/root-anchors/ available from IANA].<ref name="dnssec-status-live"/>

===Deployment at the TLD level===

Line 263:

ISC decommissioned its DLV registry in 2017.<ref>{{Cite web|title=DLV Replaced With Signed Empty Zone - Internet Systems Consortium|url=https://www.isc.org/blogs/dlv-replaced-with-signed-empty-zone/|access-date=2020-06-05|website=isc.org|date=30 September 2017}}</ref> DLV support was deprecated in BIND 9.12 and completely removed from BIND 9.16.<ref>{{Cite web|title=BIND 9.16.0, Stable Branch for 2020 and Beyond - Internet Systems Consortium|url=https://www.isc.org/blogs/bind9.16.0_released/|access-date=2020-06-05|website=isc.org|date=20 February 2020}}</ref> Unbound version 1.5.4 (July 2015) marked DLV as decommissioned in the example configuration and manual page.<ref>{{Cite web|title=Unbound 1.5.4 Changes|url=https://nlnetlabs.nl/projects/unbound/download/#unbound-1-5-4|access-date=2020-06-05|website=NLnet Labs|language=en}}</ref> Knot Resolver and PowerDNS Recursor never implemented DLV.

In March 2020, the [[IETF]] published {{IETF RFC | 8749}}, retiring DLV as a standard and moving RFC 4432 and RFC 5074 to "Historic" status.<ref>{{cite IETF |title=Moving DNSSEC Lookaside Validation (DLV) to Historic Status |rfc=879 |last1=Mekking |first1=W. |author-link1=W. (Matthijs) Mekking |last2=Mahoney |first2=D. |author-link2=Dan Mahoney (computer scientist) |date= March 2020 |publisher=[[Internet Engineering Task Force|IETF]] |access-date= 3 June 2020|doi=10.17487/RFC8749 }}</ref>

===DNSSEC deployment initiative by the U.S. federal government===