OpenDNSSEC project transferred to NLnet Labs

September 15, 2014 by benno

NLnet Labs announces that it will take full responsibility for continuing the activities of both the OpenDNSSEC softwareproject as well as the support activities of the Swedish OpenDNSSEC AB. OpenDNSSEC was created as an open source turn-key solution for DNSSEC, managing the security of domain names on the Internet. The project drives adoption of Domain Name System Security Extensions (DNSSEC) to further enhance Internet security.

After initiating the OpenDNSSEC project in cooperation with UK Internet registry Nominet, the project and development has been managed by the Swedish Internet Structure Foundation (responsible for .SE) for more than 4 years. NLnet Labs contributed strongly from the early days onwards. Working closely together, both organizations agreed upon the transition of the project ownership to NLnet Labs.

NLnet Labs and its 100% subsidiary Open Netlabs BV, will continue the development and support from August 2014 onwards. There is a strong need to move forward—as the project has picked up pace—and increase the global acceptance and implementations of OpenDNSSEC. Embedding the project, product, and support in a sustainable environment will help achieving its original objectives and providing the required added value of the OpenDNSSEC software products. In order to allocate sufficient development capacity, NLnet Labs recently opened vacancies for junior and senior software system engineers.

About NLnet Labs

The NLnet Labs Foundation (NLnet Labs for short) is a not for profit foundation founded in 1999 in the Netherlands. Its statutes define its objectives: to develop Open Source software and open standards for the benefit of the Internet. The foundation believes that the Openness of the network, as enabled by technology and policy, thrives human wellbeing and prosperity. By contributing technology and expertise in the form of Open Source Software and Open Standards, we contribute to wellbeing and prosperity for all.

About Open Netlabs

Open Netlabs is a support and consultancy company, globally supporting organisations using NLnet Labs’ open source software and assisting customers in the implementation and operations of their DNS-infrastructure. High level support and SLA’s, consultancy and training are the core of the services portfolio of Open Netlabs. Open Netlabs BV is a wholly owned, taxable subsidiary of the NLnet Labs Foundation, serving the non-profit public benefit goals of its parent. The company is guided and managed according the charter of the NLnet Labs Foundation.

A next step…

June 2, 2014 by olaf

July 11 I  will be leaving NLnet Labs to join the Internet Society as Chief Internet Technology Officer.

During the last one-and half decade I have tried to push the needle to a more secure, resilient, and dependable Internet. For the last eight and a half years I did this at NLnet Labs by leading a team that writes high quality code, participates in the Internet standards process, and works with operators on implementations. The Lab has pushed the needle on DNSSEC deployment by building products that I proudly believe, make a difference for the Open Internet.

Why does it make a difference?

Because, the Internet’s technology matters.

Bottom up innovation and deployment of technology, even if there is very little short-term economic incentive to take action, is at the very hearth of the success of the Internet. The availability of Open Source software turns out to be an important driver for the successful deployment of new protocols. That is where NLnet Labs, and a myriad of other open (and closed) source developers, in groups or as individuals, make a difference.

As a corollary, when there is such little short-term economic incentive there needs to be buy-in for the vision of ‘what good looks like’. With such vision all the independent players can work towards a common objective and we collectively take a bet on a future network value. That is where ISOC makes the difference. With its promotion of the open development, evolution, and use of the Internet (for the benefit of all people throughout the world) ISOC can share a vision and encourage technologies that help to increase trust, provide security, and make the net more stable, to gain a foothold.

For me, the transition from an organization that builds technology for the Open Internet to an organization that promotes the Open Internet is a natural path. I had evangineer as job title on my business card: A pun combining the realism of technical engineering with the evangelizing the good of the Open Internet. At ISOC I plan to continue the practice of evangineering, by working ‘with good people and fostering broad collaboration to address the [Internet’s] issues, since we all know that the Internet’s Technology Matters’ (A quote from my predecessor Leslie Daigle).

NLnet Labs will be in good hands, with NLnet Labs veteran Benno Overeinder at the helm, and Han Brouwers (director of the wholly owned subsidiary Opennet Labs BV) on his side. NLnet Labs is a solid team working on innovative projects that will shape the future. Of course, NLnet Labs continues to be committed to its projects and products.

I will be a proud and supportive alumnus.


Hackathon at TNW-2014

May 1, 2014 by wouter
Wouter Wijngaards en Olaf Kolkman


At NLnet Labs we believe that DNSSEC allows for security innovations that will change the global security and privacy landscape. Innovations like DANE, a technology that allows people to use the global DNS to bootstrap a encrypted channel, are only the start of currently unimaginable technical innovation.

The deployment of DNSSEC is a typical collective action problem and we are trying to make a difference by providing the tools that help to reduce costs or bring value for those who want to provision, provide, and use secured DNS data.

The GETDNS API plays in that space. It is an attempt to provide applications a tool to get DNSSEC information that will aid the improvement of security and privacy.


The GETDNS API is an API description desigened by application developers for accessing DNS asynchronously with DNSSEC and DANE functionality. The GETDNS API is implemented in a collaboration effort by Verisign and NLnet Labs in the getdns library.

GETDNS participants at TNW 2014

The TNW 2014 conference in Amsterdam, the Netherlands, hosted a Hack Battle this year. Participants made ‘hacks’: apps or tools; using provided APIs and their own tools and competed in this contest. The contest ran for 36 hours and with 146 participants produced a number of contest entries. Verisign Labs and NLnet Labs promoted the use of the GETDNS.API library for DNSSEC, security, privacy and DANE implementation. This library and thus the API was available to the participants. In the contest the C API, the node.js API and the python API were available.

Four entries have been made using the GETDNS.API, those participants received GetDNS Tshirts. The other teams in the back battle can be viewed here.

The presentations of the teams are on video, youtube link.



By Ruslan Mavlyutov, Arvind Narayanan and Bhavna Soman.

This entry created a plugin for Thunderbird, in python, that checks the DNSSEC credentials of DKIM record associated with an email. The user can see the status of the email.

This entry won the prize given by NLnet Labs (Raspberry Pi™ kits)!

hackerleague link


Bootstrapping Trust with DANE

By Sathya Gunasekaran and Iain Learmonth.

GETDNS participants at TNW 2014

This entry adds DNSSEC secured OTR-key lookups to the python-based gajim XMPP client.  This project allows people that use OTR in their jabber client to check if the fingerprint of a key matches the fingerprints published in the DNS. They built a python library that uses getdnsapi to fetch OTR, openPGP and S/MIME fingerprints.

This team was interviewed by the Dutch Tweakers website, video link.

Github python dnskeys library link.

Github gajim branch.


DANE Doctor

By Hynek Schlawack and Richard Wall.

This entry is a website for debugging DANE. It shows diagnostics and highlights errors.

They also integrated the python bindings for getdns with the asynchronous python framework Twisted. They hope to be able to contribute this as a DANE enabled TLS client API to the Twisted framework.

Github link.


DNSSEC name and shame!

By Tom Cuddy and Joel Purra.

This entry wants to highlight which contest sponsors do the right thing to protect DNS data and shame the ones that do it wrong.

This team won the prize given by PayPal, because of the importance of protecting DNS data.

Github link.

website link.

The GETDNS API specification is edited by Paul Hoffman. Verisign Labs and NLnet Labs are cooperating on the implementation of the API using code and expertise from the Unbound and ldns projects. The getdnsapi implementation website, twitter.

Using PMTUD for a higher DNS responsiveness

June 4, 2013 by willem


In May 2011 we were notified (from a Japan based enthusiast) that our site wasn’t reachable over IPv6 unless the user lowered the MTU on his machine. This triggered interest in the “Path MTU Discovery black holes” problem [6]  and lead to a study [2] executed by Maikel de Boer and Jeffrey Bosma, two students from the University of Amsterdam (UvA), at NLnet Labs in June/July 2012.

During that study we learned that PMTU black-holes are especially problematic for stateless protocols, such as DNS over UDP. However, we also noticed that the IPv6 ICMP error messages (that realize the PMTUD) carry as much of the provoking packet as possible. We realised that for DNS, the state carried in the PMTUD ICMPv6 messages, might be enough for DNS servers to participate in PMTUD nevertheless.

To explore that potential we initiated another study executed by two UvA students, Hanieh Bagheri and Victor Boteanu, at NLnet Labs in January/February 2013 [1]. Below an overview of some of the considerations and steps taken in this study. We also created a proof of concept software program [5] that can extend any nameserver with PMTUD (on Linux) by listening and writing on a raw sockets on the same host as that nameserver.

Fragmentation, PMTUD and Packet-Too-Big (PTB)

IPv6 changed the way fragmentation is managed. With IPv4, fragmentation (and reassembly) of DNS-UDP packets was handled transparently by the network. With IPv6, only end-points may fragment. The size of the fragments (i.e. the smallest MTU of the links on the path between two end-points) should be detected by Path MTU Discovery (PMTUD).

PMTUD operates as follows: When a packet arrives on a link at a router somewhere on the internet, and the link to the next hop is too small for the packet to fit, the router returns a ICMPv6 Packet-Too-Big message to the sender of the packet. In the packet is, besides the MTU of the next/smaller link, as much of the causative packet as possible.

Name servers don’t do PMTUD

When an intermediate router returns an ICMPv6 Packet-Too-Big (PTB) message in response to an unfitting DNS answer, only on the OS layer of the PTB receiving name server the MTU for that destination (the resolver) is learned. The (stateless) name server does not resend the answer and the resolver has to requery.

A method has been proposed that tries to prevent PMTUD by always using the minimum MTU of 1280 [3]. However, this increases the likelihood of fragmented DNS answers. Earlier research has shown that +-10% of all end-points/resolvers discard IPv6 fragments [2][4].

A closer look at the headers in a Packet-Too-Big message

Router IPv6 Header:
|Version| Traffic Class |           Flow Label                  |
|         Payload Length        |  Next Header  |   Hop Limit   |
/                Source Address = Router      IPv6 address      /
/           Destination Address = Name server IPv6 address      /
ICMPv6 Header:
|  Type = PTB   |     Code      |          Checksum             |
|                              MTU                              |
Name server IPv6 Header:
|Version| Traffic Class |           Flow Label                  |
|         Payload Length        |  Next Header  |   Hop Limit   |
/                Source Address = Name server IPv6 address      /
/           Destination Address = Requester   IPv6 address      /
Optional Fragment Header:
|  Next = UDP   |   Reserved    |      Fragment Offset    |   |M|
/                        Identification                         /
UDP Header:
|          Source port          |      Destination port         |
|            Length             |          Checksum             |
Quite a bit of the original DNS answer:
|              ID               |R|Opcode |A|C|D|A|Z|D|D| RCODE |
|            QDCOUNT            |           ANCOUNT             |
|            NSCOUNT            |           ARCOUNT             |
/            Query                                              /

ICMPv6 PTB messages contain as much of the invoking packet as possible without the whole packet exceeding the minimum MTU (of 1280). In theory it should carry at least 1176 of the original DNS answer (1280 – 40 IPv6 header of router – 8 ICMPv6 header – 40 IPv6 header of nameserver – 8 possible fragmentation header – 8 UDP header = 1176). The DNS question is embedded in a DNS answer near the beginning in the question section. A PTB message is thus very likely to carry both the destination of the request as the request (the question) itself. Enough information to answer it again in smaller packets.

Oberservations and Approach

To deliver a name server software independent solution, we implemented PMTUD for DNS  in a process separate from the name server. The process has to run on the same host and employs raw sockets to listen and react to PTB messages.

Care should be taken when responding to PTB messages. With insufficient caution opportunities for cache poisoning and amplification attacks are easily opened. This is caused by the fact that a malicious attacker may construct a PTB message indistinguishable from a real PTB targeted at the name server.

A summary of approaches follow, each with a brief analysis of the consequences.

Consider simply setting the TC (truncated) bit and retransmit what is left of the answer. This is the most simple and semantically correct approach. However, it is very easy for a malicious attacker to forge a requester’s source address. An attacker does not even have to actually spoof the source address; It just pretends it is an router on the path between a (supposedly) requester and the name sever and creates a false “Name server IPv6” header and everything below it. By simply trusting and retransmitting the answer in a PTB message, we allow third parties to send out any DNS answer from our name server’s source address; and in doing so open a cache poisoning attack vector. (Although clients are unlikely to interpret a truncated message and will most likely rerequest over TCP).

DNS answers contain the query for which it is an answer (including query ID and flags). It may be extracted from the answer and reinjected (with raw sockets). However, EDNS0 information, like the for the requester acceptable message size and the DO (DNSSEC OK) bit, is almost certainly missing because it is situated at the end of the original message (which is torn off). We can assume that it was present in the original request though, because otherwise it would not have provoked a big response.

Setting the acceptable message size to a prevailing value, like 4096, might seem just, however this would enable a malicious attacker to provoke a bigger answer than the size of the forged PTB message and thereby open an very easy opportunity for amplification attacks. No actual source address spoofing required. Therefore, care must be taken that only answers smaller or equal than the PTB message size will be given. A reinjected request must restrict the size of the answer by setting the EDNS0 acceptable message size to the size of the PTB. This approach is implemented in the proof-of-concept program [5].

Tests and measurements
We have assessed the proof-of-concept program using RIPE Atlas; a global network of probes that measure Internet connectivity and reachability. Using RIPE Atlas we were able to send DNS queries to a name server at NLnet Labs from 863 different IPv6 vantage points, all from different networks at different locations in the world.

The name server at NLnet Labs served a zone with RR’s that, when queried directly over IPv6, would generate a precisely sized answers:

  • TXT produces an 1280 bytes packet answer
  • TXT produces
    • a 1500 bytes packet when not fragmenting to the minimum MTU, or when
    • fragmented to the minimum MTU,
      a fragment of 1280 bytes and one of 180 bytes
  • TXT procudes
    • fragmented to the maximum MTU,
      a fragment of 1496 bytes and one of 160 bytes
    • fragmented to the minimum MTU,
      a fragment of 1280 bytes and one of 376 bytes.

Fragmenting to minimum MTU could be turned on or off in the name server as desired.

We identified for each probe how the network behaves with different types of messages. We started with a baseline measurement by querying for small answers ( to see which probes can reach our name server. 863 IPv6 probes successfully received the answer.

Then we identified probes with a PMTU smaller  than 1496 by answering the queries with large packets. We let the probes query for TXT with “fragmenting to minimum MTU” on our name server turned off.
439 probes did not receive an answer. Those probes have a PMTU smaller than 1496.

Then we identified the probes having fragment filtering firewalls by sending a big answer in smaller packets/fragments. Again we let the probes query for TXT, but this time with “fragmenting to minimum MTU” on our name server turned on.
68 probes did not receive an answer at all. Those probes are behind fragment filtering firewalls

Besides counting the answers received by probes, we also analysed traffic to the name server. One noticeable thing in those captures was that: 18 of the 68 fragment filtering probes,  sent an ICMPv6 “Administratively Prohibited” message in response to receiving a fragment. It appears some firewalls are friendly enough to report that they drop the message this way. Just like PTB, “Administratively Prohibited” also has most of the DNS answer in its payload. We have adapted our proof-of-concept program to respond to “Administratively Prohibited” too.

Finally we tested the proof-of-concept program by querying from the probes for TXT with “fragmenting to minimum MTU” on our name server turned off. 23 probes still did not receive an answer at all. These must be the probes that are on a smaller PMTU for which no PTB messages are sent.  The remaining probes returned PTB only occasionally or returned a non-standard sized PTB too small to extract a query from.

In the table below an overview is given of the taken measurements and the answers that could be counted. Note that for each measurement, each probe queried the name server several times (with 20 minutes interval). So it is possible for a probe to count for receiving a good answer, and receiving no answer.

measurement msg size max. pkt size # probes # answered # no answer
baseline 1280 1280 863 863 (100.0%) 0 (0.0%)
PMTU < 1500 1600 1500 861 422 (49.0%) 441 (51.1%)
fragment filters 1600 1280 861 795 (92.3%) 84 (9.8%)

With proof-of-concept program running:

unfragmented 1500 1500 828 805 (97.2%) 35 (4.2%)

All measurements were performed in the period 25 May – 2 June 2013.


Current name servers do not respond to PTB messages. As a result clients with smaller PMTUs will not receive an answer from an initial query. They will still receive a fragmented answer when a second query is sent within the PMTU expiry timeout (10 minutes). Responding to PTB will serve the initial queries too and will also serve clients that query for big answers infrequently.

Also, on RIPE atlas, responding to PTB is gives better DNS responsiveness than avoiding PTB, because fragments are more frequently filtered than PTB messages are not sent. Of the probes that did not receive an initial answer, 64% will receive one when responding to PTBs. Also, when answers exist in the 1232-1452 size range, more queries will be answered without fragmenting, resulting in an even bigger responsiveness increase.


  1. H. Bagheri, V. Boteanu, ”Making do with what we’ve got: Using PMTUD for a higher DNS responsiveness” (February 2013)
  2. M. de Boer, J. Bosma, “Discovering Path MTU black holes on the Internet using RIPE Atlas”, (July 2012)
  3. M. Andrews, “DNS and UDP fragmentation”, draft-andrews-dnsext-udp-fragmentation-01, (January 2012)
  4. J. van den Broek, R. van Rijswijk, A. Pras, A. Sperotto, “DNSSEC and firewalls – Deployment problems and solutions”, Private Communication, Pending Publication, (2012)
    Results are presented here:
  5. The PMTUD for DNS activating Proof-Of-Concept script
  6. K. Lahley, “TCP Problems with Path MTU Discovery”, RFC2923 (September 2000)
  7. W. Toorop, “Using Path MTU Discovery (PMTUD) for a higher DNS responsiveness” presentation slides at the 5th CENTR R&D workshop, Amsterdam (June 2013).


Open Recursor Blocked

April 19, 2013 by wouter

We have blocked an open recursive DNS nameserver running at NLnet Labs. This was due to abuse traffic, reflected traffic.

Two different types of abuse traffic were pointed at this server:

  • Queries of type ANY for large DNSSEC data. Sporadic bursts of about 3-5 qps, to one or two target IPv4 addresses at the same time.
  • Queries for NXDOMAIN responses, sporadic bursts of fairly low qps, with different query names for every query.

This is a low traffic volume. For a sizable Denial-Of-Service stream many more recursive resolvers must have been sent such query streams. The second type also has different query names for every query, which together with the low traffic volume would bypass RRL rate limiting.

A sample of the traffic with different query names:

Apr 10 23:08:12 : 192.x.x.x kelfmdaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:12 : 192.x.x.x fcbajpaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x iediclaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x pfkgckaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x fjcjbdaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x dcdefaaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x eemcblaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x ocadmmaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x gblhefaaaaerv0000diaaaaaaafaejam. A IN
Apr 10 23:08:13 : 192.x.x.x mmhjaaaaaaerv0000diaaaaaaafaejam. A IN

At NLnet Labs we host this open resolver for use by the dnssec-trigger project. It is used as one of the last fallback strategies for the retrieval of DNSSEC signed DNS data. The legitimate traffic is very low to this resolver, perhaps 1 qps. Dnssec-trigger is a project that helps enable DNSSEC validation on laptop and desktop computers. Dnssec-trigger probes the environment and selects a method to retrieve DNSSEC data, if possible it uses local methods, such as the DHCP supplied DNS resolver, or contacting the DNS servers on the internet over UDP. Therefore it does not contact the open resolver unless there is an alternative.

We have blocked UDP traffic for port 53 towards this open resolver. Other ports are left open so that the resolver can use UDP on other ports to retrieve DNS data from the internet itself. Dnssec-trigger uses the TCP and SSL ports for contacting this server, because if UDP works at some internet location, then dnssec-trigger uses that to contact different DNS servers.

The firewall rule that we enabled to block UDP traffic to port 53 on the open resolver:

broer = "{, 2001:7b8:206:1:bb:: }"
block in quick on $ext_if proto { udp } from any to $broer port 53 no state

The open resolver cannot be contacted for queries on UDP, but remains usable on TCP, and on ports 80 and 443. This functionality is used by the dnssec-trigger project, so the resolver remains usable for DNSSEC deployment.


ISOC.NL nominatie.

November 1, 2012 by olaf

This posting contains the text that we send to the jury after our nomination for an award from the Dutch ISOC chapter in the category Security and Privacy. Try google-translate for an awful translation of this text.

Over NLnet Labs

Stichting NLnet Labs is een algemeen nut betogende instelling die zich bezig houdt met de ontwikkeling van Open Source Software en Open Standaarden ten behoeve van het Open Internet. We concentreren ons op de technologieën die nodig zijn om de openheid het Internet te behouden; technologieën die het ‘netwerk van netwerken’ efficiënt en veilig laten draaien; technologieën die een groter algemeen belang dienen.

Sinds onze oprichting in 1999 hebben we ons bezig gehouden met de ontwikkeling van DNSSEC. DNSSEC is technologie die een belangrijke component van het Internet beveiligd en waarop nieuwe veiligheidsmechanismen op kunnen worden gebaseerd. Een voorbeeld van een dergelijke innovatie is ‘DANE’, op DNS gebaseerde certificaat signalering die de barrière voor incidenten als de Diginotar-affaire een stuk hoger legt [zie recente presentatie].

Over dnssec-trigger

dnssec-trigger is software waarmee we proberen een van de problemen van DNSSEC roll-out  weg te nemen: hoe breng je de beveiliging die DNSSEC biedt uiteindelijk naar de eindgebruiker. Dnssec-trigger overbrugt dus de zogenaamde last-mile bij het brengen van DNSSEC naar de eindgebruiker en is daarmee de eerste en vooralsnog enige tool die dit OS-breed en applicatie onafhankelijk levert.

dnssec-trigger integreert Unbound, onze high-performance recursieve nameserver, met automatische configuratie die voor de gebruiker uitzoekt of DNSSEC in het netwerk ook echt te gebruiken is. dnssec-trigger doet maximale inspanning om de eindgebruiker DNSSEC te leveren: De software houdt rekening met nomadische gebruikers die verschillende netwerken met verschillende eigenschappen gebruiken – en bijvoorbeeld tegen inlogschermen (een zg. ‘captive portal’) in een hotelnetwerk aanlopen.

dnssec-trigger past in onze filosofie om kwalitatief hoogwaardige toepassingen te leveren waarmee praktische drempels met betrekking tot de uitrol van belangrijke globale verbeteringen van de Internet infrastructuur worden weggenomen. Met het leveren van dit soort software doen we waardevolle ervaring op die we terugvoeren in het IETF-standaardisatieproces en delen met de (globale) internet gemeenschap.

De dnssec-trigger software vind je op of in je favoriete software repository.

Over de Nominatie

NLnet Labs houdt zich bezig met de ontwikkeling en uitrol van technologie die misschien niet direct het predicaat sexy heeft, maar die wel een essentiële bijdrage levert aan het open en veilig houden van het Internet. Ons werk is 100% van private donaties afhankelijk. We zijn dus blij met de aandacht die de nominatie voor dnssec-trigger ons oplevert.

Wed Sep 25 2013

© Stichting NLnet Labs

Science Park 400, 1098 XH Amsterdam, The Netherlands, subsidised by NLnet and SIDN.