Name: OARConline 32b
Start: 2020-08-11T12:45:00+00:00
End: 2020-08-11T16:30:00+00:00
Location: No location set

OARConline 32b

Tuesday, August 11, 2020 - 12:45 PM

Monday, August 10, 2020
Tuesday, August 11, 2020

12:45 PM Webinar room opens - while waiting, grab a drink and mingle with your peers at https://chat.dns-oarc.net
Webinar room opens - while waiting, grab a drink and mingle with your peers at https://chat.dns-oarc.net
12:45 PM - 1:00 PM
1:00 PM Welcome - Keith Mitchell (DNS-OARC)
Welcome
- Keith Mitchell (DNS-OARC)
1:00 PM - 1:05 PM
1:05 PM The Current State of DNS Resolvers and RPKI Protection. - Willem Toorop (NLnet Labs)
The Current State of DNS Resolvers and RPKI Protection. (Online Workshop)
- Willem Toorop (NLnet Labs)
1:05 PM - 1:30 PM
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.
1:30 PM LocalRoot -- Serve yourself the DNS root plus - Wes Hardaker (USC/ISI)
LocalRoot -- Serve yourself the DNS root plus (Online Workshop)
- Wes Hardaker (USC/ISI)
1:30 PM - 1:45 PM
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)
1:45 PM Break
Break
1:45 PM - 2:00 PM
2:00 PM Defragmenting DNS - Determining the optimal maximum UDP response size for DNS - Tjeerd Slokker (University of Amsterdam) Axel Koolhaas (University of Amsterdam)
Defragmenting DNS - Determining the optimal maximum UDP response size for DNS (Online Workshop)
- Tjeerd Slokker (University of Amsterdam)
- Axel Koolhaas (University of Amsterdam)
2:00 PM - 2:25 PM
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.
2:25 PM Defining a DNS Statistical Core - Edward LEWIS (ICANN)
Defining a DNS Statistical Core (Online Workshop)
- Edward LEWIS (ICANN)
2:25 PM - 2:50 PM
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.
2:50 PM Additional Q&A / Wrap Up
Additional Q&A / Wrap Up
2:50 PM - 3:00 PM
Time set aside for any additional questions to the speakers.

3:00 PM BYOD OARConline Social Event
BYOD OARConline Social Event
3:00 PM - 4:30 PM