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.
Testováno s IOS 12.4(11)T2.
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
testovaná verze 0.99.9
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
testovaná verze 1.0.12
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
Bind 9.6 a DNSSEC
Konsorcium ISC nedávno vydalo novou verzi pravděpodobně nejpoužívanějšího DNS serveru Bind. Bind od verze 9.6 kromě pravidelných oprav chyb a vylepšení přináší také zlepšení podpory pro technologii DNSSEC.
Bind 9.6 konečně podporuje standard NSEC3, který přináší více soukromí do podepsaných zón. Tento standard byl vydán jako RFC5155 před necelým rokem a s novou verzí Bindu je konečně podporován všemi významnými open source DNS servery podporujícími DNSSEC (Bind, NSD, Unbound).
Další novinka by měla výrazně zjednodušit správu DNSSEC podepsaných domén. Bind 9.6 přináší automatické přepodepisování zónových souborů dynamických zón. Osobně jsem ještě neměl čas se podívat na to, jak to celé funguje, protože jsem se zabýval následujícím bodem, ale myslím si, že je to správný krok ke zjednodušení nasazení DNSSECu.
Onen další bod, který mě osobně zaměstnával posledních pár měsíců, je podpora PKCS#11 přímo v Bindu. Nová verze přináší nástroj dnssec-keyfromlabel, který umožňuje vytvořit DNSSEC klíč z dat uložených na kryptografickém zařízení (např. takové ty různé USB tokeny). Mělo by to fungovat s openssl a opencryptoki – tj. musíte mít funkční podporu PKCS#11 v openssl. Dnssec-keyfromlabel pak umí vytvořit dvojici souborů .key/.private ve speciálním formátu, který říká, na kterém zařízení najít soukromou část klíče. Zatím jsem neměl čas vyzkoušet tuto funkci na Linuxu, ale společně s Francisem DuPontem z ISC se nám před týdnem povedlo zprovoznit kartu SCA6000 pod Solarisem 10. Sice to zatím vyžaduje verzi z CVS, ale mám osobně slíbeno od ISC, že tato oprava, kterou je potřeba začlenit do hlavní vývojové větve, bude v další verzi řady 9.6 (tedy pravděpodobně v 9.6.1).
Za další z nových nástrojů pravděpodobně můžu já – dnssec-dsfromkey umí z klíče vytvořit DS záznamy bez toho, aby bylo potřeba podepsat zónový soubor. Nápad na tento nástroj vznikl na základě mé diskuze s inženýry z ISC, že v některých specifických případech trvá podepsání zóny i několik (desítek) minut – a je to dost neefektivní muset podepsat zónu, aby byl soubor s DS záznamy vytvořen.
Poslední věc, která stojí za zmínku je zahrnutí sady nástrojů ZKT do distribučního souboru Bindu (hledejte v adresáři contrib). ZKT obsahuje sadu nástrojů, která umí usnadnit práci s DNSSEC klíči a automatizaci podepisování zónových souborů. Používám jej na automatizaci podepisování našich zón. A také připravuji jeho zabalíčkování do distribuce Debian (a tím pádem časem propadne i do distribucí odvozených), nicméně v současnosti je build systém trochu nevhodný na balíčkování, takže to bude chtít ještě trochu společné práce s autorem na ZKT. A času se nikdy není dost.
Ondřej Surý
Jak zjednodušit DNSSEC?
Minulý týden jsem měl docela pěknou, plodnou debatu s Ondřejem Filipem, Danem Kaminskym a Paulem Wouterem o tom, jak usnadnit použití DNSSECu pro běžné uživatele. Dan je v tom poněkud radikální a vymýšlí systém, kdy by stačilo „nasadit novou verzi“ a všechny spravované domény by byly podepsané, tj. koncový uživatel by nemusel dělat nic. Osobně si myslím, že je to zatím příliš odvážné, a že je zatím potřeba postupovat po menších kouscích. Celé to totiž začíná být složitější ve chvíli, kdy každý doménový registr má vlastní verzi registračního systému a hierarchii dat uvnitř registru.
Nicméně s Paulem jsme pak rozebírali modely toho, jak to zjednodušit a zároveň respektovat různé registrační systémy. Je jasné, že první krok, který je potřeba udělat, bude vždycky muset být ruční – jedná se o vytvoření důvěry mezi doménovým registrem a prvotním DNSSEC klíčem. V případě naší národní domény bude zachovaný proces, kdy držitel doménového jména kontaktuje existujícím komunikačním kanálem svého registrátora a ten pošle zabezpečeným kanálem přes EPP protokol přidání (nebo změnu) DNSSEC klíče do centrálního registru.
Další krok už lze automatizovat. Pokud použijeme specifikaci RFC5011, která říká, jakým způsobem lze měnit DNSSEC kořeny důvěry, tak existuje možnost, že by DNS server podepsané domény mohl poslat speciální UPDATE zprávu (podepsanou stávajícím DNSSEC klíčem) o tom, že dochází ke změně DNSSEC klíče. Specializovaný DNS server by tuto zprávu zaznamenal, ověřil změnu a vygeneroval DS záznam pro nový klíč. Celý tento proces by mohl proběhnout bez lidského zásahu.
Na konci jsme se s Paulem dohodli, že tento koncept rozpracujeme ve formě Internetového Draftu a pokusíme se jej standardizovat na půdě IETF.
Docela by mě zajímalo, co si o tomto nápadu myslíte? Své připomínky můžete psát do diskuze níže.
Ondřej Surý
cz = us… aneb ztraceno v překladu
V rámci e-mailové debaty o zavádění DNSSEC s jedním ze zahraničních držitelů domény .cz z Holandska jsem byl upozorněn na zajímavý překladatelský oříšek. Na stránkách technické podpory CZ.NIC najdete wizard, který má uživatelům pomoci projít si procesem zavedení DNSSEC, který obsahuje kroky, jak postupovat. Jelikož je v češtině, použil tento uživatel translate Google a podívejte se na výsledek (klikněte pro zvětšení):
Překlad jména domény je přinejmenším hodně originální :) Z textu je každopádně patrné, že dobrý automatizovaný překlad ještě není možný, snad jen ve filmu.
PT
Informační superdálnice nebo porno?
Informační server Živě.cz ve svém článku Konec internetové pornografie v Čechách tvrdí o webových službách typu Facebook a o internetu obecně, že „podstatnou část těchto transformovaných, nebo zcela nově vzniknuvších informací představuje porno – pornografický multimediální obsah“. A není to jen záležitost tohoto článku, je to klasické klišé, které je možné slyšet z různých stran. Je ale skutečnost opravdu taková? Co tedy nejčastěji najdete na českém internetu resp. českém webu? Budou to ta zmiňovaná spousta porna nebo hodnotné informační zdroje?
V rámci průzkumu mezi weby s adresou obsahující .cz jsme loni náhodně vybrali jeden tisíc domén a prozkoumali je (obsah webu byl hodnocen reálným člověkem), abychom se pokusili tyto otázky zodpovědět. Hledače senzací musím ale zklamat a výše uvedené klišé vyvrátit. Ukázalo se, že český internet je přece jen spíše tou informační superdálnicí; že je prakticky celý tvořen „webovými prezentacemi“, tedy stránkami jednotlivců, firem či institucí. Porno tvoří pouze zanedbatelnou část, která je navíc ještě menší než jsou celosvětové odhady, viz následující graf (čísla jsou pouze za domény, na kterých nějaká webová stránka byla – 85 % ze všech).
Jelikož máme v plánu průzkum opakovat, uvidíme zda se situace změní, případně jestli budeme moci vyvrátit nějaké další „zažité“ tvrzení.
PT
Má k lidem v ČR blíže doména .info? Podle Ministerstva vnitra ano
Lidové noviny přinesly zprávu o spuštění datových schránek, které od 1. července t. r. umožní jednodušší komunikaci mezi občany – ať fyzickými, tak právnickými osobami – a státními orgány.
Že se jedná o věc záslužnou a prospěšnou, je nabíledni. Kromě ochrany životního prostředí (protože ony se ty pověstné pruhované obálky jen tak zničehonic neobjeví, dále jsou tu papíry, které se do nich obvykle vkládají a nakonec to všechno někdo rozváží, povětšinou ne na koni nebo jiném ekologickém prostředku, nehledě na to, že dost často se ten poslední „někdo“ ani nenamáhá oznámit, že na nás taková zásilka čeká) se i ve státní správě přeneseme zase o něco blíž 21. století a budeme více komunikovat elektronicky. Právnickým osobám zapisovaným do obchodního rejstříku bude datová schránka zřízena automaticky, fyzickým osobám, ať už podnikatelům nebo občanům, na žádost.
Co ale na první pohled zarazí je, že Ministerstvo vnitra, které datové schránky zřizuje a spravuje, pro umístění informačního webu (reálně provozovány budou pravděpodobně tamtéž, i když uvidíme) použilo gTLD .info, nikoliv národní .cz, pod kterou funguje např. CzechPoint. Bylo by to logické, zvláště, když se jedná o prostředek mající usnadnit život subjektům v rámci České republiky – TLD je jedním ze znaků, který identifikuje obsah, který je pod doménou umístěn v rámci určitého teritoria, má-li se jednat o oficiální stránku orgánu veřejné správy, očekávat by se dala tím spíše. Tento stav je, bohužel, opět dokladem nejednotném přístupu při využívání možností, které Internet nabízí. Doména datoveschranky.cz je registrována na fyzickou osobu od 7. února 2008, přičemž ministr vnitra Ivan Langer o úmyslu datové schránky zavést informoval již 31. srpna 2007 (viz článek v Hospodářských novinách) a zmíněny jsou také v informační brožuře k eGovernmentu, která vznikla v dubnu téhož roku (k dispozici na stránkách MV ČR). Podobná věc se státní správě už párkrát „povedla“, z relativně nedávné doby lze vzpomenout spuštění služby InfoSoud (doména infosoud.cz Ministerstvu spravedlnosti také nepatří…). Vzhledem k tomu, jak zásadně může funkčnost této domény, samozřejmě za předpokladu, že systém datových schránek bude provozován právě na ní, ovlivnit život mnoha lidí, je překvapivé, že ministerstvo nechá pro tento účel zaregistrovat doménu v registru spravovaném zahraničním subjektem, ačkoliv má fungování CZ.NIC „posichrováno“ memorandem. Lze si těžko představit, pokud by správce .info svoji činnost z různých důvodů na kratší či delší okamžik přerušil nebo dokonce ukončil, rychlé řešení vedoucí k obnovení provozu. Jistě, je to poněkud katastrofická vize, ale v období celosvětových ekonomických problémů ji vyloučit nelze. Mnohem reálnější podobu mohou mít případné potíže se současným držitelem domény datoveschranky.info (ano, ministerstvo není jejím držitelem) nebo s obsahem, který se může objevit na ekvivalentu pod .cz, kam se jistě nemalý počet zájemců o datovou schránku či informace o ní podívá.
Zuzana Durajová
Kde je jádro VoIP pudla?
Jiří Hlavenka komentuje ve svém včerejěím článku situaci na trhu IP telefonie a dodává, že možná právě letos díky aktivitám, které už proběhly nebo jsou v plánu („nahé“ ADSL bez paušálu za telefon, dostupnost mobilních přístrojů s VoIP a snížení propojovacích poplatků za volání do mobilních sítí), bude IP telefonie úspěšnější a dočká se většího zájmu uživatelů. Všechny výše uvedené akce určitě rozjezd VoIP podpoří – s tím nelze než souhlasit. Problematické je ovšem zdůvodnění, proč za poslední léta slovy autora „obor upadl poněkud do letargie – nejenom, že se o VoIP skoro přestalo psát a mluvit, ale příliš se nezvyšuje ani zájem uživatelů.“
Vinu není možné svalovat jen na to, že bylo ADSL vázáno s telefonem, že lidé raději používají mobilní přístroje, vysoké poplatky či „FUD“ šířený díky obrovským marketingovým rozpočtům velkých operátorů. Už i autor naznačuje, že dobrý produkt lze prosadit i jinak než masivní marketingovou komunikací. Každopádně právě marketing vidím jako hlavní důvod prozatímního neúspěchu VoIP operátorů. Marketing totiž není jen komunikace, ale připomeňme si další složky jeho mixu – produkt, cenu a distribuci. Zdá se vám, že se v těchto dalších parametrech VoIP operátoři nějak odlišili od velkých operátorů?
Snad jedině cenou. Přišli s nějakým inovativním produktem či službou? Zkusili prodávat své služby nějakým zajímavým způsobem? Propagací se velkým operátorům nemohou rovnat, to je jasné. Malý rozdíl v ceně ovšem v hi-tech odvětví, kam telekomunikace patři, rozhodně nestačí. Pracovat s cenou je totiž velmi jednoduché i pro velké hráče. Dokud VoIP operátoři nepřijdou s nějakým zajímavým produktem, jako třeba Skype s geniálně jednoduchým telefonem se spoustou doplňkových služeb. Dokud nebudou své služby nabízet neotřelým způsobem, jako například jeden z norských operátorů, který prodává telefonní kity a kredit pro ně na benzinových stanicích. Jestli jediným rozdílem mezi nimi a velkými operátory bude pár haléřů v ceně minutové sazby za volání do Albánie mimo špičku, potom budou stále živořit na okraji.
PT