OARC 25 (Dallas)

15 Oct 2016, 07:00 → 16 Oct 2016, 17:30 US/Central

Gold (The Fairmont Dallas)

Keith Mitchell (DNS-OARC), Sebastian Castro (NZRS)

DNS-OARC is traveling to Dallas, TX for it's 25th Workshop!

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.

The workshops are open to OARC members and to all other parties interested in DNS operations and research, with NANOG 68 and ARIN 38 attendees particularly welcome this time around - as OARC 25 takes place just before the NANOG 68 meeting in Dallas. Attendance is free for OARC Members, Speakers and Sponsors. There are charges for other attendees and late registrations.

We are thankful to our sponsors for supporting OARC 25.

---

PREMIUM SPONSORS

     

---

PATRON SPONSORS

     

---

CONTRIBUTOR SPONSORS

               

---

Registration: will open on Tuesday 2 May 2016

Call for Presentations: is now closed

Webcast: Currently live at https://www.youtube.com/watch?v=DkIYCP3mljE

Twitter hashtag: #OARC25

Sponsors: We still have various sponsor opportunities for OARC25, and workshops in 2017. We are also offering a 20% discount on upfront commitment to sponsor (Benefactor level and above) two consecutive workshops between now and OARC 27 in the fall of 2017.

If your organization is interested in sponsoring OARC workshops, please see our Sponsor Benefits or e-mail sponsor@dns-oarc.net for more information.

 

AGM Documents

• 2015 AGM Minutes
• 2015 Financial Statements
• Proxy Voting Form

Saturday, 15 October

Members Session

1 Introduction from OARC Chairman

Speaker: Mr Ondrej Filip (CZ.NIC)

2 OARC Status Report

Speaker: Mr William Sotomayor (DNS-OARC)

Slides OARC-AGM-report_16.odp OARC-AGM-report_16.pdf

3 OARC Engineering Report

Speakers: Mr Jerry Lundström (DNS-OARC), Mr William Sotomayor (DNS-OARC)

Slides 201610_OARC_Systems_Update.pdf OARC_25_Development.pdf

4 OARC Treasurer's Report

Speaker: Duane Wessels (Verisign)

Slides Treasurer-2015_report.pdf Treasurer-2015_report.pptx

5 OARC Board Elections

Speakers: Mr Ondrej Filip (CZ.NIC), Paul Ebersman (Comcast)

6 Recent Authoritative Exhaustion Attacks

Speaker: Mr Christopher Baker (Dyn)

Slides DDoS_Bot_Attack_Analysis_(1).pdf

Public Workshop: Measurement and Testing

Convener: Mr Geoff Huston (APNIC)

7 A Study of Privacy and Anonymity in the DNS

The need for a private Domain Name System (DNS) has become increasingly important in recent years. There are several different proposals to address this growing problem, including DNS-over-TLS and DNSCurve. The former enables clients to create ephemeral sessions with either their resolver or authoritative (stub) servers in which queries can be issued. The latter uses per-query encryption to protect queries between clients and servers. Encryption is core mechanism used to enable client privacy in both of these solutions. However, in a recent study, Shulman showed that encryption alone is insufficient to protect the privacy of queries. Information leaked in DNS side channels, such query timing, frequency, and resolution ``chains,'' may reveal the contents of a query. Moreover, by observing the trust properties of DNS servers and their responses, an adversary may also learn the specific record within a domain that was requested.

Speaker: Christopher Wood (UCI)

Slides dns16.pdf

8 Domain Like an Egyptian

IDN is fun! And not just for boring things like modern languages. Build a domain name to stand the test of time...

Speaker: Shane Kerr (BII)

Slides 2016-10-15-domain-like-an-egyptian.odp 2016-10-15-domain-like-an-egyptian.pdf

12:30 Lunch

Public Workshop: DNS Testing

Convener: Mr Sebastian Castro (NZRS)

9 Yeti DNS: The First Experiments

An look at the first experimental results of the Yeti DNS project, which is an experimental root server testbed.

Speaker: Shane Kerr (BII)

Slides 2016-10-15-oarc-yeti-experiments.odp 2016-10-15-oarc-yeti-experiments.pdf

10 Authoritatives at the Second Level: Testing SLD Nameservers

Most tests of authoritative DNS servers are done on those serving the root and TLDs. Yet there are millions of name servers listed for the level under the TLDs, and the reliability and capabilities those name servers are also important for end users. In order to test properties of these authoritative servers, we collect all of the name servers from the gTLD zones and ccTLDs that make their zones available. We then tested on good name per server to determine whether or not the server supported EDNS0 and, if so, what UDP payload size it reported back. We also separately tested whether or not the authoritative server supports the long-standing NSID extension (RFC 5001) and the very recent edns-client-subnet extension (RFC 7871). It would be useful to be able to fingerprint authoritative servers if possible. We preform some preliminary tests that might assist in such categorization by looking at how the authoritative server reacts to valid but illogical queries to them (such as queries with RD=1 on names for which they are not responsible). Based on feedback we received at DNS-OARC 24, we also report on how many name servers have multiple names for a single IP address, including histograms of distributions of domains. We also show how name servers might be locally related to each other by proximity in the address space. Because the testing will be ongoing, we seek ideas for new tests that would be useful to the DNS operations community.

Speaker: Paul Hoffman (ICANN)

Slides authoritatives-2nd-level-03.pdf

11 Pre-Deployment DNS Testing: Or How to Avoid a Train Wreck

Both the DNS and its security extensions (DNSSEC) are often met with deployment challenges that can affect the quality of (or the very possibility of) resolution. Various tools have been developed to test DNS services, both pre- and post-deployment. DNSViz, available both as a Web-based tool and as a command-line suite, introduces functionality to identify problems with a DNS deployment and present them in graphical or programmatic fashion. However, previously its functionality was limited to DNS zones that were already "live". We discuss new features that allow users to check the DNS changes pre-delegation, or otherwise prior to changes in parent or child zone, so an administrator can deploy with confidence and identify issues before they arise in production.

Speaker: Dr Casey Deccio (Verisign Labs)

Slides 2016-10-15-dnsviz-oarc.pdf

15:30 Afternoon Coffee Break

Public Workshop: DNSSEC

Convener: Duane Wessels (Verisign)

12 Migrating TLD (.CZ) to Elliptic Curves

CZ.NIC is preparing to switch the DNSSEC Signing Algorithm for .CZ TLD from RSA/SHA-512 to ECDSAP256SHA256. In this presentation I will focus on the reasoning, the preparation, the plan and operational obstacles with changing the DNSSEC Algorithm to Elliptic Curves for the TLD (for the first time ever - if nobody beats us till Dallas).

Speaker: Mr Ondrej Sury (CZ.NIC)

Slides Elliptic_Curves_in_.CZ.pdf

13 Tools for Securely Getting DNSSEC Root Trust Anchors

Validating resolvers need a way to get the DNSSEC root trust anchors. Today, most use one of the tools built into the popular resolvers, such as unbound-anchor. Some systems want to get and validate the trust anchors independently of any existing resolver software. We have created a system that only requires Python 2.7 or 3.x with no additional modules, plus any recent OpenSSL command line binary, that downloads the trust anchor set, validates the download, extracts the trust anchors, and compares them against the trust anchors in the root zone. (OpenSSL is used only for validating the contents of the trust anchor file using the ICANN CA.) A primary goal of the program is to allow use in systems where the operator can't reliably install Python modules; a secondary goal is to act as readable pseudocode for developers who want to create similar functionality in different languages. This talk also briefly covers other tools for getting and validating DNSSEC root trust anchors.

Speaker: Paul Hoffman (ICANN)

Slides root-trust-anchor-tools-01.pdf

14 Rolling the Root Zone DNSSEC Key Signing Key

IANA/ICANN/PTI has prepared a plan to change the Root Zone DNSSEC KSK. This talk will present highlights of the plan to explain what will be happening, why this is important to follow, and what the audience needs to do as a result. One of the IANA Functions that ICANN performs is the management of the Key Signing Key (KSK) for the Root Zone’s DNS Security Extensions (DNSSEC). Knowing what the KSK is and how it is handled will help you judge whether to place trust in security based on it and DNSSEC in general.

Speaker: Mr Matt Larson (ICANN)

Slides KSK_Roll_Plan_Discussion-LARSON-DNS-OARC25.pdf

Sunday, 16 October

Public Workshop: Data Analysis

Convener: Duane Wessels (Verisign)

15 PCAP-TO-HDFS

CIRA designed an engine to overlay DNS queries with customer relevant information and save into a Hadoop cluster in order to provide detailed traffic information and serve as the Machine Learning R&D projects foundation. The engine was built on top of the SIDN Entrada library to leverage its efficient PCAP decoding feature. In order to easily allow concurrent processing, the engine was implemented using the Actor Model pattern. A message driven actor chain was created using the AKKA toolkit. CIRA's presentation will describe our engine and results of some experiments we performed.

Speaker: Mr Elson Oliveira (CIRA)

Slides 2016_dnsoarc_CIRA.pdf

16 What to do with SERVFAIL (the day wd2go.com fell off the Internet)

On August 3rd around 12:40 UTC the name servers for wd2go.com stopped answering queries. As this domain is used by a lot of Western Digital software devices for cloud backup these devices stopped functioning. In addition to this they issued lots of DNS queries to get to their servers. This talk looks into what burden these devices put on recursive resolvers and what in turn the different resolver implementations do with this traffic that SERVFAILS.

Speaker: Mr Ralf Weber (Nominum Inc)

Slides ServFailOarc25RalfWeber.pdf ServFailOarc25RalfWeber.pptx

17 On the search for resolvers

From data collected at the authoritative side and with machine learning algorithms in our side, we embark in the effort to see if we can identify traffic patterns matching known resolver addresses.

Speaker: Mr Sebastian Castro (NZRS)

Slides In_the_search_of_resolvers_-_DNS-OARC_25.pdf In_the_search_of_resolvers_-_DNS-OARC_25.pptx

10:30 Morning Coffee Break

Public Workshop: Anycast

Convener: Mr Ray Bellis (Internet Systems Consortium, Inc.)

18 Anycast Latency: How Many Sites Are Enough?

Today service and content providers often use IP anycast to replicate instances of their services, improving reliability and lowering latency to their users. In IP anycast a single logical address associated to a service is announced from multiple physical locations (*anycast sites*). Anycast then uses BGP routing to divide the Internet into different *catchments*, each associating some users with a nearby anycast site. Ideally users are associated with the topologically closest site, but BGP routing is based on limited information and influenced by policies, making catchment assignment more chaotic and sometimes causing users to match with more distant sites. Prior studies have shown the surprising complexity in the latency and association between anycast services and their users, but have not explored root causes or characterized the relationship between anycast deployment on service quality. This talk will report on our recent study of real-world anycast deployments and how deployment approach affects latency between users and the anycast service [Schmidt16a]. Our target is four Root DNS services (C-, F-, K- and L-Roots); their deployments ranged from 8 to 140 anycast sites which we measure using more than 7,500 RIPE Atlas probes (Vantage Points, or VPs) around the world. (These sizes were as of measurement in 2015 and 2016 and have since grown.) We evaluate the effect of different anycast configurations on the latency of DNS queries, and we believe our results generalize to the use of IP anycast for other applications such as CDNs.

Speaker: Mr John Heidemann (USC/Information Sciences Institute)

Slides anycast_latency_at_oarc_161016_1up.pdf

19 ENT was here !!!

Dear program commitee members, We had to deal with NSEC3 validation issues on NSD and Google Public DNS service. From the alert to the solutions we found, process modifications and lessons learned, we would like to share with the community and give them clues if they have that kind of configuration (NSEC3+opt-out+ENT+...) to fix it because Google public DNS does not handle it correctly yet. Here is an alpha draft of my presentation. I'll have more time to work on it when I'll be back from my summer break. If possible, I'd like a 30 minutes slot, but if there are only 15 minutes slots left, I'll modify the presentation accordingly. If you have any questions, advices or anything else, don't hesitate to contact me. Best regards. --- Vincent Levigneron.

Speaker: Mr Vincent Levigneron (AFNIC)

Slides AFNIC_OARC_Dallas.pdf

20 Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event

Distributed Denial-of-Service (DDoS) attacks continue to be a major threat in the Internet today. DDoS attacks overwhelm target services with requests or other "bogus" traffic, causing requests from legitimate users to be shut out. A common defense against DDoS is to replicate the service in multiple physical locations or sites. If all sites announce a common IP address, BGP will associate users around the Internet with a nearby site, defining the *catchment* of that site. Anycast adds resilience against DDoS both by increasing capacity to the aggregate of many sites, and allowing each catchment to contain attack traffic leaving other sites unaffected. IP anycast is widely used for commercial CDNs and essential infrastructure such as DNS, but there is little evaluation of anycast under stress. This talk will provide a *first evaluation of several anycast services under stress with public data*. Our subject is the Internet's Root Domain Name Service, made up of 13 independently designed services (``letters'', 11 with IP anycast) running at more than 500 sites. Many of these services were stressed by sustained traffic at 100x normal load on Nov. 30 and Dec. 1, 2015. We use public data for most of our analysis to examine how different services respond to the these events. In our analysis we identify two policies by operators: (1) sites may *absorb* attack traffic, containing the damage but reducing service to some users, or (2) they may *withdraw* routes to shift both legitimate and bogus traffic to other sites. We study how these deployment policies result in different levels of service to different users, during and immediately after the attacks. We also show evidence of *collateral damage* on other services located near the attack targets. The work is based on analysis of DNS response from around 9000 RIPE Atlas vantage points (or "probes"), agumented by RSSAC-002 reports from 5 root letters and BGP data from BGPmon. We examine DNS performance for each Root Letter, for anycast sites inside specific letters, and for specific servers at one site.

Speaker: Mr John Heidemann (USC/Information Sciences Institute)

Slides nov_30_analysis_161016_1up.pdf

12:30 Lunch

21 PGP Signing Session

Speaker: Mr Joseph Abley (Dyn, Inc.)

Public Workshop: Security and Privacy

Convener: Mr Geoff Huston (APNIC)

22 Inter-operator Transfers of Signed TLDs

In the last year, Rightside has transferred in two signed TLDs: REISE in June of 2015, and JETZT in May of 2016. We believe these were the first two signed TLDs to ever go through a full inter-operator transfer (including NS change and key rolls). We anticipate this type of transfer will become more common in the next few years, and would like to share our experiences with the community.

Speaker: Matthew Pounsett (Rightside)

Slides Inter-Operator_Transfers.key Inter-Operator_Transfers.pdf

23 DNS Performance Metrics

There are a number of free and commercial DNS performance comparison platforms publishing rankings and metrics. From free offerings such as DNSPerf and SolveDNS to commercial platforms such as CloudHarmony or Catchpoint. Each of these platforms measure DNS performance in their own way producing different results. What exactly are they measuring? When you look at a time series, where did the observation noted come from? This session will introduce the OARC community to a number of DNS performance measurement platforms ( beyond our beloved DNSMON, RIPE Atlas and NLNOG RING ) and address the complexity of understanding how others outside the network community are measuring the DNS. By virtue of being members of DNS OARC everyone in attendance is familiar with monitoring and operating DNS infrastructure. I’ve reviewed the data collected and methodology leveraged by of a number of providers of DNS performance metrics to assemble a set of common pitfalls and sources of skew. The goal is to identify the common pitfalls and work with other operators to come to consensus on best practices. The goal of this presentation is to facilitate a conversation about these measurement and ranking platforms and how the OARC community can help improve understanding and visibility into DNS performance.

Speaker: Mr Christopher Baker (Dyn)

Slides DNSOARC_Measurements_Draft_(2).pdf

24 Exploring CVE-2015-7547, a Skeleton key in DNS

Earlier this year we investigated a buffer overflow error in GNU libc DNS stub resolver code known as CVE-2015-7547. Similar to *"Ghost"* vulnerability in `gethostbyname()`, this vulnerability allows RCE in every application calling it, from SSH to browsers. This made it very dangerous in theory, but the exploitability was still an enigma. The disclosure mentioned a back of the envelope analysis that the exploit could penetrate DNS caches in well formed DNS responses, so we set on answering the big question - how exploitable is it in the real world?

Speakers: Ms Jaime Cochran (CloudFlare Inc.), Mr Marek Vavrusa (CloudFlare Inc.)

Slides The Skeleton Key Slides

15:30 Afternoon Coffee Break

Public Workshop: Lightning Talks

25 Should stub resolvers have root DNSSEC key preloaded?

Speaker: Mr Andrew White

Slides The_Last_Link_in_the_DNSSEC_Chain_of_Trust.pptx

26 How Changes to the Root Zone Management System are Requested

Speaker: Mr David Conrad (ICANN)

Slides rzerc-lt.pptx

27 CBOR DNS Format

Speaker: Mr Terry Manderson (ICANN)

Slides OARC-Dallas.pptx

Public Workshop

Convener: Mr Mauricio Vergara Ereche (ICANN)

28 Nameserver UDP socket buffer tuning

**Background:** The size of the UDP buffers has a significant impact on nameserver performance and, as such, is a decision that has to be taken for all DNS deployments. Due to the interaction between operating system memory allocation strategies, TCP/IP stack implementation, buffer accounting, and application software there are a lot of misunderstandings about what is the appropriate value and what are the overheads involved. By using a combination of tests, kernel source inspection, and Systemtap scripts, we aim to clarify how buffer accounting works and what is the correct process for calculating the necessary buffers. **Results:** Socket buffers are slab allocated, so they present a non-linear overhead characteristic. This leads to overhead of up to 2000% for common DNS packet sizes. Buffer size vs packet size are investigated for IPv4 and IPv6 for payload sizes between 1byte and 4kB. Using Systemtap, we analyze buffer contents and data structure sizes in different Linux kernels.

Speaker: Mr Ciprian Dan Cosma (Amazon)

Slides udp_buffer_tuning.pdf

29 The hunger for AAAA

This is a short presentation about forensic digging into DNS data to understand when and why the Internet went crazy querying for the same record again and again. Cooperation with a provider and rapid action helped to mostly fix the problem.

Speaker: Mr Sebastian Castro (NZRS)

Slides The_hunger_for_AAAA.pdf The_hunger_for_AAAA.pptx

30 RFC 2181 Ranking data and referrals/glue importance

Referrals (parent side NS RRset at zone cut) and glue are important. However, the importance is not well described in DNS standards. RFC 2181 Section 5.4.1 "Ranking data" shows that referrals ranking is lowest. However, the referrals make zones and specify name servers that serve authoritative data for the zones. The glue specifies IP addresses of the name servers that serve authoritative data for the zone. The NS RRset at the apex of the zone is authoritative data, however, it does not make the zone cut. NS RRset at parent side is more important than NS RRSet at child side. This presentation will explain the details, propose clarifications of DNS standards and new name resolution method, and report an experiment/simulation result of new name resolution algorithm. Proposed name resolution method use referrals, glue and out-of-bailiwick name server information to iterate DNS tree and responds authoritative data only (except referrals and glue).

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

Slides fujiwara-201610160810.pdf