Podpora automatického DNSSEC podepisování byla v serveru BIND přitomna již dříve, bylo ale vždy nutné přepnout zónu do dynamického režimu, což s sebou mohlo nést některé problémy. Ve verzi 9.9 se ale poprvé objevila funkce zvaná inline signing, která umožňuje zapnout podepisování a přitom zachovat původní zónové soubory beze změn.
Výchozí situace
Nasazení si prakticky předvedeme na Debianu Jessie, který obsahuje balíček bind9 ve verzi 9.9.5. Přepokládejme, že server slouží jako autoritativní server pro zónu example.com, která používá obyčejný textový zónový soubor umístěný v /etc/bind/example.com. V konfiguračním souboru /etc/bind/named.conf.local je pak následující definice zóny:
zone "example.com" {
type master;
file "/etc/bind/example.com";
}; Krok 0: dostatek entropie
Ještě než začneme zónu podepisovat, je dobré se ujistit, že systém bude mít k dispozici dostatek entropie, aby mohl generovat náhodná čísla skutečně náhodně. Všechny dále zmíněné nástroje používají jako zdroj náhodných čísel zařízení /dev/random, které při nedostatku entropie proces vytváření klíčů nebo podpisů blokuje až do chvíle, kdy entropie naroste zpět. Množství dat, které zařízení /dev/random vyrábí, můžeme ověřit nástrojem pv, který vypisuje každou sekundu počet bajtů, které protekly rourou:
# pv -nb /dev/random > /dev/null
192
192
192
^C Opakující se hodnota značí vyčerpanou zásobu entropie. Ve většině případů si můžeme pomoci instalací démona haveged, který získává další entropii z nejrůznějších vnitřních stavů procesoru:
# apt-get install haveged
# pv -nb /dev/random > /dev/null
1586646
3219499
4800458
^C Krok 1: vygenerujeme klíč
Automatické podepisování v BINDu dokáže generovat a obnovovat podpisy, klíče je však třeba generovat a případně měnit ručně. Abychom snížili míru ruční práce na minimum, použijeme k podpisu zóny pouze jediný klíč s algoritmem ECDSA P-256 a hashovací funkcí SHA256. Síla tohoto algoritmu by měla být větší než síla RSA klíče o délce 2048 bitů, takže jej není nutné vyměňovat dříve než za několik let. Zároveň jsou podpisy tímto algoritmem tak krátké, že si můžeme dovolit použít jej k podepisování každého záznamu zónového souboru.
# mkdir /etc/bind/keys
# cd /etc/bind/keys
# dnssec-keygen -a ECDSAP256SHA256 -fK example.com
Generating key pair.
Kexample.com.+013+32462
# chmod g+r K*.private V adresáři /etc/bind/keys vzniknou soubory s veřejným i privátním klíčem. Druhý jmenovaný má nastavena práva na 0600, takže je čitelný a zapisovatelný jen pro vlastníka, což je uživatel root. Aby jej mohl použít BIND k podepisování, je třeba práva upravit tak, aby daný soubor mohl číst. Tuto úpravu je třeba opakovat po každém generování klíče.
Krok 2: aktivace inline signingu
Nyní je již vše připraveno k aktivaci podepisování. Přitom se BIND pokusí vedle zónového souboru vytvořit soubory se žurnálem a s podepsanou verzí zóny. Je-li zónový soubor v /etc, toto se nepovede kvůli nedostatečnému oprávnění. Navíc z praktických důvodů není vhodné, aby se v konfiguračním adresáři objevovaly soubory automaticky generované a spravované. Vhodným řešením je přesunutí cesty k zónovému souboru z /etc do provozního adresáře /var/cache/bind, kam má BIND právo zapisovat. Vytvoříme tedy symbolický odkaz na zónový soubor:
# ln -s /etc/bind/example.com /var/cache/bind Nyní již můžeme aktivovat podepisování úpravou konfigurace:
zone "example.com" {
type master;
file "example.com";
inline-signing yes;
auto-dnssec maintain;
key-directory "/etc/bind/keys";
}; Po reloadu příkazem rndc reload by mělo dojít během několika okamžiků k podepsání zóny. Průběh můžeme sledovat pomocí:
# rndc signing -list example.com
Done signing with key 32462/ECDSAP256SHA256 Standardně je podepisováno v režimu NSEC, kdy jsou všechna jména v zónovém souboru provázána a je tedy možné postupným dotazováním zjistit všechna existující jména. Pro situace, kde je toto problém, je možné přejít na hashované záznamy NSEC3:
# rndc signing -nsec3param 1 0 10 deadbeef example.com Číselné parametry určují postupně hashovací algoritmus NSEC3 (jediný definovaný je 1 – SHA256), flagy (žádné), počet iterací hashování (10 je rozumná hodnota) a konečně sůl, která zabraňuje použítí tzv. rainbow tabulek. Jde o libovolné šestnáctkové číslo dlouhé až 255 bytů. Důrazně zde doporučuji odolat pokušení k použití zprofanovaných slov jako cafebabe, deadbeef nebo faceb00c.
Podepsaná zóna je uložena v provozním adresáři v souboru s příponou .signed. Kromě toho se v daném adresáři ještě nachází žurnálový soubor sledující změny v původním nepodepsaném souboru a žurnálový soubor podepsaného souboru. Podepsaný soubor je v surovém formátu, pokud jej chceme prozkoumat, je třeba použít utilitu named-compilezone:
# named-compilezone -f raw -j -o - example.com /var/cache/bind/example.com.signed
zone example.com/IN: loaded serial 9 (DNSSEC signed)
example.com. 60 IN SOA ns.example.com. hostmaster.example.com. 9 120 10 3600 60
…
OK Změny DNS dat provádíme stejně jako před zavedením DNSSECu – editací nepodepsaného zónového souboru a reloadem serveru. Důležité je při každé změně zvýšit sériové číslo zóny v SOA záznamu, jinak ji BIND odmítne načíst. Sériové číslo podepsané zóny sleduje číslo nepodepsané zóny, automaticky je ale zvyšováno při obnovování podpisů nebo manipulaci s klíči.
Krok 3: sdělení nadřazené zóně
Posledním krokem k vytvoření řetěžu důvěry je umístění otisku klíče do nadřazené zóny. K tomu slouží utilitka dnssec-dsfromkey:
# dnssec-dsfromkey /etc/bind/keys/Kexample.com.+013+32462
example.com. IN DS 32462 13 1 5E6C8…9D20C8
example.com. IN DS 32462 13 2 AB779…8A9001875886A0FF9170A2579AC9E1AB Vygenerované otisky se liší pouze algoritmem hashovací funkce, která je u kratšího SHA1, u delšího SHA256. Není třeba umisťovat do nadřazené zóny oba, zcela postačuje ten druhý, bezpečnější.
Speciálním případem jsou registry domén .cz a .eu. Tyto registry nepřijímají DS záznamy, ale rovnou celé veřejné klíče. Důvod je ten, že DS záznam je otiskem jak veřejného klíče, tak i doménového jména. Registry .cz a .eu pracují s tzv. keysety, které mohou být přiřazeny k většímu množství doménových jmen. Příslušné DS záznamy si pak registr vyrobí sám. Pro nás je důležité, že do keysetu vkládáme přímo obsah souboru s veřejným klíčem.
Krok 4: výměna klíče
Ačkoli je klíč daného algoritmu dostatečně silný, může nastat časem potřeba klíč vyměnit. Ani to není příliš obtížné, byť jistá ruční práce je vyžadována. Nejprve vygenerujeme nový klíč stejně jako v kroku 1 a sdělíme BINDu, že jej má používat:
# cd /etc/bind/keys/
# dnssec-keygen -a ECDSAP256SHA256 -fK example.com
Generating key pair.
Kexample.com.+013+11957
# chmod g+r *.private
# rndc sign example.com V tuto chvíli jsou aktivní oba klíče a můžeme tedy změnit DS záznam v nadřazené zóně tak, aby mířil na nový klíč. Po určité době, kdy se změna projeví a starý klíč se stane nepotřebným, můžeme naplánovat jeho deaktivaci (přestane být používán k vytváření podpisů) a poté jeho odstranění ze zóny:
# cd /etc/bind/keys
# dnssec-settime -I now -D +35d Kexample.com.+013+32462
dnssec-settime: warning: Permissions on the file
./Kexample.com.+013+32462.private have changed from 0640 to 0600 as a result of this operation.
./Kexample.com.+013+32462.key
./Kexample.com.+013+32462.private
# chmod g+r *.private
# rndc sign example.com Tímto je starý klíč okamžitě deaktivován a zcela odstraněn po 35 dnech – v této době by už zaručeně měly být všechny podpisy přegenerovány a klíč tedy bude bezpečné odebrat. To proběhne automaticky; BIND totiž adresář s klíči pravidelně kontroluje a s klíči nakládá podle časovacích metadat.
Závěrem
Podpora automatického podepisování s inline signingem umožňuje nasadit DNSSEC všude tam, kde je používán BIND. Nedochází zde k žádnému zásahu ani na straně vstupu, kde je obsluha stejná jako dříve, stejně jako není potřeba nijak upravovat případné slave servery, tedy za předpokladu, že používají přiměřeně aktuální software. Použití algoritmu ECDSA a jediného klíče celý postup zjednodušuje tak, že prakticky není potřeba věnovat žádnou péči navíc.
