Cases

Hands-on: DNSSEC-ondertekening op BIND named

Beheerders die zelf hun DNS-dienst onderhouden maken daarvoor meestal gebruik van BIND named, de meest gebruikte DNS-server buiten de wereld van de grote registrars. BIND named kan fungeren als (autoritatieve) name-server en/of (caching) resolver. In dit artikel behandelen we de ondertekening van een zone op een autoritatieve name-server. De configuratie van named als DNSSEC-validerende resolver lees je in een ander artikel.

De DNSSEC-functionaliteit van BIND is over de afgelopen jaren stapsgewijs ontwikkeld en inmiddels een volwassen onderdeel van deze DNS-server geworden. Dat betekent wel dat er aanzienlijke verschillen zijn tussen achtereenvolgende (minor) versies.

Waar mogelijk en relevant geven we in dit artikel steeds aan vanaf welke versie een bepaalde feature ondersteund wordt. Dat is met name van belang voor gebruikers van enterprise-platforms, omdat die uit stabiliteits- en veiligheidsoverwegingen in het algemeen niet de meest recente software-versies gebruiken. Daarnaast kan het heel goed zijn dat de BIND-software op een bestaande server inmiddels opgewaardeerd is via het package management systeem van het operating system, maar de gebruikte configuratie nog is gebaseerd op een oudere versie.

Nog vier weken tot de root KSK roll-over: check je DNSSEC trust anchors!

Validerende resolvers die RFC 5011 ondersteunen zouden inmiddels de nieuwe publieke root KSK-sleutel als trust anchor geïnstalleerd en geactiveerd moeten hebben. Gebruik je nog software die RFC 5011 niet ondersteunt en je hebt het nieuwe trust anchor nog niet handmatig geïnstalleerd, dan wordt het de hoogste tijd om dat alsnog te doen. Vanaf 11 oktober zijn namelijk alle internetdomeinen onbereikbaar voor gebruikers van resolvers die niet van het nieuwe trust anchor zijn voorzien.

In dit artikel laten we zien hoe je de beschikbaarheid van het nieuwe trust anchor kunt controleren.

Automatische installatie nieuwe DNSSEC trust anchor

De meeste software voor DNSSEC-validerende resolvers ondersteunt inmiddels RFC 5011. Dat betekent dat deze resolvers in staat zijn om automatisch de nieuwe publieke root KSK-sleutel als trust anchor te installeren.

Hoewel RFC 5011 ontwikkeld is om (root) KSK roll-overs zonder tussenkomst van de systeembeheerder te laten verlopen, is het belangrijk om te controleren of de huidige installatie/configuratie van je resolvers inderdaad de automatische installatie van het nieuwe trust anchor ondersteunt. Is een validerende resolver uiterlijk op 11 oktober 2017 niet van het nieuwe trust anchor voorzien, dan zijn vanaf dat moment alle internet-domeinen voor de gebruikers/applicaties van de betreffende resolver onbereikbaar.

• achtergrond
• veel gestelde vragen
• handmatige installatie

In een eerder artikel beschreven we de verschillende manieren waarop beheerders van validerende resolvers het nieuwe trust anchor op hun systemen kunnen installeren, gevolgd door specifieke informatie voor verschillende resolver software-pakketten.

In dit artikel bespreken we RFC 5011 en geven we een overzicht van de ondersteuning door de meest gebruikte resolvers. In een follow-up artikel laten we zien hoe je de goede werking van het nieuwe trust anchor kunt testen.

De root KSK roll-over — veel gestelde vragen

Op dit moment is ICANN bezig met de roll-over van het KSK-sleutelpaar van de DNS root. Dat betekent dat ICANN het huidige cryptografische sleutelpaar dat de basis vormt voor de DNSSEC-infrastructuur vervangt door een nieuw sleutelpaar.

Beheerders van validerende resolvers moeten het publieke gedeelte van het nieuwe sleutelpaar als trust anchor op hun systemen installeren. Is dat uiterlijk op 11 oktober 2017 niet gebeurd, dan kunnen vanaf die dag de digitale handtekeningen onder de DNS-records niet meer gevalideerd worden. Daarmee zijn dan alle Internet-domeinen voor de gebruikers/applicaties van de betreffende resolver onbereikbaar geworden.

Op deze pagina beantwoorden we de meest gestelde vragen over de root KSK roll-over.

Roll-over voor root zone vraagt om attentie van DNSSEC-beheerders

Afgelopen najaar heeft ICANN de roll-over van het (KSK) sleutelpaar voor de root zone in gang gezet. Dat betekent dat het cryptografische sleutelpaar dat aan de basis ligt van de hele DNSSEC-infrastructuur wordt ververst (dat wil zeggen vervangen).

Er kleven belangrijke risico's aan deze update. Hoewel de kans daarop klein is, kan een fout betekenen dat het hele internet (inclusief de niet-ondertekende domeinen) onbereikbaar wordt voor de gebruikers/applicaties die gebruik maken van validerende resolvers.

Hetzelfde speelt op lokaal niveau. Beheerders van validerende resolvers zullen moeten zorgen dat eerst de nieuwe (publieke) sleutel aan de trust anchors op hun servers wordt toegevoegd, en later dat de oude sleutel van hun systemen wordt verwijderd. Laten zij dat na, dan kunnen de digitale handtekeningen onder de top-level domeinen (TLD's) in de root zone niet meer gevalideerd worden. In dat geval zouden alle internet-domeinen voor de gebruikers van de betreffende resolver onbereikbaar worden.

RFC 5011 maakt het mogelijk de nieuwe (publieke) sleutel automatisch als trust anchor te laten installeren. De ontwikkelaars van de meest gebruikte validerende resolvers — PowerDNS, BIND named, Unbound en OpenDNSSEC — geven aan dat hun software dit protocol ondersteunt. De sterk verouderde appliances van Infoblox ondersteunen RFC 5011 niet, waarmee ze hun klanten met een nieuw probleem opzadelen.

DNSSEC-implementatie Infoblox sterk verouderd

Belangrijke aandachtspunten bij het aan zetten van DNSSEC

Twee jaar geleden bespraken we de configuratie van DNSSEC op de Trinzic DDI appliances van Infoblox. De belangrijkste conclusies waren dat het ondertekenen en valideren in de grafische interface erg eenvoudig aan te zetten waren — slechts een kwestie van aanklikken — maar dat de default-instellingen wel dringend verbetering nodig hadden.

Infoblox beloofde destijds bij monde van Chief Infrastructure Officer Cricket Liu om deze zaken in een volgende release aan te passen. Inmiddels zijn we echter twee jaar en een major release verder, en blijkt er helemaal niets te zijn aangepast of toegevoegd. Daarmee zitten Infoblox-klanten met een inmiddels sterk verouderd systeem.

Wie al een Infoblox-system heeft staan en DNSSEC aan wil zetten, zal bij de configuratie daarvan extra aandacht moeten besteden aan de cryptografische default-instellingen van zijn appliance.

MIDDAG voorziet .nl-domeinen van DNSSEC op basis van algoritme 13

De recentelijke ondersteuning van DNSSEC-algoritmen nummer 13 en 14 door SIDN kwam internet-dienstverlener MIDDAG heel goed uit. Begin dit jaar heeft het bedrijf het beheer van al zijn domeinnamen ondergebracht bij CDN-aanbieder CloudFlare. Omdat CloudFlare zijn sleutelmateriaal alleen beschikbaar stelt op basis van algoritme nummer 13 en SIDN dit protocol nog niet ondersteunde, was daarmee de weg naar DNSSEC geblokkeerd. Nu dat probleem is opgelost heeft MIDDAG gelijk alle 160 .nl-domeinen van DNSSEC voorzien.

Rond de jaarwisseling zijn we voor het beheer van al onze domeinen overgestapt naar CloudFlare, vertelt Vic D'Elfant, software architect en eigenaar van MIDDAG. We hebben toen contact opgenomen met SIDN en gevraagd of zij algoritme nummer 13 konden ondersteunen. Toen we van hen hoorden dat deze mogelijkheid in de volgende release van DRS zou zitten, hebben we dat even afgewacht.

SIDN perst laatste DNSSEC-validatiefouten uit de .nl-zone

Validation Monitor XXL controleert elke nacht alle .nl-domeinen

Afgelopen voorjaar nam SIDN de Validation Monitor XXL in gebruik. Deze tool controleert nu elke nacht alle 2,5 miljoen DNSSEC-ondertekende domeinen op validatiefouten. Daarmee is weer een flinke slag gemaakt in het terugdringen van het aantal fouten in de .nl-zone. Dat aantal ligt inmiddels onder de 1,2 promille. Bovendien gaat het steeds meer om domeinnamen die niet of nauwelijks gebruikt worden.

Voor access providers is er geen enkele reden meer om DNSSEC-validatie op hun caching resolvers niet aan te zetten. De vrees voor extra belletjes van klanten naar de helpdesk is inmiddels niet meer gerechtvaardigd. Voor de grote Nederlandse providers is het nu zaak om bij de toeleveranciers waar het beheer van hun netwerk-infrastructuur is ondergebracht aan te dringen op de ondersteuning van validatie.

Antagonist ondertekent zijn gehoste domeinnamen

Antagonist heeft eerder dit jaar alle .nl-domeinen die de webhoster voor zijn klanten beheert voorzien van DNSSEC. Daarmee brak het aantal ondertekende .nl-domeinnamen door de twee miljoen. En dankzij dit soort registrars die hun hele bestand in één keer beveiligen loopt die groei lekker door: inmiddels zijn al meer dan 2,4 van de bijna 5,6 miljoen .nl-domeinen ondertekend.

Het ondertekenen van de .nl-domeinen waarvoor ook de hosting bij Antagonist is ondergebracht werd vergemakkelijkt doordat dat in een geïsoleerde omgeving kon gebeuren. We hebben hier twee aparte sets van nameservers staan, vertelt ontwikkelaar Ewoud Kohl van Wijngaarden, een voor onze hosting-klanten en een voor mensen die alleen hun domeinnamen bij ons geregistreerd hebben. Beide omgevingen maken gebruik van PowerDNS. Voor de hosting-domeinen hebben we DirectAdmin aan PowerDNS gekoppeld. De andere domeinen worden vanuit het customer panel 'Mijn Antagonist' door de klanten zelf beheerd en kunnen weer naar servers elders verwijzen. Omdat we de domeinen anders behandelen, hebben we gekozen voor twee gescheiden omgevingen met elk hun eigen interface, nameservers en policies.

Tweeluik DANE, deel I: TLSA records voor het web

DANE is een protocol voor het veilig publiceren van publieke sleutels en certificaten dat voortbouwt op DNSSEC. Hoewel DANE dus breder inzetbaar is, doet het op dit moment zijn eerste intrede met name in de wereld van de web-certificaten (HTTPS) en de beveiliging van mail-transport (SMTP). In dit artikel focussen we daarom specifiek op de inzet van DANE voor het beveiligen van TLS — officieel DANE TLSA geheten. Dit eerste deel beschrijft de TLSA records en hun praktische inzet voor websites. In het tweede deel laten we zien hoe DANE gebruikt kan worden om mail gateways cryptografisch te beschermen.

Tweeluik DANE, deel II: TLSA records voor mail

DANE is een protocol voor het veilig publiceren van publieke sleutels en certificaten dat voortbouwt op DNSSEC. Hoewel DANE dus breder inzetbaar is, doet het op dit moment zijn eerste intrede met name in de wereld van de web-certificaten (HTTPS) en de beveiliging van mail-transport (SMTP). In dit artikel focussen we daarom specifiek op de inzet van DANE voor het beveiligen van TLS — officieel DANE TLSA geheten. Het eerste deel van dit tweeluik beschreef de TLSA records en hun praktische inzet voor websites. In dit tweede deel laten we zien hoe DANE gebruikt kan worden om mail gateways cryptografisch te beschermen.

Aandachtspunten bij de configuratie van PowerDNS voor DNSSEC

PowerDNS is de meest gebruikte autoritatieve/administratieve DNS-server bij registrars die in bulk hun domeinen ondertekenen. Naar aanleiding van de ervaringen bij die implementaties heeft hoofdontwikkelaar Bert Hubert al eerder een aantal tips op een rijtje gezet. In dit artikel voegen we daar nog drie recente aandachtspunten aan toe.

Edutel doet al vijf jaar DNSSEC-validatie voor zijn klanten

Waar de meeste Nederlandse access providers nog geen DNSSEC-validatie hebben geïmplementeerd, doet het Brabantse Edutel dat inmiddels al vijf jaar voor zijn klanten. Langzamerhand volgen meer access providers dit voorbeeld, waarmee het belang van een foutloze registratie bij houders en registars van domeinen snel groter wordt.

Edutel levert internet over glas aan Brabantse particulieren en MKB-ers. Waar de meeste Nederlandse access providers nog geen DNSSEC-validatie hebben geïmplementeerd, doet Edutel dat al sinds 2009 voor zijn klanten. Destijds kwam de veiligheid van DNS negatief in het nieuws, vertelt Network/System Engineer Michiel Piscaer. Dus toen DNSSEC beschikbaar kwam, zijn we het gelijk gaan gebruiken. En sindsdien hebben we het niet meer uitgezet. Al onze klanten krijgen via DHCP onze DNS resolvers aangeboden en zijn op die manier beschermd tegen DNS-gebaseerde aanvallen.

DNSSEC op Infoblox: een kwestie van aanklikken

Wel extra aandacht nodig voor tijdsynchronisatie en crypto-algoritmen

Wie al Infloblox-appliances in huis heeft en zijn domeinen wil ondertekenen of zijn resolvers wil laten valideren, hoeft daarvoor in principe maar heel weinig te doen. In beide gevallen is het slechts een kwestie van aanklikken. Voordat je zo ver bent, is het echter wel belangrijk om de default-instellingen voor DNSSEC aan te passen. Bovendien vereist DNSSEC een goed gesynchroniseerde systeemtijd. In dit artikel bespreken we alles wat nodig is om tot een goede DNSSEC-configuratie op Infoblox te komen.

Gemeente 's-Hertogenbosch valideert DNSSEC op basis van Unbound

Progressief in techniek, conservatief in beveiliging

Hoewel de gemeente 's-Hertogenbosch zijn hoofddomein nog niet ondertekend heeft, zijn bijvoorbeeld DKIM, SPF en DMARC wel al geïmplementeerd. Hetzelfde geldt voor de validatie van DNSSEC. Als de huidige verbouwing is afgerond zal de DNSSEC-infrastructuur verder worden geconfigureerd. DKIM kan eigenlijk niet zonder DNSSEC-ondertekening.

Hands-on: OpenDNSSEC automatiseert hele DNSSEC-proces

Installatie vraagt wel goed begrip van de onderliggende technologie

Hoewel de ondersteuning van DNSSEC in DNS-server-software steeds beter wordt, is deze nog nergens compleet. De publicatie van een eenmaal ondertekende zone lukt inmiddels prima, maar het up-to-date houden van die informatie vraagt nog steeds om handwerk of het schrijven van scripts. BIND — de meest gebruikte DNS-server — en PowerDNS — met name populair hier in Nederland — doen het wat dat betreft beter dan andere veelgebruikte pakketten, zoals NSD, Knot en Yadifa. De laatste versies van BIND bieden inmiddels configuratie-opties om het hertekenen van de zone te automatiseren als veranderingen in de zone file of de sleutels dat nodig maken.

Waar het echt nog aan schort is sleutelbeheer. Met behulp van scripts kun je met BIND of PowerDNS als basis zonder al te veel knutselwerk een heel eind komen, ook in bedrijfsmatige omgevingen. Maar wie bekend is met RFC 6781 ("DNSSEC Operational Practices, Version 2") weet dat hier nog wel wat haken en ogen aan kunnen zitten.

OpenDNSSEC neemt het complete sleutelbeheer uit handen en automatiseert alles rondom de sleutels en het ondertekenen van de zones. Het open-source pakket kan via de zone files of via zone transfers makkelijk geïntegreerd worden met BIND, PowerDNS en andere DNS-servers. Wel vraagt de installatie een goed begrip van de werking van DNSSEC, public key cryptografie, vertrouwensketens, sleutelbeheer, en alle timing-aspecten en bijbehorende afhankelijkheden rond DNS en DNSSEC. Daarmee wordt gelijk duidelijk dat DNS met DNSSEC niet langer een administratieve aangelegenheid is maar een complexe, cryptografisch beveiligde infrastructuur. Hoewel de configuratie van OpenDNSSEC wel wat tijd en aandacht kost, raden we dit pakket van harte aan als complementaire oplossing naast de DNS-server. De ervaring heeft inmiddels geleerd dat de beste manier om met de complexiteit van DNSSEC om te gaan een zo groot mogelijke automatisering is.

In dit artikel bespreken we de complete installatie van OpenDNSSEC en de integratie met de DNS-servers, zowel via de zone files als via zone transfers. Hoewel de defaults al een goed vertrekpunt bieden en maar weinig aanpassingen vragen, is wel een goed begrip van DNSSEC nodig. Vandaar dat we naast alle hands-on informatie ook veel aandacht besteden aan de uitleg eromheen.

Universiteit Twente implementeert DNSSEC op compleet vernieuwde DNS-infrastructuur

Voor studenten is dit de ideale manier om hands-on ervaring op te doen

Deze maand heeft de Universiteit Twente de implementatie van DNSSEC afgerond. Daarmee is onder andere het hoofddomein utwente.nl ondertekend en zijn alle resolvers van validatie voorzien. Waar de DNS-infrastructuur voorheen bestond uit twee autoritatieve servers, is die nu vervangen door vijf fysieke en twee gevirtualiseerde systemen, alle gebruikmakend van Bind op Ubuntu Linux. Daarmee worden ongeveer 825 eigen domeinnamen beheerd en bij elkaar zo'n 30 duizend apparaten bediend.

Dit project was onderdeel van de Campus Challenge, een competitie georganiseerd door SURFnet en SIDN. De implementatie van DNSSEC was daar een onderdeel van. Omdat een installatie op basis van Infoblox niet bleek aan te sluiten bij hun manier van werken, heeft de UT ervoor gekozen hun nieuwe DNS-infrastructuur helemaal zelf op te bouwen. Hoewel dat wel een paar maanden vertraging opleverde ten opzichte van de originele planning, was dit uiteindelijk voor zowel beheerders als twee betrokken afstudeerders een veel interessanter en leerzamer traject.

CWI voortrekker bij implementatie DNSSEC op Science Park

We zijn dringend toe aan een omgeving met meerdere lagen van bescherming

Het Centrum Wiskunde & Informatica (CWI) heeft een voortrekkersrol gespeeld bij de implementatie van DNSSEC op het Amsterdamse Science Park. Het project was een gezamenlijk initiatief van CWI, AMOLF en Nikhef. Deze drie aan NWO gerelateerde onderzoeksinstituten dienden anderhalf jaar geleden een voorstel in voor de Campus Challenge, een competitie georganiseerd door SURFnet en SIDN. De implementatie van DNSSEC was daar een onderdeel van.

Inmiddels is het project afgerond en zijn de drie instituten van zowel ondertekening als validatie voorzien. De techniek van DNSSEC is op zichzelf niet zo heel spannend. Het gaat om het maatschappelijk belang van een veiliger internet. Bovendien was het voor het CWI een goede gelegenheid om de banden met andere instituten aan te halen, en kennis en technologie uit te wisselen.

Mr. DNS: "We zitten al te lang met de risico's van een onbeveiligd DNS-systeem"

De op dit moment nog beperkte mogelijkheden voor de automatisering van het DNSSEC-beheer vormen de belangrijkste drempel voor de verdere invoering van deze beveiliging voor het DNS-systeem. Dat zegt Cricket Liu, Chief Infrastructure Officer bij Infoblox en mede-auteur van het standaardwerk 'DNS and BIND'. BIND versie 10 is een heel nieuw platform. Alle software is compleet herschreven. Tegelijkertijd heeft ISC veel functionaliteit voor de automatisering van DNSSEC aan de laatste versies van BIND 9 toegevoegd. En dat is maar goed ook. Anders waren al die BIND 9 gebruikers in de problemen gekomen. Die hadden dan naar versie 10 moeten overstappen, terwijl dat echt een heel ander systeem is.

Nieuwe kwetsbaarheden in DNS maken DNSSEC-validatie noodzakelijk

In de afgelopen weken zijn er twee wetenschappelijke studies verschenen die nieuwe kwetsbaarheden in het DNS-systeem beschrijven. Daarnaast is er wederom een aantal registrars en registrar resellers gehackt, wat duidelijk maakt dat DNS en de provisioning van DNS steeds vaker doelwit zijn van aanvallen op de internet-infrastructuur.

Er zijn al veel individuele kwetsbaarheden om bij te houden. Er is echter wel één ding dat professionele internet-infrastructuurleveranciers kunnen doen om niet vatbaar te zijn voor een toenemend aantal kwetsbaarheden. Door DNSSEC-validatie te doen op DNS resolvers, zijn de meeste aanvallen niet mogelijk.

EPP 'key relay': een structurele oplossing voor de DNSSEC-verhuisproblematiek

Deze zomer is een structurele oplossing voor het verhuizen van DNSSEC-beveiligde domeinen beschikbaar gekomen. Door de EPP-interface van SIDN uit te breiden met het 'key relay' commando kan de verhuizing van een domein worden uitgevoerd zonder dat daarbij de beveiliging wordt onderbroken. Bovendien kan de hele transitie volledig geautomatiseerd plaatsvinden. Registrars en software-leveranciers kunnen deze nieuwe faciliteit direct in hun dashboards en interfaces opnemen en aan hun gebruikers beschikbaar stellen. Daarmee is een belangrijk obstakel voor verdere adoptie van DNSSEC uit de weg geruimd.

Gebrek aan kennis is belangrijkste belemmering voor implementatie DNSSEC

Veruit de belangrijkste belemmering voor de implementatie van DNSSEC is een gebrek aan kennis bij de registrars. Zo blijkt uit een zojuist afgerond onderzoek(*) van SIDN, de beheerder van het .nl top-level domein. Andere belemmeringen zijn achtereenvolgens een gebrek aan vraag bij eindgebruikers, een goede ondersteuning in de software en de user-interfaces, sleutelbeheer, investerings- en operationele kosten, de verhuisproblematiek en te weinig kennis bij eindgebruikers.

DNSSEC als fundament onder andere beveiligingsprotocollen

DNSSEC is geen op zichzelf staande beveiligingsstandaard. Het fungeert ook als fundament onder nieuwe protocollen die bijvoorbeeld de veiligheid van server-certificaten voor web en mail versterken. Daarnaast worden allerlei bestaande beveiligingsprotocollen met de toepassing van DNSSEC automatisch van een cryptografische basis voorzien.

DNS amplificatie-aanvallen straks niet meer te stoppen zonder BCP 38

Twee weken geleden publiceerden de Universiteit van Amsterdam en NLnet Labs een gezamelijk rapport over de effectiviteit van maatregelen tegen DNS amplificatie-aanvallen. Javy de Koning en Thijs Rozekrans simuleerden bij NLnet Labs een ANY-gebaseerde aanval en onderzochten hoe Response Rate Limiting (RRL) het beste ingezet kan worden om een dergelijke aanval te pareren. Daarnaast keken zij naar de effectiviteit van RRL bij geavanceerdere aanvallen en bespreken ze DNS dampening als alternatief verdedigingsmechanisme.

Tweeluik DNSSEC en BIND deel II: sleutelbeheer

Beheerders die zelf hun DNS-servers onderhouden zullen daarvoor meestal gebruik maken van BIND named. In het eerste artikel van dit tweeluik zijn we uitgebreid ingegaan op de configuratie van DNSSEC voor deze DNS-server. In dit tweede verhaal bouwen we hier op voort met sleutelbeheer, automatische ondertekening en andere beheersaspecten.

BIT valideert DNSSEC-beveiligde domeinen

BIT is een van de Nederlandse providers die DNSSEC-beveiligde domeinen valideert. Het inschakelen van de validatie heeft ons vrijwel geen werk bezorgd. Wij vinden dat onze klanten er van uit moeten kunnen gaan dat onze DNS-servers deze extra veiligheid gebruiken als die beschikbaar is.

Op dit moment is het .nl-domein wereldwijd absoluut de grootste als het gaat om de beveiliging met DNSSEC. Inmiddels zijn bijna 1,4 miljoen van de 5,1 miljoen domeinnamen ondertekend. Het valideren van de DNS records bij de providers moet echter nog goed op gang komen. Volgens onderzoek van Verisign Labs vraagt op dit moment wereldwijd 4,3 procent van de resolvers om DNSSEC-handtekeningen. Hier in Nederland maken onder andere SURFnet, T-Mobile en BIT gebruik van validerende resolvers op hun caching DNS-servers.

SIDN fungeert als doorgeefluik bij verhuizing DNSSEC-beveiligde domeinen

Op dit moment worden beveiligde .nl-domeinen weer op onveilig gezet om ze naar een andere registrar te kunnen verhuizen. Straks is dat geen optie meer en zullen alle domeinen ook tijdens de verhuizing beveiligd moeten blijven. Technisch is dat ook heel goed mogelijk, maar het vraagt wel administratieve afstemming tussen latende en verkrijgende registrar. SIDN zal daarbij als doorgeefluik fungeren.

DANE maakt PKI-systeem weer veilig en betaalbaar

Deze zomer is de specificatie voor DANE als officiele RFC gepubliceerd. DANE, kort voor DNS-based Authentication of Named Entities, is een uitbreiding van DNSSEC. Daarmee kunnen ook sleutels en certificaten voor beveiligde websites in het DNS-systeem worden opgenomen.

DANE maakt het PKI-systeem weer veilig en betaalbaar, vertelt Marco Davids, Technisch Adviseur bij SIDN, de beheerder van het .nl top-level domein. De certificaten waarmee websites, en in mindere mate ook e-mail, op dit moment worden beveiligd, zijn vrij prijzig. Bovendien kent het PKI-systeem enkele ernstige tekortkomingen.

Betrouwbaarheid overheidsinformatie van cruciaal belang

Deze zomer is DNSSEC toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst. Daarmee zijn overheidsorganisaties nu verplicht deze veiligheidsstandaard te gebruiken. Alleen als zij goede redenen hebben om dat niet te doen, mogen zij daar van afwijken. DNSSEC vormt een belangrijk fundament onder een veilige elektronische overheid. Vandaar dat het College Standaardisatie deze standaard zo snel na de introductie in Nederland op de 'pas toe of leg uit'-lijst heeft opgenomen. Overheidsorganisaties zijn nu verplicht hun domeinen te ondertekenen en de validatie van ondertekende domeinen op hun systemen te implementeren.

Dnssec-trigger brengt DNSSEC naar de eindgebruiker

DNSSEC beveiligt de hele keten van DNS-informatie. In de huidige versies van Windows en (Mac) OS X is deze standaard echter nog niet volledig geïmplementeerd. Dnssec-trigger is een intelligente tool waarmee de vertrouwensketen tot helemaal op de client kan worden uitgebreid. Daartoe wordt naast de bestaande resolver een alternatieve resolver geïnstalleerd. Dat maakt deze software essentieel voor eindgebruikers die de DNSSEC-verificatie niet aan hun internet service provider willen overlaten en voor organisaties die zeker willen weten dat de mobiele computers van hun werknemers onderweg bij de juiste IP-adressen uitkomen.

SURFnet implementeert DNSSEC

SURFnet is altijd al een pionier geweest. Wij brengen niet alleen innovatieve ICT naar onze doelgroep maar dragen ook bij aan de ontwikkeling daarvan. Twee jaar voor de brede uitrol van DNSSEC had men deze technologie al in zijn infrastructuur geïmplementeerd. In september komt deze functionaliteit voor alle klanten algemeen beschikbaar.

DANE: de macht aan de domeinnaam-houders

Hoewel DNSSEC de houders van domeinnamen in staat stelt hun DNS-informatie cryptografisch te beveiligen, is de directe meerwaarde daarvan nu nog beperkt. Met DNSSEC wordt echter een basis-infrastructuur aangelegd waarop weer verder gebouwd kan worden. DANE is de eerste uitbreiding. Daarmee kunnen eerst server-certificaten en later ook mailberichten worden beveiligd. Deze technologie had bijvoorbeeld het DigiNotar-debacle kunnen voorkomen. Direct voordeel voor domeinnaam-houders is dat zij voor de garantie van hun server-certificaten niet meer afhankelijk zijn van de commerciële diensten van een CA.

PowerDNS en DNSSEC: aandachtspunten en ondersteuning

Deze maanden werken diverse DNS-operators samen met PowerDNS aan grootschalige implementaties van DNSSEC. De ervaringen en lessen die daarbij worden opgedaan, zijn bijzonder waardevol voor zowel developers als gebruikers van PowerDNS. We geven ontwikkelaar Bert Hubert dan ook graag de gelegenheid hier een aantal tips te plaatsen voor het werken met PowerDNS en DNSSEC. Bovendien biedt PowerDNS, in samenwerking met SIDN, de komende tijd gratis ondersteuning bij de controle van uw configuratie en versies.