- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
OARC 38 is planned to be a hybrid in-person and online workshop.
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: #OARC38
Mattermost Chatroom: Workshops on chat.dns-oarc.net (sign-up here)
Sponsorship opportunities for OARC 38 are available. Details at:
https://www.dns-oarc.net/workshop/sponsorship-opportunities
|
Annual Workshop Patrons for 2022 are available. Details at:
https://www.dns-oarc.net/workshop/patronage-opportunities
We launched the first ever DNS-over-QUIC resolver about 18 months ago. In this presentation I'll talk about our experience running it and share some data on how it performs.
QUIC might become mainstream transport for future DNS, including recursive to authoritative. The benefits are: privacy by encryption, low latency by zero-RTT handshake, no a-priori response size limit, no source address spoofing.
With previous implementation of XDP stack in Knot DNS for UDP and TCP, the authoritative server can be resilient to many types of resource exhaustion attacks. However, QUIC measurements show high enough query-per-second numbers for legitimate traffic only, but without additional protection, the attacker might DoS the server by utilizing its CPU with encryption routines.
Other quirks of athoritative DoQ may be discussed as well (certificate exchange, slow first handshake).
ExternalDNS is an open-source application to make Kubernetes resources discoverable via public DNS servers.
We have deployed ExternalDNS on AWS in a large scale: externalDNS updates zones of more than 8000 resource records. During the external DNS development and deployment, we encountered challenges regarding AWS service limits, e.g. Route53 API frequency, Route53 resource record limit.
We will cover the following items in this talk:
Nominet operate around 50 GTLDs some as a registry and some as an operator on behalf of other registries. During the X years we have been operating in this space we have undertaken several projects to transition in and transition out many GTLDs. This has led us to develop a process (and some automation), this presentation will talk about the process we follow, the automation we use and further plans for the future. We would also welcome input from the community on what we do and how we can improve.
We discuss standard and non-standard mechanisms for protecting DNS queries against cache poisoning attacks between resolvers and name servers. The techniques covered include DNS cookies, 0x20 bit munging, nonce prefixes and DNS over TLS/QUIC. We present data from implementing these techniques in Google Public DNS and some interesting behaviors observed during the implementation.
The talk builds on the material covered at
https://developers.google.com/speed/public-dns/docs/security.
At Salesforce, to provide better resilience and performance, we host multiple zones containing millions of DNS records across many DNS providers. However, this increases the complexity for client applications, the operations teams, and even the DNS admin managing DNS records. The client applications would need to know which provider hosts which zone and make API calls for DNS CRUD to the specific provider. When we add new zones and migrate zones between DNS providers, things get more complex.
To solve this problem, we built a highly available and scalable cloud-based microservice named Athena that hides all the complexity from the end-users. Athena acts as the single Rest API endpoint in front of all the DNS providers. The end-users send all DNS CRUD requests to Athena without needing to know which providers host the zones. Upon receiving a request, Athena automatically figures out the provider for the zone, converts the request to the right format based on the provider's Rest API specifications, sends the request to the provider, and converts the return message to a standard response for the end-user.
In this presentation, we will talk about the architecture of Athena, availability, scalability, zone-vendor mappings management, account management, development/release pipeline, monitoring, and more.
Traditionally DNSSEC how-tos start with a variation of:
Be prepared for higher resource consumption when you enable DNSSEC validation.
Is that still true in 2022? According to our measurements - not really.
In this talk, we compare answer latency, resolver CPU usage, memory consumption, and network bandwidth between validating and non-validating configurations of a busy ISP resolver running BIND.
One of the stated goals of people asking for root server instances to be added near their resolvers is to get better round trip times. These requests are made without knowing any specific metric of what a good round trip time is, or knowing what round trip times typical resolvers are currently seeing. The research in this presentation focuses on the second question.
Many root server operators can easily determine typical round trip times by sampling the addresses in the traffic stream to their anycast instances and sending pings from the instances to the querying addresses. The ICANN Managed Root Server (commonly also known as L-root) is not able to do this due to contractual agreements that prevent originating traffic measurement queries from their instances. However, this restriction does not completely prevent such measurements because the servers collect IP TTL values for incoming queries.
This research shows how, using probing from RIPE Atlas systems, the IP TTL values seen can be converted to approximate round trip times and aggregated across instances. The research results estimate the median and 90th percentile measurements for round trip times for current resolvers.
Last year the IETF published RFC 8976, titled "Message Digest for DNS Zones." It describes a protocol and new DNS record that provides a cryptographic message digest over DNS zone data. When used in combination with DNSSEC, it allows recipients to verify zone data for integrity and origin authenticity, providing assurance that received zone data matches published data, regardless of how it was transmitted and received.
This presentation provides an introduction to the zone digest protocol, its record format, parameters, and use cases. It also covers known implementations of the protocol and provides some benchmark measurements for zones of varying size. Lastly, it introduces plans to deploy the ZONEMD protocol in the root zone.
Details emailed to registered attendees
The presentation looks at the various ways to measure the connection between recursive resolvers and end usewrs and the meanings associated with each measurement approaches.
Subtitle: Rule 53: If you can think of it, someone's done it in the DNS.
DNS has been used -- and misused -- in more ways than you might think possible. Peter talks through a collection of some of the more interesting things people have done with it.
ISC
NSD
PowerDNS
KnotDNS
Q/A All panel
This talk will discuss a novel application of cryptography, the zero-knowledge middlebox. There is an inherent tension between ubiquitous encryption of network traffic and the ability of middleboxes to enforce network usage restrictions. An emerging battleground that epitomizes this tension is DNS filtering. Encrypted DNS (DNS-over-HTTPS and DNS-over-TLS) was recently rolled out by default in Firefox, with Google, Cloudflare, Quad9 and others running encrypted DNS resolvers. This is a major privacy win, protecting users from local network administrators observing which domains they are communicating with. However, administrators have traditionally filtered DNS to enforce network usage policies (e.g. blocking access to adult websites). Such filtering is legally required in many networks, such as US schools up to grade 12. As a result, Mozilla was forced to compromise, building a special flag for local administrators to instruct Firefox not to use Encrypted DNS.
This example points to an open question of general importance, namely: can we resolve such tensions, enabling network policy enforcement while giving users the maximum possible privacy? We propose using zero-knowledge proofs for clients to prove to middleboxes that their encrypted traffic is policy-compliant, without revealing any other additional information. Critically, such zero-knowledge middleboxes don’t require trusted hardware or any modifications to existing TLS servers. We implemented a prototype of our protocol, which can prove statements about an encrypted TLS 1.3 connection such as “the domain being queried in this encrypted DNS packet is not a member of the specified blocklist.” With current tools, our prototype adds around fifteen seconds of latency to opening a new TLS 1.3 connection, and at least three seconds to produce one proof of policy-compliance. While this is too slow for use with interactive web-browsing, it is close enough that we consider it a tantalizing target for future optimization.
This talk will cover the tension between encryption and policy-enforcing middleboxes, including recent developments in Encrypted DNS and the necessity of DNS filtering. It will then present and argue for the new zero-knowledge middlebox paradigm. Finally, the talk will describe our prototype implementation as well as future avenues for improvement, such as ways to reduce latency overheads.
At OARC 33, pktvisor (https://pktvisor.dev) was presented as a free and open source traffic analyzer that summarizes critical information from DNS edge networks in real time, making the resulting lightweight telemetry available locally on node and easily collectable into a central database for dashboarding and alerting.
Since then we’ve introduced Orb (https://getorb.io), a free and open source dynamic edge observability platform which builds on our earlier work. Orb acts as a control tower for a distributed fleet of pktvisor agents, combining dynamic orchestration of analysis policies with data collection and sinking functionality, accessible via web UI and REST API.
The agent can now analyze packet capture, dnstap, flow and other inputs, combining deep traffic analysis with data sketch algorithms to efficiently extract counts, top-k heavy hitters, set cardinality, quantiles and other key information from data streams directly on the edge. The result is lightweight time series metrics that plug into modern observability stacks.
Together the goal of Orb and pktvisor is to deliver immediately actionable insights local to the traffic source and simultaneously collected and integrated into global result sets.
This talk will introduce and advocate for the powerful “small data” use case, discuss the goals and status of the projects, and look to the future as they extend beyond traffic analysis and into general network debugging and analytics embedded at the edge.
DNS-based Authentication of Named Entities (DANE) is a framework
for application security using DNSSEC. It uses signed DNS records
to securely associate domain names with cryptographic keying
material such as public keys and X.509 certificates. This tutorial
will give an overview of DANE, and current and potential applications
of it. It will go into details of the DANE protocol, DANE (and DANE
like records) such as TLSA, SMIMEA, OPENPGPKEY, etc.