... | ... | @@ -16,19 +16,21 @@ Jedním z problémů operátorů s velkým počtem zón je, že nové zóny neus |
|
|
|
|
|
Příklad:
|
|
|
```
|
|
|
catalog-role: interpret
|
|
|
catalog-template: tpl_standard
|
|
|
```
|
|
|
Tento řádek v konfiguraci zóny signalizuje, že jde o katalogovou zónu. Taková nebude odpovídat na obyčejné DNS dotazy zvenčí. Zároveň se projdou všechny `PTR` záznamy v ní a na základě nich se nakonfigurují členské zóny. Na každou z nich se aplikuje konfigurační šablona `tpl_standard`, ve které může být například definována sada sekundárních serverů k rozeslání NOTIFY, nebo parametry DNSSEC podepisování.
|
|
|
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ěkerým z dostupných nástrojů, to je však zdlouhavý proces, který omezuje rychlost a frekvenci změn v zóně.
|
|
|
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-policy: validation_policy
|
|
|
dnssec-validate: 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. Valdiač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.
|
... | ... | @@ -39,9 +41,9 @@ Tato kontrola je pochopitelně přínosná hlavně v případě, že se k podepi |
|
|
|
|
|
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 ksignzone
|
|
|
## 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 `ksignzone`, 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.
|
|
|
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
|
|
|
|
... | ... | @@ -54,7 +56,7 @@ $ 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 jej 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.
|
|
|
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 jej 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:
|
|
|
```
|
... | ... | @@ -70,4 +72,8 @@ Utilita `kdig`, sloužící především adminům pro kontrolu funkčnosti DNS s |
|
|
Příklad:
|
|
|
```
|
|
|
$ kdig @193.17.47.1 +https=/doh example.com.
|
|
|
``` |
|
|
\ No newline at end of file |
|
|
```
|
|
|
|
|
|
## 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ě. |
|
|
\ No newline at end of file |