In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.

I have read and understood the above.

Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.

Heian I/II

Okura Hotel

DNS-OARC is returning to Amsterdam, NL for its 29th Workshop to have a joint Programme with the 39th CENTR Technical 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, with attendees from RIPE 77 particularly welcome this time around - as OARC 29 and CENTR-Tech 39 takes place just before this in the same venue.

WORKSHOP PATRONS 2018

PREMIUM

OARC 29 SPONSORS

DELUXE

ASSOCIATE

CONTRIBUTOR

How much does it cost to attend an OARC Workshop?

We have various registration options: Complimentary (0), Discounted (USD 350) and Standard (USD 450). The Discounted and Standard Registration fees are subject to a USD 100 late registration fee from 3 weeks before the Workshop. Further details are on the Registration page.

Operational experience for DNS over HTTPS (DoH) and DNS over TLS (DoT)30m

Cloudflare has launched support for DoT and DoH for its 1.1.1.1 resolver from day 1. With DNS traditionally carried over UDP, moving to connection-based and encrypted transport protocols brings new operational challenges. This talk will cover the protocol uptake, deployment challenges with both protocols, as well as the feasibility and overhead for providing the service. It will show the evolution of our current system architecture, and client-side software.

Verisign is planning to make a few changes to the operation of its TLDs in the coming months. These changes include increasing the truncation limit on large responses, increasing ZSK strength, reducing TTLs, and elimination of “cross-zone glue.” In this short presentation we explain the nature of the changes, the rationale, and when possible provide estimated timelines for their deployment.

In CZ.NIC, we completed our third DNSSEC KSK rollover in June. It was our second algorithm rollover and it resulted in the first usage of ECDSA algorithm for DNSSEC KSK in TLD space. The talk will summarize how did we get to the situation when ECDSA algorithm is the most used DNSSEC algorithm in .CZ zone, how the conservative algorithm rollover was done and what we have learned during whole process.

Okura Hotel

DNSThought - Everything you ever wanted to know about caching resolvers but were afraid to ask30m

On 20 and 21 April 2017, the RIPE DNS measurements hackathon took place. Our team created DNSThought: a measurements analysis portal providing insight into caching resolver's availability and capabilities. In the context of the project permanent running measurements were started for all resolvers of all probes in RIPE Atlas, measuring:

Resolver identity (what IPs are seen at the authoritative eventually)

IPv6 capability (can the resolver query IPv6 only nameservers)

IPv4 and IPv6 TCP support

NXDOMAIN hijacking

In June that year (2017), DNSThought started collaborating with the rootcanary project, and 78 more measurements were started looking into DNSSEC algorithm support. In July 2018 measurements were added for the root key trust anchor sentinel for DNSSEC.

In the presentation we show progression of those resolver capabilities over the last 18 month, and also how the portal can be used as a tool for operators and researches to provide detailed insight in availability and progression of capabilities of certain resolvers -- by ASN and/or geographical location -- currently and in the past.

Afnic has been working for a while towards the objective of extending
DNS for IoT use cases. Previously, Afnic worked with the GS1 standard
organisation (Barcode/RFID registry for the supply chain industry), and
contributed to the evolution of the Object Naming Service (ONS) standard
[EPCglobal standard]. The ONS standard uses DNS as an overlay for
service discovery. The use cases are - "track and trace" and "extended
packaging information" of a consumer product. The consequence of this
experience for Afnic was that, well established industries like the
supply chain are reluctant to use open infrastructure like DNS due to
fallacious paranoia.

This pushed us to look at upcoming technologies or nascent industries in
the IoT for using DNS. This is where we stumbled upon on LoRaWAN, which
started as a fablab project some three years ago. LoRaWAN is an
ISM-based wireless technology for long-range low-power low-data-rate
applications developed by the LoRa Alliance [LoRa Alliance], a
membership consortium.

LoRaWAN networks are typically organized in a star-of-stars topology in
which Gateways relay messages between end devices and a central "network
server" in the backend. Gateways are connected to the network server
via IP links, while end devices use single-hop LoRaWAN communication
that can be received at one or more Gateways.

LoRaWAN use case are multiple; from smart meters to geo-localisation to
agriculture. Since LoraWAN uses unlicensed band, the cost of setting up
the infrastructure (approximately 3 to 4 million euros CAPEX to cover a
region similar to France) and for users using the LoRaWAN service
(approximately 1 euro per device per month) is quite low.

Due to the low cost, there are public LoraWAN operators (e.g. Bouygues
and Orange in France) and also number of private operators. This results
in a scenario, wherein it is difficult to manage the roaming
infrastructure. Hence, the current backend interface specification [LoRa
Backend Interface] for LoRa uses DNS for roaming purpose.

Similarly, for Over the Air Activation (i.e. to set the first
communication session between the device and the network server in the
Internet), the backend specification uses DNS.

This talk will include

A basic introduction of the LoRa infrastructure

How DNS is used by the LoRaWAN ecossytem for Roaming and Over the Air
Activation?

Afnic's involvement in the LoRa alliance as LoRa DNS operator

How possibly DNS could be used for cryptographic key exchanges in the
LoRa ecosystem?

And, if there is time, how DNS could be used for exchanging the rules
for compression/decompression?

As noted recently, "getting" DNS now requires reading 2000 pages of RFCs. This partially explains the dire quality of new (closed source) DNS implementations. Hello-DNS is an effort to make DNS more accessible by explaining it in modern language, in the right order. This project has now also spawned a 'teachable authoritative server' (TDNS) which attempts to be a display of best-practices and 'doing it right'.

This presentation introduces 'Hello-DNS' and the 'TDNS' nameserver, and is also an appeal for more contributions so we can make this shine.

Finally, there is some discussion on the recent further increase of DNS complexity (& intertwining it with HTTPS and CDN logistics), and an overview of yet more standards text in our near future, and an open question what we should do with this.

A traditional route for DNS traffic capture is to record traffic in PCAP format. Recorded files are compressed and used as input for subsequent processing. PCAP files, though, suffer from two disadvantages; they record much transport layer data that is unnecessary, and compression requires significant system resources.

The C-DNS file format (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/) for storing DNS traffic capture in a resource-efficient way is now moving towards standardisation. In this talk we discuss the background to C-DNS and give an overview of the format. We'll outline how the C-DNS format and its associated open source tools (including https://github.com/dns-stats/compactor) can be used to capture DNS traffic in resource constrained environments and look at an existing deployment for a busy root server.

We will also look at downstream processing of C-DNS files from PCAP re-generation to recent work on importing C-DNS into a ClickHouse database. The data can be used for both ad-hoc low-level queries and visualisation with Grafana to produce DSC-style graphs. We'll highlight the advantages of ClickHouse for this application and talk about scaling of this solution.

Internet bad actors have long been known to register look-alike domains and stand up phishing sites and create spam campaigns in order to hoodwink users into revealing personal information including login credentials, credit card numbers and social security numbers. Detecting and combatting criminal activity related to look-alike domains becomes a much more difficult problem when you start adding International Domain Names (IDNs) into that mix.

This talk will focus on Farsight's work with real-time detection of in-use IDN homographs.

This presentation will feature:

Discussion of our method of detection/collection

Overview of the analysis of a large corpus of "a year in the life of IDNs" including in-the-weeds analysis using various views of the corpus

Gallery/discussion of a few real-world examples of detected (previously-) live phishing sites

Using DNS traffic observed at the .nz nameservers, hand curated monitoring and resolver addresses, feature engineering and machine learning, we are able to identify resolver behaviour using traffic from an authorative nameserver. This technique can be extended to detect other patterns, like validating resolvers or QNAME minimization.

This talk will review the latest evolutions in encrypted DNS transports and the concept of 'Trusted Recursive Resolvers' (TRRs) from the operators perspective.

Mozilla and Firefox have partnered to operate a DoH (DNS-over-HTTPS) service for Firefox. There are currently no discovery mechanisms for DoH services (or Strict DNS-over-TLS) and as a result clients wanting to use them must use either fixed lists with defaults or have users provide configuration. While Cloudflare will likely be the short term default TRR for Firefox, it is not clear what the longer term plans are for Firefox, other browsers and new DoH use cases.

What does this mean for today's operators?

Will increasing amounts of traffic migrate from network provided resolvers to 'well-known' DoH/DoT providers? Will a secure and reliable discovery mechanism be developed and deployed in the near future? Will ISPs and enterprises be motivated to deploy DoH/DoT to retain visibility and control of the network traffic and also work around issues with hard-coded TRRs (such as breaks to split horizon DNS)? How will trust models between clients and resolvers evolve with the introduction of authenticated, encrypted protocols? Will one protocol win out or will operators more typically run multiple services (DNS-over-TLS/HTTPS/QUIC/foo)?

In this rapidly evolving landscape who knows what the situation will be by the time of OARC 28!

In 2017, we started a cycle of security exercises for our organisation so as to be prepared to face DNS major attack / outage scenarios (e.g. DDoS attack, zone file corruption...). While the first edition was focused on IT response skills, with some crisis management, the second one was more meant to cover - as much as possible – all relevant aspects one organization must handle should a major security incident occur. Such a security exercise allowed us, for instance, to test our 3C’s (“Coordination”, “Co-operation” & “Communication”) from the time when the first alert was received, until when we were back to normal (or almost) and the crisis meeting was over.

We would like first to share information on main achievements and lessons learned from our 2017 exercise editions. We also would like to trigger some discussion on challenges ahead in terms of involving relevant partners in the future exercises preparation, such as transit providers, Anycast providers, DNS resolver operators, registrars and DNS hosting providers.

PLEASE NOTE the slides for this presentation are not available at the Speaker's request.

Speakers:
Vincent Levigneron
(AFNIC), Mr.Mohsen Souissi
(AFNIC)

12:30
→
13:45

Lunch
1h 15m
Foyer

Foyer

Okura Hotel

Ferdinand Bolstraat 333
1072 LH
Amsterdam
NL

13:00
→
13:40

PGP Signing Session40mHeian I/II

Heian I/II

Okura Hotel

Send your PGP keys to pgpsign@dns-oarc.net before the morning break on Saturday.

"Message Digest for DNS Zones" is a new Internet Draft describing a protocol and DNS Resource Record used to provide a message digest over DNS zone data. Although DNSSEC signs individual RRsets that can be validated, it is not sufficient in general because zones may also contain unsigned data (delegations and glue). This protocol can verify all data in a zone file.

In this presentation I will explain the motivation for this feature, and describe the algorithm for computing a digest over zone data. I will furthermore discuss some proposals and tradeoffs for supporting incremental zone updates with zone digests. Using an implementation of zone digests I will provide benchmarks for the time required to digest and verify zones of different sizes, with and without incremental updates.

In a cooperative effort, .CL and .NZ collected data about how many domains will be affected by the DNS Flag days changes on February 1st, 2019. We compare our results with ISC's efforts over the general TLD space and Alexa Top 1000 domains.

Standard DNS does not allow CNAME records to coexist with other normal data, which is sometimes confusing for non-DNS experts who want to redirect one domain to the other, like example.com. -> example.net.

Various actors invented their own solution, be it ALIAS or ANAME RR types with non-standard backend software, and some others decided to just ignore the CNAME limitation in standards and put CNAME RR next to other data.

In this talk we will explore how real resolvers react to situation where CNAME RR and other data reside at the same node in DNS tree. Is the currently deployed code sufficient or do we need a new standard?