Předchozí stav
Co se dozvíte v článku
Před lety vyšel na Rootu článek DNSSEC s BIND 9.9 snadno a rychle, ve kterém jsme popisovali nový způsob podepisování DNS zóny pomocí takzvaného inline signingu, který umožňuje zapnout podepisování a přitom zachovat původní zónové soubory beze změn.
Původní způsob byl poloautomatický a umožňoval sice generovat a udržovat podpisy, ale správa klíčů byla ponechána na uživateli. Bylo tedy potřeba provést několik kroků, než bylo možné zapnout vytvoření podepsané kopie zóny pomocí volby auto-dnssec maintain.
Tato volba je už nějakou dobu označena za zastaralou, protože obnovuje jen podpisy, zatímco klíče je třeba měnit ručně. BIND přitom už nějakou dobu umí plně automatickou správu DNSSEC, včetně klíčů, podobně jako třeba Knot DNS.
Pozor na to, že počínaje verzí 9.20 je původní způsob konfigurace nefunkční a pokud jste před lety konfigurovali svůj BIND původním způsobem s volbou auto-dnssec, po aktualizaci už se nerozeběhne. Dříve či později tedy budeme muset provést úpravy popsané v tomto článku. Je lepší to udělat hned, protože verze 9.16 a 9.18 podporují oba přístupy, takže se změnou připravíte na budoucnost.
Automatický DNSSEC
Nová metoda konfigurace se nazývá Key and Signing Policy (KASP) a popisuje, jak se mají spravovat klíče a jak má probíhat podepisování zóny. Je to vymyšleno tak, že pro většinu běžných situací by měla být vhodná výchozí politika default, která nabízí aktuální doporučované postupy pro práci s DNSSEC. Později si ukážeme, jak politika vypadá uvnitř a jak si můžeme vytvořit vlastní.
Prvním krokem po instalaci je vytvoření zónového souboru. V souboru /etc/bind/named.conf.options je nastavená volba directory, která ukazuje na pracovní adresář. Pokud v konfiguraci uvedeme relativní jméno souboru, bude soubor hledán právě v tomto adresáři. Volba je po instalaci nastavena na /var/cache/bind, což je pro BIND zapisovatelný adresář.
# ls -ld /var/cache/bind drwxrwxr-x 2 root bind 5 Apr 24 11:35 /var/cache/bind
To je okolnost velmi důležitá, protože BIND si sem později bude zapisovat různé soubory, včetně kopie naší zóny doplněné o záznamy s podpisy. Do adresáře tedy musí mít právo zápisu, jinak celý proces selže. Není ale rozumné přímo v tomto adresáři udržovat ručně editované soubory, protože o ně můžeme přijít.
Proto si v /etc/ vytvoříme adresář zones, kde budeme pracovat. Z /var/cache/bind/ si pak uděláme symbolický odkaz. Hned si také vytvoříme první zónový soubor a zapíšeme do něj záznamy:
# mkdir /etc/bind/zones/
# vim /etc/bind/zones/example.com.db
$ORIGIN example.com.
$TTL 60
@ IN SOA example.com. hostmaster (
1 ; serial
120 ; refresh (2 minutes)
10 ; retry (10 seconds)
3600 ; expire (1 hour)
60 ; minimum (1 minute)
)
@ NS ns.example.com.
@ A 192.0.2.1
@ AAAA 2001:0db8::1
Obsah tohoto souboru zůstane v naší správě a BIND do něj nebude zasahovat. To je hlavní výhoda inline signingu, kdy se nám automaticky spravované podpisy nemíchají do lidsky čitelného a jednoduchého zónového souboru.
Nezapomeneme soubor nalinkovat do pracovního adresáře:
# ln -s /etc/bind/zones/example.com.db /var/cache/bind/example.com.db
Nyní si přidáme novou zónu do konfigurace autoritativního DNS serveru. Připíšeme ji na konec souboru /etc/bind/named.conf.local.
# vim /etc/bind/named.conf.local
zone "example.com" {
type primary;
file "example.com.db";
dnssec-policy default;
inline-signing yes;
};
Volby říkají, že jde o primární autoritativní zónu (master), nachází se v souboru daného jména, chceme aplikovat výchozí politiku a chceme strojově pracovat s kopií zóny. Nyní požádáme server, aby si znovu načetl upravený konfigurační soubor:
# rndc reload
Co se událo
Po restartu se můžete podívat do pracovního adresáře /var/cache/bind/, ve kterém přibyla řada souborů, jejichž názvy vycházejí z původního názvu našeho zónového souboru. Je tu soukromý klíč (přípona .private), stavové informace k tomuto klíči ( .state), žurnál ( .jnl) a především soubor s příponou .signed, který obsahuje kopii zóny včetně automaticky doplněných podpisů.
Do tohoto souboru se můžeme podívat, ale budeme potřebovat utilitu named-compilezone, která nám surová data interpretuje a vypíše v čitelné podobě.
# named-compilezone -f raw -j -o - example.com /var/cache/bind/example.com.db.signed zone example.com/IN: loaded serial 4 (DNSSEC signed) example.com. 60 IN SOA example.com. hostmaster.example.com. 4 120 10 3600 60 example.com. 60 IN RRSIG SOA 13 3 60 20240508094858 20240424084858 48071 example.com. PulAb4FsFygUajpDPJqiEAcT93sUOFYS5LToErfqsm/uF3yafqP6sPsX YtZkei4I01OrZJc0UVpTTCZQWMPVEg== ; resign=20240508094858 example.com. 60 IN NS ns.example.com. …(zkráceno)
Na aktuální stav podepisování se můžeme kdykoliv zeptat ovládací utilitou rndc:
# rndc dnssec -status example.com. dnssec-policy: default current time: Wed Apr 24 12:00:52 2024 key: 48071 (ECDSAP256SHA256), CSK published: yes - since Wed Apr 24 11:48:58 2024 key signing: yes - since Wed Apr 24 11:48:58 2024 zone signing: yes - since Wed Apr 24 11:48:58 2024 No rollover scheduled - goal: omnipresent - dnskey: rumoured - ds: hidden - zone rrsig: rumoured - key rrsig: rumoured
Bezpečná delegace z nadřazené zóny
Nakonec je potřeba přidat DS záznam s otiskem veřejného klíče do nadřazené zóny. BIND sám generuje záznamy typu CDS/CDNSKEY, které dovolují celý proces automatizovat. Ty se v zóně objeví až po určité době, kdy je jistota, že všechny kešující resolvery mají aktuální verzi zóny.
V případě, že nadřazená zóna automatickou správu podporuje (například jako .CZ), není potřeba u registrátora domény nic měnit a registr se informaci o podepsání zóny dozví sám a po sedmi dnech přidá otisky klíčů v záznamu typu DS do nadřazené zóny.
V případě, že automatizovaný postup provozovatel nadřazené zóny nepodporuje, můžeme příslušný otisk získat přímo na serveru pomocí utility dnssec-dsfromkey.
# cd /var/cache/bind/ # dnssec-dsfromkey -2 Kexample.com.+013+27231 example.com. IN DS 27231 13 2 B4012D35909E7757A622EC72D63365C4F09DD25EEE50C01DF870F7F3DF283962
Použitá politika
BIND se při své práci s podpisy a klíči řídí takzvanou politikou. To je seznam konfiguračních pravidel, která se vztahují na různé vlastnosti a parametry důležité pro DNSSEC. My nyní používáme výchozí politiku (default), takže ji nemusíme definovat. Můžeme se ale podívat na to, jak vypadá.
Není součástí běžných konfiguračních souborů, ale najdeme ji ve zdrojových kódech serveru BIND. Autoři mají v plánu ji upravovat podle aktuálních bezpečnostních trendů.
dnssec-policy "default" {
// Klíče
offline-ksk no;
keys {
csk key-directory lifetime unlimited algorithm 13;
};
// Časování klíčů
cdnskey yes;
cds-digest-types { 2; };
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
purge-keys P90D;
// Časování podpisů
signatures-jitter 12h;
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
// Parametry zóny
inline-signing yes;
max-zone-ttl 86400;
zone-propagation-delay 300;
// Parametry rodičovské zóny
parent-ds-ttl 86400;
parent-propagation-delay 1h;
};
Výchozí politika používá jediný klíč typu ECDSA, který má neomezenou životnost. Většina parametrů má rozumné hodnoty, ale je potřeba dát pozor na způsob podepisování negativních odpovědí pomocí záznamu typu NSEC. Ten umožňuje klientovi projít postupně všechny položky v zónovém souboru, i při vypnuté podpoře přenosu zón.
Je-li to pro nás problém, můžeme přejít na záznamy typu NSEC3. Lze proto napsat vlastní politiku, která nechá většinu voleb v původním stavu a upraví jen to nejnutnější. Do konfiguračního souboru pak připíšeme něco jako:
dnssec-policy "nsec3" {
nsec3param iterations 1 optout false salt-length 16;
};
Všechny parametry za klíčovým slovem nsec3param jsou nepovinné. Pokud je vynecháme, použijí se výchozí hodnoty.
Přechod z původního řešení pro BIND 9.9
Pokud jste před lety nastavili BIND podle našeho článku, bude přechod na nové řešení celkem snadný. Původní řešení použilo taktéž jediný klíč typu ECDSA, stejně jako to předepisuje výchozí politika. Pokud je při aktivaci nového řešení zóna podepsána kompatibilním klíčem, bude tento klíč používán i nadále.
Pokud však používáte jinou konfiguraci klíčů (například RSA nebo dva samostatné klíče KSK/ZSK), je třeba upravit výchozí politiku tak, aby odpovídala tomuto stavu. V opačném případě BIND nekompatibilní klíče zahodí a nahradí jinými. To by způsobilo rozpad řetězce důvěry a tedy nefunkčnost zóny.
Stačí tedy upravit konfigurační soubor, konkrétně dvě volby: cestu k adresáři s klíči a pak samotný způsob správy DNSSEC. Klíče byly původně uloženy v /etc/bind/keys/, kam ale BIND nemůže zapisovat. My tedy klíče přesuneme do pracovního adresáře /var/cache/bind/ a změníme jim vlastníka a skupinu na bind.
# mv /etc/bind/keys/Kexample.com* /var/cache/bind/ # chown bind: /var/cache/bind/Kexample.com*
Dále upravíme zmíněné volby v konfiguraci:
zone "example.com" {
type master;
file "example.com";
inline-signing yes;
auto-dnssec maintain;
key-directory "/etc/bind/keys";
dnssec-policy default;
key-directory "/var/cache/bind";
};
Po provedení změn řekneme DNS serveru, aby načetl znovu konfiguraci:
# rndc reload
V logu pro jistotu zkontrolujme, že si server na nic nestěžuje.
# journalctl -eu named
Můžeme se také podívat na stav podepisování a tím zároveň ověřit, že jsme u dané zóny přešli na nový způsob správy.
# rndc dnssec -status example.com
Po určité době, dané časovacími parametry politiky, začne BIND vystavovat CDS a CDNSKEY záznamy signalizující nadřazené zóně, že aktuálně používaný klíč má být použit pro vytvoření DS záznamu. Protože tento klíč už v nadřazené zóně je, nedojde k žádné změně. Nicméně v případě, že nadřazenou zónou je doména CZ, způsobí přítomnost CDNSKEY záznamu přechod na automatickou správu keysetů. Registr tedy od domény odpojí původní manuálně konfigurovaný keyset a připojí k doméně nový, automaticky generovaný, se stejným obsahem.
Tím je migrace hotová bez výpadku, protože jsme nezměnili algoritmus a počet klíčů. V každém případě je vhodné celý postup ověřit na testovací zóně a při migraci ostré zóny být připraven odstranit DS záznamy z nadřazené zóny, pokud by se objevily nečekané komplikace.
