OARC 47 (Vancouver, BC)

8 Nov 2026, 09:00 → 11 Nov 2026, 16:30 America/Vancouver

Asia Pacific Hall (Morris J. Wosk Centre For Dialogue, SFU)

Cathy Almond (Internet Systems Consortium), Dave Knight (OARC, Inc.)

OARC 47 will be a hybrid in-person and online workshop. 

The workshop will be held in Vancouver, British Columbia on November 09-10th, 2026

---

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: #OARC47 #LoveDNS 

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

Schedule Overview

• Newcomers’ Dinner
  8 November, 18:00–20:00 PCT
  • By invitation only. First-time attendees interested in attending should indicate this during registration. We will contact invited attendees.
• Workshop Day 1
  9 November, 10:00–17:00 PCT
• Workshop Day 2
  10 November, 09:30–15:15 PCT
• Members’ AGM
  10 November, approximately 15:45–17:45 PCT
• Community-led Sessions 08:30 - 16:30 PCT    
  
  • These will be held in the Delta Hotel next door. Space is limited for Community sessions
    
    

 All times are local Vancouver time, Pacific Time.

 

---

OARC ANNUAL WORKSHOP PATRONS 2026

 

---

Workshop Patronages for 2026 are available. Details at:

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

---

 

 

---

OARC 47 SPONSORS

---

Sponsorship opportunities for OARC 46 are available. Please contact us for details.

 

SOCIAL SPONSOR

Sunday 8 November

Newcomer's Dinner (Invitation Only): Newcomer's Dinner

This First-Time Attendee Mentor Mixer is a relaxed networking event designed to help first-time DNS-OARC workshop attendees connect with experienced community members before the workshop begins.

This informal gathering provides an opportunity to meet your mentor or mentee, make introductions, ask questions, and begin building connections in a welcoming environment before the opening sessions.

Please note: This is an invite-only event for participants in the DNS-OARC Mentor Program and is not included with workshop registration. Invitations are sent directly to confirmed mentors and mentees prior to the workshop.

Monday 9 November

09:00 In-Person Registration

OARC 47 Day 1: Day 1 Session 1

Convener: Cathy Almond (Internet Systems Consortium)

1 Welcome to OARC 47

Speaker: Dave Knight (OARC, Inc.)

2 PC Session Chair introduces Session 1 Day 1

3 Cuckoo Clock: Managing billions of names

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 resource (memory, bandwidth, CPU, disk) use.

Quad9 has developed (with funding assistance from Nominet) a new OSS Rust library called "Cuckoo Clock" that extends the standard cuckoo filter to include TTLs, Least Recently Used cache deletions, and counters. This new library has been implemented in Vector (an OSS telemetry management tool) allowing DNS-specific usage at planet-scale query volumes without custom code.

This talk will briefly address the theory of use for cuckoo filters for DNS data, but will more directly address how the filter is used for Quad9's daily distillation of hundreds of billions of names into a much smaller set of around 2 billion UDRs (Unique DNS Responses.) This method can serve as a case study for any organization interested in how to quickly sift through large amounts of highly-duplicated DNS data using relatively inexpensive hardware and open-source software.

Speaker: John Todd

4 ISP Customer DNS on Edge Compute

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 existing customer-facing anycast addresses and operational models. Rather than relocating recursive resolution, the initial design places DNS caches at the edge and retains centralized resolvers, allowing subscriber traffic to benefit from reduced latency while minimizing risk and migration complexity.
The session will cover the routing and used to advertise Do53 and DoH anycast services directly from edge locations, including health-monitored route injection, automated failure handling, and operational controls that allow selective participation in the anycast service. We will examine how encrypted DNS (DoH) was integrated into the platform using a dual-anycast IP approach and static service dependencies that eliminate traditional GSLB requirements while coupling service availability to the local DNS cache failure domain.
Attendees will also get an in-depth look at the implementation details behind running high-performance DNS workloads in Kubernetes-based edge environments. Topics include design tradeoffs between pod-level and cluster-level service models, reasons for avoiding traditional load-balancer approaches, the use of SR-IOV to steer anycast traffic directly into dedicated DNS cache workloads, health-monitoring and route-control mechanisms, deployment automation, and the telemetry and alarming systems used to operate DNS at hundreds of distributed edge locations. The presentation concludes with lessons learned from bringing one of the Internet’s largest ISP DNS services closer to subscribers while preserving reliability, operational simplicity, and existing customer configurations.

Speaker: Charlie Helfinstine (Comcast)

11:00 Day 1 Morning Break

OARC 47 Day 1: Day 1 Session 2

Convener: Cathy Almond (Internet Systems Consortium)

5 PC Session Chair Introduces Session 2 Day 1

6 Beyond Loop Limits: Comparative Analysis of CNAME-Loop Handling in Recursive Resolvers

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 delegation-loop handling in BIND 9, Unbound, and OpenDNSCache along four dimensions: exact cycle detection, CNAME-chain limits, bounds on recursive work, and resolution-failure caching and observability. BIND 9 and Unbound provide layered limits on recursive work and targeted detection of fetch or dependency cycles; for ordinary CNAME chains, both principally rely on configurable restart or chain-length limits. OpenDNSCache detects repeated names in its primary CNAME chain, allowing earlier termination of simple alias cycles, but relies on alias limits and state-machine loop bounds for nested NS-address and other recursive dependency cases.

We examine the operational consequences of these design choices under malformed and potentially malicious CNAME-loop patterns: upstream-query amplification, repeated client-triggered work, cache behavior, and observability of the actual failure cause. The goal is not to suggest that common resolvers fail to stop loops—they do—but to distinguish bounded failure from an early, explainable, and efficiently suppressed failure.

We present measurements of the upstream-work reductions achieved through exact cycle signatures and cycle detection spanning CNAME, delegation, and NS-address dependency paths. Finally, we evaluate short-lived, loop-signature-keyed failure caching and telemetry that distinguish loop-induced SERVFAILs from ordinary upstream failures, extending RFC 9520’s requirement to cache resolution failures.

Speakers: Dr Dejan Donin (Cisco), Sean Mooney (Cisco Systems Inc)

7 DNS Resolution Behaviour

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.

Speaker: Geoff Huston (APNIC)

8 Can you hear me?

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 out-of-country. We then
perform statistical analysis within each flux. Second, we look up close at the first few
milliseconds of every unique query's life, and beyond: the initial query at 0ms,
immediate duplicates at <10/30/100ms, timeout retransmissions from 300ms to 30s,
and "zombie" replays arriving after 30s — per RR type (A, AAAA, HTTPS).
That analysis exposes several findings that have an operational impact.

Speaker: Alain Durand (ICANN)

12:45 Day 1 Lunch Break

Day 1 Featured Recorded Sessions: OARC 47 Day 1

9 WeirDNS: Measuring Bogon Address Exposure in DNS

Bogon IP address space includes private, reserved, special-purpose, and unallocated IP ranges that are generally not expected in public DNS responses. Nevertheless, these addresses appear frequently in passive DNS data, and their presence does not always have the same operational meaning.

DNS answers containing bogon addresses can reveal how organizations name and connect services under operational constraints. Private address plans, cloud migration, automation, and security practices can all leave fingerprints in DNS. Our contribution is to investigate this signal at scale and distinguish some of its dominant mechanisms.

In this talk, I present an empirical characterization of domain names and resource record sets associated with bogon addresses. Using longitudinal passive DNS observations, we analyze their prevalence over time, address categories, record types, naming patterns, and likely operational contexts.

Speaker: Fariba Osali (Max Planck Institute for Informatics)

10 Seeing DNS Differently: Interactive Exploration of a Year of Passive DNS

Long-term passive DNS data contains patterns that are difficult to uncover through conventional analysis. Aggregating large datasets is necessary for scalability, but overly aggressive aggregation can hide temporal patterns and unexpected behavior. Moreover, different users may be interested in different aspects of the same traffic, making fixed analyses and visualizations limiting.

We present an interactive visualization system for exploring passive DNS traffic, and showcase said system with data collected from a university recursive DNS server. The system combines large-scale filtering and aggregation with interactive temporal visualizations, allowing users to dynamically change the time range, granularity, and traffic being analyzed. Rather than presenting a predefined set of results, the system is designed as an exploratory environment where users can follow unexpected patterns, investigate anomalies, and formulate new questions while interacting with the data.

We demonstrate the approach through several unusual observations found in the year-long dataset, showing how changing the perspective and aggregation level can reveal behaviors that are difficult to identify in conventional analyses.

Speaker: Kim Morgan de Oliveira Ito Porto (Sao Paulo State University (UNESP))

OARC 47 Day 1: Day 1 Session 3

Convener: Willem Toorop (NLnet Labs)

11 PC Session Chair Introduces Session 3 Day 1

12 DNS without Child NS Records

DNS apparently works Just Fine™ without NS records in child zones.

Speaker: Shane Kerr (IBM)

No NS.pdf

13 Subverting parent-centric resolvers

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 failing to validate delegation records. During the demonstration, I will show how a carefully positioned partial man-in-the-middle can increase their attack surface to the rest of the domain name system in some cases. Using this approach, I will then demonstrate how some important DNS records can be manipulated that would not normally have been visible to the attacker before this attack took place. The ramifications of each of these record types under attack will be discussed, along with the vulnerabilities each record type reveals. Finally, I will conclude with an evaluation of the pros and cons of selecting client-centric vs parent-centric resolvers.

Speaker: Wes Hardaker (Google and USC/ISI)

14 Mind the Gap: Cross-RFC Formal Analysis Exposes DNSSEC's Hidden Vulnerabilities

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 as specified, while wildcard expansion, the mechanism that bridges positive and negative authentication, exhibits a cross-RFC interaction vulnerability that defeats DNSSEC's integrity guarantee.

Specifically, we discover Cross-Zone Wildcard Cache Poisoning: a new attack in which a malicious zone operator exploits a gap in the DNSSEC specifications to poison resolver caches with forged records for domains outside its authority, served to clients as DNSSEC-authentic. All four major resolvers that implement the affected caching optimization are vulnerable under default configurations, and all four vendors have confirmed the vulnerability and adopted our proposed fix. To our knowledge, this is the first protocol-level attack in which a conformant validator completes validation and serves attacker-chosen positive data when the Authenticated Data (AD) bit in a response is 1: prior attacks instead exhausted availability, downgraded to AD=0, or skipped validation.

Our models additionally surface two cross-RFC denial-of-service flaws and rediscover three known attack classes. We confirm real-world impact through testing of six DNS resolvers and an Internet-scale scan of 2.24 million open resolvers, and propose updates to four RFCs to close these gaps.

Speaker: Dr Qifan Zhang (Palo Alto Networks)

DNSSECVerif — DNS OARC 47.pdf

15:15 Day 1 Afternoon Break

OARC 47 Day 1: Day 1 Session 4

Convener: Willem Toorop (NLnet Labs)

15 PC Session Chair Introduces Session 4 Day 1

16 Measuring PQ DNSSEC performance at Cloudflare

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.

Speaker: Vicky Shrestha (Cloudflare DNS)

17 Are your Zones Resolvable? Automatically Detecting DNS(SEC) Misconfigurations with Formal Reasoning

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 a new formal model of recursive resolution in the DNS that, to our knowledge, is the most complete model to date, capturing the full complexity of DNSSEC. The model was designed to reason about the resolvability of zones: which queries can be resolved under a given configuration. Instead of verifying the absence of a predefined set of undesirable properties, we verify the desirable property of resolvability. Our model compares how changes to a zone configuration impact which queries can be resolved, allowing it to naturally detect many misconfigurations without explicitly searching for them.

In this talk, we will present our new model and its implementation and demonstrate how it can naturally discover DNS zone misconfigurations. We validate our methodology both formally, proving the soundness of its reasoning, and empirically, testing its conformance with major recursive resolver implementations. This testing is only possible because our model incorporates all relevant standards, including those that specify DNSSEC. Finally, we outline how our approach could be integrated into operational practice to support real-world DNS management.

Speaker: Felix Linker (ETH Zürich)

18 Dissecting NSEC and NSEC3 Deployment in the Wild

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 Compact Denial of Existence (CDE) and White Lies deployments across DNS providers.

We further examine the interaction between authenticated denial-of-existence responses and wildcard synthesis. Our measurements suggest that wildcard behavior is non-negligible, potentially affecting approximately 19% of NSEC-enabled and 15% of NSEC3-enabled .com domains. We also analyze transitions between NODATA and NXDOMAIN responses across different levels of the DNS hierarchy. These transitions show where wildcard synthesis ceases to apply and can reveal limited information about zone structure, including the presence of closest-encloser boundaries.

Compared with the prior NSEC/3 presentation in DNS-OARC 44, our study:
- Expands the Measurement Scope: Evaluates current NSEC and NSEC3 deployments across three major gTLDs and multiple popularity lists.
- Characterizes In-the-wild Deployment: Develops new metrics to identify heterogeneous NSEC and NSEC3 variants and the name servers associated with these behavior.
- Deepens the Wildcard Analysis: Provides a detailed look at wildcard synthesis and its operational interactions with authenticated denial-of-existence responses.

Speaker: Yixin Sun (University of Virginia)

19 TLD DNSSEC Timeline

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.

Speaker: Peter Thomassen (deSEC)

2026-11-09 DNS OARC 47, TLD DNSSEC Timeline.pdf

20 Social Sponsor

21 PC Session Chair Closes Day 1 OARC 47

18:00 OARC 47 Social

Tuesday 10 November

09:00 In-Person Registration

OARC 47 Day 2: Day 2 Session 1

Convener: Merike Kaeo (Double Shot Security)

22 PC Session Chair Introduces Session 1 Day 2

23 A data-driven approach to migrating your DNS anycast platform

SIDN has been operating its own DNS anycast platform for a few years using Equinix Metal. Unfortunately, Equinix decided to sunset this service mid 2026, so we were forced to migrate.

After selecting a new vendor, we decided to adopt a data-driven approach; using the well-tried Manycastr tool, we collected data from all available i3D PoPs to all resolvers querying for the .nl TLD. From this data, we predicted the optimum deployment which would minimize latency world-wide, ensure resilience and save on costs. Flow data obtained from the i3D routers corroborates our prediction that very little DNS traffic is routed sub-optimally.

To continue measuring in production, we wrote Go tooling called Tapdance. Using dnstap data, this open-source tool continues to measure latency to all active resolvers. Latency data is graphed using InfluxDB, and helps us to continue optimizing performance and resilience of the platform.

Speakers: Jeroen Bulten (SIDN), Mr Martijn Schmidt (i3D.net)

24 Trust your paths: routing security for DNS infrastructure operators

DNS operators instrument the DNS layer closely — query volume, latency, resolution failures, DNSSEC validation — but the routing layer underneath is usually a blind spot. Anycast DNS services, root servers, and authoritative infrastructure all depend on BGP announcing the right origin AS over a legitimate path, and when that breaks, DNS-layer signals often stay healthy right up until they don't.

This talk looks at why that gap matters through three real incidents: the June 2024 outage of Cloudflare's 1.1.1.1 resolver, caused by an origin hijack and a separate route leak within the same hour; the 2018 hijack of Amazon Route 53 DNS infrastructure that led to $150,000 in stolen cryptocurrency; and a 2023 hijack attempt against A-root that was nearly invisible because of anycast's own self-healing behavior. Each incident needed a different validation mechanism to catch — RPKI Route Origin Validation (ROV) for origin hijacks, ASPA path validation for the route leak that ROV can't see — which is the core argument of the talk: DNS operators running their own ASNs and anycast networks need both, not one or the other.

We'll walk through how ROV and ASPA each work, what failure mode each one catches, and then run a live demo: replaying a hijack and a route leak against an anycast-style DNS topology in Containerlab, showing what DNS-layer monitoring alone would see (nothing, or misleading latency) against real-time ROV+ASPA validation catching both. The demo runs on RAVEN, an open-source, single-binary, BSD-3-Clause tool that ingests BGP via BMP and validates it against a standard RPKI/RTR feed — no external measurement infrastructure required. We'll close with what's realistic for a DNS operator to deploy today.

Speaker: Ritesh Mukherjee (Nokia)

OARC 47 - Trust your paths.pptx

25 How a DNS Resolver Bug Doubled Root Server Traffic for a Week

On June 30th, 2026 the root server operators observed an increase in query rates to approximately double normal levels. The additional traffic originated from a small number of related autonomous systems and, while significant in terms of volume, did not appear to be an attack.

Upon establishing contact with the originating network, they were able to identify the reason and roll back recent changes, which returned traffic to previous levels. Additionally, they were able to point to a known bug in the open source software they use as the root cause.

Speaker: Duane Wessels (Verisign)

26 RDAP in Practice: Modernizing Internet Registration Directory Services

RDAP has become the IETF-standard protocol for accessing Internet number registration data, offering structured responses, HTTPS transport, authentication, and extensibility beyond the capabilities of traditional WHOIS. A transition from WHOIS to RDAP represents more than a protocol change - it represents a significant evolution in how Internet number registration data is accessed, secured, and integrated into operational workflows.
This presentation explores ARIN's implementation and future direction for RDAP, discusses lessons learned during deployment, and examines how modern directory services support automation, security, and operational resilience. Attendees will also gain insight into interoperability across Regional Internet Registries and considerations for developers integrating RDAP into existing tools.

Speakers: Amanda Gauldin (ARIN), Mr Mark Kosters (ARIN)

11:00 Day 2 Morning Break

OARC 47 Day 2: Day 2 Session 2

Convener: Ulrich Wisser (IIS)

27 PC Session Chair Introduces Session 2 Day 2

28 Operationalizing the DNS for Drone Identity with DRIP

The Domain Name System has traditionally provided a hierarchical namespace for identifying Internet hosts and services. Emerging applications such as drones and IoT devices extend this role beyond conventional Internet resources, requiring not only globally unique identification and resolution, but also new mechanisms to establish trust, such as cryptographically binding an identifier to the entity that owns it.

The IETF Drone Remote ID Protocol (DRIP) is an interesting example of such a namespace. DRIP Entity Tags (DETs) are IPv6-formatted, self-certifying identifiers derived from an entity's public key, organized through a hierarchy of Registered Assigning Authorities (RAAs) and HHIT Domain Authorities (HDAs). DNS and DNSSEC handle the publication, delegation, and authentication of information associated with these identities.

This presentation reports on our implementation of and experimentation with this architecture, including work done during the recent IETF 126 hackathon. We built DET generation and registration, RAA/HDA namespace delegation, DNS and DNSSEC integration, and an end-to-end proof of concept that carries drone identity information from a transmitter to an observer. Working through these pieces lets us go beyond the specifications and see how a namespace like this would actually behave in practice.

DRIP is a concrete case study for a bigger question on how DNS infrastructure and registry practices need to evolve to support namespaces that hold large numbers of cryptographically derived identities for physical devices. We'll cover what we learned from the current proof of concept, where it falls short, and the additional operational and security scenarios that still need to be addressed before something like this could run at Internet scale.

Speaker: Mr Sandoche BALAKRICHENAN (Afnic)

29 How Long Is Too Long? A Fleet-Scale Census of Domain Label Depth to Right-Size QNAME Minimization

QNAME minimization (RFC 7816 / RFC 9156) reduces the information a recursive resolver leaks to upstream authoritative servers, but it does so by walking a name's label hierarchy one query at a time. For the vast majority of names this costs little, but for names with an unusually deep label structure, the same incremental walk can multiply the number of upstream queries needed to resolve a single lookup. This tradeoff is well understood in theory, but there is little published data on how often it actually occurs in production traffic, or at what depth it starts to matter operationally.

We present a fleet-wide measurement of domain name label-count distribution, collected across 700+ resolver instances spanning 50 globally distributed data centers and covering hundreds of billions of queries. We characterize the shape of this distribution, with particular attention to its tail, and identify the point at which increasing label depth stops reflecting legitimate zone structure and starts reflecting degenerate, misconfigured, or adversarial names. We use this data to reason about where a practical cutoff belongs: a maximum label count beyond which QNAME minimization is disabled for that specific query, preserving the privacy benefit for the overwhelming majority of real-world names while avoiding disproportionate query amplification for the rest.

We then describe how we turned this measurement into an operational safeguard — a configurable threshold in our resolver's runtime configuration, rather than a hardcoded limit — and share our methodology so other operators, can replicate what we did and derive a threshold suited to what they actually see, rather than an arbitrary number.

Speakers: Mr Adam Phelps (Cisco Systems Inc), Prashanth Suvarna (Cisco Systems/OpenDNS), Sean Mooney (Cisco Systems Inc)

30 Opportunistic Operator Transport Signalling (OOTS)

Opportunistic encryption of recursive to authoritative transports (Op-ADoX) is still in the early days of development and deployment. Unilateral (but blind) probing of alternative transports suggested in RFC9539 has seen only limited deployment to-date for a variety of reasons, and end users are not yet benefiting from the range of protections offered by Op-ADoX.

In this talk we will describe an new mechanism that enables a more controlled deployment of Opportunistic encrypted transports: Opportunistic Operator Transport Signaling mechanism (OOTS). This signalling is based on SVCB records which can contain a new (experimental) SVCB "oots" key that specifies per-transport query load parameters. This improves on blind probing by providing a mechanism by which a responding authoritative server may signal which alternative transports it supports, along with more detailed information about each transport.

We will describe both the Passive and Probe modes recursive resolvers can use to discover these SVCB records and highlight the minimal level of changes required to the DNS protocol to deploy this mechanism. We also describe how OOTS focusses on enabling zone operators to manage the deployment of encrypted transports rather than zone owners. Finally we will describe early implementations and test deployments.

Speaker: Mr Joseph Abley (Snake Hill Labs Inc)

31 Hiding in Plain Sight: Security Blind Spots in Composite DNS Queries

Many Internet services use composite DNS queries, where one domain is embedded within a query to another service. Translation platforms, email link protection systems, reputation services, and content delivery networks rely on this approach. While these services provide valuable functionality, they also make it harder to determine the true destination from DNS data alone, creating a visibility gap for DNS monitoring and security systems.

In this talk, we present a measurement study of composite DNS queries observed in production DNS traffic. We identify the major classes of services that generate composite DNS queries, analyze the domains embedded within them, and evaluate their contribution to DNS traffic and visibility. Our results show that a meaningful portion of domain activity is observable only through composite queries, highlighting an important gap in traditional DNS analysis.

Finally, we discuss why decisions based solely on the Response Policy Zones (RPZ) are often insufficient for disrupting threats that use composite queries. By combining service classification with analysis of the embedded destination, security systems can make decisions on individual queries without disrupting legitimate services.

Speaker: Darin Johnson (Infoblox)

12:45 Day 2 Lunch Break

Day 2 Featured Recorded Sessions: OARC 47 Day 2

32 JIGGLE Attack: What Malformed Queries Reveal About DNS Resolver Security

DNS resolvers are normally evaluated using well-formed queries, leaving a fundamental attack surface comparatively underexplored: what happens when a malformed query reaches the resolver's front door?

In this talk, we present QuerySynth, an LLM-guided framework that translates natural-language DNS specifications into executable protocol tests. QuerySynth processed 299 DNS RFCs, constructed a Structured Protocol Model containing 134 expert-validated constraints, and generated 756 normalized malformed-query vectors. Differential testing across mainstream recursive resolvers and forwarders found that 89.41% of these vectors triggered inconsistent externally observable behavior.

Our analysis uncovered three exploitable classes of query-processing behavior, collectively termed the JIGGLE Attack. First, some resolvers include attacker-controlled query content in error responses. Combined with IP fragmentation, this behavior enables a pulsing denial-of-service attack with a measured bandwidth amplification factor of 1,083.2x. The same reflection behavior can also provide a one-way covert channel. Second, inconsistent validation between forwarding resolvers and upstream servers can induce predictable upstream silence, creating a multi-second window that strengthens existing off-path cache-poisoning attacks.

To assess the operational impact, we measured 44 public DNS services and 1,315,016 open resolvers. We observed anomalous echo behavior in 18 public services and 75,711 open resolvers, while 852,770 open resolvers exhibited relevant silent behavior. Overall, 924,808 resolvers, or 70.33% of the measured population, exhibited at least one JIGGLE-related behavior.

Responsible disclosure has led to concrete remediation. Unbound released a public fix that prevents malformed-query reflection, covert-channel behavior, and inappropriate silence. AdGuard Home published a security advisory and added JIGGLE protections, while Technitium DNS Server and several public DNS operators confirmed, fixed, or investigated the reported behaviors.

The talk concludes with practical guidance for resolver developers and operators: reject malformed input consistently, return minimal error responses, never reflect arbitrary query content, avoid forwarding semantically ambiguous queries, and improve observability so that rate limiting and parser rejection can be distinguished from upstream failure.

Speaker: Yuqi Qiu (Nankai University)

33 Malicious Domain Detection in Real-World Academic DNS Traffic: A Machine-Learning Approach

This presentation describes a hybrid malicious-domain detection system deployed in an academic recursive DNS resolver operated by São Paulo State University (UNESP), processing more than 20 million DNS queries per day. The system combines automatically updated open-source threat-intelligence feeds with a lightweight Random Forest classifier designed for operational passive-DNS monitoring.

The classifier uses 28 lexical and active-DNS features, complemented by character-level TF-IDF representations extracted from domain names. Active features are collected through DNS-over-HTTPS queries. On an offline test set of approximately 50,000 previously unseen domains, the best configuration achieved an ROC-AUC of 0.918, precision of 0.794, recall of 0.832, and F1-score of 0.813.

The system was also evaluated during a one-year deployment using passive DNS data collected throughout 2025. It identified between 512 and 1,439 potentially malicious domains per month beyond direct threat-intelligence matches. However, real-world evaluation exposed a substantial precision gap: monthly precision ranged from 0.142 to 0.364, while recall ranged from 0.434 to 0.667. Furthermore, 74%–78% of observed domains could not be validated using available blocklists or allowlists.

The results demonstrate that machine learning can complement blocklists by expanding threat visibility, but production deployment requires careful thresholding, analyst validation, and approaches for handling incomplete labels and extreme class imbalance. The system is therefore best understood as an early-warning and triage capability rather than an autonomous blocking mechanism.

Speaker: Guilherme Romanholo Bofo (São Paulo State University (UNESP))

DNS-OARC 47-1.pdf

OARC 47 Day 2: Day 2 Session 3

Convener: Cathy Almond (Internet Systems Consortium)

34 PC Session Chair Introduces Session 3 Day 2

35 Benchmarking tools: new features, old bugs

In recent years, benchmarking tools have been extended to support new transports like DNS-over-TLS, HTTPS, and QUIC. These features are orders of magnitude more complex than the good old UDP and TCP, and this complexity provides fertile ground for bugs.

To make things even worse, "Who tests the testing tools?" Hardly anyone.

We developed a test suite for the testing tools and uncovered bugs which affected measurement results in various niche and not-so-niche corner cases.

In this presentation we summarize our findings and alert the audience to gotchas when benchmarking DNS software.

Speaker: Petr Špaček (Internet Systems Consortium (ISC))

presentation.pdf

36 The OARC BCP Initiative - How is it going?

Over the last few DNS-OARC workshops, we have been floating the idea of creating a group inside the OARC community to create a DNS Best Current Practices set of documents. Last year at OARC 45 we started the OARC BCP initiative.

The goal was set to create a centralized gateway to introduce DNS best
operational practices to different actors.

A year later, where do we stand? This presentation brings you up to speed on what has been done, where we are now, and intends to start the discussion on how to shape the future of BCP documents within OARC.

Speaker: Matthijs Mekking (ISC)

lt-oarc47-bcp-update.pdf

37 Lightning Talk Placeholder

38 PC Session Chair closing remarks

39 OARC 47 Wrap-UP

15:15 Day 2 Afternoon Break

OARC 47 Day 2: Members AGM

Wednesday 11 November

Community-Led Sessions Learning Group Track: Session 1

40 Intro to Vector for dnstap Monitoring: Interactive Configurations

Monitoring DNS software behavior (recursive or authoritative) is shifting from PCAP-style observation to more robust collection with the dnstap protocol. Consuming large volumes of dnstap data and making into something meaningful is a challenge. Vector is a tool that consumes dnstap messages and allows highly flexible receipt, manipulation, enrichment, aggregation, and re-transmission - it is the 'Swiss Army Knife' of streaming event data. This learning track will cover basic installation and configuration for a simple Vector installation attached to a recursive resolver, and will discuss in detail some of the medium-complexity tasks that can be achieved, and will briefly discuss some of the more sophisticated analysis that Quad9 has performed with Vector on their global open recursive resolvers.

Speaker: John Todd

Community-Led Sessions Working Group Track: Session 1

41 OARC BCP Working Group Session

Over the last few DNS-OARC workshops, the idea of have a group inside the OARC community to create a DNS Best Current Practices set of documents. Last year at OARC 45 we started the OARC BCP initiative.

The goal was set to create a centralized gateway to introduce DNS best
operational practices to different actors.

A year later, where we are now and how should we shape the future of BCP documents within OARC.

Agenda:

1. introduction (5 min)
2. how to bcp introduction tutorial (20 min)
3. open issues (45 min)
4. what makes a document an actual bcp?
5. curator selection
6. candidate topics for bcp (20 min)

Participants are encouraged to review OARC-BCP-0000: How to Write DNS-OARC BCP Documents ahead of the session:

https://oarc-bcp-0000.readthedocs.io/en/stable/index.html

The presenter may make updates to the recommended reading materials between now and October 27. Participants are encouraged to check the materials again after that date to ensure they have reviewed the latest version before the session.

Speaker: Matthijs Mekking (ISC)

OARC-BCP-0000: How to write DNS-OARC BCP documents

10:00 Morning Coffee Break

Community-Led Sessions Learning Group Track: Session 2

42 Serve your own copy of the DNS Root

Why send queries to the DNS root servers when you can answer them yourself? Most DNS resolver implementations now support the concept of "LocalRoot", which increases local privacy, zeros latency to the root zone, and protections against network outages. In this session users will be shown how to turn this support on in various resolver software.

Bring a linux or other laptop supporting Unbound, Knot or Bind to try it yourself during the session. This will be followed by a community discussion about ways to contribute the results of using LocalRoot on the network to DNS researcher networks like DNS-OARC.

A brief agenda :
* Introduction
* Background on LocalRoot
* Interactive session deploying LocalRoot yourself
* Community discussion on the future of DNS research in a LocalRoot enabled world

Speaker: Wes Hardaker (USC/ISI)

Community-Led Sessions Working Group Track: Session 2

43 The forgotten art: DNS Monitoring

Everybody is doing it, but strangely enough there is very little guidance on what are the important values are. Of course there is DSC, maintained by our host DNS-OARC. Is that enough? Does it help to detect DDoS? What are other failure modes to monitor for?
In this session we are trying to capture a list of monitoring options that can help operators to keep their servers running.

NO advanced material is required to participate in this session

Speaker: Ulrich Wisser (IIS)

44 DNS use within an AI world

DNS can be used as part of the identity of AI agents, and in the process of agent discovery. This session will look at IETF drafts and other specifications related to this with the intention of raising awareness for operators and implementors, and gathering thoughts on what the impact of this could be on the DNS.

A brief agenda:
Overview of standards and drafts in this area
Discussion on the usage of DNS in this area based on these standards

No advanced material is required to participate in this session

Speaker: Jim Mozley (Infoblox)

12:00 Lunch

Community-Led Sessions Learning Group Track: Session 3

45 Debug malicious network traffic using the open source traffic-taffy tool

Want to better understand the crazy traffic arriving at your network? Then this session is for you. Session participants will actively learn how to use the traffic-taffy tool that was developed at USC/ISI DNS root server operators analyzing the many random spikes in traffic seen at our B-Root infrastructure.

If possible, bring a laptop that has python installed (> 3.7) and be prepared to learn and be challenged. Participants will be given datasets to analyze with increasing levels of difficulty in finding the hidden traffic anomalies within.

A brief agenda:
* Introduction
* Background on the author's approach to differential analysis
* Individual and group analysis of interesting recorded network anomalies

Speaker: Wes Hardaker (USC/ISI)

Community-Led Sessions Working Group Track: Session 3

46 Deploying ADoX: Why It Matters and How Operators Can Get Started

Who this if for: Recursive and Authoritative operators interested in deploying ADoX now or in the near future

Synopsis: This session will provide context on the benefits and practicalities of ADoX, and also current and future activities in this area

Agenda:
* Why do ADoX and what is Strict vs Opportunistic?
* Who is doing Opportunistic ADoX today and what are they doing (standards and software)
* How to experiment with and deploy Opportunistic ADoX today
* ADoX challenges and solutions moving forward

Speakers: Babak Farrokhi (Quad9 DNS), Sara Dickinson (Sinodun IT)

14:30 Afternoon Coffee Break

Community-Led Sessions Learning Group Track: Session 4

47 A Hands on Tutorial on MTL

Synopsis:

This session will provide a focused tutorial on Merkle Tree Ladders (MTL) and how MTL can help address challenges with adopting post-quantum cryptographic algorithms for DNSSEC. We will walk through examples of how MTL works in practice; the benefits it can provide to operators for storage, memory, computation, and bandwidth compared to other PQ-DNSSEC approaches; and have an open discussion about MTL and broader PQ-DNSSEC related challenges.

Reading material:

• Base MTL draft

• Sig Tag extension draft

• MTL demonstration Jupyter notebooks

Speaker: Andrew Kaizer (Verisign)

Base MTL draft

MTL demonstration Jupyter notebooks

Sig Tag extension draft

Community-Led Sessions Working Group Track: Session 4

48 Implementing OOTS: Authoritative DNS Transport Signaling in Practice

Who is this for: Implementers and Operators interesting in gaining experience with OOTS

Synopsis: This session will dive into the details of a recent Internet Draft proposal for "Opportunistic Operator based SVCB transport signaling (OOTS)" which is an
alternative mechanism that enables a more controlled deployment of Opportunistic encrypted transports.

Reference material: Latest WIP version of OOTS Internet Draft

Agenda:
* What is OOTS and how does it evolve ADoX beyond Unilateral probing?
* Passive mode vs Probe mode
* Demo using prototype recursive and authoritative OOTS deployments
* What is involved in deploying ADoX?
- For recursive operators
- For authoritative operators
* Current and future plans for deployment
* Early work on stub to recursive signaling of desired upstream privacy

Speakers: Babak Farrokhi (Quad9 DNS), Sara Dickinson (Sinodun IT)

Latest WIP version of OOTS Internet Draft