2018-10-23 - Progress - Tony Finch
Last week I visited Amsterdam for a bunch of conferences. The 13th and 14th was the joint DNS-OARC and CENTR workshop, and 15th - 19th was the RIPE77 meeting.
I have a number of long-term projects which can have much greater success within the University and impact outside the University by collaborating with people from other organizations in person. Last week was a great example of that, with significant progress on CDS (which I did not anticipate!), ANAME, and DNS privacy, which I will unpack below.
- About the meetings
- CDS: background
- CDS: my contributions
- CDS in Amsterdam
- ANAME: background
- ANAME: my contributions
- ANAME in Amsterdam
- DNS privacy: background
- DNS privacy: my contributions
- DNS privacy in Amsterdam
- Conclusion
About the meetings
The DNS Operations Analysis and Research Centre holds peripatetic workshops twice a year, typically just before an ICANN or RIR meeting. They are attended by root server operators, TLD operators, large DNS service providers, DNS software suppliers, and others. CENTR is the association of European country-code TLD registries.
The RIPE NCC is the regional Internet registry for Europe and the Middle East. Earlier this year, the University of Cambridge became a local Internet registry (i.e. an organization responsible for sub-allocating IP address space) and as new members we got a couple of free tickets to attend a RIPE meeting. As well as a significant proportion of the DNS-OARC crowd, the RIPE meeting included a lot more network operators, academic researchers, and IETFers.
Both DNS-OARC and RIPE meetings are technical conferences that regularly include a lot of material that's highly relevant to my work; RIPE of course has a much broader agenda across network operations. I recommend having a look through the DNS-OARC 29 presentation archive and the RIPE77 presentation archive because I will only mention a few key items here.
I also wrote daily notes on my personal blog: Fri Sat Sun Mon Tue Wed Thu Fri; this report has a few highlights from those notes.
CDS: background
One of the pain points the University shares with other DNSSEC sites
is the difficulty of managing DNSSEC keys. Partly this is due to gaps
in the functionality of tools (though this is improving), but more
challenging are the poor interfaces available for keeping secure
delegations up-to-date, typically either a bespoke API (such as
RIPE's) or no API at all (such as for .ac.uk).
CDS records (RFC7344, RFC8078) are a mechanism for automating DNSSEC delegation maintenance that does not need any extra APIs or credentials. It has the potential to greatly simplify operations, if it is deployed.
CDS is not yet widely adopted: the only registries I know that support
it are .ch (Switzerland) .li (Liechtenstein) and .cz (Czechia).
CDS: my contributions
Last year, I wrote dnssec-cds to implement the parent side of the
CDS protocol, which is part of the tooling we need within the
University for managing delegations to the Computer Laboratory, Maths,
and others. I contributed dnssec-cds to BIND 9.12 so that ISC
can take over maintenance, and with the hope that it would encourage
wider deployment.
CDS in Amsterdam
In Amsterdam I met Ondřej Caletka of CESNET (the Czech national research and education network) who has done some work on using CDS records to drive updates via the RIPE database API, which he presented in the RIPE77 DNS-WG meeting.
I also met Anand Buddhdev who is in charge of the RIPE NCC's DNS services. (He presented a status update to the DNS-WG.) Anand encouraged me to voice support for Ondřej's work, with the aim of getting consensus for a policy change, so that RIPE NCC will implement CDS checking for reverse DNS zones.
There is a good chance that this will happen, which will be a nice simplification to our operations, and CESNET's, and others in the RIPE region.
ANAME: background
Another commonly-felt DNS awkwardness is the restriction on how CNAME records can be used. This makes it needlessly difficult to set up web sites, adding to our support overheads. It makes our database schema and API more complicated than necessary.
There are a number of proprietary extensions to the DNS which work around this problem, called things like "ANAME", "ALIAS", "CNAME flattening", etc. (but not to be confused with the different thing that the IP Register database calls an "aname"). Since last year the IETF DNSOP working group has been developing a standardized version of ANAME.
ANAME: my contributions
Earlier this year it became clear that no-one liked the ANAME draft, including its authors. Eventually, I proposed a radically [simplified ANAME][], which was generally viewed as a good improvement. So I have taken over as principal author and editor of the ANAME draft.
ANAME in Amsterdam
I completed the initial rewrite of the draft shortly before going to Amsterdam. While I was there I discussed it with several people (especially Evan Hunt, the previous author!), getting some good suggestions for improvements. I also spoke to staff from a number of DNS vendors who have proprietary ANAME-like features; they are generally keen on the idea of standardization, improving interoperability, and the opportunity to reduce technical debt.
The IETF DNSOP working group chairs are very supportive of this effort. There's still a fair amount of work remaining, but it looks like there's a reasonable chance of success.
DNS privacy: background
In recent years the IETF has stepped up its efforts to encrypt all the things. The [DNS privacy] project is leading the encryption effort for the DNS, along with other privacy-enhancing improvements.
These changes are going to have a big effect on DNS operations, by moving traffic off UDP on port 53 to encrypted transports on other ports.
DNS privacy: my contributions
I have written an implementation of DNS-over-TLS and DNS-over-HTTPS called doh101, which is running on the University's DNS resolvers.
DNS privacy in Amsterdam
I presented a lightning talk at the DNS-OARC meeting to give some idea of the number of people who are already using DNS-over-TLS (dozens of people in Cambridge, but less than 1%).
There was much valuable discussion of the consequences of DNS privacy, intended or not, especially following the talks from Sara Dickinson (one, two, three) and Ólafur Guðmundsson (four, five). There may be some useful measurements we can make, even though our traffic levels are small - I got some good suggestions from Florian Streibelt (thanks to Theresa Enghardt for introducing us).
Conclusion
This was just the main highlights of the week; there were also a number of other useful take-aways, which I will not repeat here (see the links to my daily notes above). It was a busy and productive trip!