Category: DNSSEC

Oct 24

Watch LIVE at 1:00pm US EDT today – ICANN’s DNSSEC Key Signing Ceremony XV

icann-at-15-logoIn about 15 minutes, at 1:00pm US EDT, you can watch live as members of the DNS/DNSSSEC community engage in a “Key Signing Ceremony” that will result in the generation of new keys used for managing DNSSEC at the root of the Domain Name System (DNS).  The live stream will be at:

http://dns.icann.org/ksk/stream/

The schedule, list of attendees and other information can be found at:

http://dns.icann.org/ksk/upcoming-ceremonies/cer15/

The ceremony begins at 1:00pm and is scheduled to end at 4:00pm US EDT. The script that is being followed during the ceremony is available at:

http://data.iana.org/ksk-ceremony/15/KC15_Scripts.pdf

These documents may also be helpful in understanding what happens:

Essentially what is going on is the creation and signing of new “zone-signing keys (ZSKs)” that are being signed by ICANN’s “key-signing key (KSK)” and then deployed by the ZSK operator.

As you will see if you watch, there is a very specific process that is used to ensure the integrity and security of the key signing process.  It is all documented and then archived so that there is full transparency about what goes on.

If you are interested in understanding how DNSSEC works at an operational level, you may find watching today quite informative. If you are unable to watch the stream live, it will be recorded and made available from the archive link for this 15th key signing ceremony.  (And as these key signing ceremonies happen quarterly, the next will be along in just a few months.)

Oct 24

4 NewgTLDs Launched Yesterday Marks Dawn of “DNSSEC From The Start” TLDs

dnssecYesterday was a big day for the Domain Name System (DNS). After a long process, ICANN formally delegated the first four of the “new generic top-level domains (newgTLDs)”, marking the beginning of the largest expansion of the domain name space ever. In addition to the existing “generic TLDs” like .com, .org, .net, etc., and the existing “country code TLDs (ccTLDs)” like .nl, .cz, .tv, etc., over the months and years ahead there are some 1,400 newgTLDs that are expected to be launched.

These first four newgTLDs are interestingly not English-language names like “.shop” or “.bank”, but instead what are called “Internationalized Domain Names (IDNs)” in non-Latin alphabets:

  • شبكة (xn--ngbc5azd) – Arabic for “web/network”
  • онлайн (xn--80asehdb) – Cyrillic for “online”
  • сайт (xn--80aswg) – Cyrillic for “site”
  • 游戏(xn--unup4y) – Chinese for “game(s)”

Yesterday’s “delegation” means that these TLDs now appear in the root zone of the DNS and the registries who operate these TLDs can now begin the process of selling domain names underneath these TLDs.  There is a formal process the registries have to go through to get started, but soon we should see these TLDs available as options for registration at the registrars who are supporting these TLDs.

Now, the exciting aspect of this news from a Deploy360 point of view is simply this:

All of these newgTLDs MUST be signed with and use DNSSEC!

From the very beginning of their operation these newgTLDs are already starting out with more security enabled than many of the existing country-code TLDs (ccTLDs).  If you look at ICANN’s “TLD DNSSEC Report” you can see that pretty much all of the existing major “generic TLDs” (ex. .com, .org, .net, .edu) are signed with DNSSEC.  Similarly over 100 of the existing ccTLDs are signed with DNSSEC.  These four newgTLDs can also be found in that report, with a nice green bar showing that they are all signed with DNSSEC.

The key point here is that these new registries must:

1. Keep the TLD signed with DNSSEC from an operational point of view.
2. Accept DNSSEC records (DS/DNSKEY) from registrars (or domain registrants depending upon the business model).

One important point:

Support of DNSSEC by a newgTLD does NOT mean that ALL domains registered under the newgTLD will be secured with DNSSEC!

But it means that all domain names registered under the newgTLD CAN be secured with DNSSEC – and that is a great step forward!

Furthermore, the new ICANN Registrar Accreditation Agreement (RAA) will require all “ICANN-accredited registrars” to support the passing of DNSSEC records from a domain name registrant up to the TLD registry. This means we should be seeing a great amount more of DNSSEC support from within the registrars.  Hopefully the DNS operators (which are sometimes part of registrars) will follow with making it easy for domain name holders to sign their domains.

All in all this newgTLD launch is great news for those of us looking at add more security to the Internet through the use of DNSSEC.  From here on out all the newgTLDs will be launched with DNSSEC – and hopefully this will also put some competitive pressure on the lagging ccTLDs (and a few lagging gTLDs) to join the rest of the TLDs that have already signed their domains.

And in the end, we’ll have a more secure Internet protecting users from attackers and also enabling new an innovative forms of security such as DANE’s protection of SSL/TLS certificates.

Congratulations to all the teams at these four registries (and their operators) and also at ICANN on this launch of the first new – and secure – gTLDs!

P.S. Want to understand DNSSEC and how (or why?) you can get started?  Check out our DNSSEC Basics page…

 

 

 

 

Oct 22

APNIC Offering DNSSEC Training In Dhaka, Bangladesh, on November 8, 2013

APNIC logoAre you interested in learning about DNSSEC and live near Dhaka, Bangladesh? (or can get there?) If so, the folks at APNIC are offering a day of DNS/DNSSEC trainingon November 8, 2013. From the abstract:

This course will discuss the concept of DNS Security in detail, mechanisms to authenticate the communication between DNS Servers, mechanisms to establish authenticity, and integrity of DNS data and mechanisms to delegate trust to public keys of third parties.

The outline looks quite interesting:

  • DNS concepts
  • Forward and Reverse DNS
  • DNS Security concepts
  • DNS Protocol Vulnerabilities
  • Transaction Signatures (TSIG)
  • DNS security extensions (DNSSEC)
  • Setting up secure zones
  • DNSSEC Key management
  • DNS and IPv6

(I like that bit at the end about “DNS and IPv6″! ;-) )

For more information such as location and fees, as well as the link for registration, please visit the APNIC web page for this class.

Oct 18

DNS Servers Supporting DNSSEC

When you install a DNS “server” on your network, it generally acts as either: 1) an “authoritative server” serving out DNS records on behalf of a zone; or 2) a “recursive nameserver” (also called a “caching nameserver“, a “caching recursive nameserver” or simply a “resolver“) that performs DNS queries.

The following DNS software is known to support DNSSEC.  If you have additions, please contact us.

[EDITORIAL NOTE: This page is still a work in progress.  Individual pages are being created for each of the servers listed that will link to the server website but also to specific pages and tutorials about using that server with DNSSEC. The goal is to have this completed by the end of October 2013.]

Authoritative DNS servers

The following DNS servers can serve out DNSSEC-signed zones and typically also include mechanisms for directly performing DNSSEC-signing within the software (listed alphabetically):

  • BIND
  • Knot DNS
  • Microsoft Windows Server 2012
  • NSD
  • PowerDNS

Recursive DNS servers (a.k.a. “resolvers”)

The following DNS servers can perform validation of DNSSEC signatures when performing DNS queries (listed alphabetically):

  • BIND
  • Microsoft Windows Server 2012
  • Unbound

If you know of additional software we should list here, please contact us.

Oct 16

Introducing The DNSSEC History Project – Can You Help Complete The Story?

dnssec-history-projectCan you please help us fill in the blanks and complete the story of how DNSSEC came about?  Back in 2010 after the root of DNS was signed with DNSSEC, Steve Crocker sent out an email suggesting that the community should document the history of how DNSSEC came to be. As documented on the “About The DNSSEC History Project” page, Steve said in part:

It’s taken twenty years to reach this point, starting with Steve Bellovin’s demonstration of cache poisoning and the early proposals for adding cryptographic signatures to DNS.  A very large number of people, working in a large number of places, have contributed.  There were false starts, technical challenges, controversies and long hard marches.  The large bulk of this work is not very well documented, and there is no place to go to find anything approximating the full story.

To help, the Internet Society offered a wiki site to collect information and in 2010 a good amount of text was added. You can see the current version at:

https://wiki.tools.isoc.org/DNSSEC_History_Project

In the years since 2010 a bit more text was added and some editing occurred, but quite honestly a great amount of the story is still left untold. A couple of us would now like to go in and capture some of this history before it gets lost. But to do so…

WE NEED YOUR HELP!

Some of us, such as myself, weren’t involved in the early days of DNSSEC and so we’re left to try to document the story based on what information we can find out there.  If you were involved, we’d love to have to you add in some text.  You can see the main page of the project where the information is being gathered.  We also split out the timeline into its own separate page:

https://wiki.tools.isoc.org/DNSSEC_History_Project/Timeline

Both of those pages need updates – and the main page needs, in my opinion, to be broken out into some more pages.

If you weren’t involved, but are interested in helping with the project, even just with the editing, we’d also love the assistance. The existing text could use some good editing, and this will continue to be a challenge as we add in more text from multiple people.  There are also any number of documents and events referenced in the main text for which links need to be found and inserted.  I’d also like to see the text cleaned up a bit to be more consistent across sections.

IF YOU WOULD LIKE TO HELP, please send an email message to dnssechistory@isoc.org and we can get you set up with an account for editing the wiki pages. (We’d also ask you to please read the “About” page, too, to understand the project goals.)

The end goal is to chronicle the story of how DNSSEC came to be, in part so that the larger community can remember how it all came together, but also so that developers of future protocols can perhaps gain some insight into how best to develop their protocol from the story of DNSSEC.

Please do join with us and help complete the story!  (Thank you!)

Oct 04

Slides: DNSEC And DANE Deployment – Trends, Tools and Challenges

On Wednesday, October 3rd, I spoke about DNSSEC and DANE at the ENOG 6 event in Kiev, Ukraine.  The video of the session recorded by the ENOG team should be online in about two weeks but in the meantime I thought I’d share my slides that are posted to SlideShare:

It was a great event with some excellent questions and some ideas for further work!

Oct 01

Speaking at ENOG6 On Oct 2 About DNSSEC And DANE – Will Be Streamed Live

ENOG LogoWhat is the current status of DNSSEC deployment? What is going on with DANE? What are some of the remaining challenges?

Tomorrow, Wednesday, October 2, 2013, I’ll be speaking about these DNSSEC/DANE topics at the “Eurasia Network Operators Group (ENOG) 6” event happening in Kiev, Ukraine.

My particular presentation is in the plenary block beginning at:

  • 15:00 Eastern European Summer Time (EEST), which will be
  • 14:00 in most of Europe (CEST) and
  • 8:00am US Eastern.

I’m the second presentation in the block and so I’ll start whenever the previous presenter finishes… probably sometime around 15:30.  My talk will be probably around 30 minutes at the most.

The session will be streamed live as part of the ENOG webcast available at:

http://www.enog.org/live-stream/

(And no, I don’t think the actual livestream is available over IPv6, as we did yesterday, but the ENOG website is available over IPv6.)

If you’d like a preview, my slides are available from the ENOG6 Presentations page, in both PDF and PPT.

I’m looking forward to giving the presentation… it’s a good group of people here at ENOG.  They also do NOT typically hold back in terms of asking questions from the microphones which makes for good sessions and dialogue.

And if you are at ENOG6, please do say hello… I’ll be around all day tomorrow (and am here tonight).

Oct 01

OpenDNSSEC Offering Free DNSSEC Training Oct 10-11 in Stockholm, Sweden

OpenDNSSECInterested in learning more about how to use OpenDNSSEC to secure your DNS infrastructure with DNSSEC?  We recently learned from a post by Patrik Wallström in the DNSSEC LinkedIn Group that there will be a free training class in Stockholm, Sweden, on October 10 and 11, 2013.  More information and a registration link can be found at:

https://www.opendnssec.org/support/trainings/

Patrik notes:

You are welcome to attend a free training course in OpenDNSSEC.  It is a two-day training, where you get a mixture of theory and hands-on experience. We will be using virtual servers hosted by Amazon, so please bring your own laptop.

The full agenda for the training class can be found on the .SE site.

It’s great to see this training happening in Stockholm – and Patrik notes that people can contact him to discuss offering this training in your community (his contact info is on the training page).

Sep 26

How To Securely Transfer A DNSSEC-Signed Domain Between DNS Operators – SIDN’s EPP Keyrelay

sidn-epp-keyrelayWhat happens if you want to transfer a DNSSEC-signed domain from one DNS operator to another? Perhaps you are consolidating domains into one operator… or the new operator has better security… or is less expensive…

It turns out that there has not been an easy way to do this while ensuring that the DNSSEC “chain-of-trust” remains intact.   If the old DNS operator (often referred to as the “losing operator” when talking about domain transfers) just stops serving DNS records, the new DNS operator (referred to as the “gaining operator“) can start serving DNS records – but there will be a time delay while a new DS record is recorded in the registry for the top-level domain (TLD) for whatever domain is being transferred. During that time,  validation would fail because the DNSSEC records being served would not match the DS record contained in the TLD registry.  This might only be a brief period of time… but as we start using DNSSEC more widely – and particularly for services like DANE that provide added integrity to SSL interactions – keeping the domain “always secure” will become increasingly important.

One solution that has been suggested – and successfully demonstrated! – is that of “EPP keyrelay” proposed by SIDN, the registry operator for .NL.  Antoin Verschuren from SIDN Labs wrote up this solution in a document titled “EPP keyrelay: solving the last obstacle for DNSSEC deployment” (PDF).  The mechanism has also been submitted as an Internet Draft to the IETF as: draft-gieben-epp-keyrelay.

Essentially, the mechanism introduces a new command into the Extensible Provisioning Protocol (EPP) used by DNS operators, registrars and registries and uses registry as a broker to transfer DNSSEC key information from the new DNS operator to the old DNS operator as part of the transfer process.

The document and Internet-Draft do indeed present an interesting solution to this challenge of domain transfer. Both are being discussed within the larger DNSSEC and DNS community – and I know that Antoin and the team at SIDN Labs would welcome further feedback – and implementation, of course!  It’s great to have SIDN Labs providing a solution and we look forward to seeing how this work evolves – we definitely do need to ensure that domains can remain “always secure”, even when being transfered.

 

 

 

Sep 24

NIST Releases New Version of Secure DNS Deployment Guide (SP-800-81-2, Including DNSSEC)

NIST SP-800-81-2 DocumentLooking for a solid document about how to securely deploy DNS, including how to configure DNSSEC?  We’ve written before about NIST’s excellent Secure DNS Deployment Guide and how it is very applicable to enterprises and organizations of all types, not just those of the US government.  This morning NIST’s Scott Rose announced that a new version, SP-800-81-2, has been published at:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf

The formal NIST announcement indicates that this new revision…

…adds two new sections – one to provide guidance on secure set up of recursive DNS service and the other for securely configuring validating resolvers. It also incorporates knowledge gained from DNSSEC deployment experience to provide some updated guidance for DNS Administrators on cryptographic algorithm variables, configuration and operations.

In his email to the dnssec-deployment mailing list, Scott noted:

This revision includes new sections with recommendations for the enterprise level admin in setting up recursive servers, including DNSSEC validation. Please send any comments to scottr at nist.gov and/or mouli at nist.gov, since I’m not sure if the old comment address is still working.

Note that this revision was in the pipe when NIST re-opened the comment period for the NIST SP 800-90 series, so any cryptographic recommendations are pre-discovery any may be subject to change if any new information comes to light.

It’s excellent to see this revision and we definitely appreciate all the work that Scott and the others do at NIST that helps accelerate the deployment of DNSSEC!

NOTE: Scott let me know that NIST is definitely seeking comments on this document.  Do you have suggestions for how it can be improved?  Is there additional information they could add?  Please contact him at the email addresses listed in his message.  He is asking for comments within the next 30 days.