‹ Back
Deploy360 24 May 2016

RIPE 72 – Highlights from Day 1

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

RIPE 72The RIPE 72 meeting is happening this week in Copenhagen, Denmark, and looks to be the biggest ever with nearly 800 registered participants. Jan and Kevin from the Deploy360 team are here, and we’ll be highlighting all the relevant presentations and activities.

There were three interesting DNS presentations during the opening plenary session that are worth highlighting. The first by Paul Ebersman (Comcast) asked the question “What’s so hard about DNSSEC?” and related his deployment experiences. The main reasons to deploy DNSSEC are the ability to assert responses to DNS queries, to help protect against cache poisoning, and as a way of enabling DANE and other PKIs.

The oft-heard reasons for not deploying DNSSEC are that it requires a lot of additional work, tends to break things, and is reliant on ICANN and the root servers. The reality though, is that the DNS already relies on the root servers, customers increasingly expect improved security, and that DANE is already being used for validating non-web servers. Deployment of DNSSEC can require additional effort, but this can be substantially reduced through automation.

Whilst setting-up the signing of a zone requires some effort and key rollovers need to be handled carefully, Comcast’s experience was that their signed zones typically returned less than two dozen errors per month, whilst the need for Negative Trust Anchors (NTAs) was limited to single digits per month. The message therefore, is that using DNSSEC is not without problems, but most of these can be mitigated by careful planning and communication and has been substantially less painful than anticipated.

The second presentation was an alert from Patrik Fältström (Netnod) that Web Proxy Auto‐Discovery (WPAD) queries intended for resolution on private or enterprise DNS servers have been observed reaching public DNS servers. This could result in domain name collisions with internal network naming schemes, allowing these to be abused by configuration of an external proxy for network traffic that provides the potential for man‐in-the-middle attacks. This issue has been known about for at least three years, but the problem has been increasing as more second-level domains have been created within new gTLDs and more platforms have been found to be affected.

Network administrators are therefore being asked to disable automatic proxy discovery/configuration in browsers and operating systems, use fully qualified domain names (FQDNs), configure internal DNS servers to respond authoritatively to internal TLD queries, whilst configuring firewalls and proxies to log and block outbound requests for wpad.dat.

The third presentation was an analysis by Geoff Huston (APNIC) on DNS zombies – queries that have no user awaiting the response and are instead are echoes of previous queries. Over a five month experiment and detailed analysis of around 44 billion DNS queries, it was discovered that around 20%  these queries were zombies, but question was whether this behaviour is due to DNS resolvers continually sending out queries for which responses are never accepted, or whether this was due to something more sinister? As it transpires, it would seem to be attributable to misconfigured resolvers, of which just 11 are responsible for 60% of all zombie queries. This is explained in more detail in this APNIC article.

We’d also like to highlight the presentation from our Internet Society colleague Phil Roberts on Cryptech. This an open source hardware security module (HSM) reference design that can store, manage and process digital keys as used in DNSSEC, PKI, RPKI and PGP amongst other applications. The aim is to address concerns about potentially compromised devices in critical Internet infrastructure, and to ensure IETF protocols are supported in an open and transparent manner.

The first alpha boards are now working and will be available for external testing this summer, initially supporting DNSSEC with RPKI coming shortly afterwards. Cryptech was therefore looking for people with implementation and operational experience of these technologies to help undertake additional testing of these devices, as well as help with the documentation. More information is available on the Cryptech website.

Although not directly related to Deploy360, it’s also worth checking out a couple of presentations on the State of African Peering by Andrew Owens (Teraco) and Interconnection in the Nordics by Lasse Jarlskov (TDC) which provide a good overview on where and how peering happens in two distinct regions of the world.

Following the plenary session, Jan Žorž chaired the BCOP Task Force. There were two new BCOPs up for discussion relating to DNS Operations and Using your last IPv4 address, as well as an update on the MANRS (Mutually Assured Norms for Routing Security) BCOP. The meeting was also updated on BCOP developments in Africa and Latin America, some of which were discussed in our previous post on the AfBCOP Workshop.

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at https://ripe72.ripe.net/programme/meeting-plan/

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...

Join the conversation with Internet Society members around the world