Categories
Domain Name System Security Extensions (DNSSEC) IPv6 Open Standards Everywhere Transport Layer Security (TLS)

Listen to the Hedge Podcast 39 to Learn about the Open Standards Everywhere Project

What is our Open Standards Everywhere (OSE) project all about? How did it get started? What are the project goals? What are some of the challenges web server operators face? How can we work together to make web servers more secure and available?

Recently Russ White and his team interviewed me on The Hedge Podcast Episode 39 to discuss all these questions and much more. I’ve known Russ for a good number of years and it was fun to talk with him and his co-hosts Eyvonne Sharp and Tom Ammon about all things related to the OSE project. I hope you enjoy listening to the episode as much as we enjoyed having the conversation!

Listen now

I would encourage you to listen to some of the other Hedge podcast episodes, too, as they have some great content. A few I personally enjoyed included: episode 37 about DNS privacy; episode 31 about network operator groups (NOGs); and episode 30 with Ethan Banks from the Packet Pushers Network about why understanding the fundamentals of networking is so important.

Thank you to Russ, Eyvonne, and Tom for having me on the show!

Want to be more involved with the Open Standards Everywhere project?

Thank you for your help in getting open standards deployed everywhere!

Categories
Deploy360 DNS Privacy Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IPv6

DNS Privacy & IPv6 Security @ APTLD 75

The Internet Society will be actively contributing to the APTLD 75 meeting on 20-21 February 2019 in Dubai, United Arab Emirates.

Our colleague Jan Žorž will not only be presenting on DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) during the DNS Operations, Security, and Privacy session (20 February, 11.30-12.30 UTC+4), but will then be presenting on IPv6 connectivity issues during the Security in IPv6-enabled TLDs session (20 February, 14.30-15.30 UTC+4).

He’ll be in good company in what’s shaping up to be a great programme featuring a number of DNS luminaries covering technical, policy, internationalisation and data protection issues, as well as abuse handling and registry and registrar training. Other sessions of particular interest include 5G mobile networks, the implications of Alternative DNS Root Servers, and emerging trends in the DNS.

The Asia-Pacific Top-Level Domain (APTLD) Association is a non-profit organisation of ccTLD (Country Code Top-Level Domains) registries in the Asia-Pacific region that was founded in 1998. It organises two meetings each year for its members, with APTLD 75 being held in conjunction with the 6th Middle East DNS Forum.

If you’re interested in attending then you can register at http://www.aptld75.ae/reg/end.php

Further Information

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC)

DNS Flag Day

The 1st of February was DNS Flag Day, which is an initiative of several DNS vendors and operators to address the problems of DNS name server implementations that are not in compliance with long-established DNS standards. This is causing the DNS to not only be unnecessarily slow and inefficient, but prevent operators from deploying new functionality including mechanisms to protect against DDoS attacks.

DNSSEC and other extended features of the DNS require EDNS0 (Extension Mechanisms for DNS – RFC 6891), and properly implemented name servers should either reply with an EDNS0 compliant response, or provide a regular DNS response if they don’t understand.

However, a lot of name server software is not implemented properly which has meant resolvers have had to incorporate workarounds when name servers don’t respond correctly. These cause unnecessary retries, delays, and prevent the newer features of the DNS being used.

As a result, the vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) will no longer be supporting these workarounds in new versions of their software, whilst a number of public DNS resolver operators (CleanBrowsing, Cloudflare, Google and Quad9) will no longer resolve hostnames served by broken name server implementations.

This may mean sites become unreachable, which makes it imperative that DNS administrators and domain name holders check whether their authoritative name servers are compliant with the DNS standard from 1987 (RFC1035) or the newer EDNS standard from 1999 (RFC2671 and RFC6891).

The DNS Flag Day website has some helpful information on what DNS administrators and domain name holders need to do, and there’s also a tool to check whether your domain is affected. So if you haven’t already done so, please check your domain for compliance as soon as possible!

Further Information

Categories
Domain Name System Security Extensions (DNSSEC) Improving Technical Security

Call for Participation – ICANN DNSSEC Workshop at ICANN64 in Kobe, Japan

Will you be at the ICANN 64 meeting in March 2019 in Kobe, Japan? If so (or if you can get to Kobe), would you be interested in speaking about any work you have done (or are doing) with DNSSEC, DANE or other DNS security and privacy technologies?  If you are interested, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-kobe@isoc.org before  07 February 2019.


Call for Participation

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 ICANN64 meeting held from 09-14 March 2019 in Kobe, Japan. 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 Annual General Meeting in Barcelona, Spain, on 24 October 2018. The presentations and transcripts are available at: https://63.schedule.icann.org/meetings/901549https://63.schedule.icann.org/meetings/901554, and https://63.schedule.icann.org/meetings/901555.

At ICANN64 we are particularly interested in live demonstrations of uses of DNSSEC, DS automation or DANE. Examples might include:

  • DNSSEC automation and deployment using CDS, CDNSKEY, and CSYNC
  • DNSSEC/DANE validation in browsers and in applications
  • Secure email / email encryption using DNSSEC, OPENPGPKEY, or S/MIME
  • DNSSEC signing solutions and innovation (monitoring, managing, validation)
  • Tools for automating the generation of DNSSEC/DANE records
  • Extending DNSSEC/DANE with authentication, SSH, XMPP, SMTP, S/MIME or PGP/GPG and other protocols

Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet.
We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include:

1. DNSSEC 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. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn’t it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.

2. DS Automation

We are looking at innovative ways to automate the parent child synchronization CDS / CDNSKEY and methods to bootstrap new or existing domains. We are also interested in development or plans related to CSYNC, which are aimed at keeping the glue up to date.
We would like to hear from DNS Operators what their current thoughts on CDS/CDNSKEY automation are.

3. DNSSEC/DANE Support in the browsers

We would be interested in hearing from browser developers what their plans are in terms of supporting DNSSEC/DANE validation.

4. DANE Automation

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:

  • How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?
  • What tools, systems and services are available to help automate DNSSEC key management?
  • Can you provide an analysis of current tools/services and identify gaps?
  • What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?
  • What tools and services are now available that can support DANE usage?

We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to
dnssec-kobe@isoc.org  before ** 07 February 2019 **

We hope that you can join us.
Thank you,
Kathy Schnitt

On behalf of the DNSSEC Workshop Program Committee:
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Russ Mundy, Parsons
Ondřej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Mark Elkins, DNS/ZACR


Image credit:  ICANN

Categories
Domain Name System Security Extensions (DNSSEC)

In Khartoum, A DNSSEC Deployathon

At the Internet Society Sudan Chapter office, adjacent to the west bank of the Blue Nile, four men decided to set up a local server capable of DNSSEC verification. It was an unplanned deployathon: a hands on, practical session in which a solution or service is deployed in a real-world scenario. Deployathons can help build technical capacity or set up a new service, and in this case, the men hoped to increase knowledge of DNSSEC and to prepare the individuals managing Sudan’s top-level domain (.sd) for signing in the near future.

During the SdNOG5 conference, these four men – we the authors, along with Jan Zorz of the Internet Society and Sander Steffann – continued the discussion on the deep technical challenges of deploying DNSSEC, and how Jan and Sander’s presence in Sudan provided an opportunity to leverage their experience with DNSSEC. We also reflected on the importance of DNSSEC for the country code top-level domain (ccTLD) and its positive impact on the national and international levels.

Having enjoyed some delicious Sudanese coffee, the four of us started to install a new server based on Centos 7, a Linux based operating system, from scratch. On this server, a DNS service would be run using the free and open source software known as BIND. The goal was to configure BIND as an authoritative-only name server with the hostname “sd-ns1.go6lab.si” –  a delegation from the parent “go6lab.si.” The domain “go6lab.si” is configured and running on Jan’s Go6Lab based in his home town Škofja Loka in Slovenia, EU.

The Go6lab would also provide another sub-domain to be signed known as “sd.go6lab.si.” The goal was to sign the zone “sd.go6lab.si” on the Centos 7 server (now with the name “sd-ns1.go6lab.si”) and then do a query on the same server to see whether it was serving the DNSSEC information for the signed zone.

We started by generating the Zone Signing Key (ZSK) and Key Signing Key (KSK) for “sd.go6lab.si,” after an explanation from Sander and Jan on the importance and role of the two keys. We then generated our first DS Key (Delegation Signer Key) for our “sd.go6lab.si” domain and submitted that DS Key to the parent-domain authoritative server (in this case the authoritative name servers for go6lab.si). Everything worked like a charm –enough to draw very beautiful smiles on our faces.

It was a great pleasure to have our first DNSSEC validating server – one at the same level and same capabilities as other DNSSEC validation servers around the world. Because the server is hosted locally and we had full access to it, we will be able to study how everything works and use the same resource to train the community and to raise awareness of DNSSEC.

The efforts regarding the DNSSEC for our ccTLD were not planned, but it was a great opportunity to have a very close technical insight that took into consideration all details, including the potential risk during the keys rollover.

.SD is about to launch the registry system (CoCCA) in the coming days, after which we will be able to deploy DNSSEC. Meanwhile we have sufficient practical experience to sign Sudan’s top-level domain, .SD . The Internet Society’s Sudan Chapter is about to organize a number of DNSSEC workshops to all local stakeholders, partners, and community members.

We understand many still have the fear of deploying DNSSEC as we had. Nonetheless, the process was very easy and effortless, it took us four hours to do the whole deployment process, starting from the virtual machine preparation, operating system installation, BIND software installation and configuration, and DNSSEC deployment. We encourage those who haven’t yet deployed DNSSEC to take a brave step and do it, and we will also always be there if anything is needed for the deployment process.

In the end, had it not been for the enlightenment of Jan and Sander – and the great effort exerted by them on DNSSEC – this initial deployment wouldn’t have been possible.

Thank You @Jan
Thank You @Sander

Learn the DNSSEC basics!

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF

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 minimisationdraft-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 locallydraft-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 resiliencydraft-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 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)

[UPDATE, 4 November 2018: The DPRIVE session at IETF 103 was cancelled after the working group chairs determined they did not have enough presenters to have the discussion they were seeking to have. They plan to take the conversation back to the DPRIVE mailing list and perhaps hold a virtual interim meeting in December 2018.]

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/materials/agenda-103-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/materials/agenda-103-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/materials/agenda-103-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 blogTwitter, or Facebook using #IETF103 to keep up with the latest news.

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC)

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

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

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Improving Technical Security

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

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, send email, use social media or engage in other Internet activities!

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.

[UPDATE: the Knot DNS resolver  also supports the Sentinel Test in its version 3.0.0 release – see the release notes.]

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, CentOS, and Fedora. 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.

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Events

Call for Participation – ICANN DNSSEC Workshop at ICANN63 Barcelona

Do you have a great idea about DNSSEC or DANE that you’d like to share with the wider community? If so, and you’re planning to be in Barcelona, Spain for ICANN63 in October 2018, submit a proposal to present your idea at the DNSSEC Workshop!

Send a brief (1-2 sentence) description of your proposed presentation to dnssec-barcelona@isoc.org by Friday, 07 September 2018.

For more information, read the full Call for Participation below.

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 ICANN63 meeting held from 20-25 October 2018 in Barcelona, Spain. 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 Policy Forum in Panama City, Panama on 25 June 2018. The presentations and transcripts are available at:https://62.schedule.icann.org/meetings/699560, and https://62.schedule.icann.org/meetings/699556
At ICANN63 we are particularly interested in live demonstrations of uses of DNSSEC, DS automation or DANE. Examples might include:
* DNSSEC automation and deployment using CDS, CDNSKEY, and CSYNC
* DNSSEC/DANE validation in browsers and in applications
* Secure email / email encryption using DNSSEC, OPENPGPKEY, or S/MIME
* DNSSEC signing solutions and innovation (monitoring, managing, validation)
* Tools for automating the generation of DNSSEC/DANE records
* Extending DNSSEC/DANE with authentication, SSH, XMPP, SMTP, S/MIME or PGP/GPG and other protocols
Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet.
We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include:
1. DNSSEC 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. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn’t it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.
2. Post KSK Rollover
Following the Root Key Rollover, we would like to bring together a panel of people who can talk about lessons learned from this KSK Rollover and lessons learned for the next time
3. DS Automation
We are looking at innovative ways to automate the parent child synchronization CDS / CDNSKEY and methods to bootstrap new or existing domains.  We are also interested in development or plans related to CSYNC, which are aimed at keeping the glue up to date.
We would like to hear from DNS Operators what their current thoughts on CDS/CDNSKEY automation are.
3 DNSSEC/DANE Support in the browsers 
We would be interested in hearing from browser develop what their plans are in terms of supporting DNSSEC/DANE validation.
4. DANE Automation
For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:
* How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?
* What tools, systems and services are available to help automate DNSSEC key management?
* Can you provide an analysis of current tools/services and identify gaps?
* What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?
* What tools and services are now available that can support DANE usage?
We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.
If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-barcelona@isoc.org by **07 September 2018 **
We hope that you can join us.
Thank you,
Kathy Schnitt
On behalf of the DNSSEC Workshop Program Committee:
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Russ Mundy, Parsons
Ondřej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Mark Elkins, DNS/ZACR
Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards Transport Layer Security (TLS)

IETF 102, Day 4: DNS, IoT & TLS

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Today we’re focusing on DNS, IoT and TLS issues.

LPWAN is the first event of the day starting at 09.30 EDT/UTC-4. There will be a discussion relating to the Working Group Last Call on the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities; and on how to advance the LPWAN Static Context Header Compression (SCHC) for CoAP specification. Two other drafts are being presented for adoption by the Working Group relating to SCHC specifications (see https://tools.ietf.org/html/draft-petrov-lpwan-ipv6-schc-over-lorawan-02 and https://tools.ietf.org/html/draft-zuniga-lpwan-schc-over-sigfox-03).


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


The first session of V6OPS commences at 13.30 EDT/UTC-4, and will continue on Friday morning. Today’s agenda items include a presentation on World IPv6 Trends from APNIC Labs, followed by discussion on a new draft NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks which describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network. Two existing drafts will also be discussed – Requirements for IPv6 Routers that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; and Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service which extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS).

During the second part of the afternoon starting at 15.50 EDT/UTC-4, there’s a choice of two meetings.

DNS Resolver Identification and Use (DRIU) is a BoF to discuss how to identify DNS stub resolvers that support privacy (i.e. DNS-over-TLS and DNS-over-HTTPS) using DHCP and DHCPv6. There’s a couple of drafts under discussion on DHCPv6 Options for private DNS Discovery, and DOH digests that provides a mechanism for selecting a DNS-over-HTTPS (DOH) server.

Alternatively, you can choose T2TRG that will consider the report from the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), along with an update on the iot.schema.org that enables webmasters to embed structured data on their web pages for use by search engines and other applications. Following this will be a discussion on the next steps for IoT security, including a draft that reviews the state-of-the-art and the challenges for IoT security. A further draft offers guidance for designing Internet of Things (IoT) systems that follow the REST architectural style.

Then for the evening session starting at 18.10 EDT/UTC-4, there’s again the choice of two meetings:

TLS continues on from Monday afternoon, and will consider three drafts during this session. Certificate-based Authentication with External PSK specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK); Ticket Requests describes a mechanism by which clients may request tickets as needed during a connection, in order to address a limitation on the number of parallel connection a client may initiate; whilst Encrypted Server Name Indication (ESNI) defines a simpler mechanism to conceal the domain name a client is trying to connect to.

DNSOP also continues from where it left off on Wednesday morning. A couple of interesting drafts that may come up in this session include a DNS proxy use case to tunnel DNS query and response using DNS over HTTPs (DOH) protocol; and a proposed protocol and DNS Resource Record to compute, sign, represent, and use a message digest to verify the contents of a DNS zone.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards

IETF 102, Day 3: DNSSEC, DPRIVE & IoT

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And today’s topics include DNS Security & Privacy, along with more IPv6 and IoT.

The first DNSOP session will start at 09.30 EDT/UTC-4, and will continue on Thursday evening. Topics of interest include a draft on Algorithm Implementation Requirements and Usage Guidance for DNSSEC, which updates current algorithm implementation requirements and usage guidance for DNSSEC (obsoleting RFC 6944). Another draft on Multi Provider DNSSEC models describes how to deploy DNSSEC in environments where multiple DNS providers are in use, whilst Delegation_Only DNSKEY flag introduces a new flag for DNSSEC keys that can address a potential attack.


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


Alternatively, the relatively new working group SUIT will also be meeting at the same time. Vulnerabilities in Internet of Things (IoT) devices have raised the need for secure firmware updates that are also suitable for a constrained environments, and this group aims to develop an interoperable update mechanism. There are three drafts up for discussion, including the description of the firmware update architecture, a specification for the firmware update metadata model or manifest, as well a specification for the firmware manifest format. The next steps will also be discussed.

In the first afternoon session starting at 13.30 EDT/UTC-4, there’s a choice of DPRIVE or 6TiSCH.

DPRIVE will kick off with an analysis of RIPE Atlas probe data relating to DNS Privacy, before discussing some recommendations for DNS Privacy Service Operators. There’s also some new work on Oblivious DNS that introduces an additional layer of obfuscation between clients and their queries, and there will be some discussion about how to add privacy to the communication between recursive resolvers and authoritative DNS servers. The latter is beyond the scope of the current Working Group charter and so the group will consider whether to ask to expand their mandate.

6TiSCH has a busy agenda with the 6top protocol that enables distributed scheduling being targeted for an IETF Last Call, whilst the IESG feedback on the security functionality will be discussed. Two other drafts are aiming for Working Group adoption including a description of a scheduling function that defines the behavior of a node when joining a network and a mechanism for carrying important information in infrequent network broadcasts. Another new draft defines a secure joining mechanism for enrolling devices into an 802.15.4 TSG network using 6TiSCH signalling methods.

In the second afternoon session starting at 15.20 EDT/UTC-4, Homenet will continue to discuss the Homenet profile of the Babel routing protocol. There are also two updated drafts on the agenda, relating to third party provisioning of naming services for home networks and defining DHCPv6 options so that naming services can be outsourced.

Rounding off the day is the IETF Plenary starting at 17.10 EDT/UTC-4.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

ISOC’s Hot Topics at IETF 102

The 102nd meeting of the IETF starts tomorrow in Montreal, Canada. This is will be the third time that an IETF has been held in the city, and tenth time in Canada – the first being way back in 1990.

The ISOC Internet Technology Team is as always highlighting the latest IPv6, DNSSEC, Securing BGP, TLS and IoT related developments, and we discuss these in detail in our Rough Guide to IETF 102. But we’ll also be bringing you daily previews of what’s happening each day as the week progresses.

Below are the sessions that we’ll be covering in the coming week. Note this post was written in advance so please check the official IETF 102 agenda for any updates, room changes, or final details.

Monday, 16 July 2018

Tuesday, 17 July 2018

Wednesday, 18 July 2018

Thursday, 19 July 2018

Friday, 20 July 2018

The IETF Hackathon will be held on both Saturday, 15 July 2018 (09.00-22.00 UTC-4) and Sunday, 16 July 2018 (08.30-16.00 UTC-4) in the Centre Ville Room. The Hackathon provides an opportunity for developers and implementers to discuss ideas, solutions and code to develop practical implementations of IETF standards.

The IETF Code Sprint will also be held on Saturday, 15 July 2018 (09.30-16.00 UTC-4) in the Sherbrooke/Mansfield Room. The Code Sprint brings together volunteers from the IETF Community to work on code for the IETF Datatracker, mailing lists, and other tools used by the IETF community.

You can also read the Internet Society’s latest Rough Guide to IETF 102. In particular, see:

If you can’t get to Montreal next week, you can attend remotely!  Just visit the IETF 102 remote participation page or check out http://www.ietf.org/live/ for more options.