OARC 37 (Austin, TX, USA)

Thursday 17 Feb 2022, 15:00 → 22:15 UTC

Marriott Austin Downtown

Keith Mitchell (DNS-OARC), Pallavi Aras (Salesforce), Willem Toorop (NLnet Labs)

OARC 37 is currently planned to be a hybrid in-person and online workshop.

OARC 37 will be held on Thursday 17th February, 2022 - the day after NANOG 84 ends in the same venue.

Delegates attending OARC 37 in person at Austin Marriott Downtown should note the Pandemic Safety Protocol.

DNS-OARC is a non-profit, membership organization that seeks to improve the security, stability, and understanding of the Internet's DNS infrastructure. Part of these aims are achieved through workshops.

DNS-OARC Workshops are open to OARC members and to all other parties interested in DNS operations and research.

Social Media hashtag: #OARC37

Mattermost Chatroom: Workshops on chat.dns-oarc.net (sign-up here)

---

WORKSHOP SPONSORS

---

 

Your company name here?

Sponsorship opportunities for OARC 37 are available. Details at:

https://www.dns-oarc.net/workshop/sponsorship-opportunities

---

OARC PATRONS 2022

Your company name here?

Annual Workshop Patrons for 2022 are available. Details at:

https://www.dns-oarc.net/workshop/patronage-opportunities

 

---

 

15:00 In Person Attendees Registration & Coffee

OARC 37 Day 1: Session 1

Main Session

1 Welcome and Information

Speaker: Mr Keith Mitchell (DNS-OARC)

Information.odp

Introduction to DNS-OARC

OARC37-intro.odp

Welcome and Information

2 Find Bugs in your DNS Zone files Before Deployment with GRᴏᴏᴛ

Given the DNS’s critical role in today’s Internet, any errors in zone files can have highly disruptive effects on related services. For example, Microsoft experienced a severe global outage in 2019, impacting all Azure customers for two hours due to a DNS misconfiguration. Other major DNS-related outages include those at Slack, Salesforce, GitHub, LinkedIn, iFastNet, and HBO.

To help DNS engineers prevent outages, we developed GRᴏᴏᴛ, the first tool that performs static analysis of zone files to validate properties of interest for all possible DNS queries or provide a counterexample. DNS engineers can use GRᴏᴏᴛ before deploying or updating zone files to catch any bugs in them, such as rewrite loops, black holes, etc., whereas the existing solutions are reactive and incomplete. GRᴏᴏᴛ efficiently analyzes the huge space of DNS queries by partitioning all possible queries into equivalence classes (ECs), where all the queries in the same EC are guaranteed to have the same behavior. GRᴏᴏᴛ then symbolically executes each equivalence class to efficiently find (or prove the absence of) any bugs.

We applied GRᴏᴏᴛ to the configuration files we obtained from a large campus network with over a hundred thousand records, and it revealed 109 new bugs and completed in under 10 seconds. When applied to internal zone files consisting of over 3.5 million records from a large infrastructure service provider, GRᴏᴏᴛ revealed around 160k issues of blackholing, which initiated a cleanup of the zone files.

Speaker: Mr Siva Kesava Reddy Kakarla (University of California, Los Angeles)

GRoot_OARC.pptx

16:40 30 minutes break

30 minutes break

OARC 37 Day 1: Session 2

Main Session

3 Adaptive DNSSEC

Several different DNSSEC configurations have been suggested in recent years in an attempt to address different security and privacy issues in the DNS system. In this presentation we briefly review, and analyse the performances of different configurations using a baseline throughput measurement (based on DNSPERF). We show that while each configuration serves an important role by solving some issues (e.g.: Zone Walking, Scalability for Large Zones), the overall throughput of the system is degraded, and this opens the door to DDoS amplification attacks due to the much larger message size, and extra cryptography computations.

Our goal is to design and implement (PoC level implementation) of a high throughput communication link between DNS resolver and authoritative servers that provides proof of authenticity and at the same time disables zone waking attacks. The motivation is to provide the same level of security as DNSSEC without the poor performances that come with it during a flood of NX requests attack, and without opening the door to zone walking attacks.

We designed and implemented an adaptive communication protocol between recursive resolver and authoritative servers with the above properties. We implemented a PoC that works (with Knot servers) at a throughput close to that of the standard DNS protocol, w/o DNSSEC (20,500 rps, requests per second, compared to 23,500 rps in plain DNS). We note that if one is willing to scarify and enable zone walking attacks, then a much higher throughput solution is possible as demonstrated by the NSEC3 aggressive caching implementation in Knot.

Speaker: Mr Daniel Dubnikov (Tel Aviv University)

OARC37 - AdaDoQ.pdf

OARC37 - AdaDoQ.pptx

4 Post-Quantum DNSSEC: FALCON Signatures in PowerDNS

We present the first implementation of post-quantum DNSSEC. As a prototype, we extended PowerDNS authoritative DNS server and recursor to sign, serve, and validate DNSSEC-signatures based on the FALCON signature scheme.

A high-level overview of the implementation work, which is based on a modification of the OpenSSL post-quantum fork, will be given, and statistics on performance and packet sizes of our test-bench setup are presented. Finally, we consider arguments around the necessity of post-quantum signatures in DNSSEC in general.

Speaker: Nils Wisiol (deSEC e.V.)

Post-Quantum DNSSEC with FALCON-512 and PowerDNS(2).pdf

5 Internet Survey of DANE/TLSA DNS Records: Application and Use for Mail Exchanger

We have performed an Internet survey to extract the DANE/TLSA
records in the DNS which are foreseen to indicate TLS capabilities and
to enable X.509 certificate fingerprinting for MX services. Their partic-
ular use and the application scenarios for DANE records are analyzed
on a wide scale base indicating the acceptance of policy information in
the DNS giving security recommendations for Mail Exchangers

Speaker: Dr Erwin Hoffmann (Frankfurt University of Applied Sciences)

TLSA_DANE_Usage.pdf

18:15 90 minutes break

90 minutes break

OARC 37 Day 1: Session 3

Main Session

6 Implementing dual stack recursive DNS at Microsoft: Challenges and Learning

Microsoft has implemented a dual-stack recursive resolver system for its internal resolver fleet. This talk focuses on learning and the challenges we faced during this process.

We will cover below items
- Implementing dual-stack recursive DNS using Unbound and Windows DNS Server
- Learnings/Issues encountered to achieve dual-stack
- Implementing serve-stale data from the cache (RFC 8767) in Unbound - Experience in production

Speakers: ARUNKUMAR SINGARAM (Microsoft), Karthik Umashankar

Increase DNS resolver resiliency.pptx

7 Updating Requirements for Caching DNS Resolution Failures

In October 2021, a large social media platform experienced a widespread outage of its network. In this presentation, we will show how the outage led to a significant traffic increase on Verisign's authoritative name servers. Furthermore, we will show how this incident is similar to other events and conditions, and discuss our proposal for stricter protocol requirements on negative caching of DNS resolution failures.

Speaker: Duane Wessels (Verisign)

updating-requirements-for-caching-dns-resolution-failures-v4.pdf

20:25 35 mins break

OARC 37 Day 1: Session 4

Main Session

8 Beta Availability of two TLD Data Products

Two data products are being made available for beta testing. The TLD Apex History data set contains the history of DNSSEC-related records published by TLDs since mid-2011. The DNS Core Census (v010) is a daily aggregation of metadata related to TLDs and other zones in the upper reaches of the global public DNS hierarchy. This presentation will cover the data, how it is assembled and how it is made available. Both data products are intended for use as part of other research projects and are updated on a daily basis. These data products are publically available over-the-web. The beta-nature of this work is in anticipated discussion over content, storage and other data product packaging needs.

Speaker: Edward LEWIS (ICANN)

Beta Availability of two TLD Data Products.pdf

Beta Availability of two TLD Data Products.pptx

9 IP Fragmentation and DNS-Cache-Poisoning

There are several attack methods aimed at the DNS, and most of them
are well understood, with mitigations already deployed. One relatively
new attack method abuses IP Fragmentation to circumvent some of the
mitigations and security features currently built into DNS software.

Previous research has shown that it is possible to use fragmented DNS response
messages to implant false or manipulated data into a DNS resolver’s cache.
DNS Fragmentation attacks require certain preconditions in order to be
successful. While it is known that cache poisoning through DNS
fragmentation is technically possible, prior to this study it was
unclear whether or not the necessary preconditions occur frequently in
the Internet. Therefore, it was equally unclear whether this attack
vector even poses a real and relevant threat. Additionally, while
mitigations had previously been discussed, their effectiveness and
their performance impacts had not been studied in detail.

The research presented in this talk tested the preconditions from two
points of view:

• From the perspective of the authoritative DNS Server: The study
  probed millions of authoritative DNS servers deployed in the
  Internet to determine if these servers respond with relatively large
  DNS messages that are prone to fragmentation. The domains from which
  we received fragmented responses were weighted against the Tranco
  list, containing the Internet’s most popular 1 million domains. This
  measurement found that while naturally occurring fragmentation in
  the Internet is infrequent, it is not completely irrelevant –
  especially as it also affects highly popular domains.

• From the perspective of the DNS resolver: The DNS traffic of a large
  ISP in Germany was monitored for a period of 24 hours, in order to
  measure how many fragmented DNS responses are seen in real Internet
  traffic. It was confirmed that DNS fragmentation really occurs in
  productive environments.

As fragmentation attacks mostly target DNS traffic sent over the
sessionless UDP protocol, one proposed mitigation strategy is to
switch regular DNS resolution from UDP to TCP. To evaluate the
potential of this mitigation method, the study looked into the number
of authoritative DNS servers deployed in the Internet that support DNS
over TCP. While DNS over TCP has been already mandated by the Internet
Protocol Standards for more than 10 years now, our measurements show that a
significant number of DNS servers still do not support TCP.

As a by-product of this study, the measurements mentioned above found
that a significant number of authoritative DNS servers in the Internet
run on comparatively old Linux operating systems. While these "long
term support" Linux systems are still officially maintained by their
respective vendors and therefore receive security patches, certain
default settings included in contemporary Linux kernels – some of
which would prevent successful DNS fragmentation attacks – are not
present. The analysis found that running long-term support
"enterprise" Linux systems can actually increase the risk of security
issues, even if these systems are fully patched and maintained.

Knowing that DNS fragmentation attacks are a real threat on the Internet, the
study looked into additional possible mitigation strategies. Because these
might have a negative side effect on the operation of DNS or the performance of
DNS name resolution, they were tested in detail in a laboratory environment
that mimics the structure of the real DNS, including Root-DNS, top-level
domains, and second-level domains.

Speaker: Carsten Strotmann

dnsfrag-dnsoarc-2022.org

Frag-DNS-OARC-2022.pdf

10 An idea of IP anycast analysis using DITL dataset

All Root Servers use IP anycast and operate root DNS servers at many locations in the world. This talk proposes an idea of IP anycast analysis using the DITL dataset.
To analyze the effect of IP anycast, we need to know the location of each instance, location information of clients, and latency information between clients and root servers.
The location information of each instance can be extracted from the directory name of the DITL dataset.
The location information of clients can be extracted from query source IP addresses using IP map services. The latency information between clients and root servers is extracted from TCP queries.
Then, some results of the effect of anycast on M-root will be shown.
This approach may be used as searching the under-served area of root DNS servers (and TLD DNS servers).

Speaker: Kazunori Fujiwara (Japan Registry Services Co., Ltd)

short-20220215.pdf

11 Wrap up

Speaker: Mr Keith Mitchell (DNS-OARC)

Wrap-Up