Articles

The RIPE-javik logs: Day 4 - Part 2

Our coverage of Day 4 of RIPE78 has been divided into two parts.

May 25th, 2019

carsten@menandmice:~$ cat ~/ripe/ripejavik-day4.txt | blog-publish

Because it was so filled with information, our coverage of Day 4 of RIPE78 has been divided into two parts. Read Part 1 here.

DNS Working Group

During the DNS Working Group session, I gave two talks: first one on an Overview of the DNS Privacy Software Landscape and then another “lightning” talk on unwind, a validating DNS recursive nameserver.

At the beginning of May 2019, I started a survey of software projects implementing the new DNS privacy protocols: DNS-over-TLS (DoT) and DNS-over-HTTPS (doH). My questions were:

  • Are there software projects out there that use DoT and/or DoH?
  • In which year did development start?
  • Which programming languages have been used to implement the software?

The results of the survey were presented to the RIPE DNS Working Group and are as follows:

  • Of the 46 projects I found on Gitlab and Github, 21 were implementing DoT, 32 support DoH and 7 projects support both protocols.
  • The majority (29) of the projects implemented the new protocols in 2018 and there are 9 new projects this year. At the moment, I am finding 1-2 new projects every month.
  • A large number of newly created projects use the Go programming language (17), while most established projects that added DoT/DoH to their products use C/C++ (15). There were also projects using Rust, Python, Ruby, Java and JavaScript (via NodeJS).

I was also interested in the liveliness of the projects and looked if there was any activity in the project over the last half a year, e.g. new code checking or issues tracker activity. The majority of projects are active (32) while some are dormant (14). The complete list of projects can be found here.

In the second talk, I provided some information on "unwind", a DNSSEC validating resolver for laptops running OpenBSD. For mobile computers, it is a challenge to get a secure DNS name resolution, as most DNS resolvers in wireless networks don't do DNSSEC validation and are not trustworthy. Unwind implements a DNS resolver that runs on the local machine, listens to the loopback IP addresses and either does direct DNS resolution into the Internet, or forwards the request to a trusted resolver via DoT or classic DNS (UDP/TCP).

Many WiFi networks have a captive portal that prevents direct access to the Internet, and therefore to the DNS of the Internet. unwind can be configured to detect such a situation and will switch to the DHCP supplied resolvers, with the sole purpose of getting through the portal. Once the direct access to the Internet is available, unwind switches back to secure DNS communication.

DNSSEC keytags

In the next presentation, Roland van Rijswijk-Deij (NLNetLabs) presented his research on the DNSSEC keytags he found in the OpenINTEL dataset.

Every DNSSEC key has a 16-bit number (between 0 and 65525) that helps DNS resolvers to find the correct key in a DNSSEC signed zonefile. The keytags are generated by applying a simple and fast algorithm (first standardized in RFC 2535).

In 2016, Roy Arends from ICANN already noted that the keytag numbers are not evenly distributed. This is because RSA DNSSEC keys have a structure, and some parts of the key are not random. Roland took the large data collection he has in OpenINTEL and looked at the RSA DNSSEC keys seen there.

The real world data confirms the observations in the initial experiments with DNSSEC keytags: for RSA DNSSEC keys, some keytags are never generated, and the numbers follow a structure. Also, the crypto-library used to generate the RSA keys influence the key tags, as OpenSSL has some safeguards for weak keys that other libraries don't implement.

Next, Roland looked if there are keytag collisions, where the same keytag appears in a zone twice or more for different keys. He found very few collisions, actually less than predicted by theoretical probability.

Then he tested what would happen if keytags are generated by a different algorithm that guarantees uniform distribution of the numbers (in this case CRC16). Turns out then there would be more collisions (still very few, but more nonetheless). Possibly, and without aiming to, the authors of the DNSSEC RFC chose a better algorithm.

RIPE-javik winding down

This concludes the second to last of our daily reports on RIPE78, but by no means does it signal the end of our RIPE-related coverage. Stay tuned for Day 5 tomorrow, and much more deep industry talk in the weeks to come.