SIDN Labs een kijkje achter de schermen

Met een configuratie management systeem kun je tal van repeterende routinewerkzaamheden automatiseren. Bijvoorbeeld: ‘Plaats dit configuratie-bestand in die directory en herstart daarna BIND’.

Bij SIDN hadden we hier behoefte aan. We wilden:

• Een consistente/automatische installatie van alle machines;
• Historie van veranderingen beter bijhouden;
• Alle software als packages (deb, rpm, etc.) installeren;
• De grootte van de back-up minimaliseren.

Met de introductie van Puppet is de situatie nu zo dat we een ‘kale’ machine in DNS/DHCP opvoeren en dan aanzetten. De rest gaat daarna ‘vanzelf’. Tijd voor een kop koffie dus. Tegen de tijd dat die op is, staat er een volledig geïnstalleerd en geconfigureerd systeem tot je beschikking.

Er zijn vier pijlers waarop dit rust:

• Een ‘build’-infrastructuur om packages mee te maken;
• Een ‘repository server’ waar de eigen (supplementaire) packages op worden neergezet, zodat ze eenvoudig uitgerold kunnen worden;
• PXE-boot omgeving, die werkt voor alle ondersteunde OS-en, op dit moment is dat bij ons: RedHat/CentOS en Ubuntu;
• Puppet-configuratie.

Build-infrastructuur
Om zelf packages te kunnen maken, hebben we een (virtuele) server ingericht (builder1). Deze beschikt over alle ‘sources’ van de packages die we nodig hebben. Denk bijvoorbeeld aan de source-code tar-files van BIND. Verder bevat hij de specifieke configuratie om .deb of .rpm packages te maken, zoals ‘rules’ en ‘spec’-files. Deze configuratie wordt (uiteraard) ook weer via Puppet beheerd.

Verder zijn er nog enkele ‘satellietmachines’ die de specifieke OS-en draaien waar we de packages voor willen bouwen. De hiervoor benodigde bestanden komen, via NFS-mounts, van de builder1.

Om op zo'n satellietmachine een package te bouwen is het geven van één commando voldoende:

makebind    # bouwt de nieuwste BIND9
makensd     # bouwt de nieuwste NSD

Hierna wordt het gemaakte package naar onze ‘repository server’ gekopieerd.

Repository server
Onze software-repositories worden om de zoveel tijd gesynchroniseerd met de officiële repositories van Redhat en Ubuntu. Op deze manier is SIDN in control over wat er precies op het netwerk draait. De packages die we zelf gemaakt voegen we vervolgens toe aan onze eigen repository server.

De rest van de systemen kan daarna op de gangbare manier geüpdatet worden: apt-get upgrade, yum update, etc.

PXE-boot omgeving
De derde pijler is onze PXE-boot omgeving. Deze omgeving heeft slechts één taak: zorg dat er op een willekeurige machine een OS komt te staan en een paar basis packages. Dat kan zowel een fysieke server zijn, als een virtueel systeem.

(Virtuele) harde schijven worden tijdens dit proces volautomatisch gepartitioneerd (met behulp van 'LVM'). Daarbij kan er voor worden gekozen om het filesysteem volledig te versleutelen, wat we in een aantal gevallen ook daadwerkelijk doen.

Het laatste pakket dat geïnstalleerd wordt is Puppet. Die neemt daarna de installatie over en zorgt ervoor dat de machine helemaal af-geconfigureerd wordt.

Puppet
Als vierde en laatste pijler is er een Puppet ‘master–machine’, die de configuraties bewaart in Subversion. We hebben bewust hiervoor gekozen en niet voor bijvoorbeeld Git, omdat Subversion zaken als $Id$ en $URL$ ondersteund. Zo kan je als beheerder op een machine altijd zien dat een bestand uit Subversion (en dus Puppet) komt en dat je die dus op de Puppet master machine moet veranderen en niet lokaal.

De Puppet configuratie is simpel gehouden, veel van de resource types die we gebruiken zijn:

• file;
• package
• service
• cron

De gedachte hierachter is, dat we niet de ambitie hebben om Puppet experts te willen worden, maar gewoon ‘gebruikers’ zijn. En met deze relatief simpele Puppet configuratie kun je al heel veel.

In Puppet definieer je ‘manifests’, die aangeven hoe een stukje software met eventuele configuratiebestanden op een machine moet worden neergezet. Een voorbeeld van een (onvolledig) Puppet manifest is deze:

# Class: generic::ntp
# Control the ntp configuration (/etc/ntp.conf).
# Package 'ntp' is also installed.
class generic::ntp {
    file { "/etc/ntp.conf":
        source  => [ "puppet://puppet/modules/generic/etc/ntp.conf=$hostname",
                     "puppet://puppet/modules/generic/etc/ntp.conf" ],
        require => Package["ntp"],
    }
}

Dit kleine stukje Puppet laat zien hoe we een ntp.conf neerzetten. Veel moeilijker dan dit zijn onze Puppet manifests niet.

Wat staat hier precies?

Allereerst wordt er een klasse ‘generic::ntp’ gedefinieerd. Als deze klasse wordt aangeroepen, dan zal die ervoor zorgen dat het ntp-package wordt geïnstalleerd (vanwege de ‘require’ regel). En is er voor de betreffende machine een specifieke ntp.conf (ntp.conf=$hostname), gebruik die dan. Anders vallen we terug op de generieke versie.

Voordelen
De voordelen voor SIDN zijn legio:

• Het installeren van een machine kost eigenlijk nauwelijks tijd meer. Je kunt tijdens de installatie koffie gaan halen, opdrinken, terug lopen en dan inloggen op je nieuwe server;
• Alle systeem-specifieke data is opgeslagen in Subversion;
• Software-uitrol verloopt netjes via packages;
• Het documenteren kost minder tijd, want Puppet is bijna zelf-documenterend. Alleen one-off zaken moeten nu nog apart gedocumenteerd worden.

Inmiddels is het woord ‘Puppetized’ een veel gebruikte term geworden binnen SIDN.

Bijgaand een afbeelding van een /etc/motd van een machine die door middel van Puppet is uitgerold. Rechtsboven is te zien dat deze ‘puppetized’ is.

Voor het .nl-domein is zo’n IANA-procedure af en toe nodig, bijvoorbeeld wanneer een name server een ander IP-adres krijgt.

Ook hebben we in het verleden de name servers uit het 'domain-registry.nl-domein’ gehaald en in het veel kortere 'nic.nl-domein’ geplaatst. Dat scheelde een aantal bytes, die weer van pas kwamen voor het toevoegen van 'AAAA' glue-records ten behoeve van IPV6.

Dit keer was er nog een andere reden. We willen toe naar een andere setup met minder 'name server afhankelijkheden'. Wat we daarmee bedoelen kan het beste duidelijk gemaakt worden aan de hand van een afbeelding. Onze collega's van Verisign Labs hebben daarvoor een mooie tool in het leven geroepen met de indrukwekkende aanduiding: The Transitive Trust and DNS Dependency Graph Portal:

http://trans-trust.verisignlabs.com/

Deze tool visualiseert heel fraai hoe veelzijdig het resolven van een domeinnaam kan verlopen. Voor een .nl-domeinnaam moest eerst 'nic.nl' worden geresolved, maar daarvoor moeten eerst tal van andere domeinnamen worden afgelopen. Al met al vereist dat voor een resolver met een nog lege cache een flink aantal stappen, waarbij de resolver zelfs tot in Japan kan uitkomen alvorens hij resultaat heeft. Dat kan kostbare milliseconden vergen.
 


http://trans-trust.verisignlabs.com/pix/nl.-names.png

Hoewel het DNS prima werkt in de huidige situatie, geloven we dat het vereenvoudigen van de ‘name server afhankelijkheden’ een goede stap voorwaarts is. Het maakt de situatie meer 'lean and mean' en in het meest gunstigste geval levert het ook nog een sneller DNS op.

Als de transitie straks helemaal is voltooid, zal de situatie voor .nl meer lijken op die van (bijvoorbeeld) Zweden:

http://trans-trust.verisignlabs.com/pix/se.-names.png
 
De domeinnaam 'dns.nl' die we voor de nieuwe NS records gebruiken, is een zogeheten 'empty non-terminal'. Er is geen 'apex' of ‘start of authority’ en geen aparte zonefile, want de 'ns[13].dns.nl' records staan rechtstreeks in de .nl-zone. Exact zoals de Zweedse collega's al een tijdje doen. Dat heeft een groot voordeel; alles wat belangrijk is voor de .nl-zone staat nu ook in die zone. En passant zijn de nieuwe NS records ook DNSSEC gesigned, wat voor ‘nic.nl’ nog niet het geval was.

We hebben ook nog even overwogen om het model van .fi, de Finse collega's te volgen. Zij gebruiken 1-teken .fi-domeinnamen als NS-records, zoals 'a.fi', b.fi' enz. Daarmee wordt de NS RR-set nog wat compacter.

Uiteindelijk hebben we hier voor niet gekozen, omdat dit effectief zou betekenen dat er voor .nl 1-teken domeinnamen zouden ontstaan en dat zou een nogal revolutionaire, niet geheel onomstreden verandering betekenen.

1-teken domeinnamen zijn tot op de dag van vandaag niet toegestaan in .nl, dank zij een, zo je wilt, ‘voorzienige blik’ van Piet Beertema, die destijds goed op de hoogte was van RFC952, waarin letterlijk staat:

"Single character names or nicknames are not allowed."

Nu hebben we het hier niet over hostnamen, maar over domeinnamen en DNS. In de DNS RFC's, zoals RFC1034 (en haar voorloper RFC882) wordt echter wel naar bovengenoemde RFC verwezen. Er staat dat: 'labels' (de stukjes tekst tussen de punten in een domeinnaam) moeten voldoen aan de eisen voor een hostnaam, dus aan RFC952. Geen 1-teken namen dus.

Piet Beertema en zijn collega Jaap Akkerhuis hadden het dus scherp gezien: “1-teken domeinnamen 'mogen' eigenlijk niet”, constateerden ze (al werkt het  technisch prima). Jon Postel, toen nog beheerder van alle gTLD's (.com, .net.  enz.), verkreeg dit inzicht pas in 1992, maar toen waren er al enkele 1-teken  domeinnamen geregistreerd:

http://en.wikipedia.org/wiki/Single-letter_second-level_domain
 
Dus, hoewel 1-letter domeinnamen (als NS records) prima hadden kunnen werken, hebben we er vooralsnog voor gekozen het besluit van Piet Beertema van destijds in ere te houden.

DNS.nl en geen NIC.nl
De keuze voor 'dns.nl', een beschermde .nl-domeinnaam, is gemaakt om het transitieproces te vergemakkelijken. Het geeft ons een goede gelegenheid om  onder dat domein nieuwe name servers op te tuigen en dan via de  IANA-procedure de soepele omzetting te doen van 'nic.nl' naar de 'dns.nl'  variant. Uiteraard nemen we deze gelegenheid te baat om ook flink wat  verbeteringen in de infrastructuur aan te brengen, zoals nieuwe hardware en clustering. Maar daarover wellicht een volgende keer.

In DNS RFC (1034/1035) wordt het TXT-record benoemd:

“TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found.”

Zoals verwacht, kun je in het TXT-record tekst opslaan. Je kunt van elke byte alle acht bits gebruiken, dus in principe ook niet-ASCII waardes in een TXT-record op slaan, maar in de praktijk wordt het TXT-record toch meestal gebruikt voor ASCII. Zoals in RFC 1035 wordt gespecificeerd (Sectie 3.3.14. "TXT RDATA format") bestaat de resource record data van TXT uit:

"One or more <character-string>s"

Oftewel één of meerdere strings. Zo'n string is gedefinieerd als: 1 byte met de lengte en dan maximaal 255 bytes met de tekst. In totaal dus 256 bytes.
In een zonefile kun je op de volgende manier een TXT-record definiëren:

txt.sidn.nl.    IN    TXT    "Dit is een text record"

Als we dit vertalen naar de (binaire) DNS-data (zoals deze data op het internet verzonden wordt), dan ziet dat er zo uit:

(22)Dit is een text record

Het getal tussen haakjes is de waarde in de eerste byte en geeft hier dus aan dat er 22 bytes met tekst volgen. Maar, in RFC 1035 staat "One or more", dus mag je in de zonefile ook opschrijven:

txt.sidn.nl. TXT "Dit is een text record" "En dit ook"

Binair ziet dat er als volgt uit:

(22)Dit is een text record(10)En dit ook

De totale hoeveelheid tekst (inclusief lengte-bytes) is gelimiteerd tot 65535 octets (65 kB). Dit is de maximum grootte van de data in een resource record. Soms kan een name server er voor kiezen om een lange tekst (meer dan 255 tekens) zelf in stukjes te hakken, dus bijvoorbeeld:

txt.sidn.nl. TXT "Dit is een text record en hier nog meer"

Ophakken in:

"Dit is een text record en " "hier nog meer"

Of:

"Dit is een text record " "en hier nog meer"

De twee stukjes tekst zien er binair zo uit:

(27)Dit is een text record en (14)hier nog meer

(24)Dit is een text record (17)en hier nog meer

Dit maakt voor de meeste toepassingen (en mensen) weinig uit, het is toch goed leesbaar. Er is alleen één probleem: DNSSEC.

Als een TXT-record wordt gesigneerd (voorzien van een RRSIG) dan wordt de binaire data als invoer gebruikt. De twee bovenstaande representaties leveren dan dus twee verschillende handtekeningen op.

Als verschillende DNS-implementaties op verschillende plaatsen TXT-records opknippen kan dat dus tot problemen leiden in combinatie met DNSSEC. Wat is wijsheid in deze? Een implementatie kan er voor kiezen om lange TXT-records niet op te knippen en een foutmelding geven. Als er toch geknipt moet worden kan de maximale grootte van een character-string worden gebruikt: 255 karakters.

Caching
Caching is nodig om DNS schaalbaar te maken. Zonder caching zouden alle DNS queries bij de root name servers uitkomen en die zouden het daar heel zwaar mee krijgen. Caching zorgt er voor dat een resolver eerder gegeven DNS-antwoorden kan onthouden. Als dezelfde DNS query dan weer voorbij komt, geeft de resolver het antwoord direct uit zijn cache en hoeft hij niet eerst weer langs de root. De gecachte antwoorden kunnen uiteraard niet oneindig bewaard blijven, anders zou je bijvoorbeeld nooit domeinnamen kunnen verhuizen, opheffen of resource records kunnen aanpassen. Daarom werkt DNS met een ‘Time To Live’ (TTL) parameter, die aangeeft hoe lang een resolver het antwoord mag bewaren in zijn cache.

Sticky resolvers
De vraag is nu wat je moet doen als deze TTL nog niet verstreken is in een resolver, maar deze nieuwe informatie heeft gekregen dat het antwoord nog steeds bestaat bij de authoritative name server. Een manier is om dan de TTL te ‘stretchen’ zodat het antwoord vanaf dat moment opnieuw de TTL in de cache van de resolver kan blijven staan. Daarmee belast je de authoritative name server zo min mogelijk. Dit gedrag heet ‘sticky’ omdat je vast blijft plakken aan het antwoord dat je al kent. Er zijn ook niet-sticky resolvers die altijd de TTL laten verstrijken en dan daarna compleet opnieuw resolven.

Voor de meeste DNS records is sticky-resolver-gedrag efficiënt, want het beperkt DNS-verkeer. Maar bij delegatie (NS) records kan het problemen opleveren als DNS niet goed wordt onderhouden. Voor elk domein zijn er in twee sets van NS records, namelijk die in de zonefile zelf (child zone) en die in de parent zone. Voor ‘sidn.nl’ staat er dus een NS RRset in de .nl-zone (de parent), maar ook een in de ‘sidn.nl’ zone zelf (de child). Vrijwel alle resolvers slaan de NS RRset die ze verkrijgen van de child zone op in hun cache omdat die wordt gezien als betrouwbaarder dan van de parent. De child-zone-beheerder zal zelf wel het beste weten wat zijn name servers zijn, is de redenatie. Sticky resolvers blijven vasthangen aan die name servers als ze maar vaak genoeg worden bevraagd, of de NS records een hoge TTL hebben. Dat is fijn voor de parent die daarmee minder queries krijgt. Registries als SIDN willen daarom liever ook niet dat domeinnaamhouders te lage waarden configureren voor de TTL van de NS RRset, omdat ze dan veel meer queries te verduren krijgen van resolvers.

Bijeffect
Zoals gezegd is ‘child sticky’-gedrag feitelijk heel normaal DNS-gedrag. Het is het niet in strijd met de RFC’s. Het zou ook prima werken als iedereen braaf zijn DNS-configuratie op orde zou houden..
Er is echter een trend bij DNS-beheerders, om oude zones niet onmiddellijk te verwijderen van name servers zodra ze niet langer het administratieve recht hebben voor die domeinnaam. Ze draaien bij een verhuizing niet meer, zoals zou moeten, een tijdje secondary (gedurende de NS RRset TTL). De redenen hiervoor zijn divers. Soms is het onkunde, soms gemakzucht, heel af en toe is het zelfs kwade opzet. Als gevolg hiervan blijven de oude name servers authoritative antwoord geven voor de inmiddels opgeheven of verhuisde domeinnaam.

Ghost domains
Het gevolg is ‘ghost domains’, domeinnamen die (al dan niet opzettelijk kort) worden geregistreerd en daarna door bewust hoge TTL-waarden blijven rondzwerven in sticky resolvers, zelfs al zijn ze bij de registry al (lang) opgeheven. Het risico is, dat deze ‘ghost domains’ worden misbruikt door malafide personen om bijvoorbeeld malware te verspreiden of botnets aan te sturen zonder dat ze door ‘Notice and Takedown’-procedures kunnen worden gestopt. Dat is het risico dat de heer Duan beschreef.

Wat te doen?
De consequentie van dit alles is dat steeds meer fabrikanten, zoals nu ISC, hun resolvers niet sticky meer willen maken. Met als risico een toename in DNS-verkeer en meer bevragingen bij voornamelijk parent name servers. Op zich kunnen TLD's dat wel aan, als ze door middel van bijvoorbeeld DNS-anycast hun capaciteit verhogen, maar al dit soort kleine aanpassingen leidt op den duur wel tot meer kosten en een complexere DNS-infrastructuur. Ik ben dan ook erg benieuwd wat wij op onze name servers voor .nl zullen merken als ISC zijn klaarstaande patch ook inderdaad uitbrengt.

Misschien hebben DNS-beheerders en registries ook een verantwoordelijkheid. Een DNS-beheerder die een klant kwijtraakt moet netjes zijn zone opruimen, ook al verdient hij niets meer aan die klant. Je kunt je afvragen of dat wellicht moet worden afgedwongen door de parent, in dit geval dus een registry. Maar ook dat ligt gevoelig. De meeste registries voeren geen technische controles meer uit tijdens een verhuizing of verwijderen van een domeinnaam, want registrars ervaren dat als lastig en het maakt het proces trager. Het is een afweging tussen geld steken in meer DNS-infrastructuur of in meer controle op correcte procedures. Betaald worden voor security moet er uiteindelijk toch.

Mijn persoonlijke mening is dat ISC geen patch moet uitbrengen zonder eerst alle consequenties goed af te wegen. Immers, wanneer je het ‘child sticky’-gedrag van BIND (een zeer populaire name server op internet) zomaar zou veranderen, dan kan dat onverwachte en ongewenste gevolgen hebben voor de belasting van parent name servers.

Daarom is het goed dat ISC eerst een gedegen analyse van de mogelijke consequenties gaat maken en te rade gaat bij onder andere de Internet Engineering Task Force (IETF).

Het beantwoorden van deze vragen leidde tot de geboorte van NSEC4, die is beschreven in deze draft:

http://www.ietf.org/id/draft-gieben-nsec4-00.txt 

Dit is een eerste versie (een -00 zoals dat bij de IETF heet), er zal zeker nog een -01 en misschien wel een -02 van komen.

In NSEC4:

• Wordt de wildcard NSEC3 wegbezuinigd en vervangen door een enkel bitje. Dit verkleint de negatieve antwoorden met gemiddeld 1 NSEC3 record (+signatures).
• Wordt zero-hashing geïntroduceerd, oftewel helemaal geen hashing, waardoor er effectief sprake is van NSEC met Opt-Out (wat de NSEC specificatie nu ontbeert);
• Unificeert dus eigenlijk NSEC and NSEC3 tot een nieuwe record: NSEC4.

Het is niet bedoeling dit te standaardiseren, vooralsnog mikken we op de 'experimental' track. Daarmee blijft dit document wel bewaard, maar niemand wordt gedwongen het te implementeren. Het is wel belangrijke documentatie.

Van het NSEC3-whitepaper, waarover we eerder schreven, volgt binnenkort ook een versie 2, die wat zaken verduidelijkt en nog net wat vollediger is.

Acceptatie – en regressietesten
ODS is opensource software voor UNIX-platformen (waaronder Linux). SIDN neemt het zogenaamde ‘acceptatie – en regressietesten’ van de software voor haar rekening. De resultaten geven we terug aan de OpenDNSSEC-community. Aangezien er veel testgevallen zijn, hebben we dit zoveel mogelijk geautomatiseerd. Dat zorgt namelijk voor een consistente testuitvoering, een betere benutting van tijd en goed te vergelijken resultaten: bij elke run worden dezelfde scenario's doorlopen met exact dezelfde testgegevens.

Test tool
Omdat er nog geen goede automatische test tool voor ODS bestond, hebben we er zelf één gebouwd. Op basis van specificaties van onze testanalist (degene die de testscenario's bedenkt, uitvoert en analyseert), heeft onze testautomatiseerder (die o.a. voor de technische ondersteuning zorgt) een ‘test engine’ gemaakt. Deze is geschreven in Perl en maakt  gebruik van enkele CPAN- modules, o.a. om testscripts, die gebouwd zijn in Excel, te kunnen uitvoeren.

Actiewoord-gedreven-testen
De werking is gebaseerd op de methodologie: ‘actiewoord-gedreven-testen’. De definitie van een actiewoord is als volgt: een gedefinieerde combinatie van acties, die aangeeft hoe de testgevallen uitgevoerd moeten worden. Met behulp van een verzameling van actiewoorden, al dan niet voorzien van parameters, is het mogelijk om de testscenario's in een script te beschrijven. Een paar voorbeelden van actiewoorden die de test engine kan lezen en uitvoeren zijn:

• start: het starten van de ODS-applicatie;
• CheckLog: het controleren van de message logging, waarbij je in een parameter kan aangeven 
• naar welke string/tekst je precies zoekt;
•  ODSSetup: het draaien van het commando ‘ods-ksmutil setup’, waarmee o.a. de nieuwe 
• configuratie bestanden voor ODS worden ingeladen;
• LoadConfig: het verplaatsen van de gewenste configuratie naar de default configuratie 
• directory van OpenDNSSEC, zodat deze gebruikt worden bij het uitvoeren van een testgeval.

Hieronder staat een screenshot van een deel van een testscript. Aan de linkerkant staan de actiewoorden, en in de twee kolommen ernaast de specifieke parameters.

Wanneer het testscript start, worden de testgevallen uitgevoerd vanuit een terminal. De stappen die uitgevoerd worden, alsmede het resultaat, worden zichtbaar op het scherm, maar worden tevens gelogd in een bestand. Ook de ‘syslog’-bestanden kunnen gearchiveerd worden, mits dit in het testscripts staat aangegeven.

Key tag
In bovenstaande schermafbeelding wordt er gecontroleerd of een ‘key tag’ (een identificatie waarmee snel en eenvoudig de juiste publieke sleutel bij een DS- of RRSIG-record gekozen kan worden) in een gesigneerde zone overeen komt met de verwachting. Wanneer dit het geval is (zoals in bovenstaande voorbeeld), geeft de test engine als resultaat ‘PASSED’. Wanneer dit niet het geval is zal het resultaat ‘FAILED’ worden gegeven.

Testresultaten
Voorlopig worden de verschillende testscripts nog handmatig ‘afgetrapt’. In de nabije toekomst zullen ze echter gaan draaien in Jenkins, zodat bij een nieuwe release de testresultaten veel vlotter beschikbaar zijn. De testresultaten zullen in de vorm van een samenvatting per testcluster (verzameling van testgevallen) worden gegenereerd.

Onze test engine is, net als ODS, open source software. Om een indruk te krijgen is deze hier te downloaden.

De officiële website van OpenDNSSEC is http://www.opendnssec.org/ . Hier is ook de laatste versie van SoftHSM (Hardware Security Module) te vinden.

OpenDNSSEC is opensource, dus vrijelijk te gebruiken voor het signeren van je eigen domeinnamen.