Welcome to the Internet Society DNSSEC History Project! Please refer to the About page for specific information on the project, its background, and the steps we’re taking to gather this history. Once you’ve read that, start editing the content below!

IF YOU WOULD LIKE TO CONTRIBUTE TO THIS PROJECT AND UPDATE INFORMATION, please email us at [email protected] so that we can set you up with an account for editing.

This page provides a timeline for the evolution of DNSSEC.

1983

• Paul Mockapetris invents the DNS and implements the first server: Jeeves.

1986

• Formal IETF Internet Standard. Two RFCs describe DNS: 1034 and 1035.

1988

• DNS begins to catch on the Internet.

1990

• Steven Bellovin discovers a major flaw in the DNS 2. As DNS is already widely deployed on the Internet, the report is kept secret until 1995. In those years research is started on a more secure replacement of DNS.

1995

• The article from Bellovin is published and DNSSEC (as it became known) becomes a topic within the IETF.

1997

• RFC 2065, adding security extensions, was published several years after work began.

1999

• RFC 2535 is published by the IETF to fix the flaws in RFC 2065 (see Appendix B of RFC 2535 for the full list of the differences). The DNSSEC protocol looks to be finally finished.
• BIND9 is developed to be the first DNSSEC-capable implementation.

1999-2001

• Although the RFC is finished and BIND is DNSSEC ready, deployment is stalling.

2001

• Experiments show that the key handling in RFC2535 is causing operational problems that would make deployment difficult if not impossible.
• After various ideas and drafts (sig@parent) a new record was proposed: the DS RR, Delegation Signer resource record. With this record the operational problems of DNSSEC would be solved. Because this record has the special property of only existing at the parent zone it introduced some difficulties in the DNS protocol it self. Deployment of DNSSEC looks possible now, but the current code (ie. BIND9) does not understand the new DS record.
•  It is decided to rewrite 2535 into three new drafts:
  • draft-ietf-dnsext-dnssec-intro – a introduction into DNSSEC
  •  draft-ietf-dnsext-dnssec-records – introduces the new records
  •  draft-ietf-dnsext-dnssec-protocol – details the protocol changes

2002-2003

• The drafts are getting more refined and better.
• BIND9 snapshots start appearing that are capable of handling the new DNSSEC standard (2535bis).
• NLnet Labs decides to run a new experiment called SECREG (secure registry) to test 2535bis. The results of this experiment are documented in 4. In short the experiment showed that 2535bis is ready for deployment.

2004

• The expectation is that the drafts are to be finished this year and that even the RFC could be published before 2005. Currently BIND9.3 and higher NSD2 and higher are capable of handling 2535bis DNSSEC.

2005

• At workshops for implementers, yet more problems were discovered, including extreme difficulty getting secretkey signing material to and from a zone parent.
• In response, a set of three RFCs were published with the new DNS Security Extensions (DNSSEC) standards: RFC 4033, RFC 4034, and RFC 4035.
• RFC 4033 was the first time the requirements for DNS security were documented. This means the new standard is almost official. Now we only have to wait for DNSSECbis to become the new standard.

2005 – March

• The RFCs are published:
  • RFC 4033: DNS Security Introduction and Requirements
  • RFC 4034: Resource Records for the DNS Security Extensions
  • RFC 4035: Protocol Modifications for the DNS Security Extensions

2005 – October

• Sweden (.SE) enables DNSSEC in their zone. This makes .SE the first ccTLD to deploy DNSSEC.
• At the same time RIPE NCC (ripe.net) is in the process of deploying DNSSEC in the reverse zones.

2006

• ?

2007

• September – RFC 5011 issued – Automated Updates of DNS Security (DNSSEC) Trust Anchors

2008

• Dan Kaminsky discovers how easily a flaw in the DNS can be exploited for an attack.
• March – RFC 5155 issued – DNS Security (DNSSEC) Hashed Authenticated Denial of Existence – DNSSEC gave users the ability to see the entire contents of a zone, and it was by looking at signed records that read no such domain. Privacy concerns made this unacceptable to some domain operators, so a new type of DNSSEC record was created.

2009

• March – DNSSEC Industry Coalition meets to explore ways to promote DNSSEC deployment.
• October – RFC 5702 issued – Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• December – DNSSEC Deployment Initiative begins publishing content on www.dnssec-deployment.org.

2010

• June – .org becomes the first generic TLD to be signed.
• July – Root zone signed.

2011

• RFC 6394 issued for use cases and requirements for DANE.

2012

• January – Internet Society launches Deploy360 Programme to help accelerate DNSSEC deployment.
• August – RFC 6698 issued for the DANE protocol.

2013

• Over 100 of the ccTLDs and most all the major generic TLDs have been signed (see ICANN domain report).
• All new generic TLDs applied for in planned domain name expansion by ICANN will be required to support DNSSEC.

2014

• January – Internet Society becomes home for www.dnssec-deployment.org website and for publishing weekly DNSSEC Deployment Maps.