Na začátek bych opět upřesnil, jaké nástroje a DNS servery budeme používat. Již klasicky prvním DNS serverem bude Bind. Druhým serverem, který je možné pro DNSSEC na straně autoritativního serveru použít, je NSD, opět vyvinuté v organizaci NLNet Labs jako alternativa k nejpoužívanějšímu DNS serveru Bind. Oba DNS servery nejspíše najdete přímo ve vaší distribuci. Pokud ne, tak Bind lze stáhnout ze stránek Internet Systems Consorcium (www.isc.org), které jej vyvíjí, a NSD lze stáhnout ze stránek projektu na NLNet Labs.
Pro kompilaci tentokrát není zapotřebí knihovna ldns zmiňovaná v minulém díle, ale je dobré tuto knihovnu a příklady z adresáře examples/ mít nainstalové, protože některé utility lze šikovně využít pro rozšířenou práci se zónovým souborem, případně pro kontrolu podpisu. Důležité je použít minimálně verzi 1.4.0. Předchozí verze obsahovaly chybu v nástroji na podepisování zónového souboru. Knihovnu ldns také možná najdete ve své oblíbené distribuci (v Debianu je to balík ldnsutils
), pokud ne, tak na stránkách projektu najdete zdrojové kódy.
Zapnutí DNSSEC na autoritativním serveru
Zapnutí podpory na autoritativním serveru je ještě jednodušší než jeho zapnutí na rekurzivním serveru. Pokud používáte Bind ve verzi 9.4 a vyšší nebo server NSD nemusíte dělat vůbec nic. Podpora je standardně zapnuta. Pouze pro verzi Bind řady 9.3 je zapotřebí v sekci options {};
pomocí konfigurační volby dnssec-enable boolean;
explicitně zapnout podporu technologie DNSSEC.
Vygenerování klíčů
Ve čtvrté části našeho seriálu jsme si řekli o dvou druzích klíčů KSK a ZSK. Jak tyto klíče vygenerujeme? Můžeme použít buď nástroje, které jsou standardně distribuovány s DNS serverem Bind, nebo utility z balíku nástrojů ldns.
Pro oba klíče použijeme algoritmus RSASHA1 a jako zdroj náhodných čísel budeme používat /dev/urandom
, který se na rozdíl od /dev/random
neblokuje při nedostatku entropie. ZSK klíč bude mít 512 bitů (minimum pro RSASHA1 je 512 a maximum 4096) a KSK klíč bude mít 1024 bitů.
Pro vygenerování KSK a ZSK klíčů použijeme tyto příkazy, např. pro zónu dnssec.cz:
# dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -f KSK dnssec.cz dnssec-keygen -a RSASHA1 -b 512 -r /dev/urandom dnssec.cz
Parametr -a
určuje algoritmus, parametr -b
počet bitů, parametr -r
zdroj náhodných dat, a nakonec parametr -f KSK
říká, že vygenerovaný klíč bude mít v příznacích nastavený SEP (Secure Entry Point) bit, který říká, že klíč je Key Signing Key.
Alternativně lze klíče vygenerovat pomocí utility ldns-keygen:
# ldns-keygen -a RSASHA1 -b 512 -r /dev/urandom -k dnssec.cz ldns-keygen -a RSASHA1 -b 512 -r /dev/urandom dnssec.cz
Parametry -a
a -b
mají shodný význam, pouze parametr pro vygenerování KSK klíč se z -f KSK
změnil na pouhé -k
.
Oba příkazy na standardní výstup vypíší název vygenerovaného klíče ve formátu K<zona>+<alg>+<keytag> (např. Kdnssec.cz.+005+56944) a na disku vygenerují dva soubory K<zona>+<alg>+<keytag>.key a K<zona>+<alg>+<keytag>.private (soubory Kdnssec.cz.+005+56944.key a Kdnssec.cz.+005+56944.private). V souboru s příponou .key
je veřejná část klíče a v souboru s příponou .private
je část soukromá, kterou je zapotřebí chránit, a kterou budete potřebovat pro podpis zóny.
Obsah veřejné části klíče vypadá takto:
dnssec.cz. IN DNSKEY 256 3 5 AwEAA[...]8Gm0=
V případě generování pomocí ldns-keygen obsahuje navíc ještě TTL a v komentáři pak keytag, typ klíče a počet bitů:
dnssec.cz. 3600 IN DNSKEY 256 3 5 AwEAA[...]rHE= ;{id = 35181 (zsk), size = 512b}
Veřejné části všech klíčů, kterými budeme chtít podepisovat, je zapotřebí přidat do zónového souboru (z mnoha praktických důvodů je dobré mít zónový soubor pojmenovaný stejně jako zóna). Toto je možné udělat dvěma způsoby:
1. Direktivou $INCLUDE <nazev_souboru>
, tedy například:
$ cat >> dnssec.cz << EOF $INCLUDE Kdnssec.cz.+005+23163.key $INCLUDE Kdnssec.cz.+005+56944.key EOF
2. Nebo přímo přidáním obsahu těchto souborů do souboru se zónou:
cat Kdnssec.cz.+005+23163.key >> dnssec.cz cat Kdnssec.cz.+005+56944.key >> dnssec.cz
Obsah soukromé části vypadá pro algoritmus RSASHA1 (pro algoritmus DSA je obsah souboru až na první dva řádky odlišný) takto:
Private-key-format: v1.2 Algorithm: 5 (RSASHA1) Modulus: zq0CE[...]bQ== PublicExponent: AQAB PrivateExponent: clEr[...]WQ== Prime1: 6N2ob[...]RpM= Prime2: 4zVG[...]uv8= Exponent1: tqJi[...]MhE= Exponent2: 3h9I[...]LXU= Coefficient: 3Xz6[...]/1I=
Z uživatelského hlediska je obsah tohoto souboru nezajímavý a klidně by obsah mohl být binární.
Podepsání zónového souboru
Nyní máme vygenerované dva klíče připravené pro podpis zónového souboru a pravděpodobně máme i samotný zónový soubor, který chceme podepsat.
Obsah zónového souboru může vypadat například takto:
dnssec.cz. 3600 IN SOA a.ns.nic.cz. hostmaster.nic.cz. 2008101419 10800 3600 1209600 7200 www.dnssec.cz. 3600 IN AAAA 2001:1488:0:3::2 www.dnssec.cz. 3600 IN A 217.31.205.50 dnssec.cz. 3600 IN AAAA 2002:1488:0:3::2 dnssec.cz. 3600 IN A 217.31.205.50 dnssec.cz. 3600 IN NS b.ns.nic.cz. dnssec.cz. 3600 IN NS a.ns.nic.cz. dnssec.cz. 3600 IN DNSKEY 256 3 5 AwEA[...]7VE= ;{id = 40965 (zsk), size = 512b} dnssec.cz. 3600 IN DNSKEY 257 3 5 AwEAA[...]CZc= ;{id = 42307 (ksk), size = 512b}
Příkaz dnssec-signzone
má poměrně mnoho parametrů, ale v té nejjednodušší variantě ho můžeme zavolat pouze zavoláním:
# dnssec-signzone dnssec.cz
Důležité je, aby zónový soubor měl shodný název s názvem zóny, obsahoval veřejné části klíčů, kterými chceme zónu podepsat, a tyto klíče byly v aktuálním adresáři. Zavolání tohoto příkazu způsobí vygenerování nového souboru: dnssec.cz.signed
. Tento nový soubor bude obsahovat původní obsah souboru dnssec.cz a navíc bude obsahovat nově vygenerované záznamy NSEC a RRSIG pro každý RRSet:
; File written on Sun Jan 11 20:14:32 2009 ; dnssec_signzone version 9.5.0-P2 dnssec.cz. 3600 IN SOA a.ns.nic.cz. hostmaster.nic.cz. ( 2008101419 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 1209600 ; expire (2 weeks) 7200 ; minimum (2 hours) ) 3600 RRSIG SOA 5 2 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. YEkGZPifd0B3uLER9g7C/zni+j3f7RE0OKJK e6Q3rMnKtwbY6ShZjLQiQHEnvvMmARFOk2Kr FImaDil20jGY/g== ) 3600 NS a.ns.nic.cz. 3600 NS b.ns.nic.cz. 3600 RRSIG NS 5 2 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. jW5vlsY4s85s7DV5bEJYuz0CuQqwnrb8kg69 WhGy+ftvckH2aQhUWwwnlLJgatxkLmYR2k0+ SkR6Wg8ND0fkzA== ) 3600 A 217.31.205.50 3600 RRSIG A 5 2 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. YPBL0dEVelyBpTzEb/HEratPRNeaR5ncItcm nYPXLqmwmXg20KVygDU+XhYFUnj3CgcJTZMj q0Bm20keYBCOCQ== ) 3600 AAAA 2002:1488:0:3::2 3600 RRSIG AAAA 5 2 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. ibdbXaCCfstnWPKK0xzrG+Su76xMwt2zR9oh KrwfjBEYBC28i5iABwS3fa2s5FzBdAh62Y3T xqIp2pCOJGmI/w== ) 7200 NSEC www.dnssec.cz. A NS SOA AAAA RRSIG NSEC DNSKEY 7200 RRSIG NSEC 5 2 7200 20090210181432 ( 20090111181432 40965 dnssec.cz. ydJOiwN0Xj0DBLb4uIVkYlS24AiNIEAm1Ltk lXM9CaRahmPX/1jC/vw6Um9tg0XO8mlbH7yn wCUA+J6e5mARbg== ) 3600 DNSKEY 256 3 5 ( AwEAAc/dbg0TRovNLCAEEUcSJnN4kxbGulUD 6XvkLWDRV+r2i7e0JqAlWU6tOJjwF9tE17If TOnUtauBw40nazdk7VE= ) ; key id = 40965 3600 DNSKEY 257 3 5 ( AwEAAb390x3z9UOpmpiYayEsbQ1/svbboJ5L kttKljfFiMZY7T2dYQb+dLPDOkHvIjWu7ILc EUewaolsKnz4vNy3CZc= ) ; key id = 42307 3600 RRSIG DNSKEY 5 2 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. FvK7y7v2/CA91ooU4cYKgN4sXQF/yFYhbZP+ eCPEwKEnBSddziNqfV65j7mtesXdDUHMIqkZ e1IuhpfijCmmrA== ) 3600 RRSIG DNSKEY 5 2 3600 20090210181432 ( 20090111181432 42307 dnssec.cz. cGBcC2ctsU42um1oAOuqowTJ9KbbhbZUVhoL RSAP0kQRfY6VUt/WpRHDAthC9km2oEJCBolN 9mZB3B9l951iRA== ) www.dnssec.cz. 3600 IN A 217.31.205.50 3600 RRSIG A 5 3 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. Urb1gJ7fnwvRFz064jfgccmACrG/CX9o5Y4f ga/97WufyLFwxmPPxn5PLCSQAf1PzFkkP7Sb NMU1jX4/EPpISA== ) 3600 AAAA 2001:1488:0:3::2 3600 RRSIG AAAA 5 3 3600 20090210181432 ( 20090111181432 40965 dnssec.cz. JjcqL5SYD6vGJuMXP0BQIzA5rRAfggd0sXT7 tElex1xZyx3tJ8euBeTdx0szX4CA0TCWhntF AsKshOCfOw++cw== ) 7200 NSEC dnssec.cz. A AAAA RRSIG NSEC 7200 RRSIG NSEC 5 3 7200 20090210181432 ( 20090111181432 40965 dnssec.cz. QElCh1q5zY1MIzwMpqnEpJ9k+fleQncCTbw4 XJn2xtkKAWZhEr2nx9JABO8MWF1deMuWSaFP qAQRgEchw/43yA== )
Nyní si uveďme trochu maximalističtější variantu tohoto příkazu (argumenty jednotlivých parametrů jsou zároveň standardní hodnoty):
# dnssec-signzone -s +-3600 -e +2592000 -o dnssec.cz -f dnssec.cz.signed \ -r /dev/urandom -a -k Kdnssec.cz.+005+42307.key -N keep dnssec.cz \ Kdnssec.cz.+005+40965.key
Parametry -s
a -e
určují datum platnosti nově vygenerovaných podpisů a jejich argumenty můžou být buď absolutní ve formátu YYYYMMDDhhmmss nebo relativní se znakem + na začátku, parametr -o
určuje název (origin) podepisované zóny, parametr -f
určuje název výstupního souboru, parametr -r /dev/urandom
jsme již používali při generování klíčů, parametr -a
ověřuje platnost nově vygenerovaných podpisů. Důležitý je parametr -k Kdnssec.cz.+005+42307.key
, který určuje KSK klíč, který má být použit pro podpis DNSKEY záznamů (v případě, že zónový soubor obsahuje více KSK klíčů).
Další zajímavý a užitečný parametr je -N keep
, který určuje jaký formát má mít sériové číslo výstupního souboru. Kromě keep lze použít argument increment, který sériové číslo zvýší, nebo unixtime, který ho nastaví na aktuální unixový čas (počet sekund od začátku roku 1970). Oba dvě tyto alternativní volby se snaží předcházet problému, kdy je zóna považována za nezměněnou ve chvíli, kdy nedojde ke zvýšení sériového čísla. Následuje už jenom původní podepisovaný zónový soubor a teprve po něm jsou vypsané všechny ZSK klíče, které budou použity pro podpis všech RR záznamů v zónovém souboru.
Ekvivalent tohoto příkazu z balíku ldns vypadá takto:
# ldns-signzone -i 20090111193000 -e 20090110192959 -f dnssec.cz.signed \ -o dnssec.cz dnssec.cz Kdnssec.cz.+005+42307 Kdnssec.cz.+005+40965
Příkazy jsou hodně podobné, jen u začátku ( -i
) a konce ( -e
) platnosti vygenerovaných podpisů nelze použít relativní formát. Nástroj ldns-signzone
také neumí manipulovat se sériovým číslem. KSK a ZSK klíče není potřeba na příkazovém řádku rozlišovat, dojde k automatické selekci dle nastaveného SEP bitu (256 vs. 257 v příznacích klíče).
Všimněte si, že výsledný soubor obsahuje jeden RRSIG záznam pro každý RRSet kromě RRSetu pro DNSKEY záznamy. Ten má podpisy dva – jeden podpis je pomocí KSK klíče a druhý pomocí ZSK klíče.
Použití podepsaného zónového souboru
Nyní máme vygenerovaný podepsaný zónový soubor. Co s ním? Aby mohl váš DNS server začít vracet podpisy pro dotazy, které mají nastavený DNSSEC OK (DO) příznak, musíte změnit název souboru v konfiguraci. Pro DNS server Bind je zapotřebí změnit direktivu:
zone "dnssec.cz" { type "master"; file "dnssec.cz"; };
na
zone "dnssec.cz" { type "master"; file "dnssec.cz.signed"; };
A novou konfiguraci načíst pomocí příkazu rndc reload. Po kontrole log souborů, že všechno proběhlo v pořádku, si můžete pogratulovat – právě jste začali poskytovat svou první DNSSEC podepsanou zónu.
Dnešní díl na tomto místě končí. V příštím díle si povíme něco o tom, jak se o podepsané domény starat.
Autor je technickým ředitelem sdružení CZ.NIC.