DNSSEC timing: absolute, relatieve en administratieve tijdsaanduidingen
DNSSEC heeft de wereld van de DNS operator op twee belangrijke punten veranderd. Ten eerste is DNS hiermee van een voornamelijk administratief systeem geëvolueerd tot een aanzienlijk complexer cryptografisch platform dat voor een heleboel nieuwe toepassingen gebruikt kan worden. Ten tweede introduceert DNSSEC voor het eerst absolute tijden in een systeem dat voorheen alleen relatieve tijden (TTL's) kende. Bovendien interacteren deze twee verschillende timing-methoden met elkaar.
In dit artikel behandelen we de timing-aspecten van DNSSEC aan de hand van de instellingen voor OpenDNSSEC (in het bestand /etc/opendnssec/kasp.xml). Dat is de meestgebruikte DNSSEC-oplossing voor Bind named, dat op zijn beurt weer de meestgebruikte DNS-server is.
De grote registrars gebruiken veelal PowerDNS, juist vanwege de goede ingebouwde ondersteuning van DNSSEC. Uitgangspunt van de makers daarvan is echter om zo veel mogelijk te automatiseren en te verbergen voor de gebruiker — in dit geval de beheerder. Dat betekent dat PowerDNS helemaal geen timing-instellingen aanbiedt (of vraagt). We komen aan het eind van dit artikel nog even terug op deze minimalistische visie.
Een goed begrip van de tijdsinstellingen van DNSSEC is met name van belang voor de ondertekening van record sets (RRSET's), voor key roll-overs en voor de verhuizing van beveiligde domeinen — die laatste is in feite een key roll-over verdeeld over twee verschillende registrars. Gelukkig verlopen die eerste twee processen na de initiële setup (scripting/configuratie) veelal automatisch. De verwachting is dat ook beveiligde verhuizingen straks volledig geautomatiseerd kunnen gebeuren.
Overzicht
Na de invoering van DNSSEC bevat de DNS-infrastructuur nu drie verschillende timing-methoden:
- De TTL-waarden zijn relatieve tijdsaanduidingen die gebruikt worden om de (resterende) levensduur van een record aan te geven. Caching name servers gebruiken deze waarde als aflopende secondenteller voor de geldigheid van het opgeslagen record. Naarmate de tijd verstrijkt en een record in de cache-hiërarchie steeds verder van de autoritatieve name server af beweegt, neemt de TTL-waarde af totdat het record uiteindelijk uit de caches verwijderd wordt.
De TTL-waarden waren al onderdeel van het bestaande DNS-protocol en zijn dus bekende kost voor beheerders. - De RRSIG en NSEC(3) records bevatten naast de digitale handtekening ook twee absolute datumaanduidingen die het begin en het einde van de geldigheid aangeven. Ruim voordat een handtekening verloopt, moeten de resource records opnieuw ondertekend worden. Zowel de geldigheidsduur als de periode voor herondertekening worden bepaald door de relatieve tijdsinstellingen in het DNSSEC-systeem.
Deze timing-methode hoort specifiek bij DNSSEC en is daarmee een nieuw onderdeel van DNS. - De cryptografische sleutelparen voor het ondertekenen van de resource records en het valideren van de handtekeningen hebben alleen een administratieve geldigheidsduur. Ze worden door het DNSSEC-systeem voor een specifieke periode gebruikt en moeten daarna gerold worden. Deze periode wordt echter niet hard afgedwongen; zolang er geen nieuw sleutelpaar beschikbaar is, blijft het oude paar gewoon gebruikt worden. De DNSKEY en DS records bevatten zelf geen timing-informatie. Hun relatieve (resterende) geldigheidsduur wordt dus volledig bepaald door de bijbehorende TTL-waarden.
De instelllingen voor de sleutelparen zijn specifiek voor DNSSEC en daarmee een nieuw onderdeel van DNS.
Voor specifieke records, en het ondertekenen en rollen geldt het volgende:
- Zowel de oude DNS-records als de nieuwe DNSSEC-records hebben een relatieve (resterende) levensduur bepaald door de TTL-waarde. Voor de RRSIG records moet de TTL-waarde gelijk zijn aan die van de resource records.
- Daarenboven hebben de digitale handtekeningen een absolute geldigheidsperiode expliciet gespecificeerd in het RRSIG record.
- De DNSKEY en DS sleutel-records bevatten geen timing-informatie. Daarmee is de rol van deze records beperkt tot die van schakel in de vertrouwensketen.
- Het herondertekenen van de resource records en het rollen van de sleutels zijn twee verschillende maar niet onafhankelijke processen.
- Daarbij is de herondertekening afhankelijk van drie verschillende triggers:
- veranderingen in de zone file,
- het verlopen van de bestaande digitale handtekening,
- het rollen van het (ZSK-)sleutelpaar.
- Het rollen van een sleutelpaar wordt alleen administratief getriggerd: bij "verlopen", bij een veiligheidsincident, bij de verhuizing naar een andere registrar of bij de overstap naar een ander cryptografisch algoritme. Daarbij is dit proces voor zijn timing wel afhankelijk van zowel herondertekening (van de sleutel-records) als TTL-instellingen (voor het uitspoelen van informatie).
Hieronder worden deze zaken uitgebreider besproken en toegelicht aan de hand van de timing-instellingen van OpenDNSSEC.
Time To Live
Elk DNS record heeft een eigen TTL-waarde. Deze Time To Live is relatief en geeft het aantal seconden weer dat een record nog geldig is. De initiële waarde is gespecificeerd in de zone file, eventueel per record afzonderlijk maar meestal globaal ($TTL in het SOA record).
De TTL-waarde wordt door de autoritatieve name servers doorgegeven aan opvragende resolvers. Lokale DNS caches en caching name servers gebruiken de TTL vervolgens — of zouden deze moeten gebruiken — om de geldigheidsduur van de binnenkomende records in hun cache te bepalen. Zij geven op hun beurt de resterende TTL weer door aan een volgende opvragende resolver. Naarmate een DNS record zich verder van de autoritatieve server af beweegt door de verschillende caches heen, zal zijn resterende TTL-waarde dus steeds korter worden.
Wachttijden
Voor de DNS operator is de TTL-waarde in de autoritatieve zone file cruciaal voor het administratieve beheer van zijn domeinnamen. Deze waarde bepaalt immers hoe lang het duurt voordat de oude records uit alle caches op internet zijn "weggespoeld". Bij de vaststelling van de TTL-waarde maakt de operator een afweging tussen de snelheid waarmee hij wijzigingen kan doorvoeren en fouten kan corrigeren enerzijds en de belasting van zijn DNS servers anderzijds. Specifiek voor DNSSEC zie je de TTL-waarden terug in de wachttijden van het verhuisprotocol voor beveiligde domeinen.
De timing-waarden in het SOA record (uitgezonderd de $TTL variabele) zijn alleen bedoeld voor de slaves (typisch secondary name servers) en laten we in dit artikel verder buiten beschouwing. In een DNS-infrastructuur waar de master geen NOTIFY-signaal stuurt naar zijn slaves voor het initiëren van een zone refresh, moet de vertraging in de propagatie van de master naar de slaves (de refresh time) wel meegenomen worden in de timing-berekeningen.
Dat is in ieder geval een aandachtspunt bij het opzetten van een bump-in-the-wire configuratie. Daarbij stuurt een verborgen administratieve master zijn zone files door naar een tussenstation voor ondertekening, vanwaaruit de ondertekende zones vervolgens verder verspreid worden naar de publieke name servers. In OpenDNSSEC neem je deze vertraging op in de <Zone> <PropagationDelay> variabele (default: 43200s = 12 uur).
Handtekeningen
Voor de timing van DNSSEC is om te beginnen de geldigheidsperiode van de handtekeningen van belang. De RRSIG records bevatten twee absolute datumaanduidingen die het begin (het moment van ondertekening, meestal iets eerder) en het einde van de geldigheid aangeven:
example.nl. 86400 IN RRSIG NS 8 3 86400 20160111034747
20160104084049 56851 example.nl. ETXBKyEVFcCs...
Deze periode is afgeleid van de <Signatures> <Validity> <Default> en <Denial> variabelen, die de geldigheidsduur voor respectievelijk de gewone en NSEC3 RRSIG records specificeren. Een typische instelling hiervoor is een tot vier weken (default: twee weken).
Herondertekening
De variabele <Refresh> geeft aan wanneer de DNS records opnieuw ondertekend moeten worden. Een typische instelling is drie (default) tot zeven dagen voor het verlopen ervan. De hieraan gerelateerde variabele <Resign> specificeert hoe vaak de OpenDNSSEC Signer wordt opgestart om te kijken of er iets moet gebeuren (default: elke twee uur). Deze instelling moet minstens een orde grootte kleiner zijn dan de <Refresh> zodat de timing van de policies goed gevolgd wordt.
Omdat een validerende resolver zowel de handtekening zelf als de geldigheid ervan controleert, is het van cruciaal belang dat het herondertekeningsproces goed (dat wil zeggen zonder menselijke tussenkomst!) gebeurt. Ook een verlopen handtekening betekent immers dat de record set niet meer gebruikt mag worden. Bovendien moeten er waarschuwingssignalen worden afgegeven (en gezien!) als er iets misgaat. Dat het meerdere malen is voorgekomen dat de beheerder van een top-level domein zijn handtekeningen liet verlopen, laat zien dat dit zelfs de beste kan overkomen.
Sleutels
De levensduur voor de sleutelparen is gespecificeerd in het <Keys> blok. De twee <Lifetime> variabelen bepalen de geldigsheidsduur van de KSK- en ZSK-sleutelparen (default ingesteld op respectievelijk 1 jaar en drie maanden).
In tegenstelling tot de handtekeningen hebben de sleutels echter geen harde geldigheidsperiode. Zoals men hieronder kan zien, bevat een DNSKEY record (net als een DS record) alleen een TTL (hier 86400 = 24 uur).
example.nl. 86400 IN DNSKEY 257 3 8 AwEAAcD39n4p...
example.nl. 86400 IN DS 12345 8 3 5248DB0EAE4E3...
De geldigheidsperiode van een sleutelpaar zoals die volgt uit de bijbehorende <Lifetime> variabele is daarmee niet meer dan een administratieve aangelegenheid. Laat de beheerder een sleutelpaar verlopen, dan is daarvan in de buitenwereld niets te merken. De ondertekening van de record sets en de publicatie van de publieke sleutel lopen gewoon door.
Uitsluitend de periode zoals opgenomen in het RRSIG record is dus bepalend voor de geldigheid van een handtekening. De bijbehorende publieke sleutel (DNSKEY en DS record) moet in ieder geval beschikbaar zijn zolang er nog geldige RRSIG records in omloop zijn. De rol van de sleutel-records is daarmee dus beperkt tot die van schakel in de vertrouwensketen.
Roll-over
Voordat een KSK-sleutelpaar (administratief) verloopt krijgt de beheerder bericht (via de log) dat er gerold moet worden. Dan is er al een nieuw sleutelpaar aangemaakt en is het bijbehorende DNSKEY record inmiddels lang genoeg gepubliceerd (Double-KSK zoals beschreven in RFC 6781 sectie 2.2) om overal zichtbaar te zijn. De variabele <RolloverNotification> in het bestand /etc/opendnssec/conf.xml bepaalt hoe lang tevoren dit proces in gang gezet wordt (default: 14 dagen).
Het nieuwe sleutelpaar heeft op dat moment de status "ready" (zoals gedefinieerd in RFC 7583 sectie 3.1), wat betekent dat OpenDNSSEC wacht op het signaal om deze daadwerkelijk te mogen gebruiken. Daarvoor moet de nieuwe publieke sleutel immers eerst (vooralsnog handmatig) in de bovenliggende zone als DS record worden gepubliceerd, waarmee de vertrouwensketen wordt gesloten.
Transitie
Zodra het nieuwe DS record zichtbaar is — voor de .nl zone duurt dat sinds vorige maand maximaal één uur — kan de transitie in gang gezet worden. De beheerder geeft het signaal daartoe aan OpenDNSSEC middels de opdracht 'ods-ksmutil key ds-seen -z example.nl. -x 12345'.
Pas als de oude DS records overal uit de caches verdwenen zijn, kan de nieuwe sleutel ook daadwerkelijk worden gebruikt om records te ondertekenen. Deze wachttijd is afhankelijk van de TTL-waarde zoals die door de bovenliggende zone voor de DS records is ingesteld. Hij wordt voor OpenDNSSEC opgegeven in de <Parent> <DS> <TTL> variabele.
Als dan ook de oude RRSIG records overal uit de caches zijn weggelopen, kunnen tenslotte de oude DNSKEY en DS records worden verwijderd. Voor die eerste gebeurt dat automatisch. Voor de oude DS records geregistreerd in de bovenliggende zone moet dat handmatig gebeuren.
Voor details met betrekking tot de timing-aspecten van verschillende roll-over-methoden voor ZSK- en KSK-sleutelparen verwijzen we naar RFC 7583.
TTL-waarden
De TTL-waarde van de RRSIG records moet gelijk zijn aan die van de betreffende RRset, zo is gespecificeerd in RFC 4034 (sectie 3). De $TTL-waarde wordt voor de gehele ondertekende zone (in het SOA record) ingesteld via de <Zone> <SOA> <TTL> variabele (default: 3600s = één uur).
www.example.nl. 3600 IN AAAA 2001:DB8::1:26
www.example.nl. 3600 IN RRSIG AAAA 8 3 3600 20160111034747
20160104084049 56851 example.nl. ETXBKyEVFcCs...
Voor de DNSKEY records is er een aparte instelling in de <Keys> <TTL> variabele (default: 3600s = één uur). Hetzelfde geldt voor TTL-waarde van de NSEC3PARAM records, waarvoor de <Denial> <NSEC3> <TTL> variabele gebruikt kan worden. Behalve als er goede redenen zijn om hiervan af te wijken, kunnen deze instellingen om verwarring te voorkomen het beste gelijk gemaakt worden aan de $TTL-waarde zoals gedefinieerd in de originele zone file.
In het algemeen is het voor de meeste domeinen overigens geen probleem om hogere TTL-waarden aan te houden; dat vermindert immers de belasting op de DNS servers. De trend naar steeds kortere TTL's is een gevolg van grote online dienstverleners die de TTL gebruiken voor load-distributie en van systeemleveranciers die daarmee de behoefte aan hardware willen vergroten. Maar als je maar weinig wijzigingen hebt op een zone, en die ook wel een dagje kunnen doorlopen, dan is een hele lage TTL voor de meeste domeinen niet nodig.
Wel is het een goed idee om tijdens migratie-trajecten — beveiligde verhuizingen — en de implementatie van nieuwe technologie — DNSSEC — de TTL's kort te houden, zodat veranderingen snel doorgevoerd worden. Bovendien voorkom je zo dat het nog een hele dag duurt voordat een fout die al naar het internet is gepropageerd overal uit de caches is verdwenen.
PowerDNS
De hier genoemde timing-variabelen zijn alleen bedoeld om de verschillende timing-aspecten van DNSSEC te illustreren. OpenDNSSEC biedt er nog aanzienlijk meer, zoals aparte tijdsinstellingen voor de NSEC records en extra marges voor het opvangen van kleine tijdsverschillen tussen systemen, van zomertijd en van netwerkproblemen. Alles bij elkaar gaat het om tientallen variabelen.
De makers van PowerDNS gaan uit van een hele andere filosofie. Wij hebben welgeteld nul DNSSEC-specifieke timing-instellingen,
aldus senior engineer Peter van Dijk. Wij geloven in slimme defaults die goed werken voor de meeste gebruikers. Bovendien richten wij ons op een specifieke doelgroep: die van de grote hosters. Vraag naar meer of andere instellingen is er niet of nauwelijks. Wat dat betreft is OpenDNSSEC beter geschikt voor specifieke deployments zoals bij TLD registries.
De handtekeningen worden door PowerDNS elke donderdag opnieuw gegenereerd, met een voorwaartse geldigheidsduur van twee weken. Meer is er niet. Automatische key roll-overs zijn niet eens geïmplementeerd. Waarom zou je beheerders al dat touw geven om zichzelf op te hangen? Het enige argument voor het almaar rollen van sleutels is dat je het dan in de vingers hebt op het moment dat het nodig is.
