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.

EPP (Extensible Provisioning Protocol) is een op XML gebaseerd protocol en een internet standaard van de IETF. Het protocol beschrijft de interface en de input/output van een registratiesysteem. Wie geïnteresseerd is in de details, kan kijken naar RFC 5730, RFC 5731, RFC 5732, RFC 5733 en RFC 5734.

Bij SIDN wordt sinds de introductie van DRS5 gebruik gemaakt van EPP als vervanging van de voormalige e-mailformulieren. De EPP-interface maakt gebruik van een TCP-verbinding die met TLS wordt gecodeerd.  Een cliënt maakt een connectie met de EPP-server en zal vervolgens XML-requests versturen. Dit werkt op zich prima, alleen hebben we gemerkt dat het gebruik van een ‘stateful’ TCP verbinding een aantal bezwaren kent.

Bezwaren van EPP
EPP is gedefinieerd als een ‘stateful protocol’. Dat wil zeggen dat de server van elke cliënt informatie moet bijhouden over de lopende sessie. Dat impliceert (in onze setup), dat de cliënt gedurende de duur van een sessie steeds bij dezelfde server moet terug komen voor een volgend EPP-verzoek. Onze load-balancers zorgen daar dan ook voor.  Dat maakt het echter lastig om een bepaalde server, waarop sessies actief zijn, voor onderhoud uit de pool van beschikbare servers te halen. En het is jammer dat een load-balancer verzoeken niet simpelweg kan doorsturen naar de op dat moment minst belaste EPP-server. Als oplossing kan ‘session state’ op een andere manier worden bijgehouden, maar dat maakt de infrastructuur weer complexer.

Wanneer de TCP-verbinding van een lopende sessie onverwachts verbroken wordt  (zonder eerst het <logout> commando te versturen), bestaat de EPP-sessie nog steeds op de server. Dat kan een probleem opleveren, aangezien bij SIDN sprake is van een maximaal aantal simultane sessies. Wanneer nieuwe sessies worden opgezet, terwijl de oude sessie nog niet is opgeruimd, kan een registrar tegen een sessie-limiet aan lopen. Ook hier moet dus omheen worden gewerkt.

Internet draft: RESTful EPP (REPP)
Toen we aan het nadenken waren over dit onderwerp, ontstond het idee om EPP te gaan doen op een ‘stateless’ manier, dus op een manier waarop ‘state’ niet meer bijgehouden hoeft te worden. Dat idee hebben we uitgewerkt in een internet-draft, waarvan versie ‘00’ onlangs is ingediend bij de IETF.

We hebben er bij ons idee voor gekozen om gebruik te maken van ‘Representational state transfer’ (REST), een bepaalde software-architectuurstijl, die de laatste jaren toenemende belangstelling geniet.

De oplossing moest zo dicht mogelijk bij de bestaande EPP-standaarden blijven, vonden we, omdat deze wereldwijd al veel wordt gebruikt. Daarnaast hadden we de volgende wensen:

• Stateless;
• XML-gebruik minimaliseren;
• Simpel te integreren.

Het was al snel duidelijk dat een ‘stateless’ API veel van de bezwaren zou oplossen. Stateless  is de natuurlijke tegenhanger van stateful. HTTP is het misschien wel bekendste voorbeeld van een stateless protocol. 

REST is een architectuurstijl die bovenop HTTP is gedefinieerd. Met REST is het mogelijk om een API te ontwerpen die eenvoudig leesbaar is en ook eenvoudig te gebruiken is. REST definieert een zogenaamde ‘resource’, die een object definieert waarop een operatie moet worden uitgevoerd. Deze operatie wordt bepaald door de ‘HTTP method’, zoals GET of POST. Een API die werkt volgens de principes van REST wordt aangeduid als ‘RESTful’ API. De nieuwe interface heeft dan ook de naam REPP gekregen, wat staat voor “RESTful EPP”.

Eigenlijk werkt REPP heel eenvoudig. Een domein <check> commando is bijvoorbeeld:

HEAD /rest/v1/domains/sidn.nl

Met de RESTful EPP-interface wordt een EPP-commando dus niet meer verstuurd door middel van een XML request, maar als een REST resource. Bijvoorbeeld een domeinnaam-resource “/rest/v1/domains/sidn.nl” en een  HTTP methode die aangeeft wat er met deze resource moet  gebeuren, bijvoorbeeld een GET voor een <info> of een HEAD voor een <check> commando.

Zie hieronder het verschil tussen een RESTful en een stateful domeinnaam check:

RESTful

HEAD /rest/v1/domains/sidn.nl
X-REPP-cltrid: ABC-12345

Stateful

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <command>
      <check>
        <domain:check
          xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
          <domain:name>sidn.nl </domain:name>
        </domain:check>
      </check>
      <clTRID>ABC-12345</clTRID>
   </command>
</epp>

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).

Deze versie heeft de volgende wijzigingen ten opzichte van versie 1: 

• Een aantal correcties;
• Het NSEC3-voorbeeld retourneert nu drie NSEC3 records in plaats van twee;
• Een tweetal illustraties is toegevoegd;
• 'Empty non-terminals' worden kort uitgelegd.

De versie 2 kun je hier dowloaden. 

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.