Domain Name System Security Extensions: Difference between revisions

Revision as of 21:50, 14 May 2023

Revision as of 02:22, 15 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 IETF |last1=Herzberg |first1=Amir |last2=Shulman |first2=Haya |dateyear=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 IETF | 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 242:

|url=http://www.internetnews.com/security/article.php/3774131

|title=.ORG the Most Secure Domain?

|work=www.internetnews.com

|author=Sean Michael Kerner

|access-date=2008-09-27

Line 283:

Gaps in the chain of trust, such as unsigned top-level domains or registrars that did not support DNSSEC delegations, meant administrators of lower-level domains could use DLV to allow their DNS data to be validated by resolvers which had been configured to use DLV. This may have hindered DNSSEC deployment by taking pressure off registrars and TLD registries to properly support DNSSEC. DLV also added complexity by adding more actors and code paths for DNSSEC validation.

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=www.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=www.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 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>

Line 352:

* [[BIND]], the most popular DNS name server (which includes [[Domain Information Groper|dig]]), incorporates the newer ''DNSSEC-bis'' (DS records) protocol as well as support for NSEC3 records.

* [[Unbound (DNS server)|Unbound]] is a DNS name server that was written from the ground up to be designed around DNSSEC concepts.

* [[mysqlBind|mysqlbind]], Thethe GPL [[DNS management software]] for DNS ASPs, now supports DNSSEC.

* [[OpenDNSSEC]] is a designated DNSSEC signer tool using [[PKCS11|PKCS#11]] to interface with [[hardware security module]]s.

* [[Knot DNS]] has added support for automatic DNSSEC signing in version 1.4.0.