Od vydání finální verze Knot DNS 2.0 uplynulo již několik týdnů. Dokud je to stále aktuální, rád bych sepsal, co nás vedlo k vydání této nové důležité verze, a shrnul nejdůležitější změny a novinky.

Vydání finální verze Knot DNS 2.0 trvalo déle, než jsme čekali, ale věříme, že všechna zdržení byla nezbytná pro doladění konečné podoby serveru. Když jsme měnili formát konfiguračního souboru, chtěli jsme si být jistí, že nové koncepty jsou skutečně použitelné, abychom se v blízké budoucnosti vyhnuli zbytečným a nekompatibilním změnám.

V tuto chvíli máme dvě stabilní verze Knot DNS: dlouhodobě podporovanou verzi 1.6, u které budeme pouze opravovat chyby a provádět drobná vylepšení, a verzi 2.0, ve které se odehrává všechen nový vývoj. Důvodem je, že máme celkem dost uživatelů, kteří jsou už v tuto chvíli spokojeni s Knot DNS co se týče podporovaných funkcí. Existují ovšem i další uživatelé hledající řešení pro problémy, které v současnosti mají s provozováním DNS serverů. V neposlední řadě chceme také realizovat vlastní nápady. Všechny tyto požadavky zkrátka nebylo možné sjednotit.

Knot DNS 2.0 přináší dvě velké změny, které slouží jako základ pro nové funkce plánované do budoucna. Jsou to nový formát konfigurace a nová implementace DNSSEC.

Nová konfigurace

Asi nejviditelnější změnou v Knot DNS 2.0 je odlišný formát konfiguračního souboru. Přešli jsme z našeho vlastního formátu konfigurace na YAML (ve skutečnosti se jedná o zjednodušený YAML, který časem rozšíříme). Starý formát byl těžkopádný a často nekonzistentní. A také jsme chtěli změnit některé koncepty.

Změny se netýkají jenom formátu – pod kapotou se toho také hodně změnilo. Naším cílem je vytvořit konfigurační rozhraní, které by umožňovalo dotazovat a měnit konfiguraci serveru za běhu. Doufáme, že to usnadní život velkým operátorům. Server se bude spouštět rychleji a bude možné například okamžitě přidávat nebo odstraňovat jednotlivé zóny bez nutnosti provést úplný reload serveru. V Knot DNS 1.6 je reload serveru časově velmi náročná operace pokud server obsluhuje miliony zón. Někdy v budoucnu také chceme použít toto konfigurační rozhraní pro remote server provisioning.

Z technického hlediska se nyní používá LMDB databáze namísto uchovávání aktuální konfigurace v paměti. Databáze se vytvoří při spuštění serveru a při ukončení běhu serveru zanikne. V budoucnu bude možné databázi zachovat i při vypnutí serveru a textový formát se bude používat pouze pro import a export konfigurace. Chceme však, aby celý proces byl průhledný i pro uživatele, kteří se budou chtít držet textového formát a kteří výhody dynamické konfigurace neocení.

Nová konfigurace: Šablony

Šablony jsou něco, o co nás uživatelé často žádali a co se velmi podobá patterns v NSD. Šablony umožňují sdílet společnou konfiguraci mezi více zónami. Změna šablony se odrazí ve všech zónách, které tuto šablonu využívají, ale všechny parametry z šablony je možné v zóně přepsat. (Stojí za to zmínit, že se jedná pouze o konfiguraci, nikoli obsah zón.)

Ukažme si použití šablon na příkladu:

template:
  - id: default
    storage: /var/lib/knot
    acl: [ ddns_update ]
  - id: slave
    storage: /var/lib/knot/slaved
    master: [ ns-a ]
    acl: [ notify_from_master ]

zone:
  - domain: knot-dns.cz
  - domain: labs.nic.cz
  - domain: dnssec.cz
  - domain: nic.cz
    template: slave
  - domain: unsigned.cz
    template: slave
    master: [ ns-a, ns-b ]

V tomto příkladu konfigurujeme dvě skupiny zón představované šablonami. Pro první skupinu zón se náš server chová jako master a na těchto zónách povolujeme pouze dynamické aktualizace. Pro druhou skupinu zón se server chová jako slave a stahuje zóny z jiného master serveru. Pro tuto skupinu zón jsou také povoleny příchozí notify zprávy. Všimněte si, že seznam master serverů ze šablony je u poslední zóny přepsán.

Nová konfigurace: Vzdálené servery a oprávnění

Pokud jde o konfigurační koncepty, změnili jsme některé věci týkající se definicí vzdálených serverů (remotes) a opravnění (ACL). V Knot DNS 1.6 nebyl vzdálený server v podstatě nic víc než pojmenovaný cíl pro připojení – IP adresa s portem a případně TSIG klíč. Později jsme přidali skupiny serverů (groups). Skupina jen seskupuje definici více vzdálených serverů a se všemi servery ve skupině se zachází samostatně. V Knot 2.0 jsme umožnili pro jeden vzdálený server zadat více IP adres a sémanticky se k jednomu vzdálenému serveru chováme jako k jedinému serveru. Když se tedy vytváří spojení k serveru, nepřipojujeme se ke všem jeho adresám. Použijeme první adresu z definice serveru a když se připojení nezdaří, použije se další adresa, a tak dále.

Dalším rozdílem je, že verze 1.6 používala definici vzdálených serverů i pro nastavení povolených operací na zóně (např. odchozí přenos zóny). Verze 2.0 k tomu používá ACL. V našem případě je definicí ACL prostě sada povolených IP adres, TSIG klíčů a typ operace. Definované ACL se později přiřadí jednotlivým zónám.

Podívejme se, jak jsou vzdálené servery a oprávnění definovány v Knot DNS 2.0:

server:
    listen: ::@53

key:
  - id: masters
    algorithm: hmac-sha256
    secret: QWggZnJlZGRsZWQgZ3J1bnRidWdnbHk=
  - id: operator
    algorithm: hmac-sha256
    secret: VGh5IG1pY3R1cmF0aW9ucyBhcmUgdG8gbWU=

remote:
  - id: ns-a
    address: [ 2001:db8::1, 192.0.2.1 ]
    key: masters
  - id: ns-b
    address: [ 2001:db8::2, 192.0.2.2 ]
    key: masters

acl:
  - id: notify_from_master
    address: [ 2001:db8::/120, 192.0.2.0/24 ]
    key: masters
    action: notify
  - id: ddns_update
    key: operator
    action: update

Tento příklad ukazuje definici dvou vzdálených serverů. Oba servery se nacházejí v dual stack IP síti. Upřednostňována je IPv6 adresa, protože je na seznamu adres uvedena jako první. Následuje definice dvou pravidel ACL. První pravidlo povoluje příchozí upozornění na změnu zóny z adresního rozsahu, jehož součástí jsou oba servery. Druhé pravidlo povoluje dynamické aktualizace podepsané klíčem operátora. Všimněte si, že ACL zatím nejsou přiřazeny žádným zónám.

DNSSEC založený na KASP

Další významnou novinkou v Knot DNS 2.0 je počáteční podpora DNSSECu založeného na KASP. Myšlenka je taková, že místo generování klíčů pro podepisování a ručního provádění všech výměn klíčů jsou definována pravidla podepisování. Pravidla určují, jak má být zóna podepsána, tj. který algoritmus má být použit, jaká je požadovaná velikost klíče, délka života klíče, délka platnosti podpisu apod. V tuto chvíli je podpora KASP omezena na vygenerování počátečních podpisových klíčů a výměnu ZSK klíče, ale v budoucnu budou přidány další funkce.
V Knot DNS ukládáme informace o podepisování v takzvané KASP databázi. V tuto chvíli není tato databáze nic jiného než adresář na souborovém systému s pár soubory uvnitř. Pro správu databáze KASP se používá utilita keymgr.

Podívejme se, jak to fungujme a povšimněme si přitom syntaxe příkazů:

$ # Inicializace nové KASP databáze
$ cd /var/lib/knot/kasp
$ keymgr init
$ # Definování testovací politiky s názvem 'lab'
$ keymgr policy add lab algorithm ecdsap256sha256 ksk-size 256 zsk-size 256

Stav podepsání je rovněž uložen v databázi KASP. Každá zóna, která má být podepsána, potřebuje svůj vlastní záznam. Ten se přidává následovně:

$ keymgr zone add knot-dns.cz policy lab

Poslední, co je třeba udělat, je povolit podepisování zónu v konfiguraci serveru:

zone:
  - domain: knot-dns.cz
    dnssec-signing: true

Hotovo. Spustíme server a můžeme se podívat se do logu:

[knot-dns.cz] zone will be loaded, serial 0
[knot-dns.cz] DNSSEC, executing event 'generate initial keys'
[knot-dns.cz] DNSSEC, loaded key, tag 33007, algorithm 13, KSK yes, ZSK no, public yes, active yes
[knot-dns.cz] DNSSEC, loaded key, tag 54399, algorithm 13, KSK no, ZSK yes, public yes, active yes
[knot-dns.cz] DNSSEC, signing started
[knot-dns.cz] DNSSEC, successfully signed
[knot-dns.cz] DNSSEC, next signing on 2015-07-30T00:40:45
[knot-dns.cz] loaded, serial 0 -> 42

Tento proces samozřejmě počítá s tím, že zóna nebyla před první podepsáním zabezpečená. Dále je potřeba publikovat DS záznam v nadřazené zóně pro vygenerovaný a použitý KSK. Současná verze keymgr nepodporuje export veřejného klíče jako DS záznamu. Je však možné místo toho použít ldns drill:

# drill @::1 -s knot-dns.cz DNSKEY
...
; equivalent DS records for key 33007:
; sha1: knot-dns.cz.	10	IN	DS	33007 8 1 ...
; sha256: knot-dns.cz.	10	IN	DS	33007 8 2 ...

To je vše, co je potřeba k automatizovanému podepsání zóny. Stále je však možné provádět podepisování postaru jako v Knot DNS 1.6 nebo BIND. Pro ilustraci přidáme další zónu bez politiky a ručně vygenerujeme jeden klíč pro Single-Type Signing:

$ # Vytvoření záznamu bez přiřazení politiky
$ keymgr zone add dnssec.cz policy none
$ # Vygenerování klíče
$ keymgr zone key generate dnssec.cz algorithm ecdsap256sha256 size 256
id 503ff2c3c945c685c3b4eab3ef00c23a42f7f193 keytag 53630

Poměrně jednoduše můžeme naplánovat i výměnu klíče kolem specifického data:

$ # Nastavení konce života starého klíče
$ keymgr zone key set dnssec.cz 503ff2c3 retire 20150801 remove 20150801
$ # Vygenerování nového klíče, který nahradí klíč starý
$ keymgr zone key generate dnssec.cz algo 13 size 256 publish 20150731 active 20150801

Podrobnosti o podepisování najdete v dokumentaci nebo v manuálové stránce keymgr.

Plány do budoucna

Co se týká konfigurace, máme v plánu přidat knotc příkazy pro dotazování a změny konfigurace běžícího serveru. Zároveň bychom chtěli zavést lepší konfigurační protokol, který bude použit jako základ pro remote provisioning. V DNSSEC chceme dodělat celou řadu věcí: KASP postrádá podporu pro Single-Type Signing, výměnu KSK klíčů a výměnu salt u NSEC3. Dále chceme doladit keymgr utilitu. Také pracujeme na modulu pro online podepisování (užitečné v kombinaci s moduly syntetizující odpovědi), na modulu pro GeoIP a na modulu pro statistiky. A v neposlední řadě chceme zpracovat na celkovém výkonu serveru.

Je skvělé, že se vám podařilo dočíst se až sem. Těšíme se na vaší postřehy, připomínky a dotazy.

Autor: Jan Včelák