Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

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.

DNS -operators die hun eigen systemen opzetten vertrouwen daarvoor meestal op Linux in combinatie met Bind of PowerDNS. Dan biedt OpenDNSSEC een complete oplossing voor geautomatiseerd sleutelbeheer en ondertekening.

Appliances

In commerciële omgevingen kiest men vaker voor appliances, bijvoorbeeld die van Infoblox. Zo worden deze gebruikt door bijna alle Nederlandse banken, maar ook door de Universiteit Leiden. De Universiteit Twente kwam eerder dit jaar echter tot de conclusie dat de Infoblox-appliances niet aansloten bij hun manier van werken. Waar systeembeheerders hun machines zien als hosts voorzien van meerdere NIC's met meerdere IP-adressen, is deze hiërarchie in de IPAM-implementatie van Infoblox platgeslagen tot een tabel. Na onderzoek als onderdeel van de Campus Challenge besloot de UT hun DNS-infrastructuur toch weer te vernieuwen op basis van Linux en Bind.

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.

Systeemtijd

Om te beginnen vraagt DNSSEC om een goed gesynchroniseerde systeemtijd. Waar de traditionele DNS-service alleen relatieve tijdsaanduidingen gebruikt (TTL's), introduceert DNSSEC absolute tijdsaanduidingen. De digitale handtekeningen (RRSIG-records) hebben immers een absolute geldigheidsperiode, terwijl de sleutelparen waarmee de DNS-records ondertekend worden een administratieve geldigheidsduur hebben.

Voor het automatisch synchroniseren van de systeemtijden moeten we de NTP-service configureren. Deze levert een hiërarchische infrastructuur om systeemklokken (op UTC) over Internet gelijk te schakelen (via UDP/123).

Grid NTP-server

Elk Infoblox-grid heeft een eigen ingebouwde NTP-server, dat wil zeggen een service om systeemtijden van externe NTP-servers binnen te halen en die weer naar lokale NTP-clients te verspreiden. Op een nieuwe installatie kan deze service worden geconfigureerd als onderdeel van de Grid Setup Wizard. Deze vraagt in stap 5 om NTP te enablen en geeft daarbij de mogelijkheid om een lijstje externe NTP-servers in te vullen. Een betrouwbare configuratie bestaat uit minstens drie externe NTP-servers, bij voorkeur Stratum-1 servers die hun systeemtijd direct van een referentie-klok krijgen. Wil je zelf geen aparte NTP-hardware kopen, dan kun je op ntp.org ook publieke servers vinden.

In aanvulling daarop kan de Grid Master als centrale NTP-server worden geconfigureerd en de andere systemen als client. Op die manier fungeert de Grid Master automatisch als fall-back ingeval de externe servers niet bereikt kunnen worden. Daarnaast kun je eventueel voor de afzonderlijke systemen nog aanvullende externe NTP-servers configureren. Binnen een HA-paar synchroniseert alleen de actieve node met de externe NTP-servers; de passieve node neemt de systeemtijd over van de actieve node.

NTP op een bestaand grid

Om NTP te configureren op een bestaand Infoblox Grid ga je eerst naar de 'Grid'->'Grid Manager' tab. Dan vind je in de Toolbar rechts een NTP-menu.

Selecteer de optie 'NTP Grid Config' om de externe NTP-servers toe te voegen.

In hetzelfde 'Toolbar'->'NTP' menu vind je ook de optie 'NTP Member Config', waarmee NTP-servers voor de afzonderlijke systemen kunnen worden gedefinieerd (de 'Override' optie in de 'General/Basic' tab).

Voor clients en servers die hun tijdsignalen in beveiligde vorm uitwisselen — een belangrijke bescherming tegen MITM-aanvallen — dien je eerst de geheime sleutel in te voeren. Dat mechanisme is vergelijkbaar met de TSIG-encryptie van DDNS en zone transfers (AXFR/IXFR) tussen DNS masters en slaves. Omwille van de veiligheid is het een goed idee om alleen te synchroniseren met externe NTP-servers die hun signalen in beveiligde vorm kunnen aanbieden, of een eigen Stratum-1 server op te zetten.

Het is niet nodig om het verkeer binnen het grid zelf te beveiligen: alle communicatie tussen de Grid Members gebeurt via de onderliggende database (replicatie) of via het tussenliggende VPN.

Beveiliging

Helaas ondersteunt Infoblox op dit moment alleen de niet zo stevige MD5- en DES-protocollen. Hoewel de leverancier zegt NTPv4 te gebruiken, was dit tweetal ooit de standaard voor NTPv3. DES heeft inmiddels de status 'deprecated', waarmee voor nu alleen MD5 nog overblijft. De NTPv4 software biedt ook een nieuw public-key-gebaseerd protocol — Autokey — maar dat kan alleen gebruikt worden tussen systemen met een echt publiek IP-adres (d.w.z. niet achter NAT). Cricket Liu, mede-auteur van het standaardwerk 'DNS and BIND' en Chief Infrastructure Officer van Infoblox, heeft aangegeven dat hun engineers naar ondersteuning voor Autokey gaan kijken.

Om de NTP-service aan te zetten, gaan we naar de 'Grid'->'Grid Manager'->'Services' tab. Daar selecteren we de server en klikken we op de 'Play' button.

Na bevestiging wordt de NTP-service opgestart en kunnen we door naar de DNSSEC-instellingen.

DNSSEC-instellingen

Nu de tijdsynchronisatie voor elkaar is moeten we de default-instellingen voor DNSSEC aanpassen. Om te beginnen verifiëren we dat de EDNS0-optie aan staat. Deze biedt een uitbreiding op het oude DNS-protocol, zodat nu ook de grotere DNSSEC-pakketten en bijbehorende vlaggen en velden ondersteund worden. Daarvoor gaan we naar de 'Data Management'->'DNS' tab en selecteren in de Toolbar de 'Grid DNS Properties'. Klik nu op 'Toggle Advanced Mode' en open de General/Advanced tab. Daar vinden we halverwege de 'Disable EDNS0' optie: zorg dat deze uit staat.

Voor de DNSSEC-instellingen klikken we in hetzelfde window naar de 'DNSSEC/Basic' tab. De ondersteuning voor ondertekening en validatie staan beide standaard aan. De timing-instellingen kunnen blijven zoals ze zijn: ZSK en KSK roll-overs na respectievelijk één en twaalf maanden, en een herondertekening van de DNS-records elke vier dagen. Hoewel deze waarden veel gebruikt worden, zou je zou deze perioden voor de meeste domeinen ook kunnen verdubbelen of verviervoudigen. Je zou de roll-overs bijvoorbeeld op respectievelijk drie maanden en vier jaar kunnen zetten, en de herondertekening van de DNS-records maar eens in de maand kunnen laten uitvoeren. Dat bespaart je werk (voor de KSK roll-overs) en haalt wat onnodige dynamiek/hectiek uit de DNSSEC-installatie.

De encryptie-algoritmen voor de KSK- en ZSK-sleutelparen moeten in ieder geval aangepast worden: deze staan standaard ingesteld op RSA/SHA1 (algoritme #5), terwijl SHA-1 inmiddels niet meer gebruikt zou moeten worden. Bovendien wordt bij deze optie gebruik gemaakt van NSEC, een methode om lege DNS-replies (zoals een bericht "deze bestaat niet", NXDOMAIN) toch te kunnen voorzien van DNSSEC-beveiliging. NSEC biedt echter geen bescherming tegen "zone walking" of "zone enumeration", zelfs niet bij een afgeschermde zone transfer.

We veranderen deze optie daarom voor beide sleutelparen in RSA/SHA-256/NSEC3 (algoritme #8 in combinatie met NSEC3). Algoritme #10 maakt gebruik van SHA-512 en is daarmee nog veiliger, maar deze vraagt wel om extra verwerkingskracht op 32-bits processoren (mobiele devices). Liu heeft aangegeven dat de huidige default-waarden inderdaad verouderd zijn. Ze zullen aangepast worden in een volgende versie van NIOS.

Zones die al ondertekend zijn zullen bij de volgende roll-over automatisch naar het nieuwe algoritme worden omgezet. Op die manier wordt de vertrouwensketen niet onderbroken en blijft de bescherming van DNSSEC dus doorlopend bestaan.

Hoewel de meeste DNS-operators (om goede redenen) met een dubbel sleutelpaar (KSK en ZSK) zullen werken, wordt het gebruik van een enkel sleutelpaar door Infoblox überhaupt niet ondersteund.

Ondertekening

Na deze voorbereidende werkzaamheden zijn we toegekomen aan de daadwerkelijke ondertekening van onze zone example.nl. Daarvoor gaan we naar de Zone-pagina 'Data Management'->'DNS'->'Zones', waar we in de Toolbar rechts een DNSSEC menu aantreffen:

• Sign Zones
• Unsign Zones
• Import Keyset
• Export Trust Anchors
• Rollover Key-Signing Key
• Rollover Zone-Signing Key
• Check KSK Rollover Due

Openen we dit menu vanuit een specifieke zone, dan werken deze opties daarop. Doen we dit een niveau hoger, dan kunnen we vervolgens een of meerdere zones selecteren.

De ondertekening van een zone is slechts een kwestie van aanklikken en bevestigen. Vervolgens worden de sleutelparen en DNSSEC-records automatisch gegenereerd. Daarna wordt het serienummer van de zone (in het SOA record) opgehoogd en worden notificaties naar de slave servers gestuurd zodat zij een zone transfer in gang kunnen zetten.

Ondertekenen moet per se op de Grid Master gebeuren. Deze fungeert dus als administratieve master, eventueel verborgen (hidden). In dat laatste geval wordt een andere DNS-server (een Grid Member of een externe server) als primary server ingesteld. Externe slaves krijgen hun ondertekende zone file via de normale transfers (AXFR/IXFR) toegestopt. Voor Grid Members loopt die uitwisseling via de onderliggende database.

In een alternatieve set-up wordt de Grid Master als slave geconfigureerd voor een externe (hidden) master of HSM die via het netwerk een (ondertekende) zone file aanlevert.

Helaas levert de appliance software geen feedback over het al dan niet goed verlopen ondertekeningsproces. Wel kunnen we in de zone pagina zelf aan de toegevoegde DNSSEC-records (RRSIG, NSEC3 en DNSKEY) en het DNSSEC-logo zien dat de betreffende zone nu inderdaad ondertekend is.

DS records

Met behulp van de DNSSEC menu-optie 'Export Trust Anchors' kunnen we nu het KSK DNSKEY-record of het bijbehorende DS-record als file downloaden. Dat sleutelmateriaal moet vervolgens naar de registry worden geüpload, waarmee de vertrouwensketen met het bovenliggende domein wordt gesloten.

Het record-formaat dat je nodig hebt verschilt per registry: Sommige vragen een DS-record, dat direct gepubliceerd kan worden. Andere — waaronder SIDN, de registry voor .nl — vragen een DNSKEY-record, op basis waarvan zij zelf een DS-record (een hash) voor publicatie genereren. Reden om voor die laatste optie te kiezen is dat de registry daarmee zelf de controle heeft over de gebruikte cryptografische algoritmen.

De export-functie voor de DS-records genereert de hashes voor zowel SHA-1 (algoritme #1) als SHA-256 (algoritme #2):

  example.nl. IN DS 25819 8 1 48C5635D59EE976BF7914C255E0253A0F3A39CD1
  example.nl. IN DS 25819 8 2
      9078E0E082E528F70205075AFD5EEFC0F0E21B03F8F54B0290342A16441954D4

Bij het invoeren van DS-records voor gedelegeerde domeinen wordt echter alleen SHA-1 ondersteund. Die beperking kun je omzeilen door de DS-records te importeren, of eerst de DNSKEY-records te importeren en de DS-records vervolgens daaruit te laten genereren. Liu heeft al aangegeven om de ondersteuning van SHA-256 in een volgende versie van NIOS compleet te willen maken.

Het importeren van DS-records voor onderliggende zones die op hetzelfde Infoblox grid beheerd worden is niet nodig. Deze worden na ondertekening of een KSK roll-over automatisch in de bovenliggende zone opgenomen.

Roll-overs

Key roll-overs (beschreven in RFC 4641) worden op de Infoblox uitgevoerd volgens de double signature methode. Pas vanaf NIOS versie 6.11 is voor ZSK roll-overs ook de pre-publish methode beschikbaar.

Roll-overs voor de ZSK-sleutelparen worden volautomatisch uitgevoerd. In geval van problemen raadde de handleiding voor NIOS versie 6.10 aan om de ondertekening van een zone te verwijderen en gelijk daarna weer te enablen. Dat lijkt ons geen goede oplossing. Vanaf NIOS versie 6.11 worden gelukkig ook handmatige roll-overs voor ZSK-sleutelparen ondersteund. Bovendien kunnen onveilige sleutelparen nu ook direct verwijderd worden.

KSK roll-overs moeten handmatig geïnitieerd worden. Daarna moeten vanzelfsprekend de nieuwe DNSKEY/DS-records worden geëxporteerd en naar de registry worden geüpload. Zeven dagen voor het verlopen van een KSK-sleutelpaar — deze hebben een administratieve levensduur — krijg je een melding in de admin interface. Die periode lijkt ons te kort voor een domein dat maar weinig mutaties heeft. Bovendien is in de interface (de DNSSEC-menu optie 'Check KSK Rollover Due') niet te zien welke roll-overs er aan zitten te komen. Volgens Liu openen veel DDI-beheerders de Infoblox-interface meerdere malen per dag, of hebben zij dat scherm zelfs de hele dag openstaan. Desondanks heeft hij hun engineers gevraagd om te kijken of het aantal notificaties kan worden uitgebreid en of deze eerder uitgestuurd kunnen worden. Daarnaast kunnen klanten de Infoblox API gebruiken om bijvoorbeeld met behulp van Perl zelf de database te bevragen.

Validatie

Tenslotte werpen we nog een blik op de validatie van DNSSEC. Ook dat is slechts een kwestie van aanvinken. We kunnen dat voor alle Grid Members tegelijk aanzetten. Ga daarvoor naar de 'Data Management'->'DNS' tab en selecteer in de Toolbar de 'Grid DNS Properties'. Als we de 'DNSSEC/Basic' tab selecteren, komen we in hetzelfde scherm waar we eerder de cryptografische algoritmen hebben aangepast. Halverwege vinden we de optie 'Enable DNSSEC validation', waarmee we deze beveiliging in één keer voor het hele grid aanzetten.

Wil je validatie alleen aanzetten op een specifieke Grid Member (typisch een resolver), dan ga je eerst naar naar de 'Data Management'->'DNS'->'Members' tab, selecteert daar de betreffende server, en klikt vervolgens op het 'Edit' icoon. In het 'Member DNS Properties' window selecteer je dan de 'DNSSEC/Basic' tab, waar je de grid-brede instellingen kunt overrulen.

Afsluiting

Het aanzetten van DNSSEC op een Infoblox-appliance is heel eenvoudig te doen. In principe omhelst dat niet meer dan het aanklikken van een menu-optie. Vanaf NIOS versie 6.11 is er ook voldoende functionaliteit aanwezig om beheerszaken rondom key roll-overs goed af te kunnen handelen. Een upgrade naar de laatste versie — gratis voor klanten met een support-overeenkomst — is dan ook zeer aan te raden alvorens met DNSSEC aan de slag te gaan.

Wel vraagt DNSSEC om goed gesynchroniseerde systeemtijden. Daarvoor is het van belang eerst de NTP-service te configureren. Ander belangrijk aandachtspunt vooraf zijn de instellingen voor de cryptografische algoritmen; de default-waarden zijn niet optimaal. De leverancier heeft naar aanleiding van dit artikel bij monde van Cricket Liu toegezegd op dit gebied nog verbeteringen door te zullen voeren.