Věrohodné DNS čili DNSSEC

Asi největší letošní událostí ve světě DNS bylo přijetí trojice RFC definujících novou podobu rozšíření DNSSEC. Jejich cílem je poskytnout mechanismy založené na digitálním podpisu pro ověření pravosti údajů uložených v DNS. Vyplatí se však zvýšená zátěž, související se zpracováváním DNSSEC záznamů?

reklama

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:

  1. Přidá se veřejný klíč (DNSKEY) domény použitý k podepsání záznamů.
  2. 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.
  3. 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.

KL2014

       

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ří.

Anketa

Vyplatí se podle vás DNSSEC?

       

Pavel Satrapa

Autor dělá nepořádek v příslovích, protože sítě nejen dělá, ale i učí a dokonce také řídí. Vede katedru informačních technologií na Technické univerzitě v Liberci. Píše knihy.

Školení Google Analytics

  •  
    Jak vyhodnocovat úspěšnost reklamních kampaní.
  • Jak ovládat Google Analytics a najít co potřebuji.
  • Jak měřit hodnotu objednávek z webu.

Detailní informace o školení Google Analytics »

       
6 názorů Vstoupit do diskuse
poslední názor přidán 27. 5. 2005 15:57

Tento text je již více než dva měsíce starý. Chcete-li na něj reagovat v diskusi, pravděpodobně vám již nikdo neodpoví. Pro řešení aktuálních problémů doporučujeme využít naše diskusní fórum.

Zasílat nově přidané příspěvky e-mailem