As happened earlier this year at IETF 102 in Montreal, DNS privacy will receive a large focus in the DNSOP, DPRIVE and DNSSD working groups. Given the critical role DNS plays as part of the “public core” of the Internet in linking names and identifiers to IP addresses, the DNS must have stronger security and privacy controls. As part of our Rough Guide to IETF 103, here’s a quick view on what’s happening in the world of DNS.
Note – all times below are Indochina Time (ICT), which is UTC+7.
DNS Operations (DNSOP)
The DNS sessions at IETF 103 start on Monday afternoon from 13:50-15:50 with the DNS Operations (DNSOP) Working Group. As per usual, DNSOP has a packed agenda. The major security/privacy-related drafts include:
- DNS query minimisation – draft-ietf-dnsop-rfc7816bis – Back in 2016, RFC 7816 defined an experimental way to increase DNS privacy and limiting the exposure of DNS query information by simply not sending the entire query all the way up the DNS resolver chain. This new work is to move that RFC 7816 document from being an experiment to being an actual Internet standard.
- Running a DNS root server locally – draft-ietf-dnsop-7706bis – Another way to increase DNS privacy is to not send queries up the DNS resolver chain to the root by running your own local copy of the root DNS servers. Back in 2015, the informational RFC 7706 defined how to do this and specified running it on the “loopback” interface of your local computer. This new work broadens that to allow the local copy to run more generally on local systems. At the recent ICANN 63 meeting in Barcelona, this was discussed as “hyperlocal” copies of the root zone of DNS. Wes Hardaker at ISI also has a site about this effort: https://localroot.isi.edu/ Not only could this increase privacy, but also resiliency of the DNS system. However, it is not without its critics and so there could be a good discussion in Bangkok.
- Serving stale data to increase DNS resiliency – draft-ietf-dnsop-serve-stale – This project is setting up the criteria for when DNS resolvers could continue to use DNS data even after the Time To Live (TTL) expires. Basically, if you can’t reach an authoritative server for some reason, under what conditions could you continue to serve the records you previously retrieved from that server?
If there is time in the session, Paul Hoffman’s draft-hoffman-resolver-associated-doh may come up for discussion. This relates to the somewhat controversial DNS Over HTTPS (DOH), now defined in RFC 8484, that lets an app such as a web browser send DNS queries over HTTPS to a DOH server where the DNS resolution can occur. The controversy with DOH is primarily two points: 1) it lets an application 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:
- http://www.internetsociety.org/deploy360/dnssec/
- http://www.internetsociety.org/deploy360/resources/dane/
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: https://datatracker.ietf.org/group/dnsop/about/
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: https://datatracker.ietf.org/group/dprive/about/
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: https://datatracker.ietf.org/group/dnssd/about/
Follow Us
It will be a busy week in Bangkok, and whether you plan to be there or join remotely, there’s much to monitor. Follow us on the Internet Society blog, Twitter, or Facebook using #IETF103 to keep up with the latest news.