The Men & Mice Blog

The RIPE-javik logs: Day 4 - Part 2

Posted by Carsten Strotmann on 5/25/19 2:25 PM

ripe day 4_2carsten@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.

Topics: DNSSEC, DNS, DNS privacy, DNS-over-HTTPS, unwind

DNS Privacy: DNS-over-HTTPS

Posted by Men & Mice on 4/16/19 5:24 AM

DNS-over-HTTPS (DoH for short) is a standard developed by the IETF (under the RFC 8484 designation) to solve privacy concerns in DNS communication.

DNS Privacy: a primer

As we’ve talked about before, using DNS has been done in cleartext: the queries and responses between both the end user (applications, or stub resolvers, such as a browser) and the (first-hop) DNS resolver and the resolver and the DNS nameserver(s) are unencrypted by default.

While DNSSEC extensions were developed early on, they only added response integrity and not privacy. As IETF states, “either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private.

In recent years, however, that changed. Privacy has become a central concern and addressing it has spawned numerous solutions, such as DNS-over-HTTPS (DoH).

DNS-over-HTTPS

DoH conducts DNS operations using secure http urls and mapping DNS queries and responses into http exchanges, using default media formatting types.doh

While DoH uses existing protocols for communication, the IETF emphasizes that “[The] described approach is more than a tunnel over HTTP.” Aligned with existing http features, DNS servers and clients supporting DoH are called ‘DoH server' and ‘DoH client’ respectively, as they can be used for more than only DNS.

While DNS-over-HTTPS and DNS-over-TLS are colloquially used as different protocols, because DoH uses https it also includes TLS security. The key difference between DoH and DoT is the manner in which DNS operations are conducted.

DoH in action

DoH clients are configured with a URI template containing the url structure for DNS resolution. The client then uses a GET or POST method to send an encoded DNS query.

DNS-over-HTTPS uses standard https traffic (via port 443) to communicate. Because DNS communication is done through standard https methods and resides within https traffic, overhead for DoH is low.

DoH challenges

DNS-over-HTTPS is a newer protocol than DNS-over-TLS. DoH has had less testing and research than DoT, but because it aligns with https as an underlying transport protocol, it is less susceptible to issues other than those associated with https itself.

DoH, though still young, has successfully leveraged the existing ecosystem of native web applications and APIs. It can create more efficient (and private!) communications with DNS.

Arguments against DNS-over-HTTPS (in its current form) stem more from operational considerations. Whereas DoT can be controlled because of its use of a single and unique port, DoH is almost impossible to control or filter.

DNS privacy (DoH, as well as DoT and other solutions) is a good representation of the operational shifts network managers and architects face. DNS-over-HTTPS in particular is a solution born from a public networking mindset. Traditional corporate network operations that are increasingly dependent on cloud services and experience an influx of connected devices through IoT and BYOD, have to re-adjust.

But DNS privacy also means that the opportunity for corporate network managers and architects is more pertinent than ever before. DoH, DoT, and other solutions are young and still forming. Whereas the question before centered around ‘adoption’ of protocols, these new technologies offer a chance to ‘influence’. Ongoing participation in the conversation and debate over the merits and shortcomings of each is necessary.

Additionally, pilot programs, particularly those run in regulated, corporate environments, are invaluable to both the developers of DNS privacy solutions as well as the network managers and architects who will be charged with implementing it.

Topics: DNS privacy, DNS-over-HTTPS

Why follow Men & Mice?

The Men & Mice blog publishes educational, informational, as well as product-related material for everyone and anyone interested in IP Address Management, DNS, DHCP, IPv6, DNSSEC and more.

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all