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

The Men & Mice Guide to RIPE-javik

Posted by Men & Mice on 5/15/19 7:40 AM

RIPE 78 is barely a week away! We feel it's our duty, both as locals to the city and as sponsors to the event, to compile a guide to help you make the most  of your stay.

ripe

What to attend at RIPE

You're coming to attend sessions and talks at RIPE, so let us start there. There'll be an excellent lineup of speakers, making it hard to choose. May we suggest starting with Carsten Strotmann?

Carsten has been supporting customers with Unix and PC/Windows networks in Germany and abroad for more than 27 years. His specialties are Unix systems, DNS, DNSSEC and IPv6 security. He's a trainer in the field of DNS/DHCP/IPv6/Linux/Unix security for Internet Systems Consortium (ISC), Linuxhotel and Men & Mice. He also is the author of various articles on IT security topics in specialist magazines.

Carsten will give two talks at RIPE:

  1. Unwind, a Validating DNS Recursive Stub-Resolver: a short introduction on what unwind(8) is, and how this always-running, validating DNS recursive nameserver on OpenBSD can help to secure DNS name resolution for mobile devices and laptops in hostile public networks.
  2. Overview of the DNS Privacy Software landscape: new DNS privacy protocols have sparked a number of new open source software tools that make use of DNS-over-TLS and DNS-over-HTTPS - however, functionalities and software quality differ greatly. This talk will give an overview of available tools, the functions they provide and their availability on popular operating systems and also a brief look on missing pieces in the DNS privacy software landscape.

Apart from the Plenary and BoF (Bird of a Feather) Sessions and Tutorials, RIPE78 features no less than 10 Working Group sessions, on DNS, IPv6, IoT, Open Source, Anti-Abuse and more.

Talks and sessions not to be missed include:

  •        Tutorial by Enno Rey on IPv6 Security for Enterprise Organisations (Monday, 20 May)
  •        The plenary session dedicated to current DDoS threads and how to mitigate them (Tuesday, 21 May),
  •        High Performance Traffic Encryption on x86_64 (Max Rottenkolber), part of the Open Source Working Group Agenda (Wednesday, 22 May)
  •        IPv6 reliability measurements (Geoff Huston) and Large-scale Deployment of IPv6-enabled Wi-Fi Hotspots (Enno Rey) – both on Thursday, 23 May
  •        Revisiting the Root (David Hubermann, ICANN), Long-Term Active Measurements for DNS Research, and That KSK Roll (Geoff Huston) – all on Tuesday, 21 May

Diversity engagement: Women in Tech Panel at RIPE78

Sponsored by Netflix with additional support from Men & Mice and WomenTech Iceland, RIPE78 will also host a Women in Tech diversity panel discussion on the 21st of May, on which our own Paula Gould will join panelists from GRID, WuXi NextCode and Lady Brewery.

Paula is the Head of Brand & Communications for Men & Mice, and has worked with IT companies for over 15 years on go-to-market, growth, and brand strategies. She founded WomenTechIceland, and has been deeply involved in notable international women-in-business and women-in-tech initiatives for two decades.

women in tech ripe

After hours: making the most of RIPE-javik

Good times don't stop at the end of the official schedule. We’ve compiled seven useful tips to make your stay during RIPE78 as pleasant as possible. (And also financially sensible.)

  1. Leave your umbrella: OK, maybe not if it’s Cisco, but if it’s one of those hand-held thingies, you may want to just let it go. There can be unexpected gusts of winds, and unless you want to re-enact Mary Poppins, there are other better (and warmer) ways to get around.
  2. Entertainment: If you want to have a good laugh at the end of a long day of DNS and IP addresses, the Secret Cellar does comedy in English every evening in a cellar on Lækjargata, smack in the middle of downtown Reykjavík.
  3. Non-alcoholic beverages: An indisputable must in almost every Icelander’s daily life is coffee: the stronger, the blacker, the better. And if you’re feeling out of sorts on your visit, why not coffee and a cat? The Cat Café, home of outstanding coffee and four-legged creatures, offers you just that.
  4. Alcoholic beverages: If coffee is not your thing, beer easily rates as the other staple Icelandic beverage. Icelanders have caught up quickly since the lift of the beer ban in 1989: these days, everyone and their brother is making their own. Micro-breweries are literally on every other corner and these bars offer an excellent selection.
  5. Hands-on fun: Beyond food and drinks, there's much else to be enjoyed in Reykjavik. You definitely can’t go wrong with karaoke Wednesdays at Sæta Svínið (The Sweet Pig) Gastropub, or Monday’s Ping Pong Tournament in "Miami". (The one on Hverfisgata, not Florida. But complete with tropical décor and cocktails to match.)
  6. Volcanic gifts: Iceland's so rife with geothermal water that we use it to heat not only our homes, but also our pavements and driveways. We love our water. And you haven’t really been to Iceland until you’ve shot the breeze with the locals in a ‘hot pot’ at one of the many public pools scattered around the country. (Note: to enter the pool area, you are required to shower naked and wash all the right spots thoroughly and with soap.)
  7. More about water: You're quite safe to drink the water from the tap in your hotel and don't hesitate to ask for tap water in restaurants. It’s pure, tastes fantastic and doesn’t cost you a krona. Bring a refillable water bottle for refreshing hydration no matter where you go.

See you at RIPE78 (come say hello to us in person or on social media) and have a great stay in Iceland!

Topics: DNS privacy, RIPE 78, Women in Tech

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

DNS privacy: DNS-over-TLS

Posted by Men & Mice on 4/10/19 11:05 AM

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

DNS Privacy: a primer

As we’ve talked about before, until recently,  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 the 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-TLS.dot

DNS-over-TLS

DoT approaches privacy by encrypting DNS queries and responses between entities (predominantly between the stub resolver and the first hop resolver) using TLS (Transport Layer Security).

DoT uses a standard port (853) to initiate and accept DNS queries. It is possible to use a mutually agreed different port, but it is not the default. Once the connection is made, a TLS handshake is attempted, and after authentication the encrypted DNS communication can commence.

DNS servers supporting DoT are not accepting unencrypted data on the designated port, neither during session initiation, nor after a failed TLS authentication.

DoT overhead

Computers are powerful and efficient, but not without limits. DNS-over-TLS adds latency to DNS operations that needs to be accounted for and minimized.

DNS clients are required to adhere to a certain field length (two octets) and it is recommended to keep established, but idle, connections alive to the server. Another way to minimize latency is to pipeline multiple queries over the same TLS session. In this case, it’s the DNS client’s responsibility to match responses to queries, as they may arrive and be answered out of order.

Keeping established connections alive helps distribute the connection setup costs. Misconfigured handling of idle connections can lead to denial of service issues.

Flavors of DoT

DNS-over-TLS can be used in various ways. The IETF standard identifies opportunistic and Out-of-Band Key-Pinned privacy profiles.

Opportunistic privacy profile means the client recognizes a TLS-enabled DNS resolver and attempts to use it. If it successfully validates it, DNS-over-TLS may be used, but isn’t mandatory and the client can fall back to non-encrypted DNS.

Out-of-Band Key-Pinned privacy profile is usable where the trust between stub and recursive resolvers is already established. Enterprise DNS is one good example. With this profile, DNS clients authenticate servers by a set of (previously distributed) SPKI Fingerprints.

DoT pros and cons

DNS-over-TLS addresses privacy, but not the security of DNS operations. It is important to note that DNSSEC and DoT are not mutually exclusive, but rather compatible protocols that complement each other.

DoT is a straightforward protocol, and fairly easy to implement. TLS authentication is a mature, trusted, and well-maintained technology for encryption. But DNS-over-TLS also presents a number of challenges and concerns.

Attacks against TLS itself, such as protocol downgrade, affect DNS-over-TLS. DNS resolvers offering DoT have to be aware and be patched against TLS vulnerabilities. DNS clients can, in order to defend against person-in-the-middle attacks, discard cached data from a server stored in cleartext.

DoT isn’t fully protected against traffic analysis and SNI leaks. (Although it is in constant development to patch these vulnerabilities.) Split horizon DNS, where the DNS response may be different based on the source of the query, is also known to experience issues when used with DoT.

Network managers for both private networks and public services need to learn more about DNS privacy, DoT (and DoH and other implementations), and the solutions, and challenges, they present for their work. Education about these protocols is also important for end users — both for owning their privacy and to avoid issues resulting from unintentionally harmful configurations brought to a network.

DoT, DoH, and other protocols are in constant development, offering ways to influence their evolution. All network managers and architects, whether they’re running public or private infrastructures, should participate in pilot programs to discover and best voice and address their challenges and requirements.

Topics: DNS-over-TLS, DNS privacy

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