OARC 24 (Buenos Aires)

31 Mar 2016, 09:00 → 1 Apr 2016, 19:00 America/Buenos_Aires

Montserrat (Intercontinental Buenos Aires)

Keith Mitchell (DNS-OARC), Sebastian Castro (NZRS)

DNS-OARC's 24th Workshop ("Spring" 2016) took place just before the IETF 95 meeting in Buenos Aires and was sponsored by:

Premium

          

 

Benefactor

 

Patron

 

Contributor

 

DNS-OARC Workshops are open to OARC members and to all other parties interested in DNS operations and research, with IETF attendees particularly welcome this time around. Attendance is free for OARC Members, Speakers and Sponsors. There are charges for other attendees and late registrations.

If your organization is interested in sponsoring OARC workshops, please see our Sponsor Benefits or e-mail sponsor@dns-oarc.net for more information.

Thursday, 31 March

Registration

Members Session

Convener: Mr Keith Mitchell (DNS-OARC)

1 Welcoming Remarks

Speaker: Mr Ondrej Filip (CZ.NIC)

2 OARC Status Update

It has been another busy 6 months for the OARC Team. In particular, we're well down the path of executing a plan which will re-locate our primary infrastructure hosting site to multiple new locations. We also have a new staff member recently joined as Software Engineer, and are gearing up for our DITL2016 data gathering exercise shortly after the workshop. This presentation will update OARC Members and the audience on these developments and OARC's 2016 budget and fees.

Speaker: Mr Keith Mitchell (DNS-OARC)

Slides OARC24-Status.odp OARC24-Status.pdf

3 Recent DDoS attacks against RIPE NCC's DNS servers

In the last several weeks, the RIPE NCC's DNS infrastructure has experienced some DDoS events. In this presentation, I would like to talk about what we experienced, and how we tried to mitigate the attacks. I will talk about the nature of the attacks, and specifically what kind of methods and tools we used to try and defence our infrastructure.

Speaker: Anand Buddhdev (RIPE NCC)

Public Workshop: First Session

Convener: Mr Sebastian Castro (NZRS)

4 How we are developing a next generation DNS API for applications

Many new and developing DNS features have emerged in recent years to improve both the security and privacy of DNS ( e.g. DNSSEC/DANE and DNS-over-TCP/TLS). A major reason for the lack of uptake and deployment of these features by applications is that existing DNS APIs either do not support the features or do not provide an application friendly interface. To solve this problem the getdns API was developed with the main goals of: - Ease of use by application developers across a variety of languages - DNS capabilities that most application developers might want now or in the next few years We present an implementation of the getdns API (verging on production release) and discuss how it has evolved through close involvement with application developers and standards developments. This collaborative development model has also helped to identify practical and implementation specific roadblocks to real-world deployment particularly for DANE and DNSSEC. As a result the API has been refined and the implementation provides easy access to DNS data both directly in C and via a range of bindings including Python, nodejs and Java. Participation by the development team in multiple international hackathons has also demonstrated how the API enables rapid development of prototype implementations (including many DNS privacy related IETF drafts) with getdns proving a powerful research tool in these areas. Integration of getdns into operating systems is also discussed, as it the fact that by enabling new DNS features for client applications the API will create demand for upstream services which is of consideration to operators.

Speakers: Sara Dickinson (Sinodun IT), Mr Willem Toorop (NLnet Labs)

Slides OARC_Spring_2016_getdns.pdf

5 Real-Time Analytics of DNS packets

In OARC 22 (Amsterdam) we gave a lightning talk about the possibilities and prospects of using Apache Storm for real-time analytics of DNS packets. Now, after a year of work, we are glad to present RaTA-DNS, our modular system for realtime analytics. RaTA-DNS was designed as a set of self-contained modules aiming to an easy integration with existing systems such as DSC and Hedgehog, and new systems such as SIDN Lab's ENTRADA. The main components of our system are three: Fievel, a packet monitor responsible for capturing network traffic and perform a preliminary processing (for reducing the data rate in order to be transmitted to aggregators); Gopher, which is responsible for aggregate the captured data received from multiple servers (Gopher was developed in Go language instead using the Apache Storm framework for modularity reasons); and Remy, the dashboard (data visualisations), which is connected to several Gopher modules to provide real time displays. The idea is to provide a programmable framework for real-time monitoring of DNS. Thus, Fievel has been developed as a scriptable module, where preprocessing is programmable and adaptable to the needs of different users, producing a monitoring system fully customisable. Additionally, as Fievel provides the tcp-replay function and Remy the play-pause-rewind functions, RaTA-DNS can be also seen as a very useful tool for forensic analysis of DNS traces. Actually, RaTA-DNS is connected to 2 NIC Chile DNS servers, processing in a normal operations day around 1200 (queries-responses)/sec per server, and aggregating statistical information such as queries/sec, non-rfc-conformant queries (queries using underscores), top-K queries by source, destiny, and geolocation. Further information can be seen in http://ratadns.niclabs.cl

Speaker: Dr Javier Bustos-Jiménez (NIC Chile Research Labs (NICLabs). Universidad de Chile)

Slides ratadns.pdf

12:00 Lunch

Public Workshop: Data Analysis

Convener: Mr Sean Stuart (Verisign)

6 AAAA Deep Dive: DNS Resolution Anomalies and Performance across a Huge Data Set

Much has been written about IPv6 adoption and its performance. One thing that has not been explored is how IPv6 DNS resolution contributes to overall user experience. What impact does transport, authoritative server configuration and other factors have on the “long tail” of domains queried over IPv6? This talk will present experimental results using a data set of approximately 35 million unique names and query types, extracted from production resolvers around the world. This data will feed dnsperf, a widely used utility for evaluating DNS performance, to query resolvers set up in the following ways: IPv4 only, IPv6 only, & prefer IPv6, all with EDNS0 on by default, along with a control server with EDNS0 off. Differences in resolution performance will be evaluated and presented for each of the resolvers.

Speaker: Mr Ralf Weber (Nominum Inc)

Slides DiggingInTheDirt-DNS-OARC-201603.Combined01.pptx

7 ENTRADA: The Impact of a TTL Change at the TLD-level

SIDN, the registry for the .nl ccTLD, managing 5,6 million .nl domain names, has recently made significant changes to its zone file publication policy: - A new zone file is now available every hour, instead of every 2 hours. - The delegation TTL value has been decreased to match the new publishing interval. - The SOA minimum TTL value has been decreased from 900 to 600 seconds. We used ENTRADA to analyse the impact of these changes on: - Overall DNS traffic - Specific query types - Specific domain name types (popular, unpopular, nxdomain) This presentation will show the results of this work. We are also pleased to announce that ENTRADA is now available as open source project. ---------- ### ENTRADA [ENTRADA][1] (ENhanced Top-level Domain Resilience through Advanced Data Analysis) is a DNS big data platform built on top of Hadoop, we use it at SIDN Labs for analysing over 100 billion DNS queries. Each day ~400 million new queries are added. [1]: http://entrada.sidnlabs.nl/

Speaker: Mr M Wullink (SIDN)

Slides DNS-OARC-Buenos-Aires-final.pdf DNS-OARC-Buenos-Aires-final.pptx

8 Continuous Data-driven Analysis of Root Server System Stability

At the end of 2015 the Continuous Data-driven Analysis of Root Server System Stability (CDAR)[1] study was started by the consortium partners NLnet Labs, SIDN and TNO. The objective of the CDAR study is to analyze the technical impact of the introduction of New gTLDs in the root zone on the stability and security of the root server system. With this in mind, we engaged in the collection and analyses of a large variety of measurement data sets (RIPE Atlas measurements, RIPE DNSMON, RSSAC002, DITL, and others). The projects aims at answering the question if the growth on the root zone files impact, in any measurable way, the operational stability of the root DNS system. In this presentation, the CDAR team will discuss with the community our first results on the analysis of the measurement data, as well the data collection and analysis methods used to observe the technical impact of New gTLD program. In specific, we will present a (i) characterization of the Root DNS traffic, an (ii) analysis of RSSAC002 data and TLD domain statistic to describe the impact of new gTLDs, and (iii) the impact of fluctuations in the query rates at the Root on DNS stability. (For the latter, we can use data of the late root DDoS attacks [2] and analyse the combined data of RIPE Atlas, DNSSMON and RSSAC002 data.) A second type of assessments focusses on the correctness of DNS data and its impact on the Root stability and security. Results will be presented from continuous, valid/broken DNSSEC chain validations between the Root and (New g)TLDs, amongst others. By sharing the current CDAR results we contribute to building on previous results from the DNS-OARC community and we enable the community to reflect on the study results. [1] http://cdar.nl
[2] http://root-servers.org/news/events-of-20151130.txt

Speaker: Mr Bart Gijsen (TNO)

Slides CDAR@DNS-OARC.pptx

15:00 Afternoon Coffee Break

Public Workshop: Privacy

Convener: Mr Ray Bellis (Internet Systems Consortium, Inc.)

9 Testing Most Authoritative Servers for Conformance

ICANN has recently begun testing live authoritative servers for conformance to the DNS protocols, particularly for TCP and EDNS(0) compliance. We do this by collecting registered names from the zone files of all gTLDs, as well as a representative sampling of names registered in the ccTLDs. This paper shows the test methodology, the levels of compliance found, and suggests avenues for further testing.

Speaker: Paul Hoffman (ICANN)

Slides peh-oarc-gtld-ns.pdf

10 State of the "DNS privacy" project: running code

The "DNS privacy" project started at the IETF meeting in Vancouver a few months after the Snowden revelations. What is its current state? A problem statement has been published, RFC 7626. Two directions are followed: QNAME minimisation, to decrease the amount of data sent to the name servers. And encryption, to prevent a sniffer to get the data. This talk will present the state of standardisation (it is possible that all the RFC are published before the meeting) and will demo the running code: QNAME minimisation in Unbound and Knot, and how does it work with broken name servers (such as those sending NXDOMAIN for an ENT), and DNS over TLS.

Speaker: Mr Stéphane Bortzmeyer (AFNIC)

Slides bortzmeyer-dns-privacy-code.pdf

11 QNAME minimisation in Unbound

Data stored in the DNS is publicly visible. DNS transactions, on the other hand, contain privacy sensitive information. The Snowden revelations about pervasive monitoring are seen as a wake up call for the internet community to increase the focus on privacy protection. One of the privacy threat mitigation methods mentioned in RFC6973, is the principle of data minimisation[0]. The RFC states that: "Reducing the amount of data exchanged reduces the amount of data that can be misused or leaked.". One of the new features in Unbound 1.5.7 is the support of QNAME minimisation[1]. QNAME minimisation is a technique to improve DNS privacy by limiting the amount of privacy sensitive data exposed to authoritative nameservers. This is done by limiting the number of labels in the QNAME sent to nameservers and by setting the QTYPE to NS in order to hide the original QTYPE where possible. Although the proposed minimisation of the QNAME and using the NS QTYPE are not strictly forbidden in the original DNS RFC, not all nameservers handle these queries the way they should. Common wrong responses are NXDOMAIN on empty-non-terminals and refusing queries with QTYPE=NS. Resolving when using QNAME minimisation will fail on these broken nameservers. We suspect that operators will not adopt QNAME minimisation when it is implemented according to the specification. Unbound is shipped with an implementation that will resolve queries "as usual" when broken nameservers are detected. QNAME minimisation can increase the number of queries sent to nameservers. This is most notable when resolving in the ip6.arpa name space. To limit the number of queries for reverse IPv6 lookups, unbound increments the minimised QNAME with 8 labels on each iteration when the original QNAME is a subdomain of ip6.arpa. An uncovered topic in the specification is QNAME minimisation and forwarders. Because of the "best effort" approach, there is no privacy enhancement when minimising queries to forwarders. Unbound does not minimise queries sent to forwarders. The most important reason to enable QNAME minimisation is the improved privacy. There are, however, some other benefits. One of them is that querying all intermediate domain names will result in a more precise negative cache. This improves both performance and privacy. Although using a completely different technique, QNAME minimisation can lead to the same result as described in draft-wkumari-dnsop-cheese-shop-00[2]. Namely reducing the amount of traffic to the root servers. [0] - https://tools.ietf.org/html/rfc6973#section-6.1 [1] - https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-09. [2] - https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-00

Speaker: Ralph Dolmans (NLnet Labs)

Slides unbound_qnamemin_oarc24.pdf

Friday, 1 April

Registration

Public Workshop: Tools & Measurements

Convener: Anand Buddhdev (RIPE NCC)

12 Knot DNS Resolver

Knot DNS Resolver is a new CZ.NIC project that builds a fully DNSSEC-validating DNS resolver. But it's more it's a powerful platform for building resolver service due its extensibility via modules and configuration in Lua.

Speaker: Mr Ondrej Sury (CZ.NIC)

Slides KNOT-RESOLVER-20160401-OS-OARC24.odp KNOT-RESOLVER-20160401-OS-OARC24.pdf

13 Threshold-Cryptography Distributed HSM

In the 20th DNS-OARC workshop, we showed a virtual HSM based on threshold cryptography. This system has the purpose to be used with OpenDNSSEC in order to provide a low cost solution to DNS record signing automation. But that system had a single point of failure: the key manager. Single points of failure are undesirable, even more in a fault tolerant distributed system. After a reengineering during the last year, we solved this problem by implementing the whole protocol within the PKCS #11 API. The communication now is done directly between the application that uses the system and the nodes, without the need of any centralised subsystem. This reengineering not only help us to have a really fault tolerant system but to improve the performance by reducing the latency of the operations. In this presentation, we will walk through the main features of the system, how simple is to integrate it with currently working systems, and how the system might help to improve the number of deployed DNSSEC systems when a secure low-cost cryptographic solution is needed.

Speaker: Mr Francisco Cifuentes (NIC Chile Research Labs)

Slides oarc.key oarc.pdf

14 Multi-vantage point DNS Diagnostics and Measurement

The ability to measure network and server behaviors from different network vantage points is important for understanding the general health of a network ecosystem. There are various platforms, frameworks, and APIs designed and built to accommodate this need. In this talk we discuss a new DNS looking glass framework designed for low-overhead deployment and great flexibility, and available for use with the DNSViz measurement tool. Recursive and authoritative inspection are both supported, via direct, client-based, or HTTP-proxy-based looking glass perspectives.

Speaker: Dr Casey Deccio (Verisign Labs)

Slides 2016-04-01-dnsviz-oarc.pdf 2016-04-01-dnsviz-oarc.pptx (Protected)

10:30 Morning Coffee Break

Public Workshop: Research

Convener: Mr Mauricio Vergara Ereche (ICANN)

15 Review and analysis of attack traffic against A-root and J-root on November 30 and December 1, 2015

On November 30 and December 1, 2015, some of the Internet's Domain Name System (DNS) root name servers received large amounts of anomalous traffic. The twelve root operators jointly published a report of the incident ([http://www.root-servers.org/news/events-of-20151130.txt][1]). The event also generated spirited discussion and speculation on public mailing lists, website forums, and blog postings. This presentation will specifically cover Verisign's observations and analysis of the attack in operating both A-root and J-root. Topics to be discussed include: - A recap of the attack, including an exact timeline of the event along with some specifics of the traffic itself. - A brief discussion about any perceivable impact on A-root and J-root, and the root as a whole. - Actions taken before, during, and after the attack. What worked well? What could of been done better? - A video that visualizes the attack as a Hilbert Curve representation. This analysis clearly suggests that the source addresses were spoofed. - Assumptions regarding the purpose of the attack (Hint: the attacker was not specifically targeting the root servers) [1]: http://bit.ly/1TdUJyN

Speakers: Duane Wessels (Verisign), Mr Matt Weinberg (Verisign)

notes https://www.youtube.com/watch?v=f8J52JhukLo

Slides OARC-Root-Attack-Final.pptx

16 The Quest for the Missing Keytags

In an effort to create all possible 64K keytags for a DNSSEC signing key, an anomaly surfaced that caused 75% of the possible keytags to never appear. This effort to generate certain cryptographic keys became an adventure in itself that included beautiful discrete math, flawed functions, carefully crafted primes, multiple cryptographic libraries, and some brilliant people. The result of this effort shows that using an ancient checksum function to identify cryptographic keys is not optimal.

Speaker: Roy Arends (ICANN)

Slides Quest_for_the_missing_keytags.pdf Quest_for_the_missing_keytags.pptx

17 Increasing the Root Zone ZSK Size

Verisign, in its role as Root Zone Maintainer, plans to increase the size of the root zone Zone Signing Key (ZSK) in 2016. The ZSK has been a 1024-bit RSASHA256 key since the initial deployment of DNSSEC to the root zone in 2010. In the latter half of 2016, the ZSK size will be increased to 2048-bits. In this presentation we will outline the schedule for the change, describe various technical and non-technical details for implementing the change, describe how the change will affect root zone response sizes, and our plans for emergency fallback to a 1024-bit in the unlikely event it should be necessary.

Speaker: Duane Wessels (Verisign)

Slides verisign-zsk-change.pptx

12:30 Lunch

Public Workshop

Convener: Duane Wessels (Verisign)

18 Deckard -- Integration Testing of DNS Servers

A generic testing framework was produced as a part of developing the Knot Resolver. This framework is written in python and can use UNIX domain sockets to bypass the underlying physical network and fake time using libfaketime. Apart from short introduction I will show the audience some real-life scenarios for testing the recursive and authoritative DNS servers and how to integrate Deckard into your own testing platform - this is important both for vendors and for people deploying new versions of servers into production.

Speaker: Mr Ondrej Sury (CZ.NIC)

Slides DECKARD-20160401-OS-OARC24.odp DECKARD-20160401-OS-OARC24.pdf

19 DNS Secondary service for customers, evolution and "meta-slave"

NIC Chile, .CL ccTLD registry, started to offer a secondary name service to its customers as a way to improve the overall internet robustness in Chile more than 10 years ago. We are going to show the evolution of a free of charge service from an unicast ip server to an anycast cloud, and using a sort of "meta-slave" daemon for provisioning the nodes.

Speaker: Mr Diaz Marco (NIC Chile)

Slides secondary-service-NIC-Chile.odp secondary-service-NIC-Chile-v2.pdf

20 ECDSA - Reviewed

This is intended to be an update to an earlier presentation on the extent to which DNS resolvers are able to performance validation on ECDSA-signed data

Speaker: Mr Geoff Huston (APNIC)

Slides 2016-03-30-ecdsa.pdf

Public Workshop: Lightning Talks

21 Zombies

Speaker: Mr Geoff Huston (APNIC)

Slides 2016-04-01-zombies.pdf

22 DNS-Stats Collector Project

Speaker: Sara Dickinson (Sinodun IT)

Slides OARC_Spring_2016_dns-stats.pdf

23 EDNS Compliance

Speaker: Mr Mark Andrews (ISC)

Slides https://ednscomp.isc.org/compliance/summary.html https://ednscomp.isc.org/compliance/tld-report.html

24 COM/Net Anycast Changes

Speaker: Mr Matt Weinberg (Verisign)

25 RIPE Atlas and DNS

Speaker: Mr Stéphane Bortzmeyer (AFNIC)

15:30 Afternoon Coffee Break

Public Workshop: DNSSEC Algorithm Rollover

Convener: Mr Sebastian Castro (NZRS)

26 Rolling the Root Key

This is a report of one member's perspectives on the work of the Root Key Roll Design Team, looking at the various operational tradeoffs that were involved in preparing the plan to roll the root key. I would also like to make some comments on the state of standards and implementations of resolvers and the lack of clear standard specifications about how to signal a key roll. Where possible I will illustrate the considerations with measurement data about the behaviour of resolvers that query authoritative name servers.

Speaker: Mr Geoff Huston (APNIC)

Slides 2016-03-30-kskroll.pdf

27 Algorithm roll-over experiences

Algorithm roll-overs are part of any security system, because older algorithms lose their strength, and stronger and newer algorithms come along. At the RIPE NCC we recently rolled our algorithm from SHA1 and to SHA256. We had some interesting issues, and I'd like to talk about them, especially as more people may want to consider rolling their algorithms now. Amongst these issues were things like software support, testing, planning of the roll-over and timing issues.

Speaker: Anand Buddhdev (RIPE NCC)

Slides OARC24_AnandBuddhdev_AlgRollover.key

28 Panel: DNSSEC algorithm flexibility

This is a proposal to have a discussion panel with DNS vendors (ISC, NlNetLabs, PowerDNS, CZ.NIC, Nominum, Microsoft) and people from operating systems and Linux distros (Microsoft, Debian, Ubuntu, RedHat, SuSE) to come and discuss challenges of introducing new and deprecating old DNS(SEC) algorithms. The proposed moderators are Dan York and Olaf Kolkman as neutral moderators. Also invited to participate are large scale DNS resolver like Google DNS, and reaching for other operators as well. The initial ideas to discuss are: 1. The life cycles of upstream (DNS vendors); 2. The life cycle of downstream (linux distros' releases, windows releases, etc.); 3. Experiences with customers' deployments, etc. 4. Other ideas We are expecting a 45 to 60 minute slot to have enough time for discussion.

Speakers: Dr Benno Overeinder (NLnet Labs), Dan York (Internet Society), Evan Hunt (ISC), Jan Včelák (CZ.NIC), Mr Ondrej Sury (CZ.NIC), Paul Wouters (Redhat), Mr Ralf Weber (Nominum Inc)

Slides

• BINDatOARC24.pdf
• DEBIAN-20160401-OS-OARC24.odp
• DEBIAN-20160401-OS-OARC24.pdf
• DNS-OARC24-DNSSEC-Alg-Flexibility-1.pdf
• Knot_DNS_Algorithm_Flexibility.pdf