Tweeluik DNSSEC en BIND named
Deel 2: sleutelbeheer
Beheerders die zelf hun DNS -servers onderhouden zullen daarvoor meestal gebruik maken van BIND named. In het eerste artikel van dit tweeluik zijn we uitgebreid ingegaan op de configuratie van DNSSEC voor deze DNS-server. In dit tweede verhaal bouwen we hier op voort met sleutelbeheer, automatische ondertekening en andere beheersaspecten.
Uitgangssituatie voor dit artikel is een goed werkende DNS-installatie, voorzien van DNSSEC-ondersteuning zoals beschreven in deel één. Dat betekent dat DNSSEC is aangezet in de configuratie, dat er KSK/ZSK-sleutelparen zijn aangemaakt in de directory /etc/bind/keys/, en dat deze zijn gebruikt om de zone file te ondertekenen. De DS records — SIDN gebruikt voor .nl-domeinen de DNSKEY records — zijn via de registrar naar de beheerder van het top-level domein geupload. Gecontroleerd is dat de DNS-server in deze configuratie desgevraagd (dig @localhost +dnssec) ook RRSIG records voor validatie tegen het trust anchor aanlevert.
Geldigheidsduur digitale handtekeningen
De file db.example.com.signed bevat nu weliswaar de digitale handtekeningen (RRSIG records) voor alle zone informatie, maar deze zijn maar beperkt geldig. De standaard geldigheidsduur die het dnssec-signzone commando zonder specifieke opties aan de records meegeeft is 30 dagen vanaf de ondertekening. Dat kunnen we natuurlijk ook zien in de getekende zone file zelf, waar zowel begin- als eindtijd in absolute vorm staan aangegeven, bijvoorbeeld zoals hier:
86400 RRSIG SOA 6 2 86400 20121220141914 (
20121120141914 21523 example.com.
CFjCeSmUYh020rCPRsacvj9/zjghWQAGrm9M
/PVY/z8/mbB2Oc0IKTY= )
Let op dat in het record zelf de eerste datum de einddatum is en de tweede de begindatum.
Willen we de start- en eindtijd precies instellen, dan zijn daarvoor respectievelijk de opties -s en -e beschikbaar, waarmee zowel een absolute als relatieve tijd kan worden meegegeven. Voor een geldigheidsduur van twee weken (1209600 seconden) zouden we bijvoorbeeld dnssec-signzone met de optie -e +1209600 gebruiken.
Refresh
We kunnen deze mogelijkheid bovendien combineren met de -i optie. Daarmee kan een refresh-interval (ook weer in seconden) worden gespecificeerd. Geven we een eerder ondertekende zone file als input, dan worden alleen die records opnieuw ondertekend die binnen deze periode zouden verlopen.
Is dit interval niet gespecificeerd, dan wordt hiervoor een kwart van de geldigheidsduur aangehouden. Voor de default geldigheid van 30 dagen komt dat dus neer op een refresh-interval van 7,5 dag.
Voor het aanpassen van de meta-informatie van al bestaande sleutels is het dnssec-settime commando beschikbaar.
We zouden deze mogelijkheden kunnen combineren in wat kleine shell scripts en cron jobs om onze zone files bijvoorbeeld steeds een week voor het verlopen van de digitale handtekeningen automatisch opnieuw te laten ondertekenen.
Auto-DNSSEC en Inline-Signing
Gelukkig is het meeste van dat handmatige geknutsel inmiddels niet meer nodig. Vanaf versie 9.9 ondersteunt BIND named de mogelijkheid tot Inline-Signing. Dat betekent dat de hele ondertekening en publicatie van zone informatie geautomatiseerd kan worden.
Daarvoor voegen we deze optie toe aan de configuratie file /etc/named.conf:
key-directory "/etc/bind/keys";
En deze aan elke afzonderlijke zone:
auto-dnssec maintain; inline-signing yes;
Vervolgens geven we dit commando om de nieuwe configuratie in te lezen:
rndc reconfig
De auto-dnssec optie (beschikbaar vanaf BIND named versie 9.7) maakt het mogelijk om zone files opnieuw te laten ondertekenen als deze veranderd zijn of als nieuwe sleutels zijn neergezet. Daarmee kan ook de roll-over van ZSK-sleutels worden geautomatiseerd, simpelweg door de nieuwe sleutels in de key-directory te plaatsen. Named zal deze zelf als DNSKEY publiceren, en ze gebruiken om te ondertekenen zodra ze actief worden. Maar de meta-data wordt ook steeds gecontroleerd op verlopen of ingetrokken sleutels. Nieuwe zones waarvan tevens de sleutels zijn aangemaakt, worden automatisch ondertekend na het commando:
rndc sign example.com.
Standaard staat het interval voor het scannen van de key-directory op 60 minuten, maar dit kan veranderd worden met de dnssec-loadkeys-interval optie. Wil je wijzigingen direct laten verwerken, dan kun je daarvoor dit commando gebruiken:
rndc loadkeys
Wil je de standaard geldigheidsduur van 30 dagen voor de handtekeningen aanpassen, dan is daarvoor de sig-validity-interval optie beschikbaar.
Aandachtspunten
Waar we eerder de zone file db.example.com in de configuratie file /etc/named.conf handmatig vervingen door het met dnssec-signzone gegenereerde bestand db.example.com.signed, blijft bij gebruik van de auto-dnssec optie de naam van de originele zone file staan. Het ondertekenen van de zone informatie gebeurt immers intern.
De inline-signing optie is pas vanaf BIND named versie 9.9 beschikbaar. Eerder <> (voor BIND named versie 9.9; bij versie 9.7 en 9.8) maakte Auto-DNSSSEC gebruik van Dynamic DNS (DDNS) om zone informatie on-the-fly te kunnen ondertekenen. Daartoe werd de auto-dnssec optie voorheen steeds gecombineerd met deze optie:
update-policy local;
Updates op de configuratie en zone informatie konden hierbij bijvoorbeeld via nsupdate -l commandos's worden gegeven, waarna de zone informatie opnieuw door named onder handen kon worden genomen.
Deze aanpak is echter afhankelijk van een oneigenlijk gebruik van DDNS en bijvoorbeeld niet te gebruiken in combinatie met database-gedreven back-ends of een bump-in-the-wire setup.
De status van een zone kan tenslotte gecontroleerd worden met het volgende commando (vanaf BIND named versie 9.9):
rndc signing -list example.com
[root@services]# rndc signing -list example.com Done signing with key 8160/RSASHA256 Done signing with key 19273/RSASHA256
Ondertekende zone files
De automatisch gegenereerde (ondertekende) zone files — in ons geval het bestand db.example.com.signed — zijn in deze nieuwe opzet niet langer leesbaar. Omwille van de snelheid worden zone files nu in een binair formaat opgeslagen. Om ze toch te kunnen bekijken kan het volgende commando gebruikt worden:
named-checkzone -D -f raw -o - example.com example.com.db.signed
Of met dig natuurlijk:
dig @localhost axfr example.com
Daarnaast worden er voor elke zone journaal-bestanden bijgehouden: db.example.com.jnl in ons geval. Ook deze is in binair formaat; hij kan bekeken worden met het commando:
named-journalprint db.example.com.jnl
Rollen van sleutels
Er is in principe geen geldigheidsduur gekoppeld aan de KSK- en ZSK-sleutelparen die we eerder hebben gegenereerd. Alle sleutels werden direct gepubliceerd en geactiveerd op het moment dat ze werden gegenereerd. Die informatie is gewoon in de sleutelbestanden zelf als meta-data opgenomen:
; This is a zone-signing key, keyid 38215, for example.com. ; Created: 20121111104101 (Sun Nov 11 11:41:01 2012) ; Publish: 20121111104101 (Sun Nov 11 11:41:01 2012) ; Activate: 20121111104101 (Sun Nov 11 11:41:01 2012) example.com. IN DNSKEY 256 3 6 CKIICOcGpT7Z03WaMRpqM6j48EgfudMABFNLvxzJuSngAdsLeBPC08+G aFosKivZFucTR1ZMIzMRgqLauNKWzrANTAbXiBEyNhXLYBxRkCieVlCx ScjgnmHGtwdbrCu4R94rKmjYpeQk7tCuNL2nh6FuCpASE//k10Zgr9+G Ujxla5ab4PtGKPFfOTGGsnKTVNDmo0FUkj1wUoVLDb4T8leKBvS0gISs fnE68iSQynQDxMMuzs6RGJJhvZRcgBVH1zxBHLr1DVQEzFlGcI9usaso bRIwpu9mhch/Ei2YRAvhRTqoX/BzwcM6iRPW0fKhumTN4/X4Mv/qyrOD eVpICF2ln3c14xKW24j6UiQVED1Zq72WPyF0qYU34y7Nl/iZAfm4kzoO acX9s+w1GROUN6g2a4rPZn6tqMZSkWqP2jzK5YePYPJoJTNmvFXZg0uW rsncs7hxttW1OujovGCcgk4FCNcSK5yNhHyeeDzl6Bde31C8Xtc7tuPE V2MAwGTPPHCxy00cXphj1QonPeE3Mq1WdV4O
Hoewel dat niet persé noodzakelijk is, wordt aangeraden om de ZSK-sleutels regelmatig te verversen (te "rollen"), bijvoorbeeld elke maand. Daartoe worden niet één maar twee ZSK-sleutelparen aangemaakt. De eerste ZSK is direct actief (die hebben we dus al). De tweede ZSK wordt wel al gepubliceerd, maar pas later geactiveerd. Dat laatste wil alleen zeggen dat named deze nog niet gebruikt om zone informatie te ondertekenen. Op deze manier kunnen overlappende sleutels worden gegenereerd, zodat het rollen zonder haperingen verloopt.
Om een tweede (prepublished) ZSK-sleutelpaar te genereren dat direct gepubliceerd wordt, maar pas over 5 weken (3024000 seconden) wordt geactiveerd, voegen we deze opties aan het dnssec-keygen commando toe: -P now -A +3024000.
dnssec-keygen -3 -a RSASHA256 -b 1024 -P now -A +3024000 -r /dev/random -n ZONE example.com
; This is a zone-signing key, keyid 34640, for example.com. ; Created: 20121122163046 (Thu Nov 22 17:30:46 2012) ; Publish: 20121122163046 (Thu Nov 22 17:30:46 2012) ; Activate: 20121227163046 (Thu Dec 27 17:30:46 2012) example.com. IN DNSKEY 256 3 6 CLscUngALZQ1VioIYqU4zp9M5MRPjOM51MMVZMWNLB1vCTtTPowAxKYK 4lV8sYZ68TqZDC92Fbj8MDgSCpCjcyUVrjOBnrPO+n2g4qx12EmON4EJ PRkgOYm4b5Xzbri92xiR8hZDV60j5ufDgRJKDPiII1IEscLUw7aNaujF zST2/bzaAFJWoERNNNtVhw8D5KyLJi8SZlC87y3Zv/1IdIwE0UNasw+b BbZUGUVbt2UoTmwbpA7/kbw8H0+qvXAXwrexGsljVD6wCpKCy1j+S6L2 QHkJQvJRjKRfthr9MfbosFX1/9uxgkgb3Go3sudJWuyFhoocjmw+5NGt OamuoeMOtm1DusEOXXVOw/lzOA2zJluBhFM/VjIPThI028+FbMZuhwx2 BxbfAoEWYWcUoXHPLO3HDBYRW0yiIXPiGUrCVwINMmZo4r4AULQoaYOO L5ShfTYmMLm6wxPIjtS5R35GlNYLiw16RTGjSygEPpcpCjnJ6vYlSYUs 9dDKsn++omTW+NJmQe2TuHYuO/VyMTjkFK3W
We hebben bij het genereren van beide sleutelparen gekozen voor de pseudo-random generator /dev/random. Vooral op een machine waar maar weinig gebeurt kan het zijn dat deze generator erg langzaam is omdat er op dat moment te weinig random bits beschikbaar zijn. Een alternatief is de /dev/urandom generator; deze wacht niet tot er voldoende bits beschikbaar zijn maar levert in dat geval bit strings met minder "entropie" (randomness). Dat resulteert dus in een onveilig sleutelpaar. Voor productie-systemen wordt dan ook aangeraden altijd de '-r /dev/random' optie te gebruiken.
Volledig geautomatiseerd
We hebben in dit tweeluik aandacht besteed aan de praktische opzet van DNSSEC voor BIND named. Met de laatste versie van named, versie 9.9, is het ondertekenen van de zone-informatie en het rollen van sleutels grotendeels geautomatiseerd. Op dit moment hoeven eigenlijk alleen de sleutelparen nog "handmatig" te worden aangemaakt, en zelfs aan de automatisering daarvan wordt gewerkt.
Tenslotte nog een handige link: DNS-dienstverlener Six53 heeft een compacte DNSSEC reference card gepubliceerd.
