Introduction to DNS-OARC (Public Workshop)

• Keith Mitchell (DNS-OARC)

Room: Ballroom 1

DNS Recursive Resolver Delegation Selection in the Wild (Public Workshop)

• Kyle Schomp (Akamai Technologies)

Room: Ballroom 1 DNS zones should have multiple nameservers. Combined, RFC 1034 and RFC 2182 require that zones have at least two topologically and geographically distributed nameservers. A primary reason for multiple nameservers is to increase robustness in the face of individual failures. Thus, many zones including those considered critical to many enterprises operate with a large number of NS records per zone. This provides recursive resolvers with a choice: which nameserver to contact when sending each DNS query? Previous research has studied the behavior of specific recursive resolver software in the lab and the behavior of recursive resolvers in the wild using synthetic traffic loads. This previous work shows that many recursive resolvers will attempt to home in on the lower RTT nameservers and prefer sending DNS queries to them. In this work, we look at the recursive resolvers’ choice of nameserver under production workloads of several zones important to the Akamai platform. We observe how many and how significantly recursive resolvers prefer nameservers by RTT given real world DNS query rates. We go on to consider the impact that this has on performance and security with an eye toward improvements that can be made.

Developing a Testbed For Interactions Between Resolvers and the Root (Public Workshop)

• Paul Hoffman (ICANN)

Room: Ballroom 1 At RSSAC's request, the RSSAC Caucus is developing a testbed to simulate resolvers interaction with the root servers. The initial areas of inquiry that were requested by RSSAC are root server selection, priming, and caching, but more areas might be tested later. The testbed will consist of copies of many versions of open source resolvers as well as the ability to test other resolver software such as Windows Server. It will also have mechanisms to model delays between a resolver and the 13 root servers, as well as different contents of the root zone (such as signing with different DNSSEC algorithms). The development of this system has started, but it is not complete. Instructions for setting up the test bed are open, and it is expected to be completed in fall 2019. This presentation covers the testbed design, components of the testbed, current status, how researchers can participate in the development of the testbed, and the plan for completing the testbed and running the first sets of simulations.

The Modality of Mortality in Domain Names (Public Workshop)

• Paul Vixie (Farsight Security)

Room: Ballroom 1 Domain names established for routine use are typically registered for one or more years, and faithfully renewed thereafter. Knowing nothing else, we'd expect that a domain existing today will still be there tomorrow. This is an expectation of 'domain continuity'. Other domains get treated as effectively being 'disposable'. Those domains get registered, quickly abused for cybercrime-related purposes (such as spamming, phishing, malware distribution, etc.), and are then abandoned after becoming unusable due to being blacklisted or 'held' by registrar action. In this study, we've obtained an ongoing feed of 'Newly Observed Domains' from Farsight Security's SIE, and then periodically probed those names from global measurement points to determine: What fraction of new domain names 'die a premature death' due to being blocklisted or suspended? What causes the 'death' of those domains? Do they mostly get blocklisted? Or do they 'die' due to action by registrars or others? What does the survival curve for those names look like over time? Are there differences between the traditional gTLDs, ccTLDs and ICANN's new gTLDs? Vixie will address these topics and make recommendations as to how to reduce domain name abuse.

DNS Security: Past, Present, and Future (It’s Not Easy) (Public Workshop)

• Ralf Weber (Nominum Inc)

Room: Ballroom 1 DNS and security have a long sometimes adverse relationship. The last decade was mostly securing the authenticity of DNS data with DNSSEC. After several tries it got slow operator uptake even as new attacks on the DNS were discovered. After the 2014 Snowden revelations the focus shifted to securing the DNS transport channel. The formation of the IETF dprive working group brought fresh ideas and people into the DNS community and resulted in the release of DNS over TLS (RFC 7858) followed by the doh working group releasing DNS over HTTPs (RFC 8484). We’ve always had documentation or problems with definitional scope with new standards and in this case there will be a need for new operational practices. This talk will describe issues we’re likely to encounter and discuss ways we might deal with them (or not!) in the future.

Who Is Answering My Queries: Understanding and Characterizing Interception of the DNS Resolution Path (Public Workshop)

• Chaoyi Lu (Tsinghua University)
• Baojun Liu (Tsinghua University)

Room: Ballroom 1 DNS is a critical service for almost all Internet applications. Since almost all DNS queries are sent in plain-text, it’s possible for transparent proxies to intercept DNS queries sent to public resolvers, and surreptitiously respond using alternative resolvers instead. However, this kind of hidden interception can introduce privacy and security issues to client users. Understanding the characterizes of hidden DNS interception is by no means trivial. It’s very challenging to observe interception because we need vantages points sharing the same network with interceptors. We solved this problem by re-targeting the proxy and a popular security software used by a large number of real-world users to conduct the measurement study. In the end, we performed a first large-scale measurement study of on-path DNS interception and shed light on its scope and characterizes. In practice, we designed a novel approach to detecting interception and deployed a global measurement platform. As different transport protocols and various recursive servers are considered, our measurement study is achieved with good depth and breadth. The key observation is that, among the 3,047 ASes that we investigate, we find intercepted DNS queries in 259 ASes. Particularly, 27.9% DNS/UDP queries from China to Google Public DNS are intercepted. Our research provides a first large-scale study on DNS end-to-end violation. Our work delivers strong evidence of DNS interception and serves as strong motivation of deploying DNS-over-Encryption. After being published, our findings are reported by several well-known media, such as ACM Technews, The Register, and Hackread. Our paper also gets comments from Nick Sullivan, head of cryptography at Cloudflare, that “this paper accelerates the need to transite DNS from an unencrypted protocol to one that protected by strong encryption and authentication technologies.”

Multi-signer DNSSEC Models (Public Workshop)

• Shumon Huque (Salesforce)
• Jan Včelák (NS1)

Room: Ballroom 1 Many enterprises today employ the service of multiple DNS providers to operate their authoritative DNS service. Two providers are fairly typical and this allows the DNS service to survive a complete failure of any single provider. Deploying DNSSEC in such an environment can have some challenges depending on the configuration and feature set in use. In particular, large enterprises often make use of a number of non-standardized DNS features, that necessitates having each provider independently sign the DNS zone data with a coordinated set of keys. We will present several operationally viable deployment models for multi signer DNSSEC. One of the goals of this talk is to generate interest in these models and encourage managed DNS providers to support them (encouragingly, several are already planning to do so), as this will solve an important deployment hurdle for enterprise DNSSEC. Additionally, it may be possible to leverage the multi-signer models to allow non-disruptive handoff of DNSSEC signed zones from one DNS operator to another. We now have an early implementation of some of the key management mechanisms needed to deploy the multi-signer models, and will share details of the implementation.

A Story on Unsupported DNSSEC Algorithms (Public Workshop)

• Matthijs Mekking (ISC)

Room: Ballroom 1 RFC 6944 provides an applicability statement on algorithm implementation status for DNSSEC component software. ince its publication new DNSSEC algorithms have arrived and recommendations on existing algorithms have changed. The IETF document draft-ietf-dnsop-algorithm-update plans to obsolete RFC 6944. DNS vendors are actively following the new implementation requirements. Can we expect issues when a server has removed support for a certain algorithm when another server is still actively using it? This presentation covers the expected and observed behavior of DNS servers when interacting with DNSSEC unsupported algorithms.

Signing with offline KSK in Knot DNS 2.8 (Public Workshop)

• Jaromír Talíř (CZ.NIC)

Room: Ballroom 1 CZ.NIC's DNSSEC operations involve signing with offline KSK. This has been traditionally managed by a set of shell scripts. DNS administrators for .CZ together with KnotDNS developers joined together to design and implement this functionality into the KnotDNS DNSSEC signer. This feature was released in KnotDNS 2.8. This presentation describes the feature in the context of current operations in .CZ.

Seeing the effects of DNS Flag Day in action (Public Workshop)

• Willem Toorop (NLnet Labs)

Room: Ballroom 1 DNS Flag Day is a collaborative effort and agreement of DNS implementers and DNS resolver operators, in which they have committed themselves to no longer provide work-arounds for non-standard compliant authoritative nameservers as of 1 February 2019. In the run-up to DNS Flag day, and as part of the outreach, the focus for measurements was always the authoritative nameservers that needed to be fixed. With this presentation we take the other perspective and have a look at public resolvers and resolver implementations. What was resolver behaviour on the Internet before DNS Flag Day, and how does the uptake of dropping work-arounds disseminate in the wild?

DNS flag day 2019 panel discussion (Public Workshop)

• Petr Špaček (CZ.NIC)
• Ondrej Sury (Internet Systems Consortium)
• Brian Hartvigsen (OpenDNS)
• John Todd (Quad9)
• Ólafur Guðmundsson (CloudFlare)
• Ralph Dolmans (NLnet Labs)
• Puneet Sood (Google)

Room: Ballroom 1 This panel discussion will focus on the 2019 DNS Flag Day effort, where vendors of major open source DNS resolvers and operators of several major public DNS resolver services committed to removing workarounds for incorrect behavior on the part of authoritative DNS servers that have failed to follow basic DNS protocol standards established two decades ago. The panel will include representatives of the software vendors and public resolver services. Topics to be discussed will include an assessment of the impact of Flag Day, lessons learned, and suggestions for what form a future flag day might take. Please [submit your questions](https://docs.google.com/forms/d/e/1FAIpQLSfXY1j4mzeEZ-U2lSuZk3OuEq3LMlUPnmdNkPhohakxTLrzuw/viewform) for discussion beforehand, it will help us to moderate the discussion.

The road to the Ultimate Stub-resolver (Public Workshop)

• Ólafur Guðmundsson (CloudFlare)

Room: Ballroom 1 Stub-resolvers do not got much attention in the DNS world. They are frequently dumb and simple, that is fine in some situations. Cloudflare operates systems all over the world that do lots of DNS requests, those requests are highly time critical with high reliability requirement. We have evolved the system from simple Unix stub resolver to resolver on each box, through a series of tiered setups. In each step of the way we tried to measure the performance impacts and document the failures we encountered on the way. In addition the modern DNS world with DNSSEC and new transports over DoT, DoH, DoQ really call for obsoleting the old style sub-resolvers. We will outline the basic operating principles for modern stub-resolvers based on our experiences, both corporate and personal, by operating or testing bind, dnssec-trigger, dnsdist, knot, stubby and unbound.

OpenINTEL - Creating a "long-term memory" for the global DNS (Public Workshop)

• Willem Toorop (NLnet Labs)

Room: Ballroom 1 In this talk we present the OpenINTEL project. The project started with the idea that we wanted to create reliable time series about the DNS once every 24 hours for as large a part of the name space as we could manage. Since we started measuring in February of 2015, we have grown our measurement to cover over 216 million domain names on a daily basis (approximately 60% of the global name space). It currently incorporates almost all gTLDs and a growing number of ccTLDs. We will explain why we want to collect this data, how we do this (responsibly) and provide examples of currently ongoing research that illustrates how this data can be used. The examples include 1) studies into DNSSEC operational practices that led to improvements in DNSSEC incentive schemes, 2) ongoing work on DNS resilience and 3) the stupidest thing we could find in a TXT record. With this talk we also hope to reach out to ccTLD operators to convince them to contribute data to our project.

DNSKEY Flood what does that tell us about resolvers (Public Workshop)

• Ólafur Guðmundsson (CloudFlare)
• Ray Bellis (Internet Systems Consortium, Inc.)

Room: Ballroom 1 When ICANN rolled over the KSK for the first time in October 2018 things apparently went smoothly with only a few minor incidents reported, but after a while it became evident that some resolvers did not like the rollover. This can be measured by looking at the DNSKEY queries from those resolvers which in some cases have increased by 100x at F-root. Some of those resolvers in this process expose a number of interesting behavioral patterns. In some cases this may expose the query frequency and in others the upstream selection algorithm. We will explain the patterns using data collected by a subset of F-root instances around the world and look at geographical differences. In some cases this may expose the query frequency and in others the upstream selection algorithm.

KSK Rollover Post-Analysis (Public Workshop)

• Duane Wessels (Verisign)

Room: Ballroom 1 October 2018 saw the culmination of a years-long project to roll the root zone DNSSEC Key Signing Key. More recently, the old KSK was published as revoked. In this presentation we use passively and actively collected datasets to explore how validating recursive name servers were impacted by the root zone KSK rollover and revocation. This data includes RFC 8145 trust anchor signals, query traffic to root servers, and "root canary" measurements made via RIPE Atlas probes. While the rollover and revocation are generally perceived to be a non-event, our data shows some significant changes in behavior by individual DNS clients that may have impacted end user queries. These analyses and techniques may be useful in planning and conducting future KSK rollovers.

Local DNS Policy Disclosure: Comments on Automating Policy Discovery (Public Workshop)

• David Dagon

Room: Ballroom 1

What part of “NO” is so hard to understand? (Public Workshop)

• Geoff Huston (APNIC)

Room: Ballroom 1 An examination of the DNS query profile for non-existent names, looking at the extent to which the resolver infrastructure generates synthetic re-queries for non-existent names

Incentivizing the adoption of (new) standards (Public Workshop)

• Maarten Wullink (SIDN)

Room: Ballroom 1 In this presentation i will discuss the incentive program of SIDN (.nl ccTLD) The goal of this program is to create incentives for registrars to implement standards such as IPv6, DMARC, STARTTLS, DKIM and SPF. Some of the points i will talk about are: - incentive rules - how we measure compliance - results See attached pdf and powerpoint for a first presentation draft.

Measures against cache poisoning attacks using IP fragmentation in DNS (Public Workshop)

• Kazunori Fujiwara (Japan Registry Services Co., Ltd)

Room: Ballroom 1 Researchers proposed DNS cache poisoning attacks using IP fragmentation. This talk reports them and proposes feasible and adequate measures at full-service resolvers against these attacks. To protect resolvers from these attacks, avoid fragmentation (limit requestor's UDP payload size to 1220/1232), drop fragmented UDP DNS responses and use TCP at resolver side. And more, it will report current status of fragmentation and EDNS0 payload size. It is time to consider to avoid IP Fragmentation (and path MTU discovery) in DNS. It is not good that DNS is the biggest user of IP fragmentation. (draft-fujiwara-dnsop-fragment-attack)

PGP signing session

• Matthew Pounsett (Nimbus)

Room: Ballroom 1 Please send your keys to <pgpsign@dns-oarc.net> if participating.

Flamethrower: A flexible tool for DNS load and functional testing (Public Workshop)

• Jan Včelák (NS1)

Room: Ballroom 1 [Flamethrower][1] is a new DNS performance and functional testing utility. Originally envisioned as an “improved dnsperf” and allowing simulation of realistic looking traffic patterns it has become a versatile tool for DNS server development and load testing. We will discuss motivations for its existence, its features, technical architecture, and use cases. The tool has been developed at [NS1][2], has been open-sourced in January 2019, and currently lives on DNS-OARC's GitHub. [1]: https://github.com/DNS-OARC/flamethrower [2]: https://ns1.com

Hyper-hyper-local root serving (Public Workshop)

• Ray Bellis (Internet Systems Consortium, Inc.)

Room: Ballroom 1 I've recently developed a prototype "root zone only" server which can be deployed within local networks to provide an on-site root server without putting a copy of the root zone within each recursor (c.f. RFC 7706). The software is fast, and scalable (it'll run on anything from a RPi3 up to high-end multicore servers, so long as it's running on Linux). I've also built an (almost) turn-key distribution for the Raspberry Pi, such that a root server can be turned up just by copying the binary image to an SD card, editing a text file to configure its IP address and then powering it on. This talk will introduce the concept, talk about the Linux networking stack and how packet flows are optimised on multi-core / multi-nic queue systems, and also discuss how the root zone is particularly amenable to pre-computation of answers.

respdiff: Regression and interoperability testing for the Internet (Public Workshop)

• Petr Špaček (CZ.NIC)

Room: Ballroom 1 We present open-source tool called "[respdiff][1]" which can be used for regression and interoperability testing of DNS implementations. In principle, the tool sends the very same DNS query to various implementations and compares their answers using configurable criteria. This approach, when combined with DNS resolvers connected to the Internet, allows us to detect protocol incompatibilities before a new software release is made available to users. Our approach works relatively well if a human is evaluating the test results, but automating test result evaluation proved to be more difficult. The presentation will discuss limitations of the method and solicit feedback from the audience. [1]: https://gitlab.labs.nic.cz/knot/respdiff/blob/master/README.rst

Oh, another DoH (Lightning Talks)

• Jaromír Talíř (CZ.NIC)

Room: Ballroom 1 Few weeks ago we upgraded ODVR that CZ.NIC has operated for about 10 years. New version is based on latest Knot Resolver 4.0 and it allows to test new experimental implementation of DoH inside resolver. We have an idea that DoH may help us resurrect our popular tool DNSSEC validator.

DNSCrypt

• Brian Hartvigsen (OpenDNS)

Room: Ballroom 1

DNS Flag day: kiwi flavour (Lightning Talks)

• Sebastian Castro (InternetnNZ)

Room: Ballroom 1 Lighting talk telling the story how we mostly fixed DNS Flag day in .nz

Whither DANE?

• Shumon Huque (Salesforce)

Room: Ballroom 1 What's going on with DANE? Will it really happen? Status of protocol specifications. Where DANE has had some success. The sad saga of DANE prospects for the web.

Welcome from OARC Chairman (Public Workshop)

• Duane Wessels (Verisign)

Room: Ballroom 1

OARC Status Report (OARC Business (Open to all))

• Keith Mitchell (DNS-OARC)

Room: Ballroom 1

OARC Engineering Report (OARC Business (Open to all))

• Matthew Pounsett (DNS-OARC)
• Jerry Lundström (DNS-OARC)

Room: Ballroom 1