Conveners
OARC 47 Day 1: Day 1 Session 1
- Cathy Almond (Internet Systems Consortium)
OARC 47 Day 1: Day 1 Session 2
- Cathy Almond (Internet Systems Consortium)
OARC 47 Day 1: Day 1 Session 3
- Willem Toorop (NLnet Labs)
OARC 47 Day 1: Day 1 Session 4
- Willem Toorop (NLnet Labs)
Large recursive resolvers see significant amounts of unique DNS name/qtype/rrdata tuples, and as part of threat intelligence or other analysis work it is necessary to process and store these unique tuples in an effective and economic manner. The use of cuckoo filters (similar to Bloom filters) is a useful tool in understanding what objects have been seen before, in a way that minimizes...
With Comcast vCMTS Edge Compute providing internet services to tens of millions of broadband access subscribers, work is underway to move DNS Service to locations significantly closer to Comcast subscribers for lower latency and smaller blast-radii. This presentation describes Comcast’s architecture for deploying DNS caching services in the vCMTS Edge Compute environment while preserving...
CNAME and delegation loops are well-known causes of recursive resolver instability and unnecessary upstream traffic. Although modern resolvers ultimately terminate these failures, they differ substantially in how quickly they recognize a loop, how much work they permit before failure, and whether they suppress repeated equivalent work afterward.
This presentation compares CNAME and...
The DNS can be quite extravagant in the number of queries used to resolve a DNS Name. This presentation compares measurements from 7 years ago of query repetition against the current measurements, and explores the likely causes of repetition.
The presentation also looks the various ways to give a negative answer and relates each method to the consequent query profile.
Using APNIC Labs' ad-based measurement system (daily collection since November
2025 to June 2026, 7.4+ billion unique query IDs), we examined resolver-to-
authoritative traffic in two ways that, to our knowledge, have not been done before.
First, we separate queries into per-resolver fluxes — ISP IPv4, ISP IPv6, each public
DNS service individually, and other resolvers in- and...
DNS apparently works Just Fine™ without NS records in child zones.
This presentation will focus on dangers attributed to clients when they use a parent validating DNSSEC resolver. Specifically, we will quickly highlight an attack associated with parent-centric resolvers that choose not to validate the upstream delegation information. We’ll follow this with some attack demonstrations of the types of malicious activity that can be accomplished because of this...
This paper presents a cross-RFC formal analysis of DNSSEC specifications, built on the SAPIC+ symbolic verifier, modeling cross-RFC interactions including cryptographic operations and stateful caching. We verify four core security guarantees: data origin authenticity, integrity, chain of trust, and authenticated denial of existence. Our analysis shows that core authentication properties hold...
Experiences from implementing PQ DNSSEC using MLDSA44 on public resolver 1.1.1.1, Cloudflare authoritative DNS and Cloudflare Registrar.
Measurements such as qps, latency, resource utilization, resolve success/failure, validation success/failure.
How customers can enable MLDSA44 on their zone and start testing with 1.1.1.1 or their own resolvers to validate PQ DNSSEC signatures.
DNS zone misconfigurations are a notorious source of outages and frustration, particularly when DNSSEC is involved. Previous research has attempted to address the problem of zone misconfigurations using formal reasoning methods, but all existing proposals (i) suggest verifying only the absence of specific, known classes of misconfiguration and (ii) do not consider DNSSEC.
We have developed...
We present a large-scale measurement study of NSEC and NSEC3 behavior across 174 million domains in the .com, .net and .org zones, together with domains drawn from four major popularity rankings. Characterizing denial-of-existence implementations in the wild is challenging due to provider-specific deployments. To address this, we introduce new statistical metrics to distinguish heterogeneous...
In June 2026, we started daily measurements of DNSSEC status for all TLDs. The data is displayed and can be analyzed in various ways on a web site (https://desec-io.github.io/tld-dnssec-timeline/). In order to obtain a full timeline, we've also imported historic data.
I'd like to quickly explain what's measured and how, and then showcase a few things that can be inspected on the web site.
