OARC 27 (San Jose)

US/Pacific
Regency 2 Ballroom (Fairmont San Jose)

Regency 2 Ballroom

Fairmont San Jose

170 S Market Street, San Jose, 95113, CA, USA
Keith Mitchell (DNS-OARC), Ray Bellis (Internet Systems Consortium, Inc.)
Description

 

DNS-OARC is traveling to San Jose, California, USA for its 27th 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 attendees from NANOG Hackathon, NANOG 71 and ARIN 40 particularly welcome this time around - as OARC 27 takes place just before them in the same venue in San Jose. Attendance is free for OARC Members and Sponsors. There are charges for other attendees and late registrations.

We are thankful to our Sponsors for supporting OARC 27.


PRINCIPAL SPONSOR

ICANN


PREMIUM SPONSOR

Verisign


BENEFACTOR SPONSORS

Comcast     ThousandEyes


CONTRIBUTOR SPONSORS

Infoblox


 

Video:

Jabber: xmpp:dns-operations@conference.dns-oarc.net

Twitter hashtag: #OARC27

Sponsors: We have various sponsor opportunities for OARC workshops.

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
  • Ajay Sriram
  • Aleksandr Ilin
  • Ales Koprivnikar
  • Alexander Dupuy
  • Alexis Fasquel
  • Allison Mankin
  • Amanda Swain
  • Anand Buddhdev
  • Andrea Barberio
  • Andres Pavez
  • Andrew Boling
  • Andrew Sullivan
  • Andrew White
  • Arturo Paulite
  • Ashley Roeckelein
  • Austin Brower
  • Barry Greene
  • Benedict Addis
  • Bill Snow
  • Bolek Kulbabinski
  • Brad Gorman
  • Brad Verd
  • Brian Dickson
  • Brian Hartvigsen
  • Brian Somers
  • Bruce Roberts
  • Carl Clements
  • Carlil Macedo
  • Casey Deccio
  • Cathy Almond
  • Chris Baker
  • Christian Petrasch
  • Christian Saide
  • Christopher Cherry
  • Christopher Quesada
  • Cricket Liu
  • Cristian Rojas
  • Dan Mahoney
  • Daniel Karrenberg
  • Darren Kara
  • Dave Fraleigh
  • Dave Knight
  • David Back
  • David Blacka
  • David Funk
  • David Lawrence
  • David Moran
  • David Trout
  • Denesh Bhabuta
  • Dmitrii Kovalenko
  • Dmitry Kohmanyuk
  • Dominic Marks
  • Donavan Fritz
  • Duane Wessels
  • Eddy Winstead
  • Eduardo Alvarez
  • Edward Lewis
  • Eric Germann
  • Eric Ziegast
  • Evan Hunt
  • Gabriel Nunez
  • Geoff Huston
  • George Michaelson
  • Han Zhang
  • Herbert Faleiros
  • Jacob Zack
  • Jan Včelák
  • Jaromir Talir
  • Jason Castonguay
  • Jay Kothari
  • Jean Roy
  • Jeff Osborn
  • Jerry Lundström
  • Jim Belton
  • Jim Troutman
  • Jing Qiao
  • Joao Luis Silva Damas
  • Joel Ferman
  • John Barnitz
  • John O'Brien
  • John Todd
  • Jorge Cano
  • Joseph Crowe
  • João Schiavo
  • Jurong Li
  • Kazunori Fujiwara
  • Keith Mitchell
  • Ken Renard
  • Kevin Lahey
  • Kevin Wright
  • Laura Hendriksen
  • Liam Hynes
  • Manu Bretelle
  • Marcelo Gardini
  • Marco Díaz
  • Marek Vavrusa
  • Mario Guerra
  • Martin Levy
  • Matt Larson
  • Matt Mahan
  • Matt Weinberg
  • Matthew Pounsett
  • Mauricio Oviedo
  • Mauricio Vergara Ereche
  • Melissa Muth
  • Michael Sinatra
  • Miles McCredie
  • Mingkai Zhang
  • Mingtao Yang
  • Mohamed Elbashir
  • Moritz Müller
  • Nikita Agarwal
  • Ondrej Sury
  • Pallavi Aras
  • Patrik Fältström
  • Paul Ebersman
  • Paul Emmons
  • Paul Hoffman
  • Peter DeVries
  • Peter Hagopian
  • Peter Janssen
  • Peter Losher
  • Peter ONeill
  • Petr Špaček
  • Phelps Williams
  • Piet Barber
  • Prab Singh
  • Puneet Sood
  • Punky Duero
  • Raja Mandapati
  • Ralf Weber
  • Ralph Dolmans
  • Rami Ismaeil
  • Ray Bellis
  • Ray Gilstrap
  • Richard Lamb
  • Rob Fawcett
  • Robert Edmonds
  • Robert Fleischman
  • Robert Seastrom
  • Rod Rasmussen
  • Rog Murray
  • Rok Papež
  • Samir Jafferali
  • Sara Dickinson
  • Scott Rose
  • Scott Silzer
  • Sean Stuart
  • Sebastian Castro
  • Shawn Instenes
  • Shinji Kawaguchi
  • Shumon Huque
  • Stephan Lagerholm
  • Stephen Morris
  • Steve Bailey
  • Steve DeJong
  • Steven Hotz
  • Susan Graves
  • Takashi Yajima
  • Tatuya Jinmei
  • Tim Wicinski
  • Tom Noto
  • Ulrich Wisser
  • Vasily Funtikov
  • Vicky Shrestha
  • Victor McLane
  • Victoria Risk
  • Vijay Sarvepalli
  • Vincent Levigneron
  • Warren Kumari
  • Wes Hardaker
  • William Sotomayor
  • Yasmin Omer
  • Yuedong Zhang
  • Yuriy Yuzifovich
  • Ólafur Guðmundsson
Support - Help
    • 8:30 AM
      Registration Regency Ballroom Foyer

      Regency Ballroom Foyer

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • Public Workshop: DNSSEC Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 1
        Workshop Opening
        Speaker: Mr Keith Mitchell (DNS-OARC)
        Slides
      • 2
        A Look at RFC 8145 Trust Anchor Signaling for the 2017 KSK Rollover
        RFC 8145 ("Signaling Trust Anchor Knowledge") was published in April 2017. This RFC describes how recursive name servers can signal, to authoritative servers, the trust anchors that they have configured for Domain Name System Security Extensions (DNSSEC) validation. Shortly after its publication, both Unbound and BIND implemented the specification. As organizations begin to deploy the new software versions, some of this “key tag data” is now appearing in queries to the root name servers. This is useful data for Key Signing Key (KSK) rollovers, and especially for the root. Since the feature is very new, the number of recursive name servers providing data is not as significant as one might like for the upcoming root KSK rollover. Even so, it will be interesting to look at the data. By examining this data we can understand whether or not the technique works and hopefully inspire further adoption in advance of future KSK rollovers.
        Speaker: Duane Wessels (Verisign)
        Slides
      • 3
        DNSSEC Operations in the .gov TLD
        We look at the results of multiple years of DNSSEC scanning to see how DNSSEC is being maintained in the .gov TLD. We look at signing algorithm use, hash algorithms use in DS RRsets and parameters used in NSEC3. We also look for trends and changes over time to detect algorithm rollovers and changes to NSEC3 parameters. The goal of this work is to see how DNSSEC is being deployed and administered in .gov delegations and if there are any issues that need to be addressed. We are primarily looking at NSEC/NSEC3 usage and algorithm usage to see how well they conform to best common practices and federal policy.
        Speaker: Mr Scott Rose (NIST)
        Slides
      • 4
        Quantifying the Quality of DNSSEC Validation in the Wild
        The Root Canary Project has the goal to monitor and measure the rollover of the DNSSEC root KSK. In this project we use over 9000 RIPE Atlas probes and ten-thousands of vantage point of the Luminati VPN network to continuously monitor recursive resolvers during the 9 months period of the rollover. From each vantage point we query for testing domains that have bogus and valid signatures of the 12 DNSSEC algorithms that are standardized by the IETF. Thereby we can measure how recursive resolvers behave, for example, when the new KSK of the root becomes active. Additionally, we gain operational insights into the behavior of recursive resolvers in the wild that go beyond the root KSK rollover. For example, we now know that the majority of the observed validating resolvers are stable and that some resolver implementations have incorrect behavior when they encounter certain DNSSEC algorithms. In this presentation we want dig deeper in the support of DNSSEC algorithms and want to show how well recursive resolvers in the wild support the different signing algorithms, try to explain why some fail, and compare these results with the actual deployment of DNSSEC in major gTLDs and ccTLDs. Until the 27th DNS-OARC workshop, we will have over 3 months of continuous measurements at our disposal. We want to invite the community to provide feedback to our measurements and help us to improve our ground truth data set. Therefore we want to introduce a small tool with which operators can contribute to the Root Canary Project and to studies like the one presented.
        Speaker: Mr Moritz Müller (SIDN)
        Slides
    • 11:00 AM
      Morning coffee break Regency Ballroom Foyer

      Regency Ballroom Foyer

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • Public Workshop: Operations #1 Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 5
        How Dual DNS Improves Resiliency
        http://prezi.com/snfdsqsoywtm/
        Speaker: Mr Samir Jafferali (LinkedIn)
        Slides
      • 6
        Verfploeter: Broad and Load-Aware Anycast Mapping
        IP anycast provides DNS operators and CDNs with automatic fail-over and reduced latency by breaking the Internet into catchments,each served by a different anycast site. Unfortunately, understanding and predicting changes to catchments as sites are added or removed has been challenging. Current tools such as RIPE Atlas or commercial equivalents map from thousands of vantage points (VPs),but their coverage can be inconsistent around the globe. This paper proposes Verfploeter, a new method that maps anycast catchments using active probing. Verfploeter provides around 3.8M virtual VPs, 430 times the 9k physical VPs in RIPE Atlas,providing coverage of the vast majority of networks around the globe. We then add load information from prior service logs to provide calibrated predictions of anycast changes. Verfploeter has been used to evaluate the new anycast for B-Root, and we also report its use of a nine-site anycast testbed. We show that the greater coverage made possible by Verfploeter's active probing is necessary to see routing differences in regions that have sparse coverage from RIPE Atlas, like South America and China.
        Speaker: Wes Hardaker (USC/ISI)
        Slides
      • 7
        High-Proof Data: TSDB Distillation of Recursive DNS Metric Data
        As part of the creation of a new public DNS resolver by PCH, multiple monitoring projects have been introduced. This open sourced monitoring suite is part of an effort to allow a better internal understanding of our public DNS resolution service but also to answer specific questions asked by some of our partners. The various components look at the full stream of DNS data, distills and transforms the data to finally output results in a compatible time series format. They each collect predefined data to take on challenges such as unique DNS records monitoring for easier malware domains detection or query origin monitoring through BGP resolution. This talk will present the work that has been done and the results achieved thus far.
        Speaker: Mr Alexis Fasquel (Packet Clearing House)
        Slides
      • 8
        DNS64 at scale – Turning off IPv4
        Over the last 10 years, T-Mobile have had a strategy of removing our dependency of IPv4. In the spring of 2017 we finally flipped the switch and turned off IPv4 for over 10 million handsets. We have in other words reached the utopia of making our customer experience independent of IP transport protocol. To achieve this we are using DNS64 and related technologies. Stephan will share some of T-Mobile’s experience with DNS64 and give some advice on how to find and handle broken applications and websites. Talk outline: • Background T-Mobile’s journey towards IPv6 only • Background, RFC6147, RFC6877 and RFC7050 • Selection algorithm and happy eyeballs (RFC6555) • Common failure scenarios for IPv6 only hosts • RFC compliance and how popular DNS64 resolvers react to various common DNS misconfigurations • Conclusion and learnings
        Speaker: Mr Stephan Lagerholm (T-mobile)
        Slides
    • 1:00 PM
      Lunch Club Regent (Ground Floor)

      Club Regent (Ground Floor)

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • Public Workshop: Operations #2 Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 9
        Real User Measurement DNS - Using Big Data to decide RData
        Slides at http://prezi.com/yhvism0pufps/
        Speaker: Mr Samir Jafferali (LinkedIn)
        Slides
      • 10
        Running DNS root on localhost and its implications
        Is RFC 7706 aka Decreasing Access Time to Root Servers by Running One on Loopback a good idea or not? If not, can we implement similar with less disadvantages? In this presentation we will analyze measurement data from small and big recursors to estimate impact of RFC 7706 and its alternatives like Agressive NSEC use (IETF draft-ietf-dnsop-nsec-aggressiveuse).
        Speaker: Mr Petr Špaček (CZ.NIC)
        Slides
      • 11
        DNS Service Monitoring at Salesforce
        Highly available and responsive DNS access is critical to earn the trust of enterprise customers for a Software as a Service (SaaS) cloud company such as Salesforce. To provide better DNS services, we have implemented several types of monitoring which are different from those of infrastructure DNS organizations, but we think provide useful insights about DNS. Monitoring DNS services benefits us from various aspects. First, it provides us real-time and time-series status of our DNS services. For example, we can monitor whether the authoritative name servers always answer the DNS queries. Second, we can use the monitoring to benchmark DNS services of multiple vendors to compare their performance. This helps executives and individual contributors in planning and decision-making. Third, regularly sharing the monitoring reports to vendors can improve DNS services. Last, monitoring also helps find hidden problems, for example, some undocumented Rest API behaviors. Currently we monitor the DNS services provided by our vendors from three vantages. The first is the reachability of the authoritative name servers and also the vendors’ Rest API. The second is the consistency of vendors’ name servers, meaning that they provide the same data. The third is propagation delay, specifically, if we make some DNS record changes, how soon the changes can be visible on the name servers. We have built dashboards to visualize the monitoring results using monitoring and alerting platforms developed by Salesforce, ReFocus[1] and Argus[2]. Both tools are open source. Refocus is a platform to visualize the health of many services in a manageable way. At Salesforce, ReFocus connects our numerous monitoring sources into a single, self-service platform. Argus is a time-series monitoring system that allows engineering teams to collect, store, annotate, and alert on massive amounts of time-series data, using a scalable, resource-protected architecture. Argus is similar to Graphite[3], but has been refactored to improve scaling behavior for the very diverse requirements of a large cloud organization. In this presentation, we will first talk about how primary/secondary and active/active is used at Salesforce. Then, we will discuss how we monitor name servers’ availability, consistency, and propagation delay, followed by showing how we use ReFocus and Argus to visualize these results. We have been running the monitoring and collecting data since the end of 2016. We have done some analysis using the collected data and we will present these results. A first draft of the presentation is included in this submission. [1] ReFocus: https://engineering.salesforce.com/take-a-moment-to-refocus-86b6546c90c [2] Argus: https://engineering.salesforce.com/argus-time-series-monitoring-and-alerting-d2941f67864 [3] Graphite: https://graphiteapp.org/
        Speaker: Dr Han Zhang (Salesforce)
        Slides
      • 12
        A Study of DNS Rate Limiting Deployment
        Domain Name System (DNS) authoritative servers are a critical component of Internet infrastructure, and as such, they are deliberately accessible to any Internet computer, as a means to find the Internet services they wish to access. Such accessibility can attract ill-intended users to use these same servers with malicious intent, a primary example being DNS reflection-based Distributed Denial-of-Service (DDoS) attacks. One preventative measure used to combat DDoS attacks is for DNS operators to enable a rate-limiting mechanism to mitigate the effects of the potential attack. In this talk we present a study of the deployment of DNS rate limiting across authoritative servers for TLDs and many of the popular domains, in an effort to better understand the mechanisms being deployed to protect the DNS and other critical infrastructure. We demonstrate the impact of deployment and its impact, measured as a factor of amplification reduction. An improved understanding of existing defense mechanisms will allow us to propose improvements to the Internet infrastructure that will ultimately yield a more stable and secure internet.
        Speaker: Dr Casey Deccio (Brigham Young University)
        Slides
    • 4:00 PM
      Afternoon coffee break Regency Ballroom Foyer

      Regency Ballroom Foyer

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • Public Workshop: Protocol and Implementations Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 13
        DNS Privacy clients: Stubby, Mobile apps and beyond!
        The goal of this talk will be to review the current status of DNS clients that can provide DNS Privacy for end users. Stubby (from the getdns team) is becoming more mature - moving to it’s own project, improving packaging and there is a prototype GUI and iOS app on the way. Some Android folks spent time at the last IETF Hackathon implementing support for opportunistic DNS Privacy, and for the hard-core user Unbound is always an option. This talk will compare what is currently available and speculate about upcoming support in your favourite resolver....
        Speaker: Dr Sara Dickinson (Sinodun IT)
        Slides
      • 14
        Performance and maintainability improvements in BIND
        A discussion of recent work in BIND 9, improving query performance -- particularly with respect to delegation responses -- and code maintainability in the query handling code. These changes have improved root zone performance by a factor of five and reduced McCabe cyclomatic complexity in several large functions by factors of ten or more.
        Speaker: Evan Hunt (ISC)
        Slides
      • 15
        Persistent DNS ‘sessions’ - where next?
        Recent years have seen significant changes in the standards for DNS-over-TCP, a new EDNS0 Keepalive option, a new standard for DNS-over-TLS and a new Internet Draft proposing ‘DNS Session Signalling’. The latter specifies a completely new mechanism to manage persistent DNS sessions which has already been utilised for DNS Service Discovery to introduce novel ways to propagate DNS data e.g. server initiated PUSH messages. In addition to this, recent DDoS attacks have operators thinking more carefully about how they can protect services for customers in such circumstances, for example by using dedicated sessions for ‘top-talking’ customers. This talk will take a tour of the evolution of doing DNS over session based protocols and focus in depth on the potential new use cases that DNS Session signalling opens up. It will try to enumerate the trade-offs encountered when using DNS sessions and summarise some of the recent research on the operational costs of doing so.
        Speaker: Dr Sara Dickinson (Sinodun IT)
        Slides
      • 16
        Performance of ALIAS records vs CNAME
        The Canonical Name, CNAME, record has become the default means of service integration for a number of Cloud and SaaS providers. The scope of services integrated via CNAME includes everything from marketing automation services to cloud load balancers. In some cases, you may have a service integration which is done by a CNAME and points to another CNAME, which may point to yet another CNAME. Some authoritative providers have implemented custom record types that seek to collapse CNAMEs to reduce the latency of the chain of DNS queries required to unwind such a CNAME chain. This presentation is an overview of recent testing of the Dyn+Oracle ALIAS record in the wild. We surveyed ASNs for those with the highest volume to our authoritative, then looked for RIPE Atlas probes in those networks. Probes were configured to use their default resolvers and execute two tests. In the first test, they requested a domain which was the start of a CNAME chain. In the second, they requested a domain associated with an ALIAS record, collapsing the same CNAME chain. This presentation contrasts the performance of the ALIAS record vs. the CNAME chain, as well as provides an overview of edge cases observed. This latter point is included to highlight the potential importance of a "fallback record" in the implementation of the ANAME ( https://tools.ietf.org/html/draft-ietf-dnsop-aname-00 ), a new record type intended to standardize this behavior across providers.
        Speaker: Mr Christopher Baker (Dyn)
        Slides
    • 17
      ICANN Root KSK Roll Discussion Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      Speaker: Paul Hoffman (ICANN)
      Slides
    • 6:30 PM
      Social Event Around the corner from the Fairmont San Jose

      Around the corner from the Fairmont San Jose

    • 8:30 AM
      Registation Regency Ballroom Foyer

      Regency Ballroom Foyer

    • Public Workshop: Testing and Measurement Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 18
        Flexible Testbed for Recursive Resolver Software
        ICANN has recently released a design that allows researchers to easily test multiple resolver programs for things such as how they handle DNSSEC trust anchors and how they choose root servers from priming queries. The testbed can include common open-source resolver software, but also handles any resolvers that can be run in a virtual machine such as Windows Server and other proprietary software. It automatically captures packet traces and allows for easy running of multiple resolvers (such as "all resolvers that do DNSSEC validation"). The testbed is under active development, and ICANN welcomes extensions to the types of testing that it can perform.
        Speaker: Paul Hoffman (ICANN)
        Slides
      • 19
        DNS Priming Queries 2017
        The number of queries for the '. NS' RRset received at K.root-servers.net today is around 2000/second. This is much higher than what we would expect from well behaved clients. Hence we have studied all priming queries received at K for seven consecutive days in July 2017. This work describes the general characteristics of the priming queries and suggests a classification of client behavior. We will then briefly explore possible strategies for root name servers to improve service to well behaved clients and to support a larger '. NS' RRset.
        Speaker: Mr Daniel Karrenberg (RIPE NCC)
        Slides
      • 20
        Cache Effect of Shared DNS Resolver
        The Domain Name System (DNS) is a key part of the infrastructure of the Internet. Recent discussions have centered on the removal of the shared DNS resolver and the use of a local full-service resolver instead. From the viewpoint of the cache mechanism, these discussions involve removing the shared DNS cache from the Internet. Although the removal of unnecessary parts from a total system tends to simplify the system, such a large configuration change in the system would need to be be carefully analyzed before its actual deployment. This talk presents our analysis of the effect of a shared DNS resolver based on the campus network traffic. Our findings were as follows: 1) this removal can be expected to amplify the DNS traffic by about 3.3 times, 2) the amplification ratio on the root DNS is much higher (about 10.9 times), and 3) removal of all caching systems from the Internet is likely to amplify the DNS traffic by approximately 12.1 times. Thus, the above-mentioned shared DNS resolver removal should not be considered. Our data analysis also revealed: 4) an increase in the number of clients that do not have a local DNS cache and generate repeated queries at short intervals (less than 1 min). 5) Since the amount of traffic from such clients is not small (about 95.0% of total DNS traffic), the deployment of a local cache itself is feasible. This material comes from K. Fujiwara, A. Sato, K. Yoshida, "Cache Effect of Shared DNS Resolver", Proceeding of COMPSAC 2017 (IEEE Computer Society Signature Conference on Computers, Software and Applications).
        Speaker: Mr Kazunori Fujiwara (Japan Registry Services Co., Ltd)
        Slides
      • 21
        DNS over IPv6 - a Study of Fragmentation
        RFC7872 pointed to some issues with the use of IPv6 extension headers in the Internet and noted a failure rate of some 20% of tests when directing IPv6 packets with IPv6 extension headers towards authoritative name servers. This is a study of a test of the ability to pass fragmented IPv6 packets in the opposite direction, namely from authoritative name servers towards visible resolvers. This is a study of the observed drop rate when the authoritative name servers generate fragmented IPv6 responses.
        Speaker: Mr Geoff Huston (APNIC)
        Slides
      • 22
        What's In the Cache?
        Caching resolvers are the backbone of the internet, answering trillion of questions for billions of subscribers every day. Every request is cached until its TTL expires or something else needs to be cached. DNS data researchers often construct queries so they’re not cached, but let’s have a detailed look inside a resolver to see how it reacts to queries from average Joe’s accessing the Internet to do their jobs or just going through their daily routine. What’s served out of cache and what requires resolution? What are the most frequently queried domains? What is validated with DNSSEC? What’s the impact of cache size on the cache hit rate? This session will examine data from a production resolver to answer these questions.
        Speaker: Mr Ralf Weber (Nominum)
        Slides
    • 11:00 AM
      Morning coffee break Regency Ballroom Foyer

      Regency Ballroom Foyer

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • Public Workshop: Security Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 23
        Detecting DGA Botnets Using DNS Traffic
        Cyber security constitutes one of the most serious threats to the current society, costing billions of dollars each year. Botnets is a very important way to perform many attacks. In botnets, the botmaster and bots exchange information through C&C channels, which can be implemented using many protocols. HTTP-based botnets are very common as they are easy to implement and maintain. To improve the resiliency of HTTP-based botnets, bot masters began utilizing Domain Generation Algorithms (DGA) in recent years. In particular, hundreds or thousands of domains can be algorithmically generated every day, but the botmaster only registers one or a few of them as C&C domains and publishes the commands there. DGA technique evades static blacklists, avoids single point of failure, and also prevents security specialists from registering the C&C domain before the botmaster. There are four reasons to detect DGA botnets using DNS traffic. First, the DGA bots have to send DNS queries to look up the IP addresses of C&C domains. Second, the amount of DNS traffic is much less than the overall traffic. Focusing on a relatively small amount of traffic helps to improve performance, making it possible to detect bots in real time. Third, the DNS traffic of DGA bots has different patterns compared to legitimate hosts. For example, DGA bots send more DNS queries than legitimate hosts. Last, if we can detect bots only using DNS traffic when they look for C&C domains, we can stop the attacks even before they happen. In this work, we introduce BotDigger, a system that detects an individual bot by only using DNS traffic collected from a single network. This single network can be a company network, a university network, or a local area network (LAN). Notice that “detecting individual bot in a network” does not mean BotDigger cannot detect all the bots in a network. If there are multiple bots in the same network, BotDigger can still detect them, but individually. BotDigger uses a chain of evidences, including quantity evidence, linguistic evidence, and temporal evidence to detect bots. We evaluate BotDigger with two datasets from Colorado State University and NetSec research lab, as well as two DGA-based botnets. The results show that BotDigger detects more than 99.8% of the bots with less than 0.5% false positives. We have deployed BotDigger at multiple universities and enterprises, including Colorado State University, University of Southern California/ISI, Los Alamos National Lab, and Northrop Grumman. BotDigger is open source and available at GitHub, network administrators at any enterprise can easily deploy BotDigger and detect bots in real-time. In this presentation, we will first talk about DGA botnets. Then, we will discuss why we use DNS traffic to detect DGA botnets and compare BotDigger with other related work. After that, we will describe the methodology of BotDigger, followed by discussions of our deployment at various networks.
        Speaker: Dr Han Zhang (Salesforce)
        Slides
      • 24
        Responsible Reporting / Reporting Responsibility
        While collecting data in the name of research, an operational "guffaw" is detected, or suspected? What is the appropriate next step? Name and shame has been one next step, but is questionable on many fronts. Contacting the operator directly may face many obstacles including, lack of attentiveness, lack of proper registered contact addresses, organization barriers, and so on. Once a "guffaw" is uncovered, does the research bear some responsibility (liability) to report it? The talk is motivated by some on-going research meant to measure the health of a protocol's development. There's no obvious answer to this, but it appears to be a topic worthy of a community discussion and perhaps some best practice style recommendations.
        Speaker: Mr Edward LEWIS (ICANN)
        Slides
      • 25
        What's Lurking in Core Domains
        A “core” domain, aka an “effective 2nd level domain” (e2LD) usually captures domain ownership (www.example1.com, www.example2.co.uk) and is thus a useful marker for analysis of DNS data. New core domains, are particularly interesting, since they’re highly correlated with malicious activity. For the past 5 years we’ve been tracking new core domains and last year undertook a project to greatly improve our infrastructure in order to study them more intensively. This presentation will discuss development of a read/write in-memory processing engine that was used on a 1 million QPS data stream collected from resolvers worldwide. This engine was designed to enable real time processing to reduce noise in the data and evaluate relevance of each query. Typical findings in the data will also be discussed: basic stats such as what percentage of queries to new core domains resolve, first level categorical distribution (benign, returns errors, suspected DGA, scanning, suspicious, confirmed malicious), how often new core domains are queried, by how many IPs, etc. Finally it will discuss methods for turning this raw data into actionable intelligence.
        Speaker: Mr Yuriy Yuzifovich (Nominum)
        Slides
      • 26
        PGP Key Signing Update
        Speaker: Matthew Pounsett (Rightside)
      • 27
        Exercise your organisation
        In order to test how our organization was able to deal with DDoS attacks, we put in place a full-scale test program, the first of which took place a month ago. We know that it is not possible alone to counter this type of attack, but we must be prepared, as an organization, to make the best decisions when this kind of event happen. The primary goal of this first exercise was not only to test the technical skills of our IT team but to verify how communication was organized, how information would circulate and how decisions were made. The attack that wanted to be realistic allowed us to test tools like Drool or SOP. From the preparation to the outcomes and lessons learns, we propose to share our experience on this topic.
        Speaker: Mr Vincent Levigneron (AFNIC)
        Slides
    • 1:00 PM
      Lunch Club Regent (Ground Floor)

      Club Regent (Ground Floor)

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • 28
      PGP Signing Session Redwood Room

      Redwood Room

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      Send your PGP keys to pgpsign@dns-oarc.net before the morning break on Saturday. Please attend Matt's talk about how the PGP signing will be done which will happen during the session after the morning break.
      Speaker: Matthew Pounsett (Rightside)
      Keyring
      Slides
    • Lightning Talks Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • 3:00 PM
      Break (only for members attending the AGM) Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
    • OARC Business / AGM - members only Regency 2 Ballroom

      Regency 2 Ballroom

      Fairmont San Jose

      170 S Market Street, San Jose, 95113, CA, USA
      • 34
        Introduction from OARC Chairman
        Speaker: Duane Wessels (Verisign)
      • 35
        OARC Status Report
        Speaker: Mr Keith Mitchell (DNS-OARC)
        Slides
      • 36
        OARC Engineering Report
        Speakers: Mr Jerry Lundström (DNS-OARC), Mr William Sotomayor (DNS-OARC)
        Slides
      • 37
        OARC Treasurer's Report
        Speaker: Mr Keith Mitchell (DNS-OARC)
        Slides
      • 38
        OARC Governance Resolutions
        Speakers: Duane Wessels (Verisign), Mr Keith Mitchell (DNS-OARC)
        Document
      • 39
        OARC Board Elections
        Speaker: Mr Keith Mitchell (DNS-OARC)
        Slides
    • 40
      Further Dispatches from the DNS Frontier Imperial Ballroom

      Imperial Ballroom

      Fairmont San Jose

      This talk will give an introduction and summary for the wider NANOG71 audience of the latest DNS material freshly presented at OARC27.
      Speaker: Mr Keith Mitchell (DNS-OARC)
      Slides