Historie DNSSEC patří mezi méně zářivé epizody ve vývoji Internetu. Když v roce 1999 vyšlo RFC 2535 s jeho specifikací, zdálo se, že je vyhráno. Jenže praxe ukázala, že navržené postupy jsou neohrabané a v praxi obtížně uplatnitelné. Během následujících šesti let proto vznikala nová definice, aby nahradila svou nepříliš povedenou předchůdkyni. V březnu letošního roku se tak skutečně stalo. Je rozdělena do tří dokumentů:
- RFC 4033
- popisuje základní pojmy a principy jeho fungování
- RFC 4034
- definuje nové záznamy, jež DNSSEC používá
- RFC 4035
- popisuje příslušné změny v protokolu DNS
O DNSSEC jsme vás informovali přibližně přede dvěma roky (1. část, 2. část). Na jeho mechanismech se od té doby mnoho nezměnilo. Nejvýznamnější úpravou je změna názvů jeho záznamů.
Připomenu ve stručnosti hlavní principy. Cílem DNSSEC je poskytovat ověřené informace z DNS, a to včetně negativních (že určitý záznam neexistuje). Vychází z digitálního podpisu: každá sada záznamů (záznamy stejného typu pro stejné jméno) je podepsána – přidá se k ní záznam RRSIG (dříve SIG) s podpisem.
Pro podpis se používá obvyklých kryptografických metod s veřejným klíčem, kdy privátní klíč použitý k vytvoření podpisů je držen v tajnosti (zcela mimo DNS a v ideálním případě i mimo síť jako takovou). Jemu odpovídající veřejný klíč, jehož prostřednictvím lze pravost podpisu ověřit, je uložen přímo do zónového souboru patřičné domény pomocí záznamu DNSKEY (dříve KEY).
Vzniká samozřejmě otázka, jak ověřit pravost tohoto klíče. Proto se do nadřazené domény vkládá jeho otisk (digest, záznam DS). Jelikož je uložen v doménové hierarchii o patro výše, je podepsán klíčem nadřazené domény. Čili problém důvěryhodnosti se posouvá o jedno patro výše. Důvěřuje-li klient zdejšímu klíči, ověří si postupně všechny záznamy. V opačném případě může použít stejný postup a šplhat v hierarchii ještě výše.
V ideálním případě by tedy stačilo, aby klient měl důvěryhodný veřejný klíč ke kořenové doméně, a od něj by pak byl schopen rozvinout řetězec důvěry až ke zkoumanému záznamu. Samozřejmě za předpokladu, že všechna patra v hierarchii podporují DNSSEC.
K ověření negativních odpovědí slouží záznamy NSEC (dříve NXT). Ke každému jménu v dané doméně je přiřazen jeden záznam typu NSEC. Přináší dvě informace: seznam typů záznamů definovaných pro toto jméno a následující jméno v doméně. Jeho prostřednictvím lze tedy ověřit obě typické situace: neexistující jméno (server pošle NSEC záznam jeho předchůdce, z nějž je patrné, že dané jméno v doméně není), tak neexistující typ záznamu pro existující jméno (server pošle jeho NSEC dosvědčující, že požadovaný typ záznamu pro toto jméno chybí). Pro účely NSEC definuje RFC 4034 přesná pravidla k uspořádání záznamů v doméně.
Tolik hrubé obrysy DNSSEC. Větší podrobnosti najdete ve výše odkazovaných článcích – až na názvy záznamů se prakticky nic nezměnilo. Podívejme se nyní, jak se DNSSEC projeví prakticky.
Vyjděme z jednoduché fiktivní domény kdesi.cz, jež obsahuje jen dva počítače: boule.kdesi.cz (server) a koule.kdesi.cz a přezdívku www.kdesi.cz pro bouli. Kromě toho jsou pro doménu definovány dva DNS servery a dva servery přijímající poštu. Definice této domény by vypadala následovně:
kdesi.cz. IN SOA boule.kdesi.cz. kdosi.kdesi.cz. (
200505200 3600 1800 2419200 86400
)
IN NS boule.kdesi.cz.
IN NS ns.jinde.cz.
IN MX 0 boule.kdesi.cz.
IN MX 50 mail.jinde.cz.
boule.kdesi.cz. IN A 147.230.16.113
koule.kdesi.cz. IN A 147.230.16.37
www.kdesi.cz. IN CNAME boule.kdesi.cz.
Má-li být doplněna o DNSSEC, musí projít následujícími změnami:
- Přidá se veřejný klíč (DNSKEY) domény použitý k podepsání záznamů.
- Ke každému jménu v doméně se přidá NSEC záznam se seznamem typů záznamů pro toto jméno a následujícím jménem.
- Pro každou dvojici jméno–typ záznamu se přidá záznam RRSIG obsahující podpis celé sady (všech záznamů daného typu pro toto jméno), a to včetně záznamů přidaných v předchozích bodech.
Výsledkem je následující monstrum (přírůstky jsou vyznačeny tučně):
kdesi.cz.
86400 IN SOA boule.kdesi.cz. kdosi.kdesi.cz. (
200505200 3600 1800 2419200 86400
)
86400 RRSIG SOA 1 2 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
FoCBHtJEB5JZOR0QsVFWoR0ILg7u7wEGFYKB
9HDmCSW0IXWsbnr+Cii2LOpUYcZdLsOyHuRV
kxpUXc71ARg63A== )
86400 NS ns.jinde.cz.
86400 NS boule.kdesi.cz.
86400 RRSIG NS 1 2 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
Vj+T7zR5rOhfV49mdK6r9IC8k/QB5K3Sokci
mbyFMBzXEl5ZxmhHPdE/fyc/zmMeqWLd9FxR
qZYbEc2VhAfeHg== )
86400 MX 0 boule.kdesi.cz.
86400 MX 50 mail.jinde.cz.
86400 RRSIG MX 1 2 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
MupMBN0+qcP3FwmJrm6SWxy8rOx0Hfa1aNpD
3kwgba3jtyRyXy3Lovl59pAX3j0mYJy5CeB3
novi/CQ/Hmd6oQ== )
86400 NSEC boule.kdesi.cz. NS SOA MX RRSIG NSEC
DNSKEY
86400 RRSIG NSEC 1 2 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
DIzvhigeOFQSAaWXXeyO8YHp042ioA7gxr8u
HwrGhurSQQE3cYCuR2ZRrUvmhU+awllgLvFC
HjaDkz+kaXbHWg== )
86400 DNSKEY 256 3 1 (
AQPC4fEWxzckdd5QNvWyC2Wd2Oc0MTDiOqsX
rzAq8PtGDI/Ubjsrmh5CiHMj0Gseqg/j/3hq
yrfpkhxywJa1y0rF
) ; key id = 52042
86400 RRSIG DNSKEY 1 2 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
VNw+Qsl9gJ2MtSvl8uuOmHd2j2qgvn+U19Ul
N2SaMMkx28pLE2vPuuIV0dlVPYnjHFJkNlgS
DeCdqBXa5jlaOA== )
boule.kdesi.cz. 86400 IN A 147.230.16.113
86400 RRSIG A 1 3 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
G+d0bPJSoUHD+vQ441mhVnAzFxmEXGFbzWHX
lJv2qEQPr7oRn+1rlK+dRgbGbHR6sURC7k5m
rRXUunoSgRsYuA== )
86400 NSEC koule.kdesi.cz. A RRSIG NSEC
86400 RRSIG NSEC 1 3 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
cS0QrFu5h+u+DYPl+9DRoM7eby1gi7G+Y1+q
FV6rvfOI/7yDRhrUnTuaJlh8VPNzN0N+ZXhL
00fk5oEjDTt7Fg== )
koule.kdesi.cz. 86400 IN A 147.230.16.37
86400 RRSIG A 1 3 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
LCS2UeIbo4UGOOZTqhIMRFYP176hiN734XaL
KfwgjdJHCIMONepUXAS3p0yv1KS+WlrDvg46
4ItFeMhRL2B5uA== )
86400 NSEC www.kdesi.cz. A RRSIG NSEC
86400 RRSIG NSEC 1 3 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
aceY2Od7ZUThQRETueGXa8PQvB7RlYET5Kxw
/UUr6cdQQtK/vOFps6RCke9JP6e1Rdcmbnkq
sRv2MITgO1dQVQ== )
www.kdesi.cz. 86400 IN CNAME boule.kdesi.cz.
86400 RRSIG CNAME 1 3 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
RknafDEsIQCUBXq2lrlNKfvXuovynQWnPTXI
6npfkZ1QVCm4RGg+b9gNZRey+fyADJe9YFfb
PNNkboMXxuGBsA== )
86400 NSEC kdesi.cz. CNAME RRSIG NSEC
86400 RRSIG NSEC 1 3 86400 20050623165042 (
20050524165042 52042 kdesi.cz.
O81xaBeLEfBIjUTEDDH7FV9RlWKs2TSQ1WmU
h+eAT4b8TZv/V0+7A05aBKc15Z9C6V4CzkC/
9MpI7a7gbIkf6Q== )
Všimněte si, jak je celá doména propojena NSEC záznamy (následníkem posledního jména v ní je první). Samozřejmě není nutné vytvářet ji ručně, slouží k tomu patřičné programy. Daní za služby DNSSEC je značný nárůst velikosti souboru. Z necelých 550 B jich je najednou skoro 5 kB, tedy bezmála desetinásobek. Kromě toho by ještě bylo třeba do nadřazené domény (v našem případě do domény cz) vložit:
kdesi.cz. IN NS boule.kdesi.cz.
IN NS ns.jinde.cz.
IN DS 52042 1 1 D54E9B266FFD01259F46C223333D3F4D1526F7C3
a DS záznam podepsat zdejším klíčen (NS záznamy v nadřazené zóně se nepodepisují).
Objem dat způsobuje komplikace především u velkých domén. Například com po podepsání naroste na nějakých 10 GB, a to už končí všechna legrace. Časy potřebné pro generování takto rozsáhlých souborů a jejich načítání do paměti DNS serveru rozhodně nejsou zanedbatelné.
Přirozeně vzniká otázka, jestli se to celé vlastně vůbec vyplatí. Z pohledu skeptika spíše ne. V poslední době se objevily útoky napadající DNS klienta na uživatelských počítačích. Serverová a přenosová část DNS může být sebebezpečnější a nebude to nic platné, když výsledek bude ošvindlován až v koncovém klientovi. Kromě toho podvodné změny DNS odpovědí rozhodně nepředstavují ožehavý a často citovaný problém.
Zaujmu-li stanovisko idealisty, jistě se DNSSEC vyplatí. Každá metoda jak zlým hochům zkomplikovat život je dobrá a představuje pro Internet přínos.
Faktem je, že za DNSSEC stojí poměrně silná odborná lobby, která se ověřené DNS snaží prosadit do reálného života. V dohledné době nejspíš uvidíme, zda se jí to podaří.
ČLÁNKY DO MAILU