DNS-operators die hun eigen systemen opzetten vertrouwen daarvoor meestal op Linux of een BSD-variant in combinatie met BIND of PowerDNS. Heb je niet genoeg aan de DNSSEC-functionaliteit die BIND named op dit moment biedt, dan kun je named (of een andere autoritatieve name-server) ook combineren met OpenDNSSEC, een complete oplossing voor geautomatiseerd sleutelbeheer en ondertekening.
1.1 Appliances
In grote commerciële omgevingen kiest men vaker voor appliances, en dan meestal die van Infoblox. Zo worden deze gebruikt door bijna alle Nederlandse banken, maar bijvoorbeeld ook door de Universiteit Leiden.
Wie al Infloblox appliances in huis heeft en zijn domeinen wil ondertekenen of zijn (caching) resolvers wil laten valideren, hoeft daarvoor in principe maar heel weinig te doen. Voor ondertekening is het slechts een kwestie van aanklikken; validatie staat standaard al aan. Wel blijft het belangrijk om de default-instellingen voor DNSSEC te controleren. Bovendien vereist DNSSEC een goed gesynchroniseerde systeemtijd. Helaas ondersteunt de Infoblox appliance het RFC 5011 protocol niet, zodat je zelf de nieuwe KSK-2017 sleutel als trust anchor zult moeten installeren in je validerende resolver.
1.2 Hoe dit artikel te lezen
In dit artikel behandelen we de DNSSEC-configuratie voor een autoritatieve name-server op Infoblox. De configuratie van een Infoblox appliance als validerende resolver lees je in een ander artikel.
We hebben bij het schrijven van dit artikel gebruik gemaakt van een OVA image met Infoblox NIOS versie 8.2.2, draaiend op VMware ESXi versie 6.5.0.
We bespreken steeds de belangrijkste functionaliteit en opties om tot een complete (waar mogelijk geautomatiseerde) configuratie te komen. Voor de details en minder alledaagse opties verwijzen we naar de Infoblox NIOS 8.2 Administrator Guide.
Inhoudsopgave
Infoblox DDI appliances
Met de Trinzic productlijn levert Infoblox een reeks van zowel fysieke als virtuele appliances voor DNS/DHCP/IPAM (DDI). Het binnenwerk van de systemen is gebaseerd op Fedora Linux en BIND.
Bij het schrijven van dit artikel hebben we gebruik gemaakt van een IB-V825 virtuele machine (VM) voorzien van NIOS versie 8.2.2. Een dergelijke virtuele evaluatie-versie is ook beschikbaar via de website van Infoblox.
Infoblox-klanten met een support-overeenkomst raden we ten zeerste aan hun NIOS software op te waarderen naar de laatste versie alvorens met DNSSEC aan de slag te gaan.
2 Systeemtijd
Om te beginnen vraagt DNSSEC om een goed gesynchroniseerde systeemtijd. Waar het traditionele DNS-protocol alleen relatieve tijdsaanduidingen gebruikt (TTL's), introduceert DNSSEC absolute tijdsaanduidingen. De digitale handtekeningen (in de 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 van de appliances moeten we de NTP service configureren. Deze levert een hiërarchische infrastructuur om systeemklokken (op UTC) over Internet gelijk te schakelen (via UDP/123).
2.1 Grid NTP-server
Elk Infoblox Grid (een cluster van appliances onder controle van de Grid Master) 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 kun je deze service configureren als onderdeel van de Grid Setup Wizard, te vinden als volgt: klik 'Grid' -> 'Grid Manager' -> 'Members', en vervolgens 'Toolbar' -> 'Grid Properties' -> 'Setup Wizard'.
De Wizard vraagt je in stap 5 om NTP aan te zetten 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.
2.2 NTP op een bestaand Grid
Om NTP te configureren op een bestaand Infoblox Grid ga je eerst naar de tab 'Grid' -> 'Grid Manager' ('Members'). Dan vind je in de Toolbar rechts een NTP-menu, waarin je de optie 'NTP Grid Config' selecteert.
Hier (in de 'Basic'/'General' tab) kun je de lijst met (externe) NTP-servers en hun keys beheren. Over die sleutels verderop meer.
2.3 NTP voor Grid Members
In hetzelfde NTP-menu vind je ook de optie 'NTP Member Config', waarmee NTP-servers en keys voor de individuele systemen in het Grid kunnen worden gespecificeerd. Deze optie wordt actief zodra je een Member hebt geselecteerd.
Hier (in de 'Basic'/'General' tab) staan standaard de NTP-servers en keys die je zojuist voor het hele Grid hebt ingesteld (Inherited). Hierbij neemt de betreffende Member via de onderliggende database/VPN de systeemtijd van het Grid over.
Wil je deze Member op zijn beurt weer als NTP-server laten fungeren voor andere systemen (typisch in het lokale netwerk), zet hier dan de optie 'Enable the NTP server on this Member' aan.
Wil je een specifieke Member andere (externe) NTP-servers laten gebruiken dan het Grid, klik dan op 'Override', waarna je de betreffende NTP-servers/keys kunt opgeven.
Kan een zo geconfigureerde Member zijn NTP-servers niet bereiken — bijvoorbeeld vanwege problemen met het netwerk — dan fungeert de Grid Master standaard als backup server.
Binnen een HA-paar (High Availability) kan alleen de actieve node zijn klok met externe NTP-servers synchroniseren; de passieve node neemt de systeemtijd over van de actieve node.
2.4 Versleuteling
NTP-clients en -servers die hun berichten onbeveiligd uitwisselen zijn kwetsbaar voor MITM-aanvallen. Verkeer met externe NTP-servers moet daarom versleuteld worden. Voor verkeer binnen een Grid is dit niet nodig; alle communicatie tussen Members gebeurt sowieso via de onderliggende database (replicatie) of via het tussenliggende VPN.
NTP-berichten kunnen beveiligd worden met behulp van symmetrische cryptografie. Daarvoor wordt dus aan client- en server-zijde gebruik gemaakt van dezelfde geheime sleutel.
Daarmee is dit mechanisme vergelijkbaar met de TSIG-encryptie van DDNS en zone transfers (AXFR/IXFR) tussen DNS masters en slaves.
Omwille van de veiligheid van de DNSSEC-installatie 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.
2.5 Autokey en NTS
Op dit moment ondersteunt Infoblox alleen de inmiddels niet meer veilige MD5- MD5- en DES-protocollen. Hoewel de leverancier zegt NTPv4 (RFC 5905) te gebruiken, was dit tweetal ooit de standaard voor NTPv3 (RFC 1305). Beide protocollen zijn inmiddels niet meer veilig voor gebruik, maar nu we moeten kiezen is MD5 de minst slechte oplossing van de twee, en zeker beter dan niets.
De NTPv4 software biedt ook een nieuwer, public-key-gebaseerd protocol — Autokey [1, 2] — 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 DNS Architect bij Infoblox, gaf eerder aan dat hun engineers naar ondersteuning voor Autokey zouden gaan kijken.
Die ondersteuning voor Autokey is er nooit gekomen, en inmiddels ook niet relevant meer. Autokey bleek een aantal problemen te hebben die niet werden opgelost en is inmiddels ingehaald door een nieuwe beveiligingstechnologie: Network Time Security (NTS). Op moment van schrijven (zomer 2018) nadert NTS voor NTP zijn voltooiing. Totdat NTS zijn weg vindt in een volgende NTP-versie, zullen we het echter met MD5 moeten doen.
2.6 Invoeren geheime sleutels
Dat betekent dat we voor elke externe NTP-server eerst zijn geheime MD5-sleutel moeten invoeren, en deze vervolgens naast het adres moeten specificeren bij de betreffende server.
2.7 NTP service
Om de zojuist geconfigureerde NTP service aan te zetten ga je naar de tab 'Grid' -> 'Grid Manager' -> 'NTP' ('Services'). Daar kun je de betreffende service selecteren en starten ('Play').
Na bevestiging wordt de NTP service opgestart en kunnen we door naar de DNSSEC-instellingen.
3 DNSSEC-instellingen
Nu de tijdsynchronisatie voor elkaar is, moeten we de default-instellingen voor DNSSEC aanpassen/controleren. 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 op 'Toggle Advanced Mode', waarmee een heleboel extra tabs beschikbaar komen, en open nu de 'General'/'Advanced' tab. Daar vinden we halverwege de optie 'Disable EDNS0'; zorg dat deze uit staat.
3.1 KSK en ZSK roll-over instellingen
Voor de DNSSEC-specifieke instellingen klikken we in hetzelfde window naar de 'Basic'/'DNSSEC' tab. De ondersteuning voor ondertekening ('Enable DNSSEC') en validatie ('Enable DNSSEC validation') staan beide standaard aan.
De timing-instellingen voor ondertekening 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 twee jaar kunnen zetten, en de herondertekening van de DNS-records maar eens in de maand kunnen laten uitvoeren. Dat bespaart je werk (KSK roll-overs hebben vooralsnog handmatige aanpassingen van het geregistreerde sleutelmateriaal bij de registry nodig) en haalt wat onnodige dynamiek/hectiek uit de DNSSEC-installatie.
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.
3.2 Encryptie-algoritmen
Zoals je hierboven hebt kunnen zien, staan de encryptie-algoritmen voor de KSK- en ZSK-sleutelparen standaard ingesteld op RSA/SHA-256 (algoritme nummer 8, RSASHA256), met een sleutellengte van respectievelijk 2048 en 1024 bits. Hoewel hier in principe niets mis mee is, is algoritme nummer 8 op dit moment wel het minimum. Eventueel kun je de sleutellengte van de ZSK-sleutelparen nog op 2048 bits zetten.
RSA/SHA-512 (algoritme nummer 10, RSASHA512) is specifiek ontwikkeld voor gebruik op 64-bits processoren, wat betekent dat het gebruik hiervan op 32-bits processoren (mobiele devices) extra verwerkingskracht vraagt.
Na aanpassingen in de algoritmen hier zullen zones die al ondertekend zijn bij de volgende roll-over automatisch naar de nieuwe instellingen worden omgezet. Op die manier wordt de vertrouwensketen niet onderbroken en blijft de bescherming van DNSSEC dus doorlopend bestaan.
3.3 Elliptic Curve Cryptography (ECC)
Veel liever dan RSA/SHA-256 of RSA/SHA-512 zouden we de moderne en beter voor DNSSEC geschikte ECDSA-algoritmen (nummer 13, ECDSAP256SHA256) gebruiken, maar die worden op dit moment niet door Infoblox ondersteund.
Let in ieder geval op (verifieer!) dat je appliance staat ingesteld op RSA/SHA-256 of RSA/SHA-512. Eerdere versies van NIOS maakten standaard gebruik van RSA/SHA1 (algoritme nummer 5), terwijl SHA-1 inmiddels echt niet meer veilig is voor gebruik. Bovendien wordt bij deze optie gebruik gemaakt van NSEC, een verouderde methode om NXDOMAIN replies ("dit domein bestaat niet") toch te kunnen voorzien van een DNSSEC-handtekening. NSEC biedt echter geen bescherming tegen "zone walking" of "zone enumeration", zelfs niet bij een afgeschermde zone transfer. Bij NSEC3 is dit probleem opgelost.
4 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 (boven de zojuist gebruikte 'Grid DNS Properties') ook 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
Apply Algorithm Changes
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 voor de betreffende bewerking selecteren.
4.1 Autoritatieve zone
Uitgangspunt voor dit artikel is een goed werkende (autoritatieve) DNS-installatie. Dat wil in ons geval zeggen dat we de Infoblox appliance al als primary server voor het domein example.nl hebben geconfigureerd. De bijbehorende zone file db.example.nl staat hieronder weergegeven en is hier beschikbaar voor download.
$TTL 1d ; ttl is 1 day
@ IN SOA dns1.example.nl. dns.example.nl. (
2017101300 ; serial (date & version)
8h ; refresh every 8 hours
20m ; retry after 20 minutes
4w ; expire after 4 weeks
20m ; negative caching ttl is 20 minutes
)
; DNS name servers
IN NS dns1.example.nl. ; primary name server
IN NS dns2.example.nl. ; secondary name server
; SMTP mail gateways
IN MX 10 mx.example.nl. ; MX gateway
IN MX 100 fallback-mx.example.nl. ; fallback MX gateway
; hosts
IN A 192.168.129.36 ; server
IN AAAA a022:2f87:1098::2:14 ; server (IPv6)
www IN CNAME example.nl. ; WWW server
ftp IN CNAME example.nl. ; FTP server
mx IN A 192.168.128.34 ; mail gateway
mx IN AAAA a022:2f87:1098::1:6 ; mail gateway (IPv6)
mail IN A 192.168.128.35 ; mail server
mail IN AAAA a022:2f87:1098::1:7 ; mail server (IPv6)
; exterior hosts
dns1 IN A 172.16.64.5 ; primary name server
dns1 IN AAAA 2f87:a022:0941::8:5 ; primary name server (IPv6)
dns2 IN A 172.16.128.6 ; secondary name server
dns2 IN AAAA 2f87:a022:0941::16:6 ; secondary name server (IPv6)
fallback-mx IN A 10.184.172.36 ; fallback mail gateway
fallback-mx IN AAAA 0941:20a2:7f34::32:7 ; fallback mail gateway (IPv6)
4.2 De ondertekening
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) toegestuurd. Voor Grid Members loopt die uitwisseling via de onderliggende database (replicatie). Let op dat je DNSSEC ook aan moet zetten (zoals hierboven beschreven) op Grid Members die als secondary fungeren voor een ondertekende zone.
In een alternatieve set-up wordt de Grid Master als slave geconfigureerd voor een externe (hidden) master of een Hardware Security Module (HSM) die via het (lokale/dedicated) netwerk een (ondertekende) zone file aanlevert.
Helaas levert de appliance software geen enkele feedback over het al dan niet goed verlopen ondertekeningsproces. Wel kunnen we in de zone pagina zelf aan de toegevoegde DNSSEC records (RRSIG, NSEC3, NSEC3PARAM en DNSKEY) en het DNSSEC-logo bovenaan zien dat de betreffende zone nu inderdaad ondertekend is.
4.3 DS records
Met behulp van de DNSSEC menu-optie 'Export Trust Anchors' kunnen we nu het KSK DNSKEY record of het daarvan afgeleide 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 — vragen een DNSKEY record, op basis waarvan zij vervolgens 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 inhoud van het bestand dnskeys_records.txt ziet er volgt uit:
(AwEAAelukWWueMI8eDh5JwVatqr2E7cjqZWOfNzT3ybVde92g7bfty4ghpnOHABlR6+...) ;
key id = 60106
De export-functie voor de DS records genereert de hashes voor zowel SHA-1 (digest algoritme nummer 1) als SHA-256 (algoritme nummer 2).
De inhoud van het bestand ds_records.txt ziet er als volgt uit:
example.nl. IN DS 60106 8 1 8CD8633C4E4D433D5B8A535BD64670FB626A1935
example.nl. IN DS 60106 8 2
2B27F5297B895B91C6A80133471858226DC7890D53BDCC0BA93CEA0E5427F297
Het SHA-1 algoritme is niet veilig meer en moet je inmiddels echt niet meer gebruiken. Bij een registry (of een registrar) die je toestaat direct een DS record in te voeren gebruik je dus altijd het record gebaseerd op digest algoritme nummer 2).
De laatste optie, 'BIND trusted-keys statement', genereert een speciale, gekortwiekte versie van het DNSKEY record, dat via een trusted-keys statement als trust anchor in BIND named kan worden geïmporteerd.
4.4 DS records van gedelegeerde zones
Voor het importeren van publieke sleutels van gedelegeerde zones ga je naar 'Data Management' -> 'DNS'. Daar selecteer je een zone, waarna je in de Toolbar op de 'Import Keyset' optie van het DNSSEC-menu klikt.
Hier kun je zowel DNSKEY als DS records invoeren. Maar gebruik je hier een DNSKEY record, dan genereert de appliance zelf een DS record op basis van het onveilige SHA-1 algoritme. We raden daarom aan om hier alleen DS records op basis van SHA-256 in te voeren.
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.
5 Roll-overs
Key roll-overs (beschreven in RFC 6781) werden op de Infoblox altijd uitgevoerd volgens de double signature methode. Vanaf NIOS versie 6.11 is (alleen) voor ZSK roll-overs ook de pre-publish methode beschikbaar. Belangrijkste verschil tussen deze twee methoden is dat de double signature methode direct uitgevoerd kan worden maar de zone tijdelijk twee keer zo groot maakt (vanwege de dubbele handtekeningen), terwijl de pre-publish methode de voorpublicatie van de nieuwe publieke sleutel naast de oude DNSKEY vereist. Om deze laatste methode bij noodgevallen toch te kunnen gebruiken zou je een DNSKEY permanent als reserve moeten voorpubliceren, terwijl je de bijbehorende private sleutel offline bewaart.
Voor het wisselen van de ZSK roll-over methode ga je naar de 'Data Management' -> 'DNS' tab en selecteer je in de Toolbar de 'Grid DNS Properties'. In de 'DNSSEC'/'Basic' tab — waar we eerder al zijn geweest om de cryptografische instellingen voor DNSSEC aan te passen — vinden we ook de toggle voor de 'Zone-signing Key rollover method'. Standaard staat deze ingesteld op 'Pre-publish', dus die kun je in het algemeen laten zoals hij is.
5.1 ZSK roll-overs
Roll-overs voor de ZSK-sleutelparen worden (vanwege de hoge frequentie) altijd volautomatisch uitgevoerd. In geval van (veiligheids-)problemen raadde de handleiding voor NIOS versie 6.10 aan om de ondertekening van een zone te verwijderen en gelijk daarna weer aan te zetten. Dat lijkt ons geen goede oplossing; daarmee wordt de beveiliging van de DNS-records immers tijdelijk uitgeschakeld. Vanaf NIOS versie 6.11 worden gelukkig ook handmatige roll-overs voor ZSK-sleutelparen ondersteund. Ga daarvoor naar 'Data Management' -> 'DNS' -> 'Zones', selecteer de zone die je wilt rollen, en klik vervolgens in het DNSSEC-menu op de optie 'Rollover Zone-Signing Key'.
Net als bij het ondertekenen van een zone levert de appliance software geen enkele feedback over het al dan niet goed verlopen van de roll-over. Wel kunnen we in de zone pagina zelf aan het extra ZSK DNSKEY record (de vlaggen hebben de waarde 256) zien dat de roll-over in gang gezet is.
Daarnaast kunnen onveilige sleutelparen nu ook direct verwijderd worden. Actieve sleutelparen worden door de software beschermd tegen verwijdering, dus dit kan alleen met sleutelparen die al gerold (dat wil zeggen: verlopen) zijn (of nog in hun pre-publish stadium zijn). Hiervoor ga je naar 'Data Management' -> 'DNS' -> 'Zones'. Daar selecteer je de betreffende zone en klik je vervolgens op 'Edit'. In de 'Advanced'/'DNSSEC' tab van de Authoritative Zone editor kun je de afzonderlijke KSK- en ZSK-sleutelparen beheren.
5.2 KSK roll-overs
KSK roll-overs moesten voorheen handmatig geïnitieerd worden, maar worden tegenwoordig ook automatisch uitgevoerd. Om deze functie uit te schakelen ga je naar de eerder gebruikte 'DNSSEC'/'Basic' tab, waar je de optie 'Enable automatic KSK rollover' aantreft.
Hoewel een KSK roll-over menselijke interventie nodig heeft voor het uploaden van de nieuwe DNSKEY/DS records naar de registry, raden we toch aan deze roll-over functie op automatisch te laten staan. Zeven dagen voor het verlopen van een KSK-sleutelpaar geeft de appliance software in de admin interface aan dat er een roll-over aan zit te komen. Daarnaast is er de mogelijkheid om een notificatie per SNMP en/of mail te laten versturen. Dat kan voor elk event van de roll-over, of alleen voor die events die menselijk handelen nodig hebben — het toevoegen en verwijderen van sleutelmateriaal in de bovenliggende zone.
5.3 Notificaties
Die periode van zeven dagen lijkt ons erg kort voor een domein dat maar weinig mutaties heeft. Bovendien schiet de admin interface op dit gebied tekort: selecteer je de optie 'Check KSK Rollover Due' in het DNSSEC-menu, dan is daar niet te zien welke roll-overs er aan zitten te komen als dat langer dan een week weg is.
Volgens Liu openen veel DDI-beheerders de Infoblox interface meerdere malen per dag, of hebben zij dat scherm zelfs de hele dag openstaan. Ondanks dat hij eerder aan hun engineers zou vragen om te kijken of de notificaties eerder geactiveerd en uitgestuurd kunnen worden, is die periode van zeven dagen niet aangepast.
Gelukkig leidt het vergeten van een roll-over niet tot ongelukken: KSK/ZSK-sleutelparen hebben, in tegenstelling tot DNSSEC-handtekeningen, alleen een administratieve levensduur. Daarnaast kun je de Infoblox API gebruiken om bijvoorbeeld met behulp van Perl zelf de database te bevragen.
Tenslotte is er net als voor de ZSK-sleutelparen ook voor KSK-sleutelparen de mogelijkheid om deze handmatig te rollen (de optie 'Rollover Key-Signing Key' in het DNSSEC-menu). Daarna moeten vanzelfsprekend de nieuwe DNSKEY/DS records worden geëxporteerd en naar de registry worden geüpload.
6 Stilstand is achteruitgang
De implementatie van nieuwe DNSSEC-functionaliteit in de Infoblox software verloopt maar langzaam. Met de snelle ontwikkeling (volwassenwording) van het DNSSEC-protocol over de afgelopen jaren leidt dat tot achterstand. We schreven eerder dat Infoblox-gebruikers feitelijk met een verouderd systeem zaten, en dat van eerder gedane toezeggingen omtrent het doorvoeren van verbeteringen weinig terecht gekomen was.
Inmiddels zijn veel van de eerdere kritiekpunten omtrent de cryptografie en de default-instellingen echter aangepakt, en levert de Infoblox appliance out-of-the-box voor wat betreft DNSSEC een goed bruikbare basis-installatie op.
6.1 ECDSA-algoritmen
Maar Infoblox biedt op dit moment nog geen ondersteuning voor de ECDSA-algoritmen (nummer 13 en 14), die inmiddels in opkomst zijn [1, 2]. ECDSA maakt het DNSSEC-protocol veiliger en korter, en het gebruik ervan willen we dan ook — waar mogelijk/beschikbaar — sterk aanbevelen.
RSA/SHA1 is the most widely used cryptographic algorithm for generating KSK and ZSK. However, it is recommended to use RSA/SHA-256 [nummer 8] and RSA/SHA-512 [nummer 10] for better interoperability. It is not recommend to use RSA/MD5 cryptographic algorithm as it is not very secure. As stated in RFC 6944, there are known defects in MD5.
Infoblox lijkt zijn verouderde implementatie op papier te hebben willen "repareren" door het volgende in de handleiding te zetten: In tegenstelling tot het gestelde is niet interoperabiliteit maar veiligheid de reden om het gebruik van algoritmen nummer 8 en 10 aan te raden. Bovendien laat de achterhaalde statistiek met betrekking tot het gebruik van RSA/SHA-1 zien dat Infoblox-gebruikers deze handleiding met voorzichtigheid moeten lezen.
SIDN ondersteunt de twee ECDSA-algoritmen al sinds maart 2016. Dat betekent dat registrars de DNSKEY records voor hun .nl domeinnamen ook in deze twee formaten kunnen aanleveren in de DRS-interface.
6.2 RFC 5011
Een andere feature die dringend aandacht behoeft is de (nog ontbrekende) ondersteuning in NIOS van RFC 5011. Deze standaard voorziet in een protocol waarmee nieuwe trust anchors automatisch en op beveiligde wijze (dat wil zeggen: ondertekend) kunnen worden toegevoegd aan een DNSSEC-validerende resolver.
Dit protocol speelde vorig jaar een cruciale rol bij de roll-over van het root KSK-sleutelpaar. Validerende resolvers die geen RFC 5011 ondersteunden, waaronder de Infoblox appliances, moesten handmatig van het nieuwe trust anchor worden voorzien. Eind vorig jaar werd deze roll-over uitgesteld omdat nog te weinig validerende resolvers het nieuwe trust anchor geïnstalleerd hadden.
6.3 Banken
De reden dat we niet licht aan deze tekortkomingen voorbij willen gaan is dat het hier om een DNS appliance gaat. Appliances zijn immers bedoeld om met zo min mogelijk configuratie-inspanningen zo snel mogelijk ingezet te worden. Infoblox is in deze markt een grote speler, en veel belangrijke partijen vertrouwen op hun product.
Degenen die achterlopen met hun DNSSEC-implementaties — met name de banken en andere grote organisaties — zijn relatief vaak Infoblox-gebruikers. Een achterlopende DNSSEC-implementatie helpt hen niet om die achterstand in te halen.
7 Afsluitend
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. Op de laatste versies van NIOS hoef je verder niet meer te doen dan de default-instellingen te controleren. 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.