DNSSEC-validatie op een Infoblox appliance

Nieuwe KSK-2017 trust anchor moet handmatig geïnstalleerd worden

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.

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 root KSK-2017 sleutel handmatig als trust anchor zult moeten installeren (zie hieronder) in je validerende resolver.

Hoe dit artikel te lezen

In dit artikel behandelen we de DNSSEC-configuratie voor een validerende resolver op Infoblox. De configuratie van een Infoblox appliance als autoritatieve name-server 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.

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.

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.

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) UTC) over Internet gelijk te schakelen (via UDP/123). Voor de configuratie van de ingebouwde NTP-server van Infoblox verwijzen we naar het hands-on artikel over DNSSEC-ondertekening op een Infoblox appliance (sectie 2), waarin deze in detail wordt besproken.

DNSSEC-instellingen

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

UI-017d

DNSSEC-validatie

Voor de DNSSEC-specifieke instellingen klikken we in hetzelfde window naar de 'Basic'/'DNSSEC' tab. De ondersteuning voor DNSSEC in het algemeen ('Enable DNSSEC') en validatie in het bijzonder ('Enable DNSSEC validation') staan beide standaard aan.

UI-018

UI-018a

Met deze instelling wordt DNSSEC-validatie in één keer voor het hele grid aangezet. Wil je validatie aan (of uit) zetten op een specifiek Grid Member (typisch een caching resolver), dan ga je eerst naar de 'Data Management' -> 'DNS' -> 'Members' tab. Daar selecteer je 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.

UI-050a

Verlopen handtekeningen en negatieve trust anchors

In deze schermen zie je ook de optie 'Accept expired signatures' staan. Deze optie zet je alleen in hele specifieke gevallen aan, namelijk als je resolver bepaalde DNS records blokkeert omdat de beheerder van het domein in kwestie vergeten is om de handtekeningen te vernieuwen. Omdat het verversen van die RRSIG records vanwege de hoge frequentie vrijwel altijd automatisch gebeurt, betekent dit meestal dat er "iets omgevallen" is. Je laat de validerende resolver dan alleen tijdelijk de verlopen handtekeningen accepteren, zolang de achterliggende problemen nog niet verholpen zijn.

Waar de 'Accept expired signatures' optie alle verlopen handtekeningen (tijdelijk) accepteert, kun je de 'Negative Trust Anchors' gebruiken om specifieke zones te whitelisten, eventueel ook gedurende een langere periode. Dit is typisch de plek waar je zones neerzet die DNSSEC-problemen hebben — bijvoorbeeld in hun configuratie — maar wel gebruikt worden in je organisatie, bijvoorbeeld voor een online (cloud) applicatie. Zones opgenomen in deze lijst worden helemaal niet gecontroleerd.

Trust anchors

In de lijst met 'Trust Anchors' neem je de domeinen op (met hun publieke sleutels) die je per definitie vertrouwt. Voordat de root zone ondertekend was werden top-level domeinen (TLD's) waarvoor DNSSEC wel al werkte op deze manier expliciet in validerende resolvers vastgelegd. Maar nu de root zone en de meeste TLD's daaronder van DNSSEC zijn voorzien, komt het verankeren van dit soort "islands of trust" eigenlijk niet meer voor.

Toch is deze optie juist nu heel relevant. We zitten op dit moment namelijk midden in het roll-over proces voor het KSK-sleutelpaar van de root zone. Dat betekent dat ICANN, de beheerder van de root zone, het huidige cryptografische sleutelpaar dat de basis vormt voor de hele DNSSEC-infrastructuur (KSK-2010) vervangt door een nieuw sleutelpaar (KSK-2017).

Root KSK roll-over

De daadwerkelijke roll-over zou op 11 oktober 2017 plaatsvinden, maar die transitie is even daarvoor uitgesteld omdat nog te weinig validerende resolvers het nieuwe trust anchor geïnstalleerd hadden. Een nieuwe datum is nog niet bekend, maar beheerders van validerende resolvers wordt dringend aangeraden om hun systemen up-to-date te brengen — voor zover zij dat nog niet gedaan hebben.

Nieuw trust anchor

Voor beheerders van validerende resolvers betekent dit dat zij zich ervan moeten vergewissen dat de nieuwe publieke root KSK-sleutel inderdaad als trust anchor op hun systemen is geïnstalleerd en geactiveerd. Vanaf het moment van de daadwerkelijke roll-over zijn de digitale handtekeningen gebaseerd op het oude KSK-2010 sleutelpaar namelijk niet meer geldig. Dat betekent dat validerende resolvers die niet zijn voorzien van het nieuwe trust anchor dan geen mogelijkheid meer hebben om de handtekeningen onder de DNS-records te verifiëren, waarmee alle domeinnamen voor de gebruikers/applicaties van de betreffende resolver onbereikbaar zijn geworden.

Voor resolvers waarbij de installatie van het nieuwe trust anchor niet automatisch gaat (via het RFC 5011 protocol), waaronder de Infoblox appliances, moet die toevoeging hand (out-of-band) gebeuren.

Handmatige installatie KSK-2017

De handmatige installatie van het nieuwe trust anchor begint met het binnenhalen van de publieke KSK-sleutels van de website van IANA. Maar voordat je de nieuwe publieke sleutel als trust anchor in je resolver installeert moet je eerst zeker weten dat dit inderdaad de juiste (authentieke) sleutel is. In het artikel 'Installatie trust anchor voor nieuwe root KSK' (onder de sectie 'Handmatige installatie') vind je een uitgebreide beschrijving voor het op een veilige manier binnenhalen en verifiëren van de actuele root sleutels.

Heb je de nieuwe KSK-2017 sleutel (met keyid 20326) eenmaal binnengehaald en voldoende geverifieerd, dan kun je deze als extra trust anchor in je Infoblox grid installeren. Daarvoor ga je naar de 'Data Management' -> 'DNS' tab en selecteer je in de Toolbar de 'Grid DNS Properties'. Onderaan in de 'DNSSEC'/'Basic' tab kun de KSK-2017 sleutel toevoegen. Nauwkeuriger bezien gaat het hier om de hash van de publieke sleutel (vergelijkbaar met de informatie in een DS record), dus let op dat je hier de juiste cryptografische instellingen gebruikt: KSK-2017 wordt gepubliceerd als een message digest (hash) van type nummer 2 (SHA-256) op een publieke sleutel op basis van DNSSEC-algoritme nummer 8 (RSA/SHA-256).

UI-051a

Hoewel de installatie van KSK-2017 op dit moment even niet meer zo dringend is als voorheen, raden wij je sterk aan om het nieuwe trust anchor gelijk te installeren als je toch met de configuratie van je appliance(s) bezig bent. Infoblox Nederland gaf eerder aan zijn klanten hierover actief te informeren.

Afsluitend

Voor de configuratie van DNSSEC-validatie op een Infoblox appliance hoef je op de laatste versies van NIOS in principe 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.

Omdat de Infoblox software het RFC 5011 protocol niet ondersteunt zal je de nieuwe root KSK-2017 sleutel handmatig als trust anchor moeten installeren. De reden dat we niet licht aan deze tekortkoming 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.

Reacties

  • donderdag 13 december 2018

    Kennis

    IDnext en SIDN verdiepen samenwerking

    Thumb-logo-IDnext

    Met gezamenlijk IDnext event willen organisaties een impuls geven aan innovatie op het gebied van digitale identiteiten

    Lees meer
  • dinsdag 8 mei 2018

    Over SIDN

    Kom naar DHPA TechFest!

    DHPA+Techfest+tumbnail

    Op 24 mei is DHPA TechFest in Naarderbos in Naarden.

    Lees meer
  • dinsdag 24 juli 2018

    Over SIDN

    De zoektocht naar de cyberspecialist van morgen

    Thumb-student-laptop

    De Cyberwerkplaats koppelt jong talent op een vernieuwende manier aan de praktijk

    Lees meer

Sorry

De versie van de browser die je gebruikt is verouderd en wordt niet ondersteund.
Upgrade je browser om de website optimaal te gebruiken.