Leží tady přede mnou ještě první verze knihy Pavla Satrapy o IPv6 z roku 2002 a na zadní straně přebalu si čtu:
„Společnost Cisco Systems si je vědoma budoucího významu IPv6 a aktivně se podílí na jeho vývoji.“
Rád bych vám teď zde napsal, že se po sedmi letech od vydání knížky a jen pár let do vyčerpání adresního prostoru v IPv4 dostanete na dnes probíhající konferenci CiscoExpo 2009 v rámci WiFi připojení (ESSID: CiscoExpo) i IPv6 adresu a celá síť je na dual stacku a všechno krásně funguje.
Bohužel nemůžu. Navíc tato konkrétní síť CiscoExpo blokovala protokol Jabber (o ICQ ani nemluvě).
Pozitivní je, že alespoň dle různých signálů je podpora IPv6 ve standardním image IOSu.
Ondřej Surý
DNSSEC ve linuxové distribuci Fedora 11
Přibližně za měsíc vyjde nová verze populární Linuxové distribuce Fedora. Jsem dlouholetým uživatelem distribucí Redhat a Fedora a tak mě v seznamu nových věcí velice potěšila podpora validace DNSSEC. Implementace podporuje jak DLV tak ITAR pro resolvery BIND i Unbound. Je skvělé, že tvůrci takto významné distribuce podporu DNSSEC zavedli, ostatní se jistě nenechají zahanbit. Vzhledem k tomu, že Linux už není pouze záležitostí serverů, ale že jej stále více lidí používá i jako pracovní stanici, přesouvá se tím validace DNSSEC od poskytovatelů připojení přímo ke koncovým uživatelům. V souvislosti s tímto bude zajímavé prozkoumat, jak se k DNSSEC dotazům budou stavět všemožné domácí WiFI a ADSL routery s NATem. Abychom mohli případné problémy předvídat, rozhodli jsme se, že budeme testovat domácí routery různých výrobců a budeme reportovat případné problémy.
Váš linuxový fanoušek
Červ Conficker
Červ Conficker, známý také pod názvy Downup, Downadup a Kido, napadl už milióny počítačů. Patříte mezi ně? Jednoduchý test máte přímo před sebou.
Conficker Eye Chart/Detekční tabulka
![]() |
![]() |
![]() |
Interpretace detekční tabulky v původním znění najdete zde, nebo můžete použít volný překlad z anglického originálu.
Výtažek z překladu:
„Jestliže je Vám zablokován přístup k zobrazení obrázků (log antivirových firem) v prvním řádku horní tabulky a zároveň se zobrazují loga alternativních operačních systémů v druhém řádku tabulky, pak může být Vaše Windows PC infikováno červem Conficker (nebo jiným škodlivým programem).“
Jste-li napadeni, využijte některý z dostupných nástrojů a červa Conficker co nejdříve odstraňte. Odkazy na nástroje:
Downadup-removal
Obsáhlý seznam nástrojů
Světová mapa infikovaných počítačů. Další mapy naleznete zde.

Pokud Vás zajímají bližší informace o červu Conficker, následující výběr Vám může usnadnit hledání. Doporučuji zahraniční odkazy.
Emanuel Petr
DNSSEC už i v Asii
Dnes ráno mě informoval můj DNS server, že v ITARu jsou nové klíče pro další doménu nejvyšší úrovně. Musím říct, ze jsem v tomto týdnu žádnou takovou zprávu nečekal a tak jsem byl trochu překvapený. Toto překvapení se změnilo v údiv ve chvíli, kdy jsem zjistil, že jde o podpis domény z Asie a navíc ze státu, který žádné plány na zavedení DNSSEC veřejně nevyhlásil. První podepsanou doménou v Asii je tedy doména .th – Thajsko. Doufejme, že nebude v tomto regionu osamocena dlouho.
Ondřej Filip
ENUM se (přece jen) šíří světem
Přestože někteří škarohlídové zvěstují veřejnému ENUM temnou budoucnost, opak je pravdou. Přibývají další země, kde je veřejný ENUM v plném provozu; teď jako poslední ohlásila zavedení ENUM Velká Británie. Už bych se asi opakoval po sté (i když opakování je matka moudrosti, tady to moc nepomůže), kdybych znovu říkal, že problém ENUM je v tom, že o něm stále většina lidí neví. Každá další země, která ENUM zavedla, je tak z tohoto pohledu dobrá v tom, že vygeneruje nové uživatele, více možností volání pomocí ENUM pro všechny stávající uživatele, větší publicitu, atd. Seznam zemí s delegovanou doménou je dlouhý a obsahuje delegace z dávné i nedávné doby. Kdo bude další?
PT
České firmy začínají objevovat DNSSEC
Často slýchávám názor, že pro úspěch technologie DNSSEC je potřeba, aby bylo podepsáno co největší množství domén. To mi přijde podobné, jako kdybychom chtěli, aby každý dům měl ve svém sklepení bankovní trezor odolný proti dynamitu.
Není přeci nutné podepisovat doménu, která slouží pouze pro web s fotkami z dovolené, ale naopak je důležité podepsat domény významných služeb: vyhledávačů, zpravodajských portálů, bank, e-shopů a podobně.
V nedávné době byly podepsány dvě domény, obě z té důležitější kategorie. V minulém týdnu to byla doména jednoho z největších internetových knihkupectví v republice, které funguje na internetové adrese www.kosmas.cz, a dnes jsem si všiml, ze je podepsána i doména významného internetového zpravodajského serveru lupa.cz. To jsou dobré zprávy. Doufejme, že další významné domény na sebe nenechají dlouho čekat.
Ondřej Filip
Kapacity technologie XML v Praze
Zlí jazykové před deseti lety označovali jazyk XML za pouhé „buzzword“, módní technologii, která nebude mít dlouhé trvání. Ukázalo se, že se hluboce mýlili, a tak v současnosti lze tento jazyk nalézt téměř v každé oblasti světa IT. Ve správě dokumentů jej jako svůj základ přijali dva hlavní hráči, Open Office ve svém formátu OpenDocument i Microsoft Office ve formátu OpenXML. Své pevné místo má XML v oblasti výměny dat, takže je možné s jeho využitím například podat daňové přiznáni online. Z XML kořenů vychází i webové služby, aktuálně velmi vyhledávaná technologie pro propojování aplikací na internetu. Následující seznam obsahuje oblasti, ve kterých XML a související technologie využívá náš registrační sytém FRED:
- Klíčovým místem systému je EPP, protokol pro komunikaci s registrátory, který je právě na XML založen
- Formát jednotlivých zpráv protokolu EPP je definován pomocí popisovacího jazyka XML Schema.
- Pro případné strojové zpracování posíláme registrátorům faktury právě ve formátu XML
- Pro načtení faktur do software naší účetní firmy transformujeme faktury z našeho XML formátu do XML formátu účetního software pomocí technologie XSLT
- Pro generování PDF dokumentů systému (faktury, formuláře žádostí a dopisy) používáme formátovací jazyk RML z projektu ReportLab
- Část dokumentace je uložená v XML formátu DocBook
O víkendu 21. a 22. března se v prostorách Matematicko-fyzikální fakulty Univerzity Karlovy na Malostranském náměstí uskutečnil již čtvrtý ročník konference XMLPrague. Do Prahy přijely kapacity, které se v rámci standardizační organizace W3C podílejí na vytváření výše uvedených technologií. Mezi přednášejícími byla zvučná jména jako Michael Kay (pracuje na vývoji XSLT), Makoto Murata (autor jazyka RelaxNG pro definování formátů dokumentů) nebo Norman Walsh (podílí se na rozšiřování formátu DocBook). Tématem přednášek byly mimo jiné nové verze některých z těchto technologií jako XML Schema 1.1 a EXSLT 2.0 nebo například doporučené postupy (unit testy, profiling, coverage…) a nástroje (<oxygen/>) pro vývojáře při testování a ladění práce s XML dokumenty. Hodně prostoru bylo věnováno i nedávno standardizovanému jazyku XProc pro vytváření pravidel (pipeline), podle kterých vstupní XML dokumenty procházejí celou řadou propojených transformací nebo filtrů a odpadá tak nutnost programovat klasickým způsobem práci s těmito dokumenty – vše je uloženo v jednom předpisu, který je (jak jinak) napsán v XML.
Prezentace byly streamované do internetu a s největší pravděpodobností se objeví na konferenčních stránkách, takže ani ti, kdo se nedostavili, nepřijdou zkrátka. Možná trochu zarážející je, s jakou malou odezvou se konference setkala mezi našinci. Podle mého skromného odhadu z asi 120-členného osazenstva bylo kolem 80 % cizinců. V každém případě patří dík organizátorům, že se jim podařilo vybudovat tradici, jejíž aktéry jsou tyto světoznámé osobnosti.
Jaromír Talíř
EU se zajímá o DNSSEC
Evropská agentura pro bezpečnost sítí a informací (ENISA) slouží institucím EU i členským státům jako centrum odborných konzultací a poradenství v oblasti bezpečnosti sítí a informací. Agentura podporuje instituce EU a podnikatelské subjekty, aby předcházely problémům spojeným s bezpečností sítí a aby byly schopné tyto problémy pojmenovat a řešit. Na konci ledna uspořádala tato agentura v Athénách jednodenní workshop s názvem Zvýšení odolnosti DNS. Cílem workshopu bylo prodiskutovat aktuální stav nasazení technologie DNSSEC v Evropě, identifikovat problémy, které jejímu dalšímu rozšiřování brání a hlavně, pokusit se najít způsob, jakým by ENISA mohla k tomuto rozšiřování přispět.
Workshopu se zúčastnilo asi 15 zástupců organizací, které mají k tomuto tématu co říct. Kromě evropských registrů, které DNSSEC zavedly (Bulharsko, Švédsko a České republika) zde byly například odborníci z RIPE NCC nebo holandského NlNet Labs. Kompletní program a jednotlivé prezentace jsou k dispozici na stánkách workshopu. V rámci těchto prezentací a následných diskuzí padlo mnoho zajímavých témat. Pro čtenáře našeho blogu jsem si vybral dvě z nich, která nejvíce zaujala mě. Těmi jsou nelehké prosazování DNSSEC na veřejnosti a různé alternativní možnosti využití DNSSEC.
Všechny zastoupené registry se snaží různými marketingovými kampaněmi podpořit nasazení DNSSEC. Ve Švédsku v rámci jedné takové kampaně zveřejnili na stránkách www.kaminskybug.se video, ve kterém ukazují jak jednoduché je zaútočit na některé domény a modifikovat obsah, který uživatel uvidí a to bez vědomí vlastníka domény a provozovatele služby. V Athénách bylo na úvod workshopu promítnuto toto video v nezkrácené podobě. Zveřejnění této verze bylo prý z bezpečnostních důvodů ve Švédsku zakázáno a na web musela jít mírnější varianta. Švédové toto video promítají zodpovědným osobám například v bankách.
Většina diskutujících přirozeně vidí hlavní přínos technologie DNSSEC ve zvýšení zabezpečení infrastruktury internetu a pro běžné uživatele by její nasazení mělo být naprosto transparentní. Objevili se ale i námitky, že právě toto může být pro jeho plné rozšíření kámen úrazu. Pokud uživatel neuvidí v okně svého prohlížeče u zadané domény informaci, že doména je zabezpečená, jako je to v případě SSL autentizace, nezíská k tomuto zabezpečení patřičný vztah. Například pro prohlížeč Firefox již existují rozšíření, které toto řeší. Existují ale i další způsoby jak přiblížit DNSSEC koncovému uživateli. Všechny vycházejí z toho, že DNSSEC dává světu konečně infrastrukturu veřejných klíčů (PKI), která snad v brzké době bude mít jeden kořen. Nabízí se tedy otázka, zda by klíče v DNSSEC nemohly být využity ve známých oblastech užití symetrické kryptografie – SSH autentizace, PGP nebo X509. Nebylo by pěkné mít v prohléžeči místo stovky certifikačních autorit (CA), jeden certifikát kořenové zóny? Registr nabízející DNSSEC je už teď vlastně CA, která přijímá veřejné klíče, potvrzuje jejich pravost svým podpisem a zveřejňuje tyto podepsané klíče na veřejnost v systému DNS. Jediný rozdíl oproti klasické CA je chybějící proces verifikace identity držitele klíče, kterou CA svým podpisem garantuje.
Setkání v Athénách bylo v každém případě inspirativní a představitelé ENISI si stanovili jako cíl připravit jako výstup několik dokumentů, které shrnou to podstatné, co bylo během workshopu řečeno. Budou se také v rámci Evropy snažit působit na ostatní TLD, aby zavedení technologie DNSSEC přijali jako jednu ze svých hlavních priorit.
Jaromír Talíř
AS path prepending
AS path je BGP povinný atribut. Obsahuje seznam čísel autonomních systémů (ASNs), přes které je prefix (rozsah adres) propagován. Například AS path pro ripe.net 193.0.19.25 může vypadat:
test@juniper> show route protocol bgp 193.0.19.25
inet.0: 275156 destinations, 374067 routes (275106 active,
0 holddown, 76 hidden)
+ = Active Route, - = Last Active, * = Both
193.0.18.0/23 *[BGP/170] 1w0d 17:01:53, localpref 100
AS path: 15685 1299 3333 I
> to 10.0.0.254 via ge-0/0/0.0
Má-li směrovač k danému prefixu více cest, může být délka AS path při výběru nejlepší cesty rozhodující.
AS path prepending neboli „umělé“ prodloužení AS path se užije v případě multihomingu, kdy chceme pro příchozí provoz preferovat jeden upstream před druhým.
Dne 16.2.2008 si takto svoji cestičku v globální směrovací tabulce do Uherského Hradiště/Broda (AS47868) prodloužila společnost SUPRO-NET. Využila zmiňované možnosti “AS path prependingu“ pro svůj druhý upstream a nešetřila.
Běžně stačí svoje AS znásobit jednociferným číslem. Ale 251x se ukázalo, jako velké sousto pro starší směrovače/staré verze IOSu či jakékoliv implementace BGP, které si neporadí s delším AS path. Následkem bylo rozpojení BGP sezení, velké BGP updaty a výpadky konektivity.
Článek na renesys.com popisuje, že to nebyl úmysl, ale chyba správce a bug routeru MikroTik.
Že prefixy s delším AS path nejsou ojedinělé, se můžete přesvědčit na http://bgpmon.net/maxASpath.php
Velmi dlouhé AS path jsou nerozumné, protože zbytečně zabírají systémové prostředky na směrovačích. Nejsou však v rozporu s RFC4271 . V BGP UPDATE zprávě jsou pro délku atributů vyhrazeny 2 Byty (64KB), takže AS path je omezeno snad jen samotnou velikostí BGP UPDATE zprávy, která je 4KB.
Zajímalo mě, jak se k tomu staví jednotlivé implementace. Zkoušel jsem příkazy pro omezení délky AS path, možnosti prodloužení AS path a nakonec import prefixu s velmi dlouhým AS path. Testovány byly tyto implementace Cisco, Juniper, Quagga a BIRD.
Cisco ve starších IOSech mělo s delším AS path vážné problémy! Jak se jim vyvarovat?
Od IOS 12.0(17)S by měl být implementován příkaz „bgp maxas-limit“
#bgp maxas-limit ?
<1-2000> Number of ASes in the AS-PATH attribute
pokud příkaz není dostupný, můžete použít „ip as-path access-list“ a „filter-list/route-map“ nebo sáhnout po novějším IOS.
Maximální hodnota 2000 u „bgp maxas-limit“ je taková Cisco hrátka, protože v aktuální dokumentaci uvádí <1-255>. I když je Vám umožněno zadat více, bude limit pro importované prefixy stále 255 a to i v případě, neuvedete-li příkaz „bgp maxas-limit“ vůbec.
A aby to nebylo tak jednoduché, je tu ještě odlišnost ve výpisech.
# sh ip bgp neighbors 10.0.0.22 route … zobrazuje přijaté a akceptované prefixy
V případě „bgp maxas-limit“ s hodnotou < 255, nejsou ve výstupu prefixy s delším AS path logicky zobrazeny. Ale s hodnotou >= 255 nebo bez samotného příkazu pro omezení AS path, jsou zobrazeny jako akceptované, nejsou však zařazeny do směrovací tabulky.
Ukázka omezení délky AS path na 15:
cisco(config)#router bgp 64551
cisco(config-router)#bgp maxas-limit 15
Při překročení limitu 15 ASNs se prefix ignoruje a důvod je zalogován.
*Feb 19 20:12:27.057: %BGP-6-ASPATH: Long AS path 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 15685 1299 3333
received from 10.0.0.20: More than configured MAXAS-LIMIT
Pravděpodobně jako prevence dlouhých AS path, je v IOS prodloužení AS path omezeno na maximálně 10 ASNs pro jednotlivé příkazy.
cisco(config)# route-map prepend-as permit 10
cisco(config-route-map)#set as-path prepend 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551
cisco(config-route-map)#set as-path prepend last-as 10
Při pokusu zadat více, skončíte s chybovou zprávou.
cisco(config-route-map)#set as-path prepend 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551
% Cannot have more than 10 as-paths prepended
% Cannot have more than 10 as-paths prepended
Pokud upravujete AS path pro prefix, který nemá původ u Vás, můžete přidat dalších 20 ASNs aplikací route-mapy při importu.
cisco(config-router)#neighbor 10.0.0.22 route-map prepand-as ?
in Apply map to incoming routes
out Apply map to outbound routes
Celkem lze prodloužit AS path až o 40 ASNs + 1 ASN implicitně. Tranzitní AS s Cisco směrovači si musí dát pozor na novou chybu a omezit AS path. V opačném případě může dojít při exportu k přerušení BGP spojení.
![]()
Testováno s JUNOS verzí 9.2R2.15.
Alternativou pro „bgp maxas-limit number“ je AS path regulární výraz, který následně aplikujeme ve směrovací politice.
AS path regulární výraz pro 91 ASNs a více.
[edit policy-options]
test@juniper# set as-path maxas-limit ".{91,}"
Rozšíření importovací politiky o zamítnutí všech prefixů s delším AS path než 90.
[edit policy-options policy-statement nix-import term reject-long-aspath]
test@juniper# set from as-path maxas-limit
test@juniper# set then reject
Výsledná konfigurace.
[edit policy-options ]
test@juniper# show
policy-statement nix-import {
...
term reject-long-aspath {
from as-path maxas-limit;
then reject;
}
...
}
set as-path maxas-limit ".{91,}"
Odmítnuté prefixy pak naleznete takto:
test@juniper> show route receive-protocol bgp 10.0.0.21 hidden
inet.0: 249888 destinations, 249891 routes (249886 active,
0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
10.123.0.0/16 10.0.0.1 0 64551 64551
64551 ... výpis zkrácen ... 64551 64551 64551 64551 64551 64551 I
10.124.0.0/16 10.0.0.25 0 64551 64551
64551 ... výpis zkrácen ... 64551 64551 64551 64551 64551 64551 I
Také Juniper omezuje vytvoření velmi dlouhých AS path. Prodloužit AS path se dá třemi příkazy:
as-path-prepend as-path-string ... omezuje na 30 ASNs nebo na maximální délku řetězce 256
as-path-expand last-as count n ... n = kolikrát se poslední ASNs zopakuje a to v rozmezí 1..32
as-path-expand as-path-string ... omezuje na 30 ASNs nebo na maximální délku řetězce 256
Maximálně tedy můžeme prodloužit AS path o 62 ASNs.
V případě překročení limitu 30ti ASNs pro daný příkaz dostaneme chybovou zprávu:
AS path too complex
error: configuration check-out failed
A pokusíme-li zadat řetězec delší než 256 znaků, budeme informováni o invalidním řetězci a prefix nebude vůbec propagován.
test@juniper# commit
[edit policy-options policy-statement export-limited term allow-ripe-prefix then as-path-prepend]
'as-path-prepend "25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 ... výpis zkrácen ... 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 "'
Insufficient buffer space for string
[edit policy-options policy-statement export-limited term allow-ripe-prefix then as-path-prepend]
'as-path-prepend "25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 ... výpis zkrácen ... 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 "'
Policy: Invalid string
commit complete
Omezení délky AS path na 30 ASNs:
ip as-path access-list maxas-path deny ( [0-9]+){30}$
ip as-path access-list maxas-path permit .*
Aplikujeme na příchozí prefixy:
neighbor 10.0.0.21 filter-list maxas-path in
Quagga neumožní prodloužit AS path více než o 24 ASNs.
Při pokusu zadat více, dostaneme chybovou zprávu a BGP démon se nespustí. Přes VTY sice můžete zadat více, ale příkaz bude tiše ignorován.
There is no such command.
Error occured during reading below line.
set as-path prepend 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 3333
Omezení délky AS path na 35 ASNs:
protocol bgp {
export all;
import filter {
if bgp_path.len > 35 then reject;
accept;
};
local as 64502;
neighbor 10.0.0.20 as 25192;
}
Filtry můžete testovat pohodlně z příkazové řádky BIRD klienta.
V ukázce má importovaný prefix 193.0.18.0/23 délku AS path 35.
# ./birdc -s bird.ctl
BIRD 1.0.12 ready.
bird> show route all filter {if bgp_path.len > 35 then reject; accept;}
193.0.18.0/23 via 10.0.0.20 on eth0 [bgp1 17:21] (100) [AS3333i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 25192 25192 25192 25192 25192 25192 25192
25192 25192 25192 25192 25192 25192 25192 25192 25192 25192
25192 25192 25192 25192 25192 25192 25192 25192 25192 25192
25192 25192 25192 25192 25192 15685 1299 3333
BGP.next_hop: 10.0.0.20
BGP.local_pref: 0
bird> show route all filter {if bgp_path.len > 34 then reject; accept;}
bird>
Prodloužení AS path je omezeno interní velikostí atributů 1KB. Limitu je většinou dosaženo při cca 250 ASNs. Při překročení, obdržíme chybovou zprávu a BGP prefix nebude správně propagován.
20-02-2009 14:08:35 <ERR> BGP: attribute list too long, ignoring the remaining attributes
Import prefixu s velmi dlouhým AS path
A jak si poradily jednotlivé implementace s importem prefixu, jehož AS PATH čítala 560 ASNs. Takto dlouhý BGP update byl vytvořen úpravou zdrojových kódů BIRD.
| Cisco | import zvládne, ale prefix nezařadí do směrovací tabulky |
| Juniper | OK |
| Quagga | OK |
| BIRD | OK |
Závěr
Máte-li na svém směrovači alespoň verze, které byly testovány, tak nebudete mít při samotném importu prefixu s dlouhým AS path problém.
Na směrovačích Cisco se však objevila nová chyba. Překročíte-li při prodloužení AS path délku 255 ASNs a tento prefix vypropagujete, bude BGP sezení přerušeno a následně cyklicky restartováno. Detailně se této nové chybě budu věnovat v dalším článku.
Dodatek:
1.3.2009 – Quagga má obdobný problém při exportu s AS path > 255, a to i bez dodatečného prependingu. Ve verzi 0.99.10 byla chyba opravena.
2.3.2009 – Rozbor Cisco chyby je součástí článku Proč a zda Supronet shodil Internet.
Emanuel Petr
Zdroje:
http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml
http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length
http://bgpmon.net/maxASpath.php
http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#wp1013932
http://www.juniper.net/
http://www.quagga.net/
http://bird.network.cz/
http://www.ietf.org/rfc/rfc4271.txt
http://blog.ioshints.info/2009/02/oversized-as-paths-cisco-ios-bug.html
Konečně máme kořen DNSSEC
Ačkoliv už pět správců domén nejvyšší úrovně (TLD) zavedlo technologii DNSSEC, stále nám chybí jakoby krok číslo 1, tedy podpis té úplně prvotní, neboli kořenové zóny. Pokud tedy chci v současné době plně validovat záznamy ve všech podepsaných zónách, musím si stáhnout klíče všech pěti organizací a starat se o jejich aktualizaci. To je pochopitelně poměrně nepraktické, každý správce domény má jiný způsob, jak klíče zveřejňuje. V praxi to tedy funguje tak, že každý ISP, který validaci provádí, si buď sleduje aktuálnost obvykle té pro něj nejzajímavější domény a ostatní ignoruje, nebo použije úložiště klíčů mechanismu DNSSEC Lookaside Validation – DLV. DLV je poměrně elegantní řešení, nicméně ne každý má důvěru v konkrétního provozovatele DLV. Navíc DLV není zcela obecně přijaté a standardizované řešení.
Vzhledem k tomu, že podepsání kořenové zóny z mnoha důvodů ještě nedošlo, rozhodla se organizace IANA, která se jinak o změny v kořenové zóně stará, jednat a vytvořila prozatímní řešení, do doby než se spory vyjasní a dojde k podpisu. Proto vytvořila tak zvaný ITAR – Interim Trust Anchor Repository. Toto řešení je technologické odlišné od DLV a je z hlediska typu použitého DNS resolveru zcela neutrální. Dalším plusem je, že jej spravuje důvěryhodná organizace, která se o změny v kořenové zóně stará a má tedy autentizační mechanismy pro komunikaci se správci TLD. Výhodou je poměrně přesná specifikace toho, za jakých podmínek je služba provozována, a toho, co se stane po podpisu zóny. Ještě je třeba dodat, že narozdíl od DLV slouží ITAR pouze pro TLD. Způsob, jak nastavit DNS resolver pro spolupráci s DLV nebo ITAR popisuje kolega Surý ve svém článku na serveru Root.
Ač se vznik ITAR nemusí jevit jako důležitý krok, ve skutečnosti jím je. Může totiž přesvědčit registry, kteří čekají s implementací DNSSEC na podpis kořene, k urychlení plánu. Teď totiž kořen vlastně máme.
Ondřej Filip




