OARC 27 (San Jose)

29 Sept 2017, 08:25 → 3 Oct 2017, 14:00 US/Pacific

Regency 2 Ballroom (Fairmont San Jose)

Keith Mitchell (DNS-OARC), Ray Bellis (Internet Systems Consortium, Inc.)

 

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

---

PREMIUM SPONSOR

---

BENEFACTOR SPONSORS

     

---

CONTRIBUTOR SPONSORS

---

 

Video:

• Friday morning session 1
• Friday morning session 2
• Friday afternoon session 1
• Friday afternoon session 2
• Saturday morning session 1
• Saturday morning session 2
• Saturday afternoon session 1
• Saturday afternoon session 2

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.

Document

• 2016 Financial Statements
• AGM Resolution 1
• AGM Resolution 2
• Proxy Form (updated)

Slides AGM 2016 Minutes OARC27-StaticSlides.pdf

Friday, 29 September

08:30 → 09:30 Registration

09:30 → 11:00 Public Workshop: DNSSEC

09:30 Workshop Opening

Speaker: Mr Keith Mitchell (DNS-OARC)

Slides OARC27-Intro.odp OARC27-Intro.pdf

09:40 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 wessels-key-tags-v5.pdf

10:10 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 oarc-scottr-dnssec-gov-ops.pptx

10:25 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 Slides (1.2)

11:00 → 11:30 Morning coffee break

11:30 → 13:00 Public Workshop: Operations #1

11:30 How Dual DNS Improves Resiliency

http://prezi.com/snfdsqsoywtm/

Speaker: Mr Samir Jafferali (LinkedIn)

Slides DNSOARC_MultiDNS.pdf

11:45 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 dns-oarc-hardaker-verfploeter.pdf

12:15 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 High-Proof_Data.pdf

12:30 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 Lagerholm_-_IPv6_only_-_T-Mobile_-_DNSOARC_v2.pdf

13:00 → 14:30 Lunch

14:30 → 16:00 Public Workshop: Operations #2

14:30 Real User Measurement DNS - Using Big Data to decide RData

Slides at http://prezi.com/yhvism0pufps/

Speaker: Mr Samir Jafferali (LinkedIn)

Slides DNSOARC_RUMDNS.pdf

14:45 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 DNS-OARC-27-presentation-RFC7706-8198.odp DNS-OARC-27-presentation-RFC7706-8198.pdf

15:15 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 DNS_Service_Monitoring_at_Salesforce.pptx

15:30 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 2017-09-29-rrl-oarc.pdf 2017-09-29-rrl-oarc.pptx (Protected)

16:00 → 16:30 Afternoon coffee break

16:30 → 18:00 Public Workshop: Protocol and Implementations

16:30 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 OARC_27_DNS_Privacy_clients.pdf

16:45 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 refactor.pdf

17:00 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 OARC_27_DNS_Sessions.pdf

17:30 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 ALIAS_DECK.pdf

18:00 → 18:30 ICANN Root KSK Roll Discussion

Speaker: Paul Hoffman (ICANN)

Slides Root_KSK_roll_update_for_DNS-OARC_2017-09-29.pptx

18:30 → 21:00 Social Event

Saturday, 30 September

08:30 → 09:00 Registation

09:00 → 11:00 Public Workshop: Testing and Measurement

09:00 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 Flexible_Testbed_for_Recursive_Resolver_Software_v1.pdf

09:30 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 dnsoarc.html

09:45 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 fujiwara-20170930.pdf

10:15 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 2017-09-29-xtn-hdrs-dns.pdf

10:30 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 WhatsInTheCache.pdf

11:00 → 11:30 Morning coffee break

11:30 → 13:00 Public Workshop: Security

11:30 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 Detecting_DGA_Botnets_Using_DNS_Traffic.pptx

12:00 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 ReportingResponsibility.pdf ReportingResponsibility.pptx

12:10 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 DNS_OARC_-_What's_Lurking_in_New_Core_Domains.pdf

12:40 PGP Key Signing Update

Speaker: Matthew Pounsett (Rightside)

12:45 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 Distribution of this slide deck is restricted at the presenter's request.

13:00 → 14:15 Lunch

13:25 → 14:05 PGP Signing Session

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 OARC 27 PGP Key Signing keyring

Slides keyparty.pdf

14:15 → 15:00 Lightning Talks

14:15 .SE Algorithm Rollover

Speaker: Ulrich Wissser (IIS)

Slides SE-Algorithm-Rollover.pdf

14:20 Practical Metazones

Speaker: Shawn Instenes (Salesforce)

Slides https://docs.google.com/presentation/d/19DCZ3XgjRiEnh84zJLk62EVFSsaJGZms0-yNF8GGqhE/edit?usp=drivesdk Practical_Metazones.pdf

14:30 Understanding traffic sources seen at .nz

This talk is to share my progress on source IPs cluster analysis, which is to apply the unsupervised machine learning techniques to find different patterns in the DNS traffic seen at the .nz authoritative nameservers.

Speaker: Jing Qiao (NZRS)

Slides Understanding_traffic_sources_seen_at_.nz.pdf

14:40 .internal

Speaker: Warren Kumari (Google)

Slides

• http://slides.com/wkumari/deck-f68ee558-abac-4af2-9357-5669734d3445-6/fullscreen?token=0nmevptH
• http://www.owl-stretching-time.com/oarc.html
• internal-oarc.pdf

14:50 Deprecating RFC5074

Speaker: Dan Mahoney (ISC)

15:00 → 15:30 Break (only for members attending the AGM)

15:30 → 18:00 OARC Business / AGM - members only

15:30 Introduction from OARC Chairman

Speaker: Duane Wessels (Verisign)

15:35 OARC Status Report

Speaker: Mr Keith Mitchell (DNS-OARC)

Slides OARC27-AGM-report_17.odp OARC27-AGM-report_17.pdf

16:05 OARC Engineering Report

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

Slides 201709_OARC_Systems_Update.pdf OARC27-DNS-OARC-Software.pdf

16:45 OARC Treasurer's Report

Speaker: Mr Keith Mitchell (DNS-OARC)

Slides OARC27-Treasurers-report.odp OARC27-Treasurers-report.pdf

17:00 OARC Governance Resolutions

Speakers: Duane Wessels (Verisign), Mr Keith Mitchell (DNS-OARC)

Document Special Resolution 1 Special Resolution 2

17:30 OARC Board Elections

Speaker: Mr Keith Mitchell (DNS-OARC)

Slides OARC27-AGM.odp OARC27-AGM.pdf

Tuesday, 3 October

13:30 → 14:00 Further Dispatches from the DNS Frontier

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 NANOG71-OARC-Mitchell.pdf