Category: Domain Name System (DNS)

Nov 02

Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy

As happened earlier this year at IETF 102 in Montreal, DNS privacy will receive a large focus in the DNSOP, DPRIVE and DNSSD working groups. Given the critical role DNS plays as part of the “public core” of the Internet in linking names and identifiers to IP addresses, the DNS must have stronger security and privacy controls.  As part of our Rough Guide to IETF 103, here’s a quick view on what’s happening in the world of DNS.

Note – all times below are Indochina Time (ICT), which is UTC+7.

DNS Operations (DNSOP)

The DNS sessions at IETF 103 start on Monday afternoon from 13:50-15:50 with the DNS Operations (DNSOP) Working Group.  As per usual, DNSOP has a packed agenda. The major security/privacy-related drafts include:

  • DNS query minimisation – draft-ietf-dnsop-rfc7816bis – Back in 2016, RFC 7816 defined an experimental way to increase DNS privacy and limiting the exposure of DNS query information by simply not sending the entire query all the way up the DNS resolver chain.  This new work is to move that RFC 7816 document from being an experiment to being an actual Internet standard.
  • Running a DNS root server locally – draft-ietf-dnsop-7706bis – Another way to increase DNS privacy is to not send queries up the DNS resolver chain to the root by running your own local copy of the root DNS servers. Back in 2015, the informational RFC 7706 defined how to do this and specified running it on the “loopback” interface of your local computer. This new work broadens that to allow the local copy to run more generally on local systems. At the recent ICANN 63 meeting in Barcelona, this was discussed as “hyperlocal” copies of the root zone of DNS. Wes Hardaker at ISI also has a site about this effort: https://localroot.isi.edu/ Not only could this increase privacy, but also resiliency of the DNS system. However, it is not without its critics and so there could be a good discussion in Bangkok.
  • Serving stale data to increase DNS resiliency – draft-ietf-dnsop-serve-stale – This project is setting up the criteria for when DNS resolvers could continue to use DNS data even after the Time To Live (TTL) expires. Basically, if you can’t reach an authoritative server for some reason, under what conditions could you continue to serve the records you previously retrieved from that server?

If there is time in the session, Paul Hoffman’s draft-hoffman-resolver-associated-doh may come up for discussion. This relates to the somewhat controversial DNS Over HTTPS (DOH), now defined in RFC 8484, that lets an app such as a web browser send DNS queries over HTTPS to a DOH server where the DNS resolution can occur.  The controversy with DOH is primarily two points: 1) it lets an application completely bypass local DNS servers and thereby bypass local DNS filtering or restrictions; and 2) the first announced use of DOH was by Mozilla Firefox with a DOH server from Cloudflare. This second point brought concerns about centralization and potential choke points.  As more entities have stood up DOH servers, there has been a need to help DOH clients understand which DOH server to use. Paul’s draft provides one such mechanism.

If by some miracle there happens to still be time in the session and there is an open mic, I may see if I can briefly ask the group if there is interest in moving forward the draft that several of us worked on about DNSSEC cryptographic algorithm agility – draft-york-dnsop-deploying-dnssec-crypto-algs .  However, given the agenda, I highly doubt there will be an opportunity – it will need to be mailing list activity.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday morning from 09:00-11:00 ICT.  This meeting at IETF 103 is primarily focused on the discussion about how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  Specifically they will spend about 30 minutes on the “user perspective” of DNS privacy and a full hour on the “authoritative and recursive perspective” as the working group looks at whether to expand its work to increase the privacy of even more elements of the DNS infrastructure

Extensions for Scalable DNS Service Discovery (DNSSD)

Privacy will also get attention at the DNSSD Working Group on Thursday afternoon from 13:50-15:50 ICT.  DNSSD focuses on how to make device discovery easier across multiple networks. For instance, helping you find available printers on not just your own network, but also on other networks to which your network is connected. However in doing so the current mechanisms expose a great deal of information.

The working group had a lengthy discussion at IETF 102 in Montreal about DNS privacy – and are planning for a significant 50 minute discussion block here at IETF 103 in Bangkok.

DNSSEC Coordination informal breakfast meeting

As a final note, on Friday morning we may try an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. This time we are not sure yet because with the formal meetings ending on Thursday, many people may be traveling home on Firday. We’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

DANE and DNSSEC will also appear in the TLS Working Group’s meeting on Wednesday. The draft-ietf-tls-dnssec-chain-extension will be presented as a potential way to make DANE work faster by allowing both DANE and DNSSEC records to be transmitted in a single exchange, thus reducing the time involved with DANE transactions. There has been a lengthy discussion on the TLS list and the chairs are scheduling 55 minutes for this discussion.

Given the key role DNS plays in the Internet in general, you can also expect DNS to appear in other groups throughout the week.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 103:

DNSOP (DNS Operations) WG
Monday, 5 November 2018, 13:50-15:50 ICT, Chitlada 1
Agenda: https://datatracker.ietf.org/meeting/103/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 7 November 2018, 09:00-11:00 ICT, Meeting 1
Agenda: https://datatracker.ietf.org/meeting/103/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 8 November 2018, 13:50-15:50 ICT, Meeting 2
Agenda: https://datatracker.ietf.org/meeting/103/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

Follow Us

It will be a busy week in Bangkok, and whether you plan to be there or join remotely, there’s much to monitor. Follow us on the Internet Society blog, Twitter, or Facebook using #IETF103 to keep up with the latest news.

The post Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy appeared first on Internet Society.

Oct 23

Watch Live – DNSSEC Workshop on October 24 at ICANN 63 in Barcelona

ICANN 63 banner image

What can we learn from recent success of the Root KSK Rollover? What is the status of DNSSEC deployment in parts of Europe – and what lessons have been learned? How can we increase the automation of the DNSSEC “chain of trust”? And what new things are people doing with DANE?

All these topics and more will be discussed at the DNSSEC Workshop at the ICANN 63 meeting in Barcelona, Spain, on Wednesday, October 24, 2018. The session will begin at 9:00 and conclude at 15:00 CEST (UTC+2).

The agenda includes:

  • DNSSEC Workshop Introduction, Program, Deployment Around the World – Counts, Counts, Counts
  • Panel: DNSSEC Activities
    • Includes presenters from these TLDs: .DK, .DE, .CH, .UK, .SE, .IT, .ES, .CZ
  • Report on the Execution of the .BR Algorithm Rollover
  • Panel: Automating Update of DS records
  • Panel: Post KSK Roll? Plan for the Next KSK Roll?
  • DANE usage and use cases
  • DNSSEC – How Can I Help?

It should be an outstanding session!  For those onsite, the workshop will be room 113.

 

Lunch will be served between the second and third sessions.

Thank you to our lunch sponsors: Afilias, CIRA, and SIDN.

Please do join us for a great set of sessions about how we can work together to make the DNS more secure and trusted!

If you would like more information about DNSSEC or DANE, please visit our Start Here page to begin.

Image credit: ICANN

The post Watch Live – DNSSEC Workshop on October 24 at ICANN 63 in Barcelona appeared first on Internet Society.

Oct 04

Are you ready? How to prepare for the DNSSEC Root KSK Rollover on October 11, 2018

skeleton key

Are you ready? Are your systems prepared so that DNS will keep functioning for your networks?  One week from today, on Thursday, October 11, 2018, at 16:00 UTC ICANN will change the cryptographic key that is at the center of the DNS security system – what we call DNSSEC. The current key has been in place since July 15, 2010. This is a long-planned replacement.

If everything goes fine, you should not notice and your systems will all work as normal. However, if your DNS resolvers are not ready to use the new key, your users may not be able to reach many websites!

This change of this central security key for DNS is known as the “Root Key Signing Key (KSK) Rollover”. It has been in discussion and planning since 2013. We’ve written many articles about it and spoken about it at many conferences, as have many others in the industry. ICANN has a page with many links and articles at:

But here we are, with only a few days left and you may be wondering – how can I know if my systems are ready?

The good news is that since the Root KSK Rollover was delayed 1 year, most all of the DNS resolver software has been shipping for quite some time with the new key. If you, or your DNS server administrators, have been keeping up with recent updates, you should be all set.

1. Test if you are doing DNSSEC validation

Before you do anything else, you should first check if you are doing DNSSEC validation on your network.  As noted in ICANN’s guidance document, go to a command-line / terminal / shell window and type:

dig @<IP of your DNS resolver> dnssec-failed.org a +dnssec

For example, using Google’s Public DNS Server, the command would be:

dig @8.8.8.8 dnssec-failed.org a +dnssec

If the response includes this text:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

then you ARE doing DNSSEC validation and should read the rest of this article.

If the response instead includes:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

… well, you are NOT doing DNSSEC validation. You can skip the rest of this article, go have a beverage, and not have to worry about the Root KSK Rollover on October 11.  However, you should also read up on DNSSEC and understand why you start validating to raise the level of security and trust on your network. (But, at this point, you might as well wait until October 12 to deploy it.)

If you are doing DNSSEC validation, read on. 

Two notes:

  • Unfortunately if you are not an administrator of your DNS resolvers, there are limited mechanisms to check if you have the new key. There are a couple of possibilities (see #2 and #3a below), but otherwise you will need to contact your DNS administrators / IT team and point them to this blog post and other resources.
  • In DNS / DNSSEC circles the root key is also referred to as a “trust anchor”.

2. Try the Sentinel KSK Test

For a small percentage of you reading this, you might be able to use the “sentinel test” that is based on an Internet draft that is in development. You can do so at either of these sites:

Right now there is only one DNS resolver (Unbound) that implements this sentinel test. Hopefully by the time we do the next Root KSK Rollover, some years from now, this will be more widely deployed so that regular users can see if they are protected.

However, for most of us, myself included, we need to go on to other methods…

3a. Check if your DNS resolvers have the new Root KSK installed – via various tools

There are several tests you may be able to perform on your system. ICANN has published a list at:

That document lists the steps for the following DNS resolvers:

  • BIND
  • Unbound
  • PowerDNS Recursor
  • Knot Resolver
  • Windows Server 2012RS and 2016
  • Akamai DNSi Cacheserve
  • Infoblox NIOS

For BIND users, ISC2 also provides a focused document: Root KSK Rollover in BIND.

3b. Check if your DNS resolvers have the new Root KSK installed – via specific files

If you have command-line access to your DNS servers, you can look in specific files to see if the new key is installed.  The current key (“KSK 2010”) has an ID of 19036. The new key has an ID of 20326. As Paul Wouters wrote in a Red Hat blog post today, these keys can be found in these locations in Red Hat Linux:

  • bind – see /etc/named.root.key
  • unbound / libunbound – see /var/lib/unbound/root.key
  • dnsmasq – see /usr/share/dnsmasq/trust-anchors.conf
  • knot-resolver – see /etc/knot-resolver/root.keys

Look in there for a record with an ID of 20326. If so, you are all set. If not, you need to figure out how to get the new key installed.

Note – these locations here are for Red Hat Linux. Other Linux distributions may use slightly different file locations – the point is that there should be a file somewhere on your system with these keys.

4. Have a backup plan in case there are problems

As Paul notes in his post today, it would be good to have a backup plan in case there are unexpected DNS problems on your network on October 11 and users are not able to resolve addresses via DNS. One suggestion is to temporarily change your systems to give out one of the various sets of “public” DNS servers that are operated by different companies. Some of these include:

IPv4 IPv6 Vendor
1.1.1.1 2606:4700:4700::1111 Cloudflare
8.8.8.8 2001:4860:4860::8888 Google DNS
9.9.9.9 2620:fe::fe Quad9
64.6.64.6 2620:74:1b::1:1 Verisign

You can switch to one of these resolvers while you sort out the issues with your own systems. Then, once you have your systems correctly configured, you can switch back so that the DNSSEC validation is happening as close to your users as possible (thereby minimizing the potential areas of the network where an attacker could inject malicious DNS traffic).

5. Plan to be around on 11 October 2018 at 16:00 UTC

Finally, don’t schedule a day off on October 11th – you might want to be around and able to monitor your DNS activity on that day.  This Root KSK Rollover has been in the works for many years now. It should be a “non-event” in that it will be “just another day on the Internet”. But many of us will be watching whatever statistics we can. And you’ll probably find status updates using the #KeyRoll hashtag on Twitter and other social networks.

The end result of all of this will be the demonstration that we can safely and securely change the cryptographic key at the center of DNS – which allows us to continue improving the level of security and trust we can have in this vital part of the public core of the Internet!

Image credit: Lindsey Turner on Flickr. CC BY 2.0

P.S. This is NOT what the “Root key” looks like!

Acknowledgements:  Thanks to Ed Lewis, Paul Hoffman, Paul Wouters, Victoria Risk, Tony Finch, Bert Hubert, Benno Overeinder, Hugo Salgado-Hernández, Carlos Martinez and other members of the dnssec-coord discussion list for the discussion that informed this post.

The post Are you ready? How to prepare for the DNSSEC Root KSK Rollover on October 11, 2018 appeared first on Internet Society.

Jul 13

Rough Guide to IETF 102: DNSSEC, DNS Security and Privacy

DNS privacy will receive a large focus in the latter half of the IETF 102 week with attention in the DPRIVE, DNSSD, and OPSEC working groups. In an interesting bit of scheduling (which is always challenging), most of the DNS sessions are Wednesday through Friday. As part of our Rough Guide to IETF 102, here’s a quick view on what’s happening in the world of DNS.

Given that IETF 102 is in Montreal, Canada, all times below are Eastern Daylight Time (EDT), which is UTC-4.

IETF 102 Hackathon

The “DNS team” has become a regular feature of the IETF Hackathons and the Montreal meeting is no different. The IETF 102 Hackathon wiki outlines the work that will start tomorrow (scroll down to see it). Major security/privacy projects include:

Anyone is welcome to join the DNS team for part or all of that event.

DNS Operations (DNSOP)

The DNS sessions at IETF 102 start on Wednesday morning from 9:30am – 12noon with the DNS Operations (DNSOP) Working Group. Paul Wouters and Ondrej Sury will be speaking about “Algorithm Implementation Requirements and Usage Guidance for DNSSEC“, where they will be offering updated guidance around what cryptographic algorithms should be used for different aspects of DNSSEC.  Shumon Huque will be bringing the latest updates to draft-huque-dnsop-multi-provider-dnssec, exploring how to deploy DNSSEC in environments where multiple DNS providers are in use. Paul Wouters will also bring a new draft, draft-pwouters-powerbind, which introduces a new flag for DNSSEC keys that can address a potential attack. Given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action. The DNSOP working group also has a second meeting block on Thursday from 18:10-19:10.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 EDT.  As shown on the agenda, there will be three major blocks of discussion. After some initial discussion of current work on existing DNS privacy policies, there will be a larger discussion about some new work called “Oblivious DNS” that aims to make DNS privacy protection even stronger. This work originated in a paper at Princeton University – https://odns.cs.princeton.edu/ – and now is captured in draft-annee-dprive-oblivious-dns. It should be quite an interesting discussion!

The third major area will continue discussion about how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  This is work outside the current  DPRIVE Working Group charter and so the group will be discussing whether to ask to expand their mandate to cover this new work.

Extensions for Scalable DNS Service Discovery (DNSSD)

Privacy will also get attention at the DNSSD Working Group on Thursday morning from 9:30-12:00 EDT.  DNSSD focuses on how to make device discovery easier across multiple networks. For instance, helping you find available printers on not just your own network, but also on other networks to which your network is connected. However in doing so the current mechanisms expose a great deal of information. The agenda allocates 65 minutes to Christian Huitema to guide a discussion around the way forward. Drafts under discussion include:

There are other drafts under discussion at DNSSD, but these are the ones probably most of interest to readers of this article.

DNS Resolver Identification and Use (DRIU)

IETF 102 will feature a number of Birds-of-a-Feather (BOF) sessions, and one in particular relates to DNS security. The quick description is:

The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties.

The DRIU session will be on Thursday from 15:50-17:50, right before the second DNSOP session (although in a different room).

Operational Security Capabilities for IP Network Infrastructure

In the very last slot on Friday afternoon from 11:50-13:20, the OPSEC working group will feature Benno Overeinder speaking about “Recommendations for DNS Privacy Service Operators“. This document outlines things DNS operators should thing about when considering offering “DNS privacy” services. It builds on the work coming out of the DPRIVE working group and the experience gained from the IETF Hackathon and the real-world deployment of these new protocols.

DNSSEC Coordination informal breakfast meeting

As a final note, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

DANE and DNSSEC will also appear in the TLS Working Group’s Monday meeting. The draft-ietf-tls-dnssec-chain-extension will be presented as a potential way to make DANE work faster by allowing both DANE and DNSSEC records to be transmitted in a single exchange, thus reducing the time involved with DANE transactions. Given the key role DNS plays in the Internet in general, you can also expect DNS to appear in other groups throughout the week.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 102:

DNSOP (DNS Operations) WG
Wednesday, 18 July 2018, 9:30-12:00 EDT, Laurier
Thursday, 19 July 2018, 18:10-19:10 EDT, Place du Canada
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 18 July 2018, 13:30-15:00 EDT, Place du Canada
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 19 July 2018, 9:30-12:00 EDT, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DRIU (DNS Resolver Identification and Use) BOF
Thursday, 19 July 2018, 15:50-17:50 EDT, Viger
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-driu

OPSEC (Operational Security Capabilities for IP Network Infrastructure) WG
Friday, 20 July 2018, 11:50-13:20 EDT, Viger
Agenda: https://datatracker.ietf.org/meeting/102/agenda/opsec/
Documents: https://datatracker.ietf.org/wg/opsec/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

The post Rough Guide to IETF 102: DNSSEC, DNS Security and Privacy appeared first on Internet Society.

Jun 22

Watch Live On Monday, 25 June – DNSSEC Workshop at ICANN 62 in Panama

With the DNSSEC Root Key Rollover coming up on October 11, how prepared are we as an industry? What kind of data can we collect in preparation? What is the cost benefit (or not) of implementing DANE? What can we learn from an existing rollover of a cryptographic algorithm?

All those questions and more will be discussed at the DNSSEC Workshop at the ICANN 62 meeting in Panama City, Panama, on Monday, June 25, 2018. The session will begin at 9:00 and conclude at 12:15 EST (UTC-5). [Note: this is one hour different than current US Eastern Daylight Time – Panama does not change to daylight savings time – and so this will begin at 10:00 EDT (UTC-4).]

The agenda includes:

  • DNSSEC Workshop Introduction, Program, Deployment Around the World – Counts, Counts, Counts
  • Panel: DNSSEC Activities and Post Key Signing Key Rollover Preparation
  • DANE: Status, Cost Benefits, Impact from KSK Rollover
  • An Algorithm Rollover  (case study from CZ.NIC)
  • Panel: KSK Rollover Data Collection and Analysis
  • DNSSEC – How Can I Help?
  • The Great DNSSEC/DNS Quiz

It should be an outstanding session!  For those onsite, the workshop will be in Salon 4, the ccNSO room.

Lunch will follow. Thank you to our lunch sponsors: Afilias, CIRA, and SIDN.

The DNSSEC Workshop will be followed by the “Tech Day” set of presentations from 13:30 – 18:30 EST. Many of those may also be of interest. They will also be streamed live at the same URL.

As this is ICANN’s smaller “Policy Forum” schedule, there will not be either the “DNSSEC for Everybody” session nor the “DNSSEC Implementer’s Gathering” as there is at the other two ICANN meetings each year. Also, as I am not able to travel to ICANN 62, I want to thank Jacques Latour for stepping in to help with the usual presenting and emceeing that I do.

Please do join us for a great set of sessions about how we can work together to make the DNS more secure and trusted!

If you would like more information about DNSSEC or DANE, please visit our Start Here page to begin.

Image credit: ICANN

The post Watch Live On Monday, 25 June – DNSSEC Workshop at ICANN 62 in Panama appeared first on Internet Society.

Apr 20

Call for Participation – ICANN DNSSEC Workshop at ICANN62, Panama City

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN62 meeting held from 25-28 June 2018 in Panama City, Panama.

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to  dnssec-panamacity@isoc.org by Friday, 4 May 2018

The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.  For reference, the most recent session was held at the ICANN Community Forum in San Juan, Puerto Rico on 14 March 2018. The presentations and transcripts are available at:

As this is the shorter “Policy Forum” format for ICANN meetings, the DNSSEC Workshop Program Committee is developing a 3-hour program.  Proposals will be considered for the following topic areas and included if space permits.  In addition, we welcome suggestions for additional topics either for inclusion in the ICANN62 workshop, or for consideration for future workshops

1. DNSSEC Activities Panel (Regional and global)

For this panel, we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment, including Root Key Signing Key (KSK) Rollover activities.   Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, questions of interest include:

  • What have we learned about how we manage DNSSEC?
  • What is the best practice around key rollovers?
  • How often do you review your disaster recovery procedures?
  • Is there operational familiarity within your customer support teams?
  • What operational statistics have we gathered about DNSSEC?
  • Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?

If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.

2. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.  In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:

  • Are there any policies directly or indirectly impeding your DNSSEC deployment? (RRR model, CDS/CDNSKEY automation)
  • What are your most significant concerns with DNSSEC, e.g., complexity, training, implementation, operation or something else?
  • What do you expect DNSSEC to do for you and what doesn’t it do?
  • What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?

We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.  In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to  dnssec-panamacity@isoc.org by **Friday, 4 May 2018**

 

Thank you,

The DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Ondrej Filip, CZ.NIC
Julie Hedlund, ICANN
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, Chinese Academy of Sciences (CAS)
Russ Mundy, Parsons
Kathy Schnitt, ICANN
Yoshiro Yoneya, JPRS
Dan York, Internet Society

The post Call for Participation – ICANN DNSSEC Workshop at ICANN62, Panama City appeared first on Internet Society.

Apr 02

Deadline TODAY (23:59 UTC) to submit comments to ICANN on 2018 DNSSEC Root KSK Rollover Plan

Do you believe ICANN should go ahead with the plan to roll the Root Key Signing Key (KSK) on 11 October 2018? If so (or if not), the deadline for public comment is TODAY, 2 April 2018, at 23:59 UTC. That’s about 9.5 hours from the time I’m publishing this post.

My colleague Kevin Meynell provided more info about this public comment process when it began in March. At the IETF 101 meeting in London, I spoke with ICANN staff who again stated that they would like to hear from many voices about whether they should go ahead with the Root KSK Rollover on 11 October 2018. It’s very simple to send in comments:

Learn how to submit your comments to ICANN

You can see the current list of comments at: https://mm.icann.org/pipermail/comments-ksk-rollover-restart-01feb18/2018q1/thread.html (All comments are public.)

I would encourage anyone interested to submit comments (even if they are simply “I support the plan.”).

And if you have want more information about how to get started with using DNSSEC, please see our Deploy360 Start page to begin.

Image credit: Bryce Barker on Unsplash

The post Deadline TODAY (23:59 UTC) to submit comments to ICANN on 2018 DNSSEC Root KSK Rollover Plan appeared first on Internet Society.

Mar 16

Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy

It’s going to be a crazy busy week in London next week in the world of DNS security and privacy! As part of our Rough Guide to IETF 101, here’s a quick view on what’s happening in the world of DNS.  (See the full agenda online for everything else.)

IETF 101 Hackathon

As usual, there will be a good-sized “DNS team” at the IETF 101 Hackathon starting tomorrow. The IETF 101 Hackathon wiki outlines the work (scroll down to see it). Major security/privacy projects include:

  • Implementing some of the initial ideas for DNS privacy communication between DNS resolvers and authoritative servers.
  • Implementation and testing of the drafts related to DNS-over-HTTPS (from the new DOH working group).
  • Work on DANE authentication within systems using the DNS Privacy (DPRIVE) mechanisms.

Anyone is welcome to join us for part or all of that event.

Thursday Sponsor Lunch about DNSSEC Root Key Rollover

On Thursday, March 22, at 12:30 UTC, ICANN CTO David Conrad will speak on “Rolling the DNS Root Key Based on Input from Many ICANN Communities“. As the abstract notes, he’ll be talking about how ICANN got to where it is today with the Root KSK Rollover – and about the open comment period on the plan to roll the KSK in October 2018.

David’s session will be streamed live for anyone wishing to view remotely.

DNS Operations (DNSOP)

The DNS sessions at IETF 101 really begin on Tuesday, March 20, with the DNS Operations (DNSOP) Working Group from 15:50 – 18:20 UTC. Several of the drafts under discussion will relate to the Root KSK Rollover and how to better automate and monitor key rollovers. DNSOP also meets on Thursday, March 22, from 18:10-19:10, where one draft of great interest will be draft-huque-dnsop-multi-provider-dnssec. This document explores how to deploy DNSSEC in environments where multiple DNS providers are in use. As per usual, given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 UTC.  As shown on the agenda, there will be two major blocks of discussion. First, Sara Dickinson will offer recommendations for best current practices for people operating DNS privacy servers. This builds off of the excellent work she and others have been doing within the DNS Privacy Project.

The second major discussion area will involve Stephane Bortzmeyer discussing how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  When the DPRIVE working group was first chartered, the discussion was whether to focus on the privacy/confidentiality between a stub resolver and the local recursive resolver; or between the recursive resolver and authoritative server; or both. The discussion was to focus on the stub-to-recursive-resolver connection – and that is now basically done from a standards perspective. So Stephane is looking to move the group on into the next phase of privacy. As a result, the session will also include a discussion around re-chartering the DPRIVE Working Group to work on this next stage of work.

Extensions for Scalable DNS Service Discovery (DNSSD)

On a similar privacy theme, the DNSSD Working Group will meet Thursday morning from 9:30-12:00 UTC and include a significant block of time discussing privacy and confidentiality.  DNSSD focuses on how to make device discovery easier across multiple networks. For instance, helping you find available printers on not just your own network, but also on other networks to which your network is connected. However in doing so the current mechanisms expose a great deal of information. draft-ietf-dnssd-privacy-03 and several related drafts explore how to add privacy protection to this mechanism. The DNSSD agenda shows more information.

DNS-Over-HTTPS (DOH)

IETF 101 will also feature the second meeting of one of the working groups with the most fun names – DNS Over HTTPS or… “DOH!” This group is working on standardizing how to use DNS within the context of HTTPS. It meets on Thursday from 13:30-15:30. As the agenda indicates, the focus is on some of the practical implementation experience and the work on the group’s single Internet-draft: draft-ietf-doh-dns-over-https.

DOH is an interesting working group in that it was formed for the express purpose of creating a single RFC. With that draft moving to completion, this might be the final meeting of DOH – unless it is rechartered to do some additional work.

DNSSEC Coordination informal breakfast meeting

Finally, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

DANE and DNSSEC will also appear in the TLS Working Group’s Wednesday meeting. The draft-ietf-tls-dnssec-chain-extension will be presented as a potential way to make DANE work faster by allowing both DANE and DNSSEC records to be transmitted in a single exchange, thus reducing the time involved with DANE transactions. Given the key role DNS plays in the Internet in general, you can also expect DNS to appear in other groups throughout the week.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 101:

DNSOP (DNS Operations) WG
Tuesday, 20 March 2018, 15:50-18:30 UTC, Sandringham
Thursday, 22 March 2018, 18:10-19:10 UTC, Sandringham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 21 March 2018, 13:30-15:00 UTC, Balmoral
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 22 March 2018, 9:30-12:00 UTC, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DOH (DNS over HTTPS) WG
Thursday, 22 March 2018, 13:30-15:30 UTC, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/agenda/doh/
Documents: https://datatracker.ietf.org/wg/doh/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.

The post Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy appeared first on Internet Society.

Mar 09

DNSSEC Activities at ICANN 61 in San Juan on March 11-14, 2018

Sunday marks the beginning of the DNSSEC activities at the ICANN 61 meeting in San Juan, Puerto Rico. As per usual there will be a range of activities related to DNSSEC or DANE. Two of the sessions will be streamed live and will be recorded for later viewing. Here is what is happening.

All times below are Atlantic Standard Time (AST), which is UTC-4.

DNSSEC For Everybody: A Beginner’s Guide – Sunday, 11 March

On Sunday, March 11, we’ll have our “DNSSEC For Everybody: A Beginner’s Guide” session that will include our usual skit where a bunch of engineers act out how DNS and DNSSEC work! Yes, it’s a good bit of fun and people have told us it has helped tremendously.

Please come with your questions and prepare to learn all about DNSSEC!

DNSSEC Workshop – Wednesday, 14 March

Our big 6-hour workshop will take place on Wednesday, March 14, from 09:00 – 15:00 in Room 208-BC. Lunch will be included. Thank you to our lunch sponsors: Afilias, CIRA, and SIDN.

The very full agenda includes:

  • DNSSEC Workshop Introduction, Program, Deployment Around the World – Counts, Counts, Counts
  • Panel: DNSSEC Activities, including representatives of .CA, .PR and .BR
  • A Sentinel for Detecting Trusted Keys in DNSSEC
  • Experience with DNSSEC Validation at CPE
  • DNSSEC HSM, Signer and KSK Rollover
  • Negative Trust Anchors
  • Real World DANE Inter-Domain Email Transport
  • Panel: Current State of Root KSK Rollover and What’s Next?
  • DNSSEC – How Can I Help?

It should be an outstanding session!

DNSSEC Implementers Gathering – 14 March

On the evening of Wednesday, March 14, after the DNSSEC Workshop is all over, we’ll have our informal “DNSSEC Implementers Gathering” bringing together people who have implemented DNSSEC or DANE in some way for a time to share information, have conversation and light snacks. Invitations have gone out to various DNSSEC mailing lists – if you are interested in attending please send a message to me at york@isoc.org. We thank Afilias for their generous sponsorship of this gathering at ICANN 61!

As I am not able to travel to ICANN 61, I want to thank Jacques Latour for stepping in to help with some of the emceeing and other meeting facilitation duties that I often do.

Please do join us for a great set of sessions about how we can work together to make the DNS more secure and trusted!

If you would like more information about DNSSEC or DANE, please visit our Start Here page to begin.

The post DNSSEC Activities at ICANN 61 in San Juan on March 11-14, 2018 appeared first on Internet Society.

Sep 28

ICANN Postpones DNSSEC Root KSK Rollover – October 11 will NOT be the big day

People involved with DNS security no longer have to be focused on October 11. News broke yesterday that ICANN has decided to postpone the Root KSK Rollover to an unspecified future date.
To be clear:

The Root KSK Rollover will NOT happen on October 11, 2017.

ICANN’s announcement states the the KSK rollover is being delayed…

…because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured.

Getting More Information

Discussion on the public DNSSEC-coord mailing list indicates more info may be available in a talk Duane Wessels is giving at the DNS-OARC meeting tomorrow (Friday, September 29). The abstract of his session is:

A Look at RFC 8145 Trust Anchor Signaling for the 2017 KSK Rollover

RFC 8145 (“Signaling Trust Anchor Knowledge”) was published in April 2017. This RFC describes how recursive name servers can signal, to authoritative servers, the trust anchors that they have configured for Domain Name System Security Extensions (DNSSEC) validation. Shortly after its publication, both Unbound and BIND implemented the specification. As organizations begin to deploy the new software versions, some of this “key tag data” is now appearing in queries to the root name servers.

This is useful data for Key Signing Key (KSK) rollovers, and especially for the root. Since the feature is very new, the number of recursive name servers providing data is not as significant as one might like for the upcoming root KSK rollover. Even so, it will be interesting to look at the data. By examining this data we can understand whether or not the technique works and hopefully inspire further adoption in advance of future KSK rollovers.

If you, like me, will not be in San Jose for this session, there will be a webcast / live stream. The link should be available tomorrow morning on the DNS-OARC event page. Or you can follow the #oarc27 hashtag or @dnsoarc onTwitter.

Per the OARC 27 timetable, Duane’s talk begins at 9:40am PDT (UTC-7). (Side note: for those involved with DNS, there are many other excellent sessions on the timetable!)

Apparently whatever data ICANN received through this research convinced them that not enough ISPs were ready to go with the new KSK and so a postponement was necessary.

Understandable caution

I do understand why ICANN would step back and delay the KSK roll. If there are significant sections of the Internet that will experience issues with resolving DNSSEC-signed domains on October 11, it is prudent to wait to assess the data and potentially reach out to affected ISPs and other network operators. Particularly when, as we noted in our State of DNSSEC Deployment 2016 report last year, the number of domains signed with DNSSEC continues to grow around the world.

I look forward to working with ICANN and the rest of the DNSSEC community to set a new date. As I wrote (along with my colleague Andrei Robachevsky) in our comments back in April 2013, we believe that the Root KSK should be rolled soon – and rolled often – so that we gain operational experience and make Root KSK rollovers just a standard part of operations.  (Note: our CITO Olaf Kolkman submitted similar comments, although at the time he was with NLnet Labs.)

Updating the DNS infrastructure is hard

The challenge ICANN faces is that updating the global DNS infrastructure is hard to do. The reality is that DNS resolvers and servers are massively DE-centralized and controlled by millions of individual people. You probably have one or more DNS resolvers in your home in your WiFi router and other devices.

The success of DNS is that generally it “just works” – and so IT teams often set up DNS servers and then don’t pay much attention to them. At a talk I gave yesterday to about 180 security professionals at the ISC2 Security Congress in Austin, TX, I asked how many people had updated the software on their DNS resolvers within the past year – only a few hands were raised.

All of the latest versions of the major DNS resolvers support the new Root KSK. Recent versions all generally support the automated rollover mechanism (RFC 5011). But… people need to upgrade.

And in the example of a home WiFi router, the vendor typically needs to upgrade the software, then the service provider has to push that out to devices… which can all take a while.

A group of us looking to expand the use of elliptic curve cryptography in DNSSEC wrote an Internet Draft recording our observations on deploying new crypto algorithms. Updating the root KSK as a trust anchor faces a similar set of issues – although a bit easier because the focus is primarily on all the DNS resolvers performing DNSSEC validation.

The critical point is – upgrading the global DNS infrastructure can take some time. ICANN and members and of the DNSSEC community (including us here at the Internet Society) have been working on this for several years now, but clearly the new data indicates there is still work to do.

Next Steps

The good news is that companies now have more time to ensure that their systems will work with the new key.  The new Root KSK is published in the global DNS, so that step has at least been done. More information is available on ICANN’s site:

https://www.icann.org/kskroll

I would recommend two specific pages:

The time to do this is NOW to be ready for the Root KSK Roll when it does happen.

For more information about DNSSEC in general, please see our Deploy360 DNSSEC page.

Image credit: Lindsey Turner on Flickr. CC BY 2.0

P.S. And no, that is NOT what the “Root key” looks like!

The post ICANN Postpones DNSSEC Root KSK Rollover – October 11 will NOT be the big day appeared first on Internet Society.