OARC 32 Registration now open. Click the Registration Page for details.

OARC 25 (Dallas)

US/Central
Gold (The Fairmont Dallas)

Gold

The Fairmont Dallas

1717 N Akard St Dallas, TX 75201 USA
Keith Mitchell (DNS-OARC), Sebastian Castro (NZRS)
Description

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

ICANN     Verisign


PATRON SPONSORS

Nominum     Salesforce


CONTRIBUTOR SPONSORS

Netflix     Netflix     NZRS     PowerDNS


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.

 

Participants
  • Aaron Johnson
  • Adan Mendoza
  • Ajay Sriram
  • Alexander Ilin
  • Allison Mankin
  • Amanda Constant
  • Amanda Swain
  • Andrew Bradford
  • Andrew White
  • Austin Brower
  • Bac Nguyen Huy
  • Brad Verd
  • Brian Hartvigsen
  • Brian Somers
  • Bruce Roberts
  • Carl Clements
  • Casey Deccio
  • Charles Menser
  • Chris Baker
  • Chris Lavallee
  • Christian Petrasch
  • Christopher Wood
  • Ciprian Cosma
  • Dave Knight
  • David Back
  • David Conrad
  • David Farmer
  • David Jeffers
  • David Lawrence
  • Denesh Bhabuta
  • Dmitrii Kovalenko
  • Duane Wessels
  • Eddy Winstead
  • Eduardo Duarte
  • Elson Oliveira
  • Emmanuel Bretelle
  • Erik Muller
  • Evan Thompson
  • Geoff Horne
  • Geoff Huston
  • Gonzalo Munoz
  • Gustavo Arzola
  • Herbert Faleiros
  • Isaiah Connell
  • Jacob Zack
  • Jacques Latour
  • Jaime Cochran
  • Jan Včelák
  • Jason Castonguay
  • Jean-Yves Bisiaux
  • Jeremy Brown
  • Jerry Lundström
  • Jesse Blazina
  • Jesse Lavigne
  • Jim Troutman
  • Joe Abley
  • John Crain
  • John Heidemann
  • John Kristoff
  • John O'Brien
  • Jonathan Lewis
  • Jorge Cano
  • Joseph Crowe
  • Joshua Kuo
  • Joshua Seidenberg
  • João Luis Silva Damas
  • Karl Reuss
  • Kazunori Fujiwara
  • Keith Mitchell
  • Kevin Jones
  • Liam Hynes
  • Marcelo Gardini
  • Marco Diaz
  • Marco Pizzoli
  • Marek Vavrusa
  • Mark Dokter
  • Mark Feldman
  • Mats Dufberg
  • Matt Larson
  • Matthew Pounsett
  • Matthew Rowley
  • Mauricio Oviedo
  • Mauricio Vergara Ereche
  • Melissa Muth
  • Merike Kaeo
  • Michael Lanski
  • Mike McLean
  • Miles McCredie
  • Mingxing Star
  • Ondrej Filip
  • Ondrej Sury
  • Paul Ebersman
  • Paul Hoffman
  • Peter DeVries
  • Peter Hagopian
  • Peter Janssen
  • Piet Barber
  • Ralf Weber
  • Ray Bellis
  • Ray Gilstrap
  • Rob Fawcett
  • Robert Edmonds
  • Robert Gray
  • Robert Nagy
  • Roy Arends
  • Roy Hooper
  • Saksham Manchanda
  • Scott Silzer
  • Sean Stuart
  • Sebastian Castro
  • Shane Kerr
  • Shannon Weyrick
  • Shumon Huque
  • Srini Avirneni
  • Stephan Lagerholm
  • Steve DeJong
  • Susan Graves
  • Suzanne Woolf
  • Terry Manderson
  • Tim April
  • Tim Wicinski
  • Timothy S Morizot
  • Tom Rudnick
  • Tongfeng Zhang
  • Vicky Risk
  • Vincent Levigneron
  • Wesley Hardaker
  • Willem Toorop
  • William Manning
  • William Sotomayor
  • Yoshinobu Matsuzaki
Support - Help
  • Saturday, 15 October
    • 10:00 11:45
      Members Session Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      • 10:00
        Introduction from OARC Chairman 5m
        Speaker: Mr. Ondrej Filip (CZ.NIC)
      • 10:05
        OARC Status Report 30m
        Speaker: Mr. William Sotomayor (DNS-OARC)
        Slides
      • 10:35
        OARC Engineering Report 30m
        Speakers: Mr. Jerry Lundström (DNS-OARC), Mr. William Sotomayor (DNS-OARC)
        Slides
      • 11:05
        OARC Treasurer's Report 10m
        Speaker: Duane Wessels (Verisign)
        Slides
      • 11:15
        OARC Board Elections 15m
        Speakers: Mr. Ondrej Filip (CZ.NIC), Paul Ebersman (Comcast)
      • 11:30
        Recent Authoritative Exhaustion Attacks 15m
        Speaker: Mr. Christopher Baker (Dyn)
        Slides
    • 11:45 12:30
      Public Workshop: Measurement and Testing Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Mr. Geoff Huston (APNIC)
      • 11:45
        A Study of Privacy and Anonymity in the DNS 30m
        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
      • 12:15
        Domain Like an Egyptian 15m
        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
    • 12:30 14:00
      Lunch 1h 30m Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
    • 14:00 15:30
      Public Workshop: DNS Testing Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Mr. Sebastian Castro (NZRS)
      • 14:00
        Yeti DNS: The First Experiments 30m
        An look at the first experimental results of the Yeti DNS project, which is an experimental root server testbed.
        Speaker: Shane Kerr (BII)
        Slides
      • 14:30
        Authoritatives at the Second Level: Testing SLD Nameservers 30m
        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
      • 15:00
        Pre-Deployment DNS Testing: Or How to Avoid a Train Wreck 30m
        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
    • 15:30 16:00
      Afternoon Coffee Break 30m Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
    • 16:00 17:15
      Public Workshop: DNSSEC Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Duane Wessels (Verisign)
      • 16:00
        Migrating TLD (.CZ) to Elliptic Curves 30m
        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
      • 16:30
        Tools for Securely Getting DNSSEC Root Trust Anchors 15m
        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
      • 16:45
        Rolling the Root Zone DNSSEC Key Signing Key 30m
        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
  • Sunday, 16 October
    • 09:00 10:30
      Public Workshop: Data Analysis Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Duane Wessels (Verisign)
      • 09:00
        PCAP-TO-HDFS 30m
        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
      • 09:30
        What to do with SERVFAIL (the day wd2go.com fell off the Internet) 30m
        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
      • 10:00
        On the search for resolvers 30m
        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
    • 10:30 11:00
      Morning Coffee Break 30m Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
    • 11:00 12:30
      Public Workshop: Anycast Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Mr. Ray Bellis (Internet Systems Consortium, Inc.)
      • 11:00
        Anycast Latency: How Many Sites Are Enough? 30m
        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
      • 11:30
        ENT was here !!! 30m
        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
      • 12:00
        Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event 30m
        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
    • 12:30 14:00
      Lunch 1h 30m Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
    • 13:00 13:45
      PGP Signing Session 45m
      Speaker: Mr. Joseph Abley (Dyn, Inc.)
    • 14:00 15:30
      Public Workshop: Security and Privacy Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Mr. Geoff Huston (APNIC)
      • 14:00
        Inter-operator Transfers of Signed TLDs 30m
        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
      • 14:30
        DNS Performance Metrics 30m
        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
      • 15:00
        Exploring CVE-2015-7547, a Skeleton key in DNS 30m
        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
    • 15:30 16:00
      Afternoon Coffee Break 30m Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
    • 16:00 16:15
      Public Workshop: Lightning Talks Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      • 16:00
        Should stub resolvers have root DNSSEC key preloaded? 5m
        Speaker: Mr. Andrew White
        Slides
      • 16:05
        How Changes to the Root Zone Management System are Requested 5m
        Speaker: Mr. David Conrad (ICANN)
        Slides
      • 16:10
        CBOR DNS Format 5m
        Speaker: Mr. Terry Manderson (ICANN)
        Slides
    • 16:15 17:30
      Public Workshop Gold

      Gold

      The Fairmont Dallas

      1717 N Akard St Dallas, TX 75201 USA
      Convener: Mr. Mauricio Vergara Ereche (ICANN)
      • 16:15
        Nameserver UDP socket buffer tuning 30m
        **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
      • 16:45
        The hunger for AAAA 15m
        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
      • 17:00
        RFC 2181 Ranking data and referrals/glue importance 30m
        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
Your browser is out of date!

Update your browser to view this website correctly. Update my browser now

×