Deploy360 DNS Privacy Domain Name System (DNS) Improving Technical Security Security

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions, and mentioned some of the protocols that have been recently developed to improve user privacy.

To complement this, we are publishing our DNS Privacy Frequently Asked Questions (FAQ). This highlights and provides answers to the most important aspects of DNS privacy.

Please also check our DNS Privacy page for more information!

Further Information

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

Further Information

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

Deploy360 Domain Name System (DNS) Improving Technical Security

DNS-over-TLS in Linux (systemd)

Whilst we were putting together some content about DNS privacy recently, we learned that recent distributions of Linux ship with support for making DNS queries over TLS. We therefore decided to give Ubuntu 18.10 a try on a laptop.

More recent versions of Ubuntu employ a special service for name resolution called ‘system-resolved.service(8)’. The configuration file ‘resolved.conf(5)’ specifies most of the details for name resolution, including which protocols and resolvers should be employed, whilst the ‘/etc/systemd/network/*.network’ configuration files (see ‘’ for details) of the ‘systemd-networkd.service(8)’ specify any per-link specific settings.

The default configuration of ‘systemd-resolved’ is selected at compile time, and ‘/etc/systemd/resolved.conf’ normally contains commented-out lines describing such defaults. For example, the contents of the aforementioned file on a fresh Ubuntu 18.10 installation are:

As may be inferred from the file, DNS-over-TLS (DoT) is supported, but disabled by default. At the time of  writing, only opportunistic DoT is supported according to the manual, which means that the resolver will first try resolution using DoT before falling back to traditional DNS in the event of failure – thus allowing for downgrade attacks where an attacker intentionally causes a DoT failure in order to cause name resolution to downgrade to traditional DNS.

We decided to give DoT at try by changing three configuration variables in ‘/etc/systemd/resolved.conf’:

  • Set ‘DNS’ to the IP address of the DoT server
  • Set ‘DNSOverTLS’ to ‘opportunistic’
  • Set ‘Domains’ to ‘~.’

The ‘DNS’ variable contains the list of IP addresses that correspond to the DoT recursive resolver (you can find a list of public recursive resolvers here).

Setting ‘DNSOverTLS’ to ‘opportunistic’ enables DoT in opportunistic mode – this means that DoT will be employed if possible, but the stub resolver will fall back to traditional DNS if it fails.

Finally, setting ‘Domains’ to ‘~.’ instructs ‘systemd-resolved’ to prefer the specified nameserver over any per-link DNS server that may be available. This is an important setting as otherwise a non-DoT per-link DNS resolver could take precedence over the DoT resolver.

Our resulting configuration therefore becomes:

Once these changes have been applied, you need to make them take effect by executing the command:

sudo systemctl restart systemd-resolved

With this done, we then decided to double-check that DoT rather than traditional DNS was being employed. So we simply ran a sniffer on the Ubuntu laptop, and did a DNS query for ‘’ which revealed:

Our query generated both traditional DNS and DoT traffic in parallel. In fact, when we later ran a sniffer on the authoritative nameserver itself, it confirmed that both the local resolver on our network ( and Cloud-flare’s resolver were issuing queries for the above domain.

In response to this finding, we tried to figure out why we were seeing traditional DNS traffic in parallel, instead of just DoT traffic, or at least DoT traffic followed by traditional DNS traffic on the assumption that DoT failed? In addition, why was the local resolver being employed for DNS resolution even when the ‘Domains’ variable instructs ‘systemd-resolved’ to employ the specified DoT resolver over any other resolver.

It would seem that the ‘systemd-resolved’ implementation for opportunistic DoT does not employ traditional DNS only as a result of DoT failures, but rather in parallel to DoT queries. On the other hand, a discussion on the GitHub repository for ‘systemd’ notes that the documentation for the ‘Domains’ variable is actually incorrect and simply specifies that the DoT resolver should be employed for domains matching the specified suffix (“.”, in our case), which does not mean this resolver should be the only one employed for resolving matching domains.


Based on the tests we’ve carried out, we can only conclude that there is a flaw in the DoT implementation of ‘systemd-resolved’. Quite clearly using a DoT resolver only makes sense if DNS queries are sent exclusively over an encrypted channel, or at the very least, traditional DNS is only employed in response to DoT failures (and possibly after acknowledgment from the user that traditional DNS should be employed).

We therefore currently recommend that if DoT needs to be employed, alternative implementations such as Stubby should be used until this issue is resolved with ‘systemd’.


We would like to thank Sara Dickinson for her help in debugging these issues.

Further Information

Deploy360 Domain Name System (DNS) Improving Technical Security

DNS-over-HTTPS (DoH) Support in Mozilla Firefox

Recent releases of Firefox have introduced the concept of DNS privacy under the name “Trusted Recursive Resolver”. Although Firefox ships with DNS-over-HTTPS (DoH) disabled by default, there has been some discussion within the Mozilla developer community about changing the default to “enabled”.

Although DoH is somewhat controversial because it moves control plane (signalling) messages to the data plane (data forwarding), and can thereby bypass local network policies, DoH advocates argue that it makes it harder to block or monitor DNS queries which is a commonly used method for restricting access to the Internet and/or monitoring user behaviour.

But putting these arguments aside, if you want to try out DoH then the DNS privacy (or “TRR” in Firefox speak) configuration in Firefox can be accessed as follows:

  • Enter “about:config” in the address box of the browser
  • Search for “trr” (without quotes)

A sample output of DNS privacy configuration in Mozilla Firefox is as follows:

Firefox offers its technical users quite a few settings to play with, but the most important options (along with their recommended settings) for TRR are:

“network.trr.bootstrapAddress” specifies the IP address of a recursive resolver that should be employed to obtain the address of the DoH resolver specified using the “network.trr.uri” variable.

For modes other than “3”, Firefox will employ any DNS servers learned from DHCP. However, when mode “3” is selected, queries are not sent by default to any non-DoH resolver, and hence it is necessary to specify the address of a DNS resolver to be able to “bootstrap” DNS privacy.

Setting network.trr.mode to “3” sets “strict” resolution – meaning only DoH will be employed, with no fall back mechanism. This is a sensible option, since it prevents downgrade attacks.

Finally, network.trr.uri allows the selection of a DoH server/resolver.

The resulting configuration is:

In order to check whether TRR has been successfully enabled, it’s possible to use a protocol analyzer, as follows:

  • Check the network for traditional DNS traffic – this means packets destined for TCP port 53 or UDP port 53. If DoH has been successfully enabled, you should see no traffic from the local node to those ports
  • Check the network for DoH traffic – that means packets destined for TCP port 443 of the IP address(es) corresponding to the DoH resolver in the “network.trr.uri” variable. If DoH has been successfully enabled, you should probably see traffic to this port.

A more interesting way of checking the status of TRR is to employ the Firefox’ “about:networking”  experimental interface. This allows access to internal networking-related features, and can be accessed by entering the aforementioned string (without quotes) in the address box – with the DNS cache being directly available at “about:networking#dns”.

The following figure shows a sample output of the DNS cache:

The first column contains the list of cached domain names, while the second column indicates the protocol family employed (IPv4, in all of our domain names). The third column specifies whether TRR (DoH) was employed for DNS resolution, as if it has been enabled on the browser since we ran it, all of the entries in the DNS cache should have the third column set to “true”.

The fourth column specifies the addresses resulting from DNS resolution, while the fifth column specifies the current “time-to-live” of each entry (in seconds) before the entry is purged from the cache.

Firefox TRR Configuration variables

Whilst we only need to set three configuration variables to enable TRR, Firefox offers a range of other options for tuning it:

  • trr.allow-rfc1918: false (boolean)
    • Firefox will only allow RFC1981 addresses in TRR responses if this flag is set to “true”
  • trr.blacklist-duration: 60
    • Number of seconds a domain will be kept in a “blacklist” when resolution does not work with TRR, but works with a normal resolver.
  • trr.bootstrapAddress:
    • Address of a recursive resolver to obtain the address of the server specified in “network.trr.uri”
  • trr.confirmationNS:
    • Firefox will try to do DNS resolution to check that TRR is working properly
  • trr.credentials:
    • Credentials to be used in the “Authorization” request header
  • trr.disable-ECS: true (boolean)
    • Disable sending EDNS Client Subnet (ECS) information to authoritative servers.
  • trr.early-AAAA: true (boolean)
    • Firefox normally sends both A and AAAA queries in paralell. It will only use AAAA records if they arrive first and this flag is set to true
  • trr.max-fails:
    • Number of times after which Firefox should give up on TRR resolution for a given domain name
  • trr.mode: 0
    • 0: Off – use normal resolver and don’t use TRR
    • 1: Race – do TRR and normal resolution in parallel, and use whatever answer comes first
    • 2: First – use TRR, and fall back to normal resolver if it fails
    • 3: Only – Only use TRR, and never use normal resolver (after initial setup)
    • 4: Shadow – Do TRR in parallel with normal resolver (for measurements) but only use results from normal resolver5: Off by choice – same as “0”, but represents explicit decision to disable TRR
  • trr.request-timeout: 3000
    • Time value in seconds after which a TRR query is considered to have failed
  • trr.uri:
    • URI to be employed for DNS resolution
  • trr.useGET: false (boolean)
    • Whether to use GET rather than POST method.
  • trr.wait-for-portal: true (boolean)
    • Whether to wait for captive portal detection before using DoT


Further Information

Deploy360 Domain Name System (DNS) IETF

DNS Security & Privacy discussed at e-AGE18

The Internet Society continued its engagement with Middle East networking community by participating in the e-AGE18 Conference, where we took the opportunity to promote the importance of DNS Security and Privacy. The conference was held on 2-3 December 2018 at the Marriott Hotel in Amman, Jordan and was organised by the Arab States Research and Education Network (ASREN) and co-sponsored by the Internet Society.

Kevin Meynell from the Internet Society’s Middle East Bureau, highlighted the importance of implementing DNSSEC which allows DNS resolvers to authenticate the origin of data in the DNS through a verifiable chain-of-trust. This reduces the possibility of spoofing where incorrect or corrupt data is introduced into a resolver, or a man-in-the-middle attack whereby DNS queries are re-directed to a name server returning forged responses.

Unfortunately, only the Saudi Arabia ccTLD (.sa) has operationally deployed DNSSEC in the Middle East region at the present time, although Iran (.ir) and Iraq (.iq) have deployed it on an experimental basis. On the positive side, around 18% of DNS queries originated from Middle East countries are being validated compared to 12% globally, with Yemen (45.1%), Saudi Arabia (32.1%), Iraq (30.6%), Bahrain (23.2%) and Palestine (22.5%) leading the way. This is possibly because there is a greater prevalence of the use of third-party DNS resolvers (e.g. Cloudflare, Google, Quad9 in the region.

Of course, whilst DNSSEC ensures that DNS records have not been modified without the owner’s consent, it does not keep the queries themselves confidential. DNS queries reveal what site a host is communicating with, and as they are (by default) sent in clear text, they can easily be eavesdropped.

The IETF DNS Private Exchange (DPRIVE) Working Group has therefore recently developed mechanisms to encrypt queries and responses to/from resolvers and therefore provide some confidentiality of DNS transactions. These include DNS-over-TLS (DoT), DNS-over-DTLS (DoD) and DNS-over-HTTPS (DoH), and with the exception of DoD, there are already several public DNS resolvers (Cloudflare, Quad9 & CleanBrowsing) and a few clients (Stubby 1.3+, Unbound 1.6.7+, Knot 2.0+, Mozilla Firefox 62+ and Android 9 Pie) that support these mechanisms.

It should be pointed out that clients and resolvers need to be upgraded to support DoT and DoH, and all these mechanisms currently only encrypt DNS communications between client (stub-resolver) and recursive resolver, not between recursive resolver and authoritative DNS servers. Support for the latter would require all authoritative DNS servers to be upgraded to support DoT and DoH, and there are concerns about the increased computing requirements that would required on the more heavily name servers to initiate the encrypted connections.

In addition, providers of the recursive resolver are in the position to monitor and log queries and responses, so need to be trusted. Nevertheless, these are important developments towards improving the security and confidentiality of the DNS.

Last but certainly not least, attention was drawn to DNS Flag Day which is important to be aware of. 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, but these cause unnecessary retries, delays, and prevent the newer features of the DNS being used. The vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) are therefore removing these workarounds as of 1 February 2019, with the consequence is that hostnames served by broken DNS implementations will no longer be resolved. So please check whether your domain is affected!

ASREN is a non-profit association of National Research and Education Networks in the Middle East that aims to connect institutes to enable access to services, applications and computing resources within the region and around the world, and to boost scientific research and cooperation amongst its members. Its mandate covers 22 countries, and it has partnered with the major regional R&E networking initiatives elsewhere in the world, including GÉANT (Europe), Internet2 (United States), CANARIE (Canada), WACREN (West Africa) and RedCLARA (Latin America). International connectivity is supported by the EU-funded EUMEDConnect3 project.

Deploy360 can also help you deploy DNSSEC, so please take a look at our Start Here page to learn more.

Further Information

Deploy360 Domain Name System (DNS) Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 1: IPv6, TLS, DNS Privacy & Other Crypto

The Working Group sessions start tomorrow at IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Only four days have been scheduled for the working groups this time around, which means there’s a lot of pack into each day; with Monday being no exception.

V6OPS is a key group and will be meeting on Monday morning starting at 09.00 UTC+7. It’s published four RFCs since its last meeting, including Happy Eyeballs v2, and this time will kick-off with a presentation on the CERNET2 network which is an IPv6-only research and education in China.

There’s also four drafts to be discussed, including three new ones. IPv6-Ready DNS/DNSSSEC Infrastructure recommends how DNS64 should be deployed as it modifies DNS records which in some circumstances can break DNSSEC. IPv6 Address Assignment to End-Sites obsoletes RFC 6177 with best current operational practice from RIPE-690 that makes recommendations on IPv6 prefix assignments, and reiterates that assignment policy and guidelines belong to the RIR community. Pros and Cons of IPv6 Transition Technologies for IPv4aaS discusses different use case scenarios for the five most prominent IPv4-as-a-service (IPv4aaS) transitional technologies, whilst NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks is an updated draft that 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.

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

Running in parallel on Monday morning is ROLL which focuses on IPv6 routing issues for low-power and lossy networks. This will be discussing an update ton the ROLL-BIER design that extends RPL to support routing based on Bit Index Explicit Replication (BIER) in environments with limited and lossy updates. There are also seven other drafts up for discussion, all related to RPL enhancements.

CFRG will be held during the late morning at 11.20 UTC+7. The group has yet to publish the agenda, but there’s a number of currently active drafts covering issues that include Public Key ExchangeThe Transition from Classical to Post-Quantum Cryptography, Randomness Improvements for Security ProtocolsRe-keying Mechanisms for Symmetric Keys, and Hash-Based Signatures.

There’s a choice of two sessions after lunch, starting at 13.50 UTC+7.

TLS holds the first of its two sessions (the second is on Wednesday afternoon) and has a number of important drafts up for discussion including the proposed DTLS 1.3 specification, and Connection Identifiers for DTLS, to avoid the need for additional handshaking upon NAT rebinding. There is also a proposal to deprecate TLS 1.0 and 1.1 as these versions lack support for current and recommended cipher suites.

Other drafts cover TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates, a TLS 1.3 extension that allows a server to authenticate with a certificate while also providing a pre-shared key (PSK) as an input, and definition of universal PSKs for TLS that use an extra key derivation step to reuse the same secret for all TLS 1.3 KDF hashes. In addition, a revised working group charter has been proposed.

DNSOP meets at the same time, and there’s a couple of interesting drafts worth mentioning. One outlines how run a root server instance on the same server as a recursive resolver in order to decrease access time, and another specifies a way of resolvers telling clients what its associated DNS-over-HTTPS (DoH) servers are.

6LO concludes the day at 16.10 UTC+7. This will be discussing drafts to update RFC 6775 to support registration extensions for simplifying these operations in 6LoWPAN routers, to update Address Protected Neighbor Discovery for Low-power and Lossy Networks, to update RFC 4944 with a simple protocol to recover packet fragments over a mesh network, as well preparing the IPv6 Backbone Router draft for a Working Group Last Call. The session will be rounded-off with a performance report on fragment forwarding and recovery.

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

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: 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

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 7 November 2018, 09:00-11:00 ICT, Meeting 1

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 8 November 2018, 13:50-15:50 ICT, Meeting 2


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.

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

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> a +dnssec

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

dig @ 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 2606:4700:4700::1111 Cloudflare 2001:4860:4860::8888 Google DNS 2620:fe::fe Quad9 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.

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 and

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 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

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


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