OARConline 32b

UTC
Anand Buddhdev (RIPE NCC), Jan Včelák (NS1), Keith Mitchell (DNS-OARC), Ralph Dolmans (NLnet Labs), Shumon Huque (Salesforce)
Description

DNS-OARC is currently only running online workshops.

The second OARConline will take place on August 11th (13:00 - 15:00 UTC).

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.

DNS-OARC Workshops are open to OARC members and to all other parties interested in DNS operations and research.

Social Media hashtag: #OARC32b and #OARConline

Mattermost Chatroom: Workshops on chat.dns-oarc.net (sign-up here)


WORKSHOP PATRONS 2020


PROMOTER

Verisign

Annual Workshop Patrons for 2020 are available. Details at:

https://www.dns-oarc.net/workshop/patronage-opportunities


OARConline 32b SPONSORS


HOST // DELUXE // ASSOCIATE // CONTRIBUTOR

Your company name here?

Sponsorship opportunities for OARC (online) 32b are available. Details at:

https://www.dns-oarc.net/workshop/sponsorship-opportunities


 

Participants
  • Akira Kato
  • Alejandro Acosta
  • Alexander Dupuy
  • Alexandre Pion
  • Anand Buddhdev
  • Andreas Schulze
  • Andreas Taudte
  • Andrew McConachie
  • Anthony Lieuallen
  • Anthony Maszeroski
  • Arife Vural-Butcher
  • Axel Koolhaas
  • Benno Overeinder
  • Bill Snow
  • Brantly Millegan
  • Brett Carr
  • Brian Hartvigsen
  • Brian Somers
  • Bryan Hughes
  • Carl Clements
  • Carlos Ganan
  • Carsten Schiefner
  • Casey Deccio
  • Cathy Almond
  • Cedrick Adrien Mbeyet
  • Christopher Baker
  • Claudia Erices
  • Cricket Liu
  • Dan Mahoney
  • Daniel Hanks
  • Daniel Stirnimann
  • Dave Knight
  • David Blacka
  • David Kinzel
  • David Lawrence
  • Denesh Bhabuta
  • Dipa Thakkar
  • dmitry kohmanyuk
  • Duane Powers
  • Duane Wessels
  • Eddy Winstead
  • Eduardo Duarte
  • Eduardo Mercader
  • Edward LEWIS
  • Elmar K. Bins
  • Erwin Lansing
  • Florian Obser
  • Fred Baker
  • Frederico Neves
  • Geoff Huston
  • Gonzalo Romero
  • Guillaume-Jean Herbiet
  • Guillermo Cicileo
  • Hanieh Bagheri
  • Henri L
  • Herbert Faleiros
  • Hiro Hotta
  • Hugo Salgado
  • jack tavares
  • James Richards
  • Jan Horak
  • Jan Včelák
  • Jaromír Talíř
  • Jason Livingood
  • Jeff Damick
  • Jen Campany
  • Jerry Lundström
  • Jessy Vetter
  • Jinyuan Feng
  • Joao Luis Silva Damas
  • John Heidemann
  • John Kristoff
  • John Todd
  • Jonas Andersson
  • Jonathan Hewlett
  • Jonathan Reed
  • Jorge Cano
  • Joseph Abley
  • Joseph Crowe
  • Josh Simpson
  • JOTHAN FRAKES
  • Karl Reuss
  • Kazunori Fujiwara
  • Keith Mitchell
  • Keith Rosenblatt
  • Ken Renard
  • Kevin Chen
  • Klaus Darilion
  • Larry Campbell
  • Libor Peltan
  • Lu Zhao
  • Maarten Wullink
  • Manu Bretelle
  • Marc Groeneweg
  • Marco Diaz
  • Marcus Jaeger
  • Mark Andrews
  • Mat Ford
  • Matt Diffenderfer
  • Matthew Pounsett
  • Matthias Pfeifer
  • Mauricio Vergara Ereche
  • Michael Daly
  • Michael Raymond
  • Miles McCredie
  • Milos Milosavljevic
  • Nicholas Kindberg
  • Nicolai Leymann
  • Niek Willems
  • Oleg Obleukhov
  • Oli Schacher
  • Ondrej Sury
  • Otto Moerbeek
  • Pablo Mazzini
  • Pallavi Aras
  • Paul Duffy
  • Paul Ebersman
  • Paul Harris
  • Paul Hoffman
  • Paul Muchene
  • Paul Vixie
  • Peter Davies
  • Peter DeVries
  • Peter Janssen
  • Peter Koch
  • Peter van Dijk
  • Petr Špaček
  • Phil Regnauld
  • Pieter Lexis
  • Puneet Sood
  • Raffaele Sommese
  • Ralf Weber
  • Ralph Dolmans
  • Ray Bellis
  • Ricardo Schmidt
  • Rick Burkinshaw
  • Robert Edmonds
  • Robert Story
  • Roger Murray
  • Roland Dobbins
  • Roy Arends
  • Rubens Kuhl
  • Samaneh Tajalizadeh
  • Sara Dickinson
  • Sebastian Castro
  • Shane Kerr
  • Shaohui Wang
  • Shivan Sahib
  • Shuai Hao
  • Shumon Huque
  • Simon Forster
  • Sion Lloyd
  • Steve DeJong
  • Steven Edwin
  • Steven Parsons
  • Susan Graves
  • Suzanne Woolf
  • Sven Van Dyck
  • Swapneel Patnekar
  • Tamas Csillag
  • Tejas Karandikar
  • Thomas Dupas
  • Tim April
  • Tim Wicinski
  • Tjeerd Slokker
  • Ulrich Wisser
  • Vicky Risk
  • Viktor Dukhovni
  • Wayne MacLaurin
  • Wes Hardaker
  • Willem Toorop
  • Yaroslav Kolomiiets
  • Yazid AKANHO
  • Yoshitaka Aharen
  • Zarko Kecic
    • 12:45 PM
      Webinar room opens - while waiting, grab a drink and mingle with your peers at https://chat.dns-oarc.net

      Sign up for an account on the chat server, via:

      If you are an OARC member contact (ie, with a Portal login), email admin@dns-oarc.net for your specific invitation

      Anyone else via:
      https://chat.dns-oarc.net/signup_user_complete/?id=pr3ycckbc7ygzg38uwyr9kz74y

    • 1
      Welcome
      Speaker: Mr Keith Mitchell (DNS-OARC)
    • 2
      The Current State of DNS Resolvers and RPKI Protection.

      The Border Gateway Protocol (BGP) is responsible for routing on the Internet. BGP has no security measures which makes it prone to IP prefix hijacking and route leaks. To defend against these threads, Resource Public Key Infrastructure (RPKI) has been developed by the IETF. RPKI secures the Internet’s routing infrastructure by signing & validating prefix origin data.

      However, there are still situations that one may indirectly fall victim to prefix hijacks even if their own AS is RPKI protected. A good example of this is the Amazon Route 53 BGP hijack. In this example, the prefixes of the Amazon authoritative DNS servers were hijacked. Any AS with a DNS resolver not protected by RPKI would receive a valid but malicious response from the hijacked authoritative DNS server, even if the AS where the query originated from was RPKI protected. For end-users to be fully protected, in addition to the network in which they reside, they also need their DNS resolvers to be in RPKI protected networks.

      In this talk we will present on a research on the state of RPKI protection of DNS resolvers. We used RIPE Atlas to send queries through the RIPE Atlas probe configured DNS resolvers. The queries resolution was through a CNAME referencing to a domain served on a invalid prefix. This enabled us to determine whether a probe’s DNS resolver was RPKI protected or not. Measurements have been done all DNS Resolvers on all RIPE Atlas probes, hourly since 23rd of January.

      Speaker: Willem Toorop (NLnet Labs)
    • 3
      LocalRoot -- Serve yourself the DNS root plus

      The LocalRoot project at ISI, driven by Wes Hardaker, is a project that allows users to:

      • Deploy a securely-obtained and pre-cached copy of the root and other zones in resolvers
      • Easily implement and deploy a pre-caching technology (like, but not equal to, RFC8806)
      • Receive DNS notifications when the root and other zones change
      • Perform research about the DNS root and other zones

      A talk at DNS-OARC would concentrate on two aspects:

      1. The background behind LocalRoot and its architecture
      2. Recent updates in the infrastructure and new features, which include:
        • IPv6 support
        • LocalRoot now has three upstream name-serves to serve mirrored domains
        • Suport added for generation of additional nameserver configuration:
          • Bind
          • Unbound
          • NSD
        • LocalRoot infrastructure is now in place to mirror zones other than just the root. Currently available zones for mirroring:
          • . (The root zone)
          • .arpa
          • root-servers.net
          • dnssec-tools.org
        • Infrastructure is in place for E-Mailing LocalRoot announcements and error tracking (automated monitoring of your systems coming soon)
        • Selection of E-Mail notifications can be set in the new account preferences page.
        • Multiple usability improvements (its now possible to delete keys, servers, etc)
      Speaker: Wes Hardaker (USC/ISI)
    • 1:45 PM
      Break
    • 4
      Defragmenting DNS - Determining the optimal maximum UDP response size for DNS

      DNS uses the connectionless User Datagram Protocol (UDP) by default, which causes problems with Path MTU Discovery. This is because DNS servers are stateless, and do not remember queries they have already answered. The Path MTU (PMTU) should be used as maximum size to stop fragmentation from happening. Extension Mechanisms for DNS (EDNS(0)) expands DNS with the UDP Message Size field, which communicates the response size capability of the resolver. This allows resolvers to specify the EDNS(0) they support.
      This presentation reports on a research, with as aim to provide data for a considered optimal maximum EDNS(0) UDP message size, by measuring the PMTU to which resolvers and stub resolvers on the Internet are subject. We did this by creating an environment to serve different sized DNS responses and querying this environment across the Internet. This aligns with the goals DNS Flag Day 2020. Our ambition is to suggest defaults for the maximum EDNS(0) message size for DNS.

      Speakers: Axel Koolhaas (University of Amsterdam), Tjeerd Slokker (University of Amsterdam)
    • 5
      Defining a DNS Statistical Core

      For the purposes of long-term statistical studies of the DNS, a "DNS Statistical Core" is introduced. This is meant to be a basis for statistical studies but the development of the core's map has been its own interesting project. "Core" in the name refers to the inclusion of the global public Internet's root zone, top-level zones, reverse map zones and other affiliated zones, relying mostly on access to reports of process activity related to the Root Registry, widely available zone files and other resources. The map produces JSON-formatted files for consumption by observation and analysis scripts, with easy access to many features of zones, nameservers, and addresses involved.

      Speaker: Edward LEWIS (ICANN)
    • 6
      Additional Q&A / Wrap Up

      Time set aside for any additional questions to the speakers.

    • 3:00 PM
      BYOD OARConline Social Event

      Time to catch up with industry peers and colleagues. This will be a free-flow session and we will facilitate online breakout rooms if needed. Details will only be sent to those who attend the main Workshop prior to this.