Conveners
OARC 42 Day 1: Session 1
- Petr Špaček (Internet Systems Consortium (ISC))
- Suzanne Woolf (Public Interest Registry (.ORG))
OARC 42 Day 1: Session 2
- Suzanne Woolf (Public Interest Registry (.ORG))
- Petr Špaček (Internet Systems Consortium (ISC))
OARC 42 Day 1: Session 3
- Puneet Sood (Google)
- Benjamin Schwartz (Meta)
OARC 42 Day 1: Session 4
- Benjamin Schwartz (Meta)
- Puneet Sood (Google)
Since the 2016 DDoS against Dyn, common wisdom has been to use multiple authoritative vendors for your edge.
We wanted to quantify the behavior of resolvers when one authoritative edge failed completely. To our surprise, some resolvers never shifted away from the failing authoritative servers.
This presentation covers this experiment and gives a summary of the results.
The fpdns tool was first introduced more than 20 years ago. It gained popularity in both research and operational communities, and was actively used to fingerprint DNS software at scale. Unfortunately, it has not been updated for a while. We are currently working on its successor - fpdns2. We set up more than 670 instances of recursive resolver software from 7 vendors and issue a series of DNS...
Recent experience changing delegations for an akamai domain resulted in some unexpected outcomes and useful observations. To improve IPv6 reachability we recently updated delegations for a widely used domain, adding glue records.
Although it resulted in a DNS record size beyond 1223 bytes experienced team members conferred and felt the presence of numerous RFCs specifying the use of TCP...
Recursive resolvers can aggressively requery Root and TLD authoritative name servers when all authoritative name servers for a zone return REFUSED or SERVAIL. These resolution failures consist of the same query tuple <QNAME, QTYPE, QCLASS> being asked repeatedly at an unexpectedly high rate. The cause of the excessive traffic is almost always related to aggressive resolver retry logic and...
In my talk I plan to summarize the properties of
PCH's DNSSEC bump in the wire signer from 2010.
(which was based on bind9 and custom code in c/bash/perl)
What were our goals and motivations for the upgrade.
Why we ended up choosing knot as a replacement signer.
Our process include a keysigning ceremony where ZSKs are generated and RRSIGs for those keys years in advance.
I will...
In 2023 operations for the .GOV TLD transitioned from Verisign to Cloudflare. One interesting aspect of this transition was the different approaches to DNSSEC signing by Verisign and Cloudflare. Whereas Verisign uses offline signing with RSA (algorithm 8) and NSEC3, Cloudflare generally uses online signing with ECDSA (algorithm 13) and NSEC.
Although the parties agreed to transition using...
In 2023, Verisign changed the DNSSEC signing algorithm for the .EDU, .NET., and .COM TLDs from RSA (algorithm 8) to ECDSA (algorithm 13). In this presentation we describe our conservative, double-signing approach to the algorithm rollovers, and our observations on how DNS query traffic before, during, and after each rollover.
In particular, we make observations on how DNS glue truncation...
A presentation about the KSK algorithm rollover that was done for .nl.
This will be based on the information we already published a blog posts on our...
A new delegation record is now being discussed for standardization at the IETF, the DELEG record. It is an extensible signal at the parent side of a delegation that modern resolvers can select authoritative nameservers based on features described in the delegation, not just their name. For example, support for existing standards like DNS over TLS or DNS over QUIC could be signaled...
Currently, the DNS community has limited visibility of the capabilities and deployed features of the millions of recursive resolvers in use across the internet. A helpful source of data has been provided by APNIC over the last decade or so by the use of Google Ads but it has been felt that having alternative more accessible methods of collecting this data would be advantageous and provide...
