De privacy van het DNS verhogen met QNAME minimisation

Voornaamste conclusies

• Adoptie van qmin neemt langzaam maar zeker toe

• Implementatie van qmin verschilt, afhankelijk van de gebruikte resolversoftware

• Qmin kan leiden tot een iets hogere queryload en in enkele gevallen kunnen lookups mislukken

Hoe komt het dat DNS-queries privacygevoelig zijn?

Als een applicatie (bijvoorbeeld een browser of e-mailprogramma) gebruikmaakt van het DNS om het IP-adres van een domeinnaam op te zoeken, wordt daarbij de volledige naam van het domein gebruikt. Dit houdt in dat als je met je browser naar www.netflix.com gaat, je daaruit kan afleiden dat je vermoedelijk graag films kijkt. Op dezelfde manier onthult een query naar www.nos.nl dat je waarschijnlijk geïnteresseerd bent in het laatste nieuws van de publieke omroep. Nu zal je privacy met deze queries misschien niet al te zeer aangetast worden, maar een query voor een-akelige-ziekte.example.nl kan mogelijk gevoelige medische informatie prijsgeven.

Als DNS-operator van het TLD .nl ontvangt SIDN meer dan een miljard DNS-queries per dag voor allerlei verschillende domeinnamen. Onze nameservers kennen het IP-adres van example.nl of een-akelige-ziekte.example.nl niet. Ze verwijzen de resolver waar de query vandaan komt enkel door naar de nameservers voor example.nl en negeren een-akelige-ziekte. Een resolver kan ons dus simpelweg om de nameservers voor example.nl vragen zonder de volledige querynaam (een-akelige- ziekte.example.nl) te onthullen. In de praktijk zien we echter dat meer dan 50 procent van de queries naar de nameservers van .nl meer informatie bevatten dan nodig is. De redenen hiervoor zijn hoofdzakelijk historisch.

De querynaam minimaliseren

In de QNAME minimisation standaard, in 2016 in de IETF geintroduceerd als RFC 7816, staat beschreven hoe recursieve resolvers de informatie die wordt vrijgegeven, zo beperkt mogelijk dienen te houden. Zo zou een resolver ons in het bovenstaande voorbeeld slechts een query voor example.nl moeten sturen en dan alleen voor de nameservers en niet voor het IP-adres.

Dat klinkt misschien niet al te moeilijk, maar in de praktijk ligt het concept van qmin toch wat ngewikkelder. Dit komt voornamelijk doordat op elk niveau delegeringen kunnen voorkomen. Zo kan het domein a.b.c.d.e.example.com delegeringen naar nameservers bevatten op elk (of geen) van de subdomeinen. Het punt waarop het gezag over een bepaald deel van het domein eindigt en dat van een andere nameserver begint, wordt een zone cut genoemd. Dit heeft tot gevolg dat qmin-implementaties in theorie een query voor het domein iteratief moeten uitvoeren, waarbij de lengte van het domein steeds één stap toeneemt, totdat er een delegering wordt bereikt.

Deployment

Omdat de standaard inmiddels meer dan twee jaar bestaat en sommige resolversoftware al qmin-implementaties hebben, waren we benieuwd in hoeverre de uitrol van qmin op het internet is toegenomen.

Om vast te stellen of qmin wordt ondersteund, maken we gebruik van het feit dat resolvers zonder qmin ondersteuning een delegering zouden missen op een label vóór het eindlabel. Als we delegeerden naar een andere nameserver, met een ander record voor de eindlabel in een van de labels vóór de eindlabel, zouden resolvers met qmin dus een ander antwoord krijgen dan resolvers zonder qmin.

Op grond daarvan planden we een reeks langlopende metingen met behulp van het meetnetwerk RIPE Atlas. We voerden een lookup uit met alle resolvers in het RIPE-netwerk door queries voor a.b.qnamemin-test.domain.example elk uur te herhalen, waarbij de domeinnaam in kwestie onder ons beheer stond. We waren in staat een resolver zonder qmin als zodanig te herkennen omdat een dergelijke resolver een query voor de volledige querynaam naar de autoritatieve nameserver voor qnamemin-test.domain.example zou versturen en een TXT-antwoord zou ontvangen met de tekst: “qmin NOT enabled”. Een resolver met qmin zou een query voor slechts de op één na laatste label, b.qnamemin-test.domain.example, naar de autoritatieve nameserver voor qnamemin-test.domain.example versturen. Voor die geminimaliseerde query zou een delegering naar een andere nameserver worden ontvangen, wat een TXT-record zou opleveren met de tekst: “qmin enabled”. In totaal hebben we op deze manier meer dan 18.000 resolvers getest.

In de onderstaande afbeelding wordt de adoptie van qmin sinds april 2017 weergegeven. In de periode dat we het onderzoek uitvoerden, nam de adoptie van 0,7 procent toe naar 16,8 procent. De enorme toename in april 2018 was vooral te danken aan RIPE Atlas probes die gebruikmaken van de open resolver van Cloudflare, die qmin standaard ondersteunt. De cijfers worden dagelijks bijgewerkt en hier gepubliceerd.

Behalve door gebruik te maken van RIPE Atlas, hebben we de adoptie van qmin ook gemeten door open resolvers en de nameservers van .nl te controleren. Eerst hebben we een lijst van 1,2 miljoen open resolvers bevraagd die gekoppeld zijn aan 110.000 unieke IP's, die door onze autoritatieve nameservers werden geobserveerd. Daarvan bleek slechts 1,6 procent qmin te ondersteunen.

Binnen .nl ziet de situatie er wat rooskleuriger uit. Sinds juni 2017 is het aantal bevraagde secondleveldomeinnamen toegenomen van ongeveer 33 procent naar het huidige percentage van 44 procent. We nemen aan dat een resolver qmin ondersteunt als er voornamelijk queries voor de twee meest rechtse labels van een domeinnaam (example.nl in een-akelige-ziekte.example.nl) worden verstuurd. De statistieken worden dagelijks bijgewerkt en zijn te vinden op onze statistiekenwebsite stats.sidnlabs.nl.

Implementatie

Volgens de standaard dient een resolver met qmin de naam iteratief met één label te verlengen, waarbij steeds het NS-type wordt bevraagd, totdat de volledige naam is bereikt. Vervolgens dient te worden overgestapt op het oorspronkelijke querytype. In de praktijk zien we echter dat qmin op allerlei manieren wordt geïmplementeerd, maar nooit precies zoals in de standaard wordt omschreven.

Wederom met behulp van RIPE Atlas lieten we de resolver van elke probe queries sturen naar een testdomein met 24 labels onder ons beheer. Door de queries rechtstreeks bij de autoritatieve nameserver op te halen, zagen we dat resolvers met qmin niet één query per afzonderlijke label versturen, maar doorgaans slechts een query versturen voor de eerste paar labels en dan naar de laatste label van de querynaam springen. Knot en BIND beginnen met het versturen van NS-queries, maar Unbound bevraagt alleen A-records. Resolvers kiezen voor dergelijke strategieën om de queryload te verlagen en te voorkomen dat ze vast komen te zitten in verkeerd geconfigureerde zones. In de volgende tabel wordt weergegeven hoeveel resolvers volgens onze waarnemingen de diverse gedragingen vertoonden. 

Nadelig effect op performance

Ten slotte waren we benieuwd of qmin van invloed is op de performance of het aantal succesvolle queries. We creëerden een testbed met resolvers die werkten met Unbound (versie 1.8.0), Knot (3.0.0) en BIND (9.13.3) en verstuurden queries naar de miljoen populairste domeinnamen, zoals vermeld in de top 1 miljoen van Cisco Umbrella. Unbound en BIND ondersteunen zowel een strenge (strict) als een wat soepelere (relaxed) versie van qmin en dus hebben we beide versies getest. In de strenge modus grijpen resolvers niet terug op het versturen van de volledige QNAME naar mogelijk defecte nameservers. We begonnen onze metingen met een lege cache.

Afhankelijk van de implementatie zagen we een toename van het aantal queries van 19 procent in Unbound tot 26 procent in BIND. Bij productieresolvers zal de daadwerkelijke toename waarschijnlijk lager zijn, omdat caching de overhead verlaagt.

Verder ontdekten we dat we sommige domeinnamen niet konden resolven als we de resolvers lieten draaien met de strenge implementaties van qmin: tot 3 procent met Unbound en tot 5 procent met BIND. Gelukkig bleek er in de soepele modus bij Unbound geen toename te zijn en bij BIND slechts een toename van een half procent. De volgende tabel geeft een overzicht van onze meetresultaten. Het betrekkelijk hoge aantal fouten, zelfs als qmin was uitgeschakeld, is een kenmerk van de Umbrella-lijst.

Zelf qmin meten

Je kunt zelf testen of je resolver qmin ondersteunt door met behulp van de command line tool digeen query te versturen naar het volgende domein:

dig a.b.qnamemin-test.internet.nl TXT

Conclusie: de privacy van het DNS neemt toe

Onze resultaten geven aan dat qmin in opmars is en wij vinden dat een goede zaak. De licht afgenomen performance is een aanvaardbare prijs voor de verbeterde privacy van internetgebruikers en bovendien is de daadwerkelijke afname in de realiteit waarschijnlijk lager dan waargenomen in onze tests. 

Meer informatie over de metingen is te vinden in onze paper, die is geschreven in samenwerking met Quirin Scheitle (Technical University of Munich), Willem Toorop en Ralph Dolmans (NLnet Labs) en Roland van Rijswijk-Deij (NLnet Labs en Universiteit Twente). Ook hebben we onze dataset, waarvoor we op de PAM conferentie de prijs voor de beste dataset wonnen, openbaar gemaakt.