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.
BIT besloot in december 2009 haar caching resolvers ook te laten valideren,
vertelt Sander Smeenk, teamleider UNIX & Windows Systeembeheer. Dat is een half jaar voor de officiële ondertekening van de root zone. Wij lopen graag voorop mee bij de introductie van nieuwe technologie. Zeker als deze het internet veiliger en betrouwbaarder maakt. Ons standpunt is: als iemand DNSSEC aanbiedt, gebruik (valideer) het dan ook. Als je bank toevallig HTTP én HTTPS toestaat, dan gebruik je toch ook liever de HTTPS variant? Wij vinden dat onze klanten er van uit moeten kunnen gaan dat onze DNS-servers deze extra veiligheid gebruiken als die beschikbaar is.
Launching registrar
Daarnaast was BIT een van de 'launching registrars' die samen met SIDN, de beheerder van het .nl-domein, de introductie van DNSSEC heeft gefaciliteerd. We hebben een DNSSEC sign-straat en ondertekenen inmiddels een groot deel van onze eigen domeinnamen en niet meer dan een handvol domeinen van klanten die daar expliciet om hebben gevraagd.
We hebben ervoor gekozen om niet zomaar de domeinen van onze klanten met DNSSEC te beveiligen,
vertelt Smeenk. Enerzijds omdat er een — weliswaar klein — risico is dat er dingen stuk gaan. Anderzijds omdat wij vinden dat dit een beslissing van de klant moet zijn.
Ook ons eigen bit.nl domein is nog niet (publiek) met DNSSEC beveiligd. Deze zone voert wat delegaties en andere 'spannende' situaties, zodat we eerst heel zeker van onze zaak willen zijn voor we deze zone ondertekenen. Als bit.nl het niet meer zou doen, dan doet ineens een heleboel het niet meer.
Unbound
BIT maakt voor de validatie gebruik van Unbound, een resolver ontwikkeld en onderhouden door NLnet Labs. Volgens BIT doet de software wat betreft betrouwbaarheid en stabiliteit niet onder voor "normale" recursieve DNS-servers. Het inschakelen van de validatie is echt niet meer geweest dan de laatste name server software gebruiken en het aanpassen van de configuratie van deze software. Dat heeft ons, mede dankzij ons centrale configuratiebeheer, vrijwel geen werk bezorgd.
Voor die tijd draaiden collega's op hobby-servers wel al langere tijd resolvers die validatie aan hadden staan. Op zo'n systeem maak je toch net wat makkelijker dingen stuk dan op een van de productie-servers.
De huidige DNS-infrastructuur bestaat uit drie fysieke servers. Elk daarvan heeft zijn eigen specifieke taak: autoritatief, recursief en een 'warm standby'. Alle drie systemen zijn zo ingericht dat ze op elk moment de taak van de andere kunnen overnemen. Bij elkaar opgeteld verwerken de autoritatieve en recursieve servers een kleine 200 queries per seconde. Daarbij merkt Smeenk wel op dat deze statistieken wellicht wat vertekend zijn opzichte van die van resolvers bij andere providers, omdat BIT relatief weinig 'access' diensten (DSL) levert.
The last mile
Unbound zet in het antwoord de AD-vlag (Authenticated Data) wanneer de software de DNSSEC-informatie correct kan valideren
legt Smeenk uit. Steeds meer resolver libraries blijken DNSSEC te ondersteunen. Inmiddels zien wij in meer dan negentig procent van de queries dat de DO-vlag (DNSSEC Requested) is ingeschakeld. De vraag naar DNSSEC-validatie komt dus niet bewust bij klanten of gebruikers vandaan. De software doet het zelf, en zo hoort het ook.
De beveiliging van 'the last mile' blijft echter een lastig probleem waar ook wij nog geen oplossing voor hebben. Een validerende resolver op de client zou wel uitkomst bieden, maar kantoorautomatisering valt buiten de scope van ons bedrijf.
Gesmeerd
De validatie zelf loopt volgens Smeenk echter gesmeerd. Daar zit geen werk in, anders dan het up-to-date houden van de software, maar dat doen we sowieso al.
Daarbij benadruk hij wel het belang van het bijhouden van de laatste versies. DNSSEC is nieuw; de ondersteuning in de software wordt met de dag bijgewerkt en verbeterd. Als je dat niet bijhoudt, dan loop je de kans onterecht zones als 'onjuist' te bestempelen, met alle gevolgen van dien.
Wel leerden we dat onze "firewalls" her en der toch wat te strak stonden afgesteld. En we zijn niet de enige die deze ervaring hadden. Je leest en hoort vaker over problemen met het doorzetten van DNSSEC-verkeer. De DNS-pakketten met ondertekende antwoorden zijn immers veel groter dan de traditionele niet-beveiligde pakketten, en onze (kantoor-)firewalls lieten deze gefragmenteerde pakketten niet door.
Daarbij heeft Smeenk nog een tip voor mensen die tegen dezelfde problematiek aan lopen: De 'DNS OARC Reply Size Test' heeft ons bij het onderzoeken van die fragmentatie enorm geholpen.
Validatiefouten
Op dit moment worden problemen meestal veroorzaakt door validatiefouten waar BIT zelf geen schuld aan heeft en ook niet altijd iets aan kan doen. Wij controleren niet dagelijks alle validatiefouten in onze name servers. Dat zou ook onbegonnen werk zijn. Bovendien vallen die fouten buiten het beheer van BIT. Het echte 'werk' zit dan ook in de bewustwording bij de klant.
Een enkele keer worden we gebeld door een klant die niet kan mailen naar een bepaald domein. Dan blijkt daar een DNSSEC-fout in te zitten. We kunnen die klant dan alleen uitleggen wat DNSSEC is en waarom deze fout optreedt. Maar in bijna alle gevallen kunnen wij daar zelf niets aan doen en moeten we doorverwijzen naar de internet service provider van de derde partij.
Het 'vinkje'
Gevallen waar de validatie fout gaat en voor problemen zorgt, worden door ons stuk voor stuk onderzocht,
vervolgt Smeenk. In het overgrote deel komen de fouten neer op het wel hebben van DS records in de .nl zone, maar het niet voeren van (correcte) DNSKEY records in de zone. Het beruchte 'vinkje' [een optie in de SIDN-interface die aangeeft of de DS records wel of niet gewist moeten worden bij verhuizing van een domein naar een andere registrar] speelt hier vaak in mee.
Mijn persoonlijke mening is dat het goed is dat dit vinkje standaard aan staat [waarmee de huidige DNSSEC-informatie bij SIDN bewaard blijft]. DNSSEC wordt straks gemeengoed. DNS-beheerders moet zich daar bewust van worden. Nu wordt iedereen "gedwongen" om na te denken over DNSSEC. Wel had het bestaan en de functie van het vinkje beter bekend gemaakt mogen worden.
SIDN heeft hier wel over gecommuniceerd, maar mijn indruk is dat veel registrars het vinkje desondanks geen aandacht hebben gegeven omdat ze 'toch nog niets met DNSSEC doen'. Zij zijn zich er dus ook niet van bewust dat het vinkje weldegelijk impact kan hebben bij de overdracht van domeinen.
DNSSEC-politie
Wij zijn altijd bereid om tekst en uitleg te geven bij storingen aan DNSSEC,
aldus Smeenk, maar BIT wil niet de DNSSEC-politie van .nl zijn. Daarom laten we, als blijkt dat onze validerende resolver het bij het juiste eind heeft, veel van die gevallen toch over aan de klagende partij.
BIT heeft de inschakeling van de validatie nooit officieel naar haar klantenbestand gecommuniceerd. Deze omschakeling zou immers in principe geen impact moeten hebben op het gebruik van DNS. We hebben er wel aandacht aan besteed in de blog postings die toch door een goed deel van onze klanten wordt gevolgd.
Dat heeft eigenlijk vrijwel geen vragen of opmerkingen opgeleverd van onze directe klanten. Wel spreken we naar aanleiding daarvan vaker met onze concullega-ISP's. Die zijn vooral benieuwd naar onze ervaringen.
