Open-source implementace autoritativního DNS serveru Knot DNS vyšla ve verzi 3.0. Navzdory kulatému číslu se na dosavadní funkcionalitě software nic nemění: novinek je sice o něco více než v běžné desetinkové verzi 2.9, ale jde převážně o featury, které když uživatel nezapne, bude vše fungovat jako u předchozích verzí. Migrace je tudíž jednoduchá.
XDP
Když je potřeba maximální výkon při odpovídání (hlavně jako obrana proti pokusům o zahlcení), je docela velkou brzdou zpracování packetů kernelem. V případech, kdy jádro systému není zároveň využíváno k routování, firewallování či sledování provozu, je výhodnější ho (platí pro moderní verze Linuxu) úplně obejít a předávat packety ze síťové karty rovnou do DNS démona. Tato technologie se jmenuje eXpress Data Path a její implementací v Knot DNS naroste výkon odpovídání DNS přes UDP o desítky procent. Ostatní provoz (DNS přes TCP, správa přes SSH, …) je tím nedotčen a projde kernelem jako obyčejně.
Příklad:
listen-xdp: ens2f0@53
Tento řádek v konfiguraci zapne odpovídání přes XDP na všechny UDP packety s cílovým portem 53, přicházející na rozhraní ens2f0, bez ohledu na cílovou IP adresu. Packet s odpovědí je poslán zpět stejnou cestou, tj. jsou u něj prohozeny zdrojové a cílové IP, respektive MAC adresy.
Katalogové zóny
Jedním z problémů operátorů s velkým počtem zón je, že nové zóny neustále přibývají nebo ubývají, a je tedy potřeba upravovat konfigurační soubor nejen na primárním, ale i na všech sekundárních autoritativních DNS serverech, aby pracovaly se správnou množinou zón. Katalogová zóna je falešná zóna, která není součástí globálního DNS stromu, ale slouží jako podklad pro konfiguraci velkého množství regulérních zón, přičemž je velice snadné ji standardními postupy (i inkrementálně) replikovat na sekundární servery. Při změně v katalogové zóně se každý server sám překonfiguruje na základě přidaných/odebraných záznamů.
Příklad:
catalog-role: interpret
catalog-template: tpl_standard
Ty řádky v konfiguraci zóny signalizují, že jde o katalogovou zónu. Taková nebude odpovídat na obyčejné DNS dotazy zvenčí. Zároveň se interpretuje jako katalogová: projdou se všechny PTR záznamy v ní a na základě nich se nakonfigurují členské zóny. Konfigurace členských zón se pak řídí šablonou tpl_standard (v našem případě), ve které může být například definována sada sekundárních serverů k rozeslání NOTIFY, nebo parametry DNSSEC podepisování.
Aktuálně probíhá tvorba RFC standardu pro katalogové zóny, s nímž je implementace v Knot DNS v souladu.
Další možnosti práce s katalogovými zónami, které bude možné nejenom interpretovat, ale i generovat, jsou plánovány do příštích verzí Knot DNS.
Průběžná validace DNSSEC
Zatímco pro DNS odpovídání lze díky anycastu použít více různých DNS serverů a tím diverzifikovat použitý software, podepisování zóny DNSSECem se odehrává na jednom místě a operátor si tedy musí zvolit, které implementaci bude důvěřovat. V minulosti už se objevily různé softwarové chyby, které způsobily například chybné vygenerování NSEC3 záznamů (sloužících k důkazům neexistence), což znefunkčnilo některé domény. Velcí DNS operátoři proto každou novou verzi podepsané zóny verifikují některým z dostupných nástrojů, to je však zdlouhavý proces, který omezuje rychlost a frekvenci změn v zóně.
Zapnutím v konfiguraci dnssec-validation: on bude Knot kontrolovat všechny příchozí změny do zóny, že jsou správně podepsané. Chybně podepsané změny jsou odmítnuty. Malé změny velké zóny jsou zkontrolovány rychle. Validační Knot může být nakonfigurován jako sekundár podepisovacího serveru, a zároveň jako primár veřejných serverů. Kdyby došlo při podepisování k chybě, bude tak veřejně dostupná poslední funkční verze zóny.
Tato kontrola je pochopitelně přínosná hlavně v případě, že se k podepisování používá jiná implementace.
Minimalizace odpovědí na ANY a RRSIG
V minulosti bylo na dotaz na typ ANY či RRSIG vráceno tolik záznamů, pro kolik existuje pod daným jménem typů, což vedlo k velkému poměru velikosti odpovědi vůči dotazu, a nahrávalo amplifikačním útokům. Protože je legitimní přínos takových dotazů zároveň velmi malý, je řešením na ně odpovídat minimalizovaně, podle RFC 8482. Už od verze 2.9.4 částečně, a od 3.0 úplně, odpovídá Knot DNS na tyto dotazy pouze jedním, namátkou vybraným typem, odpovědi tedy nejsou amplifikovány více, než při dotazu na konkrétní RR typ.
Utilita kzonesign
Na rozdíl od jiných, modulárních DNS implementací, preferuje Knot DNS podepisování přímo v démonu, což má výhody například v rychlosti či automatickém načasování roll-overů klíčů. Nicméně pro testovací či speciální účely nyní nabízí utilitu kzonesign, která funguje podobně jako dnssec-signzone: načte zónový soubor, podepíše zónu, a vypíše zpátky do souboru. Odlišnost je v tom, že parametry podepisování se nepředávají jako opšny v příkazové řádce, ale konfiguračním souborem ekvivalentním konfiguraci Knota.
Záloha metadat
K perzistentním datům autoritativního DNS serveru kromě zónového souboru a konfigurace patří také žurnál (change-sety posledních změn zóny), podepisovací klíče a jejich metadata, a timestampy zóny (poslední NOTIFY, poslední refresh apod.). Tato data se mohou nacházet na různých místech filesystému a jejich záloha je problematická, neboť je během ní potřeba mít všechny zóny zmražené, aby v průběhu nedošlo ke změnám dat a nebyly zálohovány nekonzistentně. Nová verze Knota umožňuje jedním příkazem bezpečně zálohovat nebo obnovit vše potřebné do/z daného adresáře.
Příklad:
$ knotc zone-backup +backupdir /mnt/backup/auth_dns
Deterministické ECDSA
Podepisovací algoritmus ECDSA je výhodný díky vysoké bezpečnosti při malé velikosti klíčů a podpisů. Má však to specifikum, že ověřování existujících podpisů trvá násobně déle, než vytváření podpisů samotných. Při podepisování se také využívá zdroj náhodnosti a podpis stejných dat stejným klíčem může pokaždé vypadat jinak. Tyto vlastnosti odstraňuje deterministické ECDSA, které generuje pokaždé stejný podpis a je ho tedy při dostupnosti privátního klíče možné ověřit znovuvygenerováním a porovnáním, což zrychluje studený start serveru nad již podepsanou zónou. Také může sloužit jako ochrana před útoky založenými na oslabení generátoru náhody.
Příklad:
policy:
algorithm: ECDSAP256SHA256
reproducible-signing: on
Dotazování DoH v kdigu
Utilita kdig, sloužící především adminům pro kontrolu funkčnosti DNS serverů a resolverů, nyní podporuje dotazování DNS-over-HTTPS (DoH).
Příklad:
$ kdig @193.17.47.1 +https=/doh example.com.
Utilita kxdpgun
S implementací výkonných síťových operací pomocí XDP přichází i testovací a benchmarkovací utilita, která je schopná generovat v extrémních případech i desetimiliony dotazů za sekundu. kxdpgun umožňuje nastavit rychlost a další parametry benchmarku, a na konci měření zobrazí statistiky přijatých odpovědí včetně návratových kódů. Tým Knot DNS už teď používá tuto utilitu k měření výkonu své a ostatních implementací DNS serverů.
Trust Anchor Roll-over
Nejčastěji v situaci, kdy je podepsaná zóna podzónou nepodepsané, se využívá správy Trust Anchoru podle RFC 5011. Při roll-overu takového klíče je potřeba, aby byl publikován s nastaveným revoked flagem. Knot DNS 3.0 to umožňuje, i když ne automatizovaně.