Organizace IETF vydala v červenci 2026 tři dokumenty naráz: RFC 10002, RFC 10003 a RFC 10004. Popisují protokol CMC a ruší platnost RFC 5272, RFC 5273 a RFC 5274 z června 2008 i jejich společného doplňku RFC 6402 z listopadu 2011. Všechny tři jsou v kategorii Standards Track, tedy plnohodnotná norma, ne informativní popis problému.

Čemu CMC slouží

CMC je zkratka za Certificate Management over CMS, tedy správu certifikátů nad syntaxí kryptografických zpráv. Je to protokol, kterým si zařízení vyžádá u certifikační autority certifikát, nechá ho obnovit nebo zneplatnit. Abstrakt RFC 10002 uvádí dvě potřeby, ze kterých protokol vzešel: rozhraní ke službám vydávajícím certifikáty postaveným na CMS a PKCS #10, a zápis klíčů, které umějí jen šifrovat a podepsat samy sebe neumějí.

Rozdělení na tři dokumenty zůstalo stejné jako v roce 2008. RFC 10002 popisuje strukturu zpráv, RFC 10003 způsoby jejich přenosu a RFC 10004 to, co musí implementace umět, aby byla v souladu s normou.

Otisky se posunuly na SHA-256

Nejpodstatnější změnu nese RFC 10004. Jeho vlastní výčet změn proti RFC 5274 a 6402 ji shrnuje třemi odrážkami: SHA-1 nahradil SHA-256, HMAC-SHA-1 nahradil HMAC-SHA-256 a přibyly algoritmy pro AuthEnvelopedData, tedy pro obsah, který je zároveň zašifrovaný a chráněný proti změně.

V podrobnostech to vypadá takhle. Každá strana musí umět ověřit i vytvořit podpis RSA-SHA256, musí podporovat AES jako šifru obsahu a AES-GCM pro obsah šifrovaný s ověřením, a to včetně dvanáctibajtové jednorázové hodnoty i dvanáctibajtového kontrolního součtu. U prvků, kterými žadatel prokazuje totožnost a držení privátního klíče, stojí SHA-256 a HMAC-SHA256 jako povinné.

Kdo provozuje starší implementaci, o spojení nepřijde. RFC 10004 přidalo odstavec o zpětné slučitelnosti: server smí starší algoritmy dál nabízet, ale měl by podle příchozích žádostí zjišťovat, které certifikáty je vhodné převést na bezpečnější.

Přenos vyžaduje aspoň TLS 1.2

RFC 10003 popisuje čtyři cesty, kterými se zprávy CMC dopravují: souborem, elektronickou poštou, přes HTTP a přímo přes TCP. Změny jsou tu drobnější, zato konkrétní. Místo TLS 1.0 se vyžaduje TLS 1.2 nebo novější a implementace se mají řídit doporučeními BCP 195. Při použití TLS 1.3 nebo QUIC je omezené odesílání časných dat (0-RTT), tedy dat poslaných ještě před dokončením ustavení spojení. Omezené je i zřetězení požadavků nad TCP.

Dokument uvádí i registrovaný port: služba se jmenuje pkix-cmc a poslouchá na TCP portu 5318. Novinka roku 2026 to není. Číslo přidělila IANA už kvůli RFC 6402, které ho v roce 2011 popisuje jako registrovaný port; ve výčtu změn RFC 10003 je uvedené proto, že RFC 5273 z roku 2008 ještě žádné přidělené číslo nemělo. Zápis v rejstříku služeb a portů IANA dnes odkazuje na RFC 10003 a nese datum 13. února 2026. Obě RFC ale port zařazují jinam: RFC 6402 mluví o registrovaném rozsahu, RFC 10003 o rozsahu dynamickém a privátním.

Nad tím vším zůstala věta, kterou nové znění přebírá po svém předchůdci: hlavní přepravou pro CMC má i nadále být HTTP.

Klíče, které neumějí podepisovat

Žádost o certifikát musí být podepsaná. Jenže klíč, o jehož certifikát se žádá, podepisovat umět nemusí. Příloha C v RFC 10002 jmenuje Diffieho–Hellmanovu výměnu klíčů, její eliptickou obdobu a mechanismy zapouzdření klíče (KEM) RSA-KEM a ML-KEM. Ten poslední je postkvantový algoritmus, tedy takový, který má odolat i útoku kvantovým počítačem.

Protokol pro ně má náhradní řešení: podpisový algoritmus, který žádný podpis nevytváří (id-alg-noSignature), a k němu dvojici prvků Encrypted POP a Decrypted POP, kterými autorita ověří, že žadatel klíč opravdu drží. Nové vydání k tomu přidalo ukázkovou výměnu zpráv pro certifikát KEM, ve které je odpověď zabalená strukturou KEMRecipientInfo.

Kde SHA-1 v protokolu zůstal

Věta „SHA-1 nahradil SHA-256“ platí pro požadavky na algoritmy, ne pro celý protokol. Starší verze dvou kontrolních prvků mají otisk zadrátovaný: prvek Identity Proof má napevno SHA-1 a HMAC-SHA1, prvek POP Link Witness rovněž. Tabulka souladu v RFC 10004 přitom u POP Link Witness ve staré verzi žádá „MUST“ po registrační i certifikační autoritě, koncovému zařízení ukládá „SHOULD“. Novější POP Link Witness Version 2 se SHA-256 je povinný pro všechny tři role.

Třetí místo je zmíněný podpis, který podpisem není. Hodnota NoSignatureValue obsahuje otisk žádosti spočítaný algoritmem SHA-1 a dokument u ní rovnou píše, že se má ignorovat a že s tímhle typem podpisu není spojená žádná bezpečnost.

Od konceptu k normě to trvalo bezmála dva roky

Obnovu si vzala na starost pracovní skupina LAMPS (Limited Additional Mechanisms for PKIX and SMIME). Podle evidence IETF vyšla nultá revize konceptu draft-ietf-lamps-rfc5272bis 12. září 2024 a poslední, jedenáctá, 26. února 2026. Editory všech tří dokumentů jsou J. Mandel ze společnosti AKAYLA a S. Turner ze sn3rd.

Do nového znění se promítlo i třináct hlášených chyb ve starších dokumentech, které RFC 10002 vypisuje jmenovitě čísly errat.

Pro provoz z toho plyne, že měnit se nemusí nic ze dne na den, protože zpětná slučitelnost zůstala povolená. Kdo ale píše novou implementaci, má od července jednoznačné zadání: SHA-256, AES-GCM a TLS 1.2 nebo novější. A kdo provozuje starou, dostal v RFC 10004 návod, podle čeho přechod načasovat – podle toho, s čím za ním klienti chodí.

Čínská Ústřední komise pro záležitosti kyberprostoru (Cyberspace Administration of China) zveřejnila 22. července 2026 plán na roky 2026–2030, podle kterého má čínský internet přejít na síť běžící jen s protokolem IPv6, bez zálohy v IPv4. Zprávu popsal server The Register, nezávisle ji potvrdil i server ChinaTechNews.com.

Co plán žádá

Dokument s názvem Implementační plán pro prohloubení technologických inovací a integrovaného využití IPv6 stanovuje, že do roku 2027 má mít Čína 900 milionů aktivních uživatelů IPv6 a protokol má nést 38 % síťového provozu. Do roku 2030 se má počet uživatelů zvýšit na 950 milionů a podíl na provozu na 42 %. Nově připojovaná zařízení mají dostávat adresu IPv6 jako výchozí a síť se má postupně zbavovat překladu mezi IPv4 a IPv6 (NAT) i souběžného provozu obou protokolů, takzvaného dual-stacku, který dnes používá většina zemí včetně Česka. Server ChinaTechNews uvádí, že plán rozepisuje 36 technických úkolů v deseti oblastech.

Rozšíření IPv6+ a SRv6

Plán zároveň žádá další práci na takzvaném IPv6+ – souboru rozšíření, která umí do paketu vložit metadata popisující jeho obsah a navrhnout trasu, kudy má putovat sítí. Jádrem je technologie SRv6 (Segment Routing over IPv6), která má v čínských plánech nahradit starší protokol MPLS a umožnit programovatelné směrování přímo podle záhlaví paketu, tedy bez centrální tabulky tras, kterou dnes drží každý směrovač zvlášť. Podle ChinaTechNews to má hlavně zrychlit a zjednodušit provoz uvnitř průmyslových a finančních sítí.

Proč to znepokojuje analytiky

Server The Register cituje analýzu institutu MERICS (Mercator Institute for China Studies), podle které má IPv6+ „zjevnou přitažlivost pro autoritářské režimy, které chtějí kontrolovat občany“ – protože operátor sítě dokáže metadata v paketu přečíst a podle nich jednat. Zmiňují se dvě možnosti: operátoři by mohli podle typu obsahu účtovat vybraný provoz, třeba video ze služeb jako Netflix nebo YouTube, zvlášť, a čtení metadat by mohlo usnadnit cenzuru – pokud by uživatel musel svůj provoz nějak označit, snáz by se dal dohledat a zablokovat. MERICS podle Registeru upozorňuje, že čínští výrobci telekomunikačního vybavení mají IPv6+ už zabudované ve svých produktech a že se tyto produkty vyvážejí i do dalších zemí.

Dřívější pokus: New IP

Čína se o prosazení vlastní verze internetového protokolu pokusila už dřív. Peking navrhoval Mezinárodní telekomunikační unii (ITU) protokol nazvaný „New IP“, který měl podle kritiků obsahovat obdobné prvky pro sledování provozu. Návrh neuspěl, protože standardy internetového protokolu spravuje organizace IETF, ne ITU. Podle Registeru teď Peking pokračuje v šíření vlastní verze IP jinou cestou – doma legislativně a v zahraničí prodejem síťového vybavení.

Co plán nenavrhuje

Dokument nechce, aby se Čína od běžného IPv6 odtrhla úplně – naopak vyzývá k čínské účasti na vývoji globálních standardů. Zároveň ale plánuje vyvíjet vlastní národní standardy IPv6 a zrychlit jejich vznik v klíčových oblastech, což by teoreticky mohlo časem vést k rozštěpení mezi tím, jak internet funguje v Číně a jinde. Zatím jde ale o plán do roku 2030, ne o hotovou infrastrukturu.

Protokol BGP drží internet pohromadě: jednotlivé sítě si jím oznamují, přes koho se dostanou k cizím adresám. Patnáct let se jeho zabezpečení točí kolem jediné otázky – je ten, kdo adresní rozsah ohlašuje, opravdu jeho držitel? Odpovídá na ni RPKI, tedy podepsaná evidence, kdo smí co ohlašovat. Přehledová práce, kterou v časopise IEEE Communications Surveys & Tutorials vydali autoři z římské Sapienzy, z propojovacího uzlu Namex a z italské agentury pro kybernetickou bezpečnost ACN, ukazuje, kolik problému za tou otázkou zůstává.

Vadný atribut, který v květnu 2025 shodil spojení

V úterý 20. května 2025 v 7 hodin UTC se globálním směrováním rozešla jedna zpráva BGP. Nešlo o únos rozsahu ani o únik trasy: byla to obyčejná aktualizace pro jeden blok /16, jenže nesla navíc atribut Prefix-SID podle RFC 8669, který do vnějšího BGP zpravidla nepatří, a k tomu měl celý vnitřek vynulovaný.

Směrovače Cisco IOS-XR a Nokia SR-OS udělaly to, co předepisuje RFC 7606 o snášenlivosti k vadným zprávám: poškozený atribut zahodily a jely dál. JunOS od Juniperu zprávu poslal beze změny dál a zařízení Arista, která ji od něj dostala, na ni odpověděla shozením celého spojení BGP. Protože přenosové sítě jedou z velké části na Juniperu, ztratily zákaznické sítě s Aristou přístup k internetu, podle rozboru Bena Cartwrighta-Coxe nejspíš až na deset minut. Směrovací servery na propojovacích uzlech běží obvykle na démonu BIRD, který atribut Prefix-SID nezná, takže ho nefiltrovaly a rozeslaly dál.

Cartwright-Cox, který incident rozebral z archivu služby bgp.tools, napočítal kolem stovky zasažených sítí; jmenovitě uvádí mimo jiné Starlink, Zscaler, ByteDance a Disney. Jeho sběrač zpráv přijímá běžně 20 000 až 30 000 zpráv za vteřinu, během příhody to bylo v desetivteřinovém průměru přes 150 000 za vteřinu. Přehledová práce totéž číslo uvádí jako víc než 150 000 aktualizací, které během deseti vteřin viděla celá směrovací soustava; to je jiná veličina než tempo na jednom sběrači.

Podstatné je, že po celou dobu nebylo porušeno nic z toho, co RPKI ověřuje. Arista podle přehledové práce chování změnila ve vydání EOS 4.28.11 a novějších.

Osm tříd v jedné tabulce

Z toho místa práce vychází. Rozděluje útoky na směrování do čtyř nadřazených skupin, uvnitř kterých autoři rozlišují osm tříd. Do manipulace s trasou patří únos předpony a úprava cesty AS_PATH. Konzistence směrování pokrývá nestabilitu tabulky a zbytečné drobení předpon. Porušení pravidel obsahuje úniky tras ve čtyřech směrech podle RFC 7908 a ohýbání vlastních pravidel přes Local Preference, MED nebo délku cesty. Poslední skupina je shození relace vadným atributem – přesně to, co se stalo v květnu 2025.

Autoři sami píšou, že nové druhy útoků neobjevili; většina rozdílů už v RFC i v provozní praxi je. Přínosem má být jednotné pojmenování, díky kterému jde ke každé třídě přiřadit obranu.

Kde ochrana opravdu je

Únos předpony je úspěch s výhradami. Pokrytí objekty ROA roste, jenže pokrytí není vynucování: měření, které práce cituje, sáhlo na více než 28 000 autonomních systémů a ukázalo, že 36,2 % z nich neověřuje původ trasy vůbec a jen 12,3 % má plnou ochranu. Benevolentně nastavený parametr maxLength navíc útočnou plochu spíš rozšiřuje, kvůli čemuž vzniklo RFC 9319.

Ověřování celé cesty řeší BGPsec. Existuje, je naprogramované a prakticky nikde nasazené – jediný účastník na trase, který ho neumí, z ohlášení bezpečnostní údaje odstraní, takže částečné nasazení nemá skoro cenu.

Nejvíc se pohnuly úniky tras. Objekty ASPA jdou od prosince 2025 ukládat do repozitářů regionálních registrů a v době psaní práce jich bylo zapsaných 1 314. Podle rozboru, o který se práce opírá, by nasazení u vhodně umístěných sítí srazilo počet zasažených autonomních systémů až o 96 %. Atribut OTC a komunita Down Only, obojí postavené na rolích z RFC 9234, by při výběrovém nasazení u dobře propojených sítí prvního a druhého řádu potlačily přes 98 % víceskokových úniků.

Zbylé čtyři třídy – nestabilita tabulky, drobení předpon, ohýbání pravidel a shození relace atributem – nemají kryptografickou odpověď žádnou. Ne částečně nasazenou: žádnou. Brání se proti nim limitem na počet předpon, filtrem na délku předpony, omezením zátěže řídicí roviny a filtrováním atributů na směrovacích serverech. Všechno to je místní, reaktivní a ten, koho útok postihne, si to nemá jak ověřit. Poctivá odpověď na otázku, jestli je síť chráněná proti záplavě rozdrobených předpon od souseda, podle autorů zní: „máte limit na počet předpon a naději“ (přeloženo z angličtiny).

Proč nepokryté třídy váží víc než dřív

Rizika posunuly dvě věci. První je aritmetika IPv6. Drobení předpon je v IPv4 omezené tím, co útočník opravdu drží; v IPv6 ne. Z jediného bloku /29 lze vytvořit až 524 288 samostatných bloků /48. Globální směrovací tabulka IPv6 měla podle práce kolem 219 000 záznamů, takže jediné přidělení a jediný směrovač ji můžou víc než zdvojnásobit. Obranou je pevně nastavený strop na počet předpon, jenže ten při přísném nastavení zadusí i legitimní růst – proto ho správci nastavují volně.

Druhá věc je posun pozornosti. Čím víc sítí ověřování původu vynucuje, tím menší je výnos z únosu předpony a tím větší z tříd, které nikdo neověřuje.

Nasaditelné poráží dokonalé

Práce z patnácti let vyvozuje, že návrhy S-BGP, soBGP a psBGP nabízely silnější záruky než cokoli dnes používaného a nedostaly se nikam, kdežto RPKI, evidence IRR a nově ASPA se ujaly, protože je lze zavádět po částech. Náklady přitom nese každá síť sama, zatímco užitek je společný; to je klasický problém kolektivního jednání a podle autorů důvod, proč dobře navržené mechanismy uvíznou. Institucionální páky jako směrnice NIS2 nebo návrh Digital Networks Act tu podle nich hrají roli, jejich účinek ale závisí na vymáhání, které je stát od státu jiné.

Nejméně jistí jsou autoři hranicí mezi útokem a nehodou. Skoro každá příhoda z těch čtyř nepokrytých tříd má po ruce nevinné vysvětlení – špatně nastavené přerozdělení tras, skript, který se pustil dvakrát, chyba výrobce. Právě proto se ty třídy zkoumají málo: kolem událostí, které nejdou nikomu připsat, se těžko staví model hrozby. Sami připouštějí, že riziko můžou přeceňovat, a v článku na RIPE Labs vyzvali správce sítí, ať je opraví.

Práce „Survey on Internet Routing Security: Stakeholder Interests, Current, and Future Research Directions“ vyšla otevřeně pod licencí CC BY 4.0 (DOI 10.1109/COMST.2026.3714569). Její shrnutí pro provozovatele sítí vydal jeden ze spoluautorů 21. července na RIPE Labs.

Vydavatel, odběratel a relé mezi nimi

MoQ, původně zkratka z Media over QUIC, je protokol typu publikuj a odebírej. Vydavatel posílá pojmenované proudy dat, odběratel si je vyžádá jménem a mezi nimi sedí relé, tedy server sítě CDN, který každý proud rozkopíruje všem zájemcům. Relé se přitom nemusí dívat dovnitř toho, co přeposílá, takže jeden vydavatel obslouží velké publikum, aniž by rozesílání řešil sám.

Běží nad protokolem QUIC, tedy nad stejným základem jako HTTP/3. Vlastní specifikace draft-ietf-moq-transport hned v úvodu upozorňuje, že navzdory jménu je k obsahu lhostejná a míří na širokou škálu použití. Vedle živého videa se s ní počítá na videohovory i na zprávy s nízkým zpožděním.

Co nové rozhraní přidalo

Loni Cloudflare zapnul MoQ na každém svém serveru a nechal ho otevřený komukoli bez ověřování. Na zkoušení klientů to stačilo, na provoz ne: kdo nemůže rozlišit, kdo smí vysílat a kdo jen poslouchat, takovou síť na nic důvěrného nepoužije. Na testovací koncové body se podle firmy dodnes denně připojí přes tisíc různých klientů.

Nové rozhraní tohle dělí. Zřízené relé je izolovaný rozsah, ve kterém se jmenné prostory, stopy a objekty jedné aplikace nepotkají s cizími. K němu se vydávají tokeny, tedy přístupové klíče: každý platí buď na vysílání, nebo na odběr, nebo na obojí, může mít dobu platnosti a dá se zrušit samostatně, aniž to shodí ostatní klienty. Relé vznikne jedním voláním rozhraní nebo v administraci a po dobu veřejné zkoušky je zdarma.

Nespouští se přitom žádný nový stroj ani proces. Cloudflare to přirovnává k přidání virtuálního hostitele na webovém serveru, který už běží: infrastruktura je na místě, zřízení k ní jen doplní nastavení a přihlašovací údaje. Klienti se pak připojují na jednu adresu anycast a rozvedení po síti řeší firma.

Standard je o tři návrhy dál

Kolem toho je dobré vědět, jak daleko protokol vlastně je. Hlavní dokument má v evidenci IETF revizi 19 z 6. července 2026 a 149 stran; RFC z něj zatím není. Pracovní skupina má v plánu prací zapsané, že do konce roku 2026 požádá o vydání protokolu pro publikování a odběr. Je to milník skupiny, ne datum vydání.

Cloudflare v oznámení uvádí, že jeho relé rozumí návrhům 14 a 16. Mezi nimi a revizí, na které se pracuje, jsou tedy tři další verze. U protokolu, který se pořád mění, to není maličkost a firma to nezastírá: u rozhraní rovnou píše, že se bude měnit, a odkazuje na dokumentaci kvůli nekompatibilním změnám.

Dvě funkce, které pro protokol nové nejsou

Oznámení jmenuje dvě věci, které podpora návrhu 16 přináší. Zpráva PUBLISH dovolí vydavateli poslat stopu do relé dřív, než si o ni někdo řekne; bez ní musí první objednávka doputovat řetězcem relé až k vydavateli a teprve pak se začne vysílat. SUBSCRIBE_NAMESPACE dovolí odebírat rovnou celý jmenný prostor včetně stop, které v něm přibudou později, třeba další zvukovou stopu spuštěnou uprostřed přenosu.

Ve specifikaci ale nová není ani jedna. Seznam změn v textu návrhu 16 uvádí PUBLISH mezi změnami proti návrhu 11, tedy od verze 12; SUBSCRIBE_NAMESPACE je ještě starší a v šestnáctce se jen přesunul na vlastní proud a oddělil od zprávy PUBLISH. Nové jsou pro relé Cloudflaru, ne pro protokol, a oznámení je popisuje ze svého pohledu.

Návrh o zřizování zatím nikdo nepřijal

Firma zároveň píše, že způsob, jakým se relé zřizuje, sepsala jako dokument IETF, aby ho mohly převzít i jiné sítě CDN. Ten dokument existuje: MoQ CDN Provisioning má pět stran, první a zatím jedinou revizi z 1. března 2026 a platnost do 2. září 2026. Je to individuální podání, ne dokument přijatý pracovní skupinou, a mluví o rozsahu (scope) místo o relé, což Cloudflare v oznámení sám uvádí.

Sledovat se u toho dají tři věci: jestli skupina návrh o zřizování přijme za svůj, jestli se relé posunou na novější revizi protokolu a jestli se do konce roku stihne žádost o vydání. Podle nás je nejzajímavější ta první. Bez společného způsobu zřizování zůstane přenositelné jen samotné vysílání, ne aplikace kolem něj, a přepisovat se pak bude to, co je na každé síti jiné.

Zdroje: oznámení Cloudflaru z 31. července 2026, evidence dokumentů IETF (draft-ietf-moq-transport, draft-englishm-moq-cdn-provisioning) a stránka pracovní skupiny Media Over QUIC.

Dva typy a dva volitelné parametry

Zapsané jsou application/protobuf pro binární podobu a application/protobuf+json pro takzvané ProtoJSON, tedy protobufové schéma promítnuté do JSONu. U druhého z nich je parametr charset povinný a musí být utf-8.

Oba typy berou dva volitelné parametry, a oba jsou zatím prázdné rukávy. Parametr encoding nabývá hodnot binary a json, jenže každý z těch dvou typů dnes připouští právě jednu z nich, takže se dá jen zopakovat, co už plyne z názvu; křížová kombinace se musí považovat za chybu. Parametr version se týká verze zápisu na drátě, ne jazyka schématu, výchozí hodnota je 1 a žádná jiná dnes neexistuje. Dokument obojí popisuje jako zásobu na budoucí rozšíření a k verzi přidává jednu tvrdou větu: klient musí odmítnout data s verzí, kterou nezná.

Vedle toho jsou jmenovitě uvedené tři zastaralé aliasy: application/x-protobuf, application/x-protobuffer a application/x-protobuf+json. Dokument je zapsaný jako informativní, tedy nikoli jako norma, a stojí za ním editor Murray Kucherawy spolu s Warrenem Kumarim a Robem Sloanem z Googlu. Správcem obou zápisů je IETF, kontaktní adresa vede na protobufový tým Googlu.

Rejstřík má zápis dřív než dokument

Kdo si rejstřík typů médií otevře, najde u obou položek datum 21. listopadu 2025 a odkaz na šestou revizi konceptu, ne na hotové RFC. To není nesrovnalost: IANA zapisuje na základě schváleného textu a číslo dokumentu doplní, až vyjde. Prakticky to znamená, že application/protobuf je oficiální o osm měsíců déle, než by se z data RFC zdálo.

Cestu k vydání jde dohledat do dne. První soukromý koncept draft-murray-dispatch-mime-protobuf je z 25. dubna 2025, pracovní skupina DISPATCH si ho převzala 30. května 2025 a poslední, sedmá revize je z 1. prosince 2025. Od prvního zápisu k vydanému RFC uplynulo patnáct měsíců, z toho posledních osm mezi poslední revizí a vydáním.

Co dnes posílají skutečné protokoly

Osmnáct let bez zápisu neznamená, že by si protobuf typ obsahu nevzal. Vzal si ho po svém, tedy s předponou x-, kterou konvence vyhrazuje pro neregistrované věci, a stihl se s ním dostat do specifikací, které se dnes berou jako závazné.

Specifikace Prometheus Remote-Write 1.0 vyjmenovává hlavičky, které odesílatel poslat musí, a je mezi nimi Content-Type: application/x-protobuf vedle Content-Encoding: snappy a vlastní hlavičky s číslem verze protokolu. Stejně tvrdě je to napsané v OTLP 1.11.0, protokolu projektu OpenTelemetry: klient i server musí u binární zprávy nastavit Content-Type: application/x-protobuf, a to v požadavku i v odpovědi.

U JSONové varianty se ty dva texty rozcházejí o něco zajímavěji. OTLP přikazuje pro JSONem zakódovaný protobuf hlavičku application/json, kdežto RFC 9996 chce v takovém případě application/protobuf+json. Není to hnidopišství, jak je vidět z dalšího oddílu.

Proč prohlížeči na příponě +json záleží

Bezpečnostní úvahy zabírají v desetistránkovém dokumentu nejvíc místa a všechny míří na jedno: co se stane, když si prohlížeč přenášená data splete s něčím spustitelným.

Přípona +json podle RFC 6839 říká, že obsah je čisté JSON. Prohlížeč pak umí nasadit ochrany, které mají zabránit tomu, aby cizí stránka data vytáhla přes vložený skript. Kdo pošle ProtoJSON pod obecným typem, tuhle informaci prohlížeči nedá. Dokument proto říká, že pro JSONovou serializaci se musí použít application/protobuf+json, a doporučuje u JSONu vždy vyplnit i znakovou sadu, protože záměna kódování je sama o sobě známý útok.

U binární podoby je rada jiná: kdykoli to jde, zakódovat obsah do base64, aby se nedal přečíst jako aktivní obsah, a řídit se pokyny RFC 9205 proti odhadování typu podle obsahu. K tomu dokument připomíná dvě věci, které se na protobuf snadno navěsí mylně. Sám o sobě neposkytuje žádné zabezpečení, soukromí, integritu ani kompresi. A ověření platnosti UTF-8 u textových polí je volitelné, takže se text může muset zkontrolovat ručně.

Verze schématu není verze drátu

Poslední věc, kterou dokument narovnává, je pojmenování verzí. Protobuf má za sebou proto2, proto3 a takzvané edice 2023 a 2024, přičemž ta poslední je v době psaní aktuální. Všechny se ale týkají jazyka pro popis schématu, ne zápisu na drátě: serializovaný objekt vzniklý pod kteroukoli z nich je slučitelný s kteroukoli jinou.

Slučitelnost bajtů přitom není totéž co slučitelnost významů a dokument to říká na vlastním příkladu. V proto2 se neznámá hodnota výčtu považovala za neplatnou, v proto3 se zachová. Data projdou, výsledek je jiný.

Co se tím mění

Prakticky nic nepřestane fungovat. Zastaralý alias je pořád alias, servery i knihovny, které posílají application/x-protobuf, budou posílat totéž i zítra a nikdo je nenutí přepisovat.

Podle nás je užitečnější ta druhá polovina dokumentu než samotný zápis do rejstříku. Registrace uklidila stůl a dala nové kódy do rukou tomu, kdo něco píše od nuly. Rozdíl mezi application/json a application/protobuf+json je ale konkrétní bezpečnostní pokyn a týká se toho, co běží dnes, včetně telemetrie posílané do prohlížeče. Právě u něj bude zajímavé, jak dlouho potrvá, než se do zavedených specifikací promítne.

Zdroje: RFC 9996 Media Types for Protocol Buffers, rejstřík typů médií IANA, historie konceptu v datatrackeru IETF, Prometheus Remote-Write 1.0 a OTLP 1.11.0.

V červenci 2026 vyšlo RFC 10029 s názvem DNS Multiple QTYPEs. Je na standardizační cestě (Standards Track), autorem je R. Bellis z organizace ISC a řeší požadavek, který podle úvodu normy zaznívá dlouhodobě: dostat víc souvisejících záznamů jedinou odpovědí.

Praktický příklad z textu normy je adresa webu. K jednomu jménu se běžně hledá záznam A (adresa IPv4), AAAA (IPv6) a HTTPS (parametry spojení). To jsou tři různé typy, takzvané QTYPE, a dnes to znamená tři samostatné dotazy.

Dvě volby, ne jedna – kvůli zařízením po cestě

Norma zavádí dvě nové volby rozšiřovacího mechanismu EDNS (RFC 6891). Do dotazu přijde MQTYPE-Query se seznamem typů, které klient chce navíc, a do odpovědi MQTYPE-Response se seznamem těch, které opravdu dostal.

Že jde o dva různé kódy místo jednoho, není nedůslednost. Text to zdůvodňuje ochranou před prostředníky v síti, kteří volby EDNS opisují z dotazu do odpovědi beze změny. Kdyby se použil jediný kód, klient by neměl jak rozlišit server, který jeho žádost zpracoval, od krabice po cestě, která ji jen zopakovala.

Rozšíření platí jak mezi koncovým resolverem a rekurzivním serverem, tak mezi rekurzivním a autoritativním. Nová čísla už má i registr IANA: MQTYPE-Query dostal kód 20, MQTYPE-Response kód 21, oba se statusem Optional.

Víc otázek v paketu: teoreticky ano, prakticky ne

První cesta k témuž cíli vedla přes hlavičku DNS. Ta počet otázek v paketu nese ve vlastním poli, takže víc otázek naráz vypadalo jako otázka formátu, ne protokolu. Norma to shrnuje bez okolků: v praxi to nefunguje.

Dva roky předtím tuhle možnost RFC 9619 (červenec 2024, autoři R. Bellis a J. Abley) uzavřelo natvrdo: mění původní specifikaci DNS tak, aby dotaz typu QUERY směl obsahovat právě jednu otázku. Autor nové normy je zároveň spoluautorem dokumentu, který tuhle možnost uzavřel.

ANY vrátí, co se serveru zlíbí

Druhá cesta byla dotaz s QTYPE=ANY, který se tváří jako „pošli všechno, co máš“. Jenže RFC 8482 v oddílu 4.1 výslovně dovoluje, aby server vrátil jedinou sadu záznamů podle vlastního uvážení – případně místo ní vyrobil náhradní odpověď. Co dotaz ANY vrátí, tedy záleží na serveru.

RFC 10029 obě uličky obchází tím, že mění jen to nutné. Otázka zůstává jedna a seznam typů navíc cestuje jako volba EDNS.

Server může nevyhovět a klient to musí čekat

Norma nedává klientovi žádnou záruku. Když se typ, o který si řekl, v odpovědi neobjeví, znamená to podle textu jednu z několika věcí: rekurzivní server ten záznam nemá v mezipaměti, dílčí odpovědi nešlo sloučit do jedné zprávy kvůli neshodě návratových kódů nebo příznaků, server žádost zpracovat nechtěl, nebo by se překročila přípustná velikost odpovědi.

Ať je důvod jakýkoli, klient musí na chybějící typy poslat samostatné dotazy. Zisk je tedy podmíněný: v lepším případě jeden dotaz místo tří, v horším jeden dotaz navíc.

Amplifikace, kterou norma přiznává sama

Bezpečnostní oddíl neschovává, že rozšíření zvětšuje potenciální zesilovací faktor při útoku odepřením služby – jedna krátká otázka může vyvolat několikanásobně větší odpověď. Druhé riziko je nutit rekurzivní servery k velkému množství práce navíc.

Doporučení zní dát provozovatelům možnost omezit počet požadovaných typů i velikost odpovědi. Konkrétní číslo padne jen jedno: ve veřejném DNS se podle textu jeví jako vhodný strop čtyři typy navíc. V privátních sítích a u objevování služeb DNS-SD mají být přijatelné hodnoty vyšší.

Vznikla u objevování služeb, ne u provozu DNS

Podle soupisu návrhů IETF má dokument delší minulost, než by se u rozšíření o dvě volby čekalo. Jako osobní návrh draft-bellis-dnsext-multi-qtypes byl v listopadu 2023 už na osmé verzi. Pak ho převzala pracovní skupina dnssd, tedy ta od objevování služeb v DNS, a text došel k revizi číslo 14 z 27. února 2026, se kterou čekal ve frontě u redakce RFC.

Stejnou cestou od osobního návrhu přes pracovní skupinu prošlo i červencové rozšíření IMAPu o dávkování schránky.

Registr IANA za tím zatím kousek zaostává: u obou nových kódů k 1. srpnu 2026 pořád stojí odkaz na pracovní jméno dokumentu RFC-ietf-dnssd-multi-qtypes-14, ne na přidělené číslo 10029. Kdo tedy kódy 20 a 21 hledá podle čísla normy, v registru je nenajde.

Náš názor: dva kódy místo jednoho vypadají jako plýtvání číselným prostorem, ale jsou to zaplacené náklady na to, že v cestě mezi klientem a serverem sedí zařízení, která protokolu nerozumějí a jen ho papouškují dál.

Zdroje

• RFC 10029 — DNS Multiple QTYPEs, červenec 2026, Standards Track, R. Bellis (ISC)
• IANA: Domain Name System (DNS) Parameters – registr kódů voleb EDNS0
• IETF: soupis všech Internet-Drafts a RFC – záznamy draft-bellis-dnsext-multi-qtypes-08 a draft-ietf-dnssd-multi-qtypes-14
• RFC 9619 — In the DNS, QDCOUNT Is (Usually) One, červenec 2024
• RFC 8482 — Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY

Kódy voleb, doporučený strop i důvody chybějících odpovědí pocházejí z textu normy a registru IANA; verze návrhů a jejich data ze soupisu IETF, ne z RFC.

V červenci 2026 vyšlo RFC 10022, rozšíření protokolu IMAP nazvané UIDBATCHES. Řeší úlohu, která zní banálně, dokud ji člověk nemusí naprogramovat: jak projít schránku, ve které je zpráv tolik, že se nedají zpracovat najednou.

Dokument je na standardizační cestě (Standards Track) a editorem je D. Eggert. Rozšíření funguje s IMAP4rev1 (RFC 3501) i s novějším IMAP4rev2 (RFC 9051).

Klient řekne velikost dávky, server vrátí rozsahy

Každá zpráva má ve schránce jednoznačné číslo, takzvané UID. Klient dosud musel rozsahy těch čísel odhadovat sám – a špatný odhad znamená buď dotaz, na který server odpoví neúnosně velkou dávkou, nebo zbytečně mnoho drobných dotazů.

UIDBATCHES to obrací. Klient pošle jediný příkaz s velikostí dávky a server mu vrátí hotové rozsahy UID, které schránku rozdělí na stejně velké části. V příkladu z normy má schránka 6 823 zpráv a klient si řekne o dávky po dvou tisících:

C: A143 UIDBATCHES 2000
S: * UIDBATCHES (TAG "A143") 215295:99696,99695:20358,…

Rozsahy chodí sestupně, takže první dávka obsahuje nejnovější zprávy. Kdo chce jen část, přidá rozsah dávek – UIDBATCHES 2000 10:20 vrátí desátou až dvacátou. Pořadí musí být vzestupné; na 4:1 odpoví server chybou BAD s kódem CLIENTBUG.

Proč to nešlo dřív

Klient měl vedle UID k dispozici i pořadová čísla zpráv, ze kterých se dávky sestavovaly snadno. Jenže režim UIDONLY zavedený v RFC 9586 pořadová čísla klientovi odepírá – a právě tam podle abstraktu normy UIDBATCHES pomáhá nejvíc. Bez pořadových čísel totiž klient nemá z čeho dávky poskládat.

Norma počítá s tím, že server to stojí práci

Spočítat rozdělení schránky není zadarmo, a text to říká otevřeně. Klient proto nesmí příkaz opakovat, kdykoli se mu zachce: jen po výběru schránky, po smazání víc než poloviny dávky zpráv a po příchodu stejného množství nových. Server smí ostatní pokusy odmítnout odpovědí NO s kódem LIMIT.

Podobně je omezený rozsah: klient nesmí najednou žádat o víc než 100 000 zpráv, jinak dostane NO s kódem TOOMANY. Opačným směrem norma serveru ukládá, že rozsahy pro 100 000 zpráv zvládnout musí.

Zajímavá je i úleva, kterou dostal server: velikost dávek nemusí sedět úplně přesně. Když ve schránce chybí kus číselné řady, smí vrátit rozsah zaokrouhlený tak, aby se mu počítal snáz. Poslední dávku má přitom ukončit jedničkou – tím dá klientovi jednoznačně najevo, že dál už nic není.

Kde se potká s dalšími rozšířeními

IMAP má rozšíření celou řadu a norma řeší, jak si s nimi UIDBATCHES nepřekáží. U rozšíření MESSAGELIMIT z RFC 9738 (březen 2025), kterým server ohlásí, kolik zpráv zvládne zpracovat jedním příkazem, má klient žádat dávky nanejvýš té velikosti. Menší si zvolit smí.

Norma zároveň radí, co dělat u opravdu velké schránky: server smí na žádost o všechny dávky odpovědět NO [TOOMANY], když je zpráv přes 100 000. Klient počet zpráv ve schránce zná, takže si má rovnou říkat o rozsahy dávek místo o všechny naráz.

Dvacet měsíců a dvaadvacátá revize

Podle soupisu všech návrhů IETF vznikl první text jako osobní návrh draft-eggert-uidbatches-00 3. listopadu 2024. Pak ho převzala pracovní skupina mailmaint a dokument dostal jméno draft-ietf-mailmaint-imap-uidbatches; revize číslo 22 ze 17. února 2026 už čekala ve frontě u redakce RFC.

Naše hodnocení: na rozšíření o jediném příkazu je to hodně kol. Ukazuje to, kolik okrajových případů se u protokolu starého přes třicet let musí dořešit – od prázdné schránky přes souběh s jinými rozšířeními až po to, co má server dělat, když si klient řekne o dávky, které neexistují.

Zdroje

• RFC 10022 — IMAP UIDBATCHES Extension, červenec 2026, Standards Track
• IETF: soupis všech Internet-Drafts a RFC – záznamy draft-eggert-uidbatches-00 (3. 11. 2024) a draft-ietf-mailmaint-imap-uidbatches-22 (17. 2. 2026)
• RFC 9586 — IMAP UIDONLY Extension, režim, ve kterém klient nemá pořadová čísla

Čísla, kódy odpovědí i příklad pocházejí z textu normy; datum prvního návrhu a počet verzí ze soupisu IETF, ne z RFC.

Dvě věty, které se přepsaly

Dokument nepřináší nový protokol ani nové šifry. Mění dvě konkrétní věty v oddílu 3.1.1 staršího RFC 9325 z listopadu 2022, které dosud popisovalo, jak TLS bezpečně nasazovat:

• místo „TLS 1.3 SHOULD být podporováno“ nově platí, že u nových protokolů nad TLS MUSÍ být podporováno,
• a místo „TLS 1.2 MUSÍ být podporováno“ nově platí, že SMÍ být podporováno.

Velká písmena tu nejsou pro důraz. Slova MUST, MAY nebo SHOULD mají v dokumentech IETF přesně dohodnutý význam podle RFC 2119, takže záměna jednoho za druhé je celá změna normy.

Pro nasazení, kde by samotné TLS 1.3 nestačilo, zůstává průchod: nový protokol smí uvést TLS 1.2 jako doplňkovou možnost, ale nesmí být výchozí.

Proč se to netýká DTLS

Výjimka je v dokumentu hned v prvním odstavci a týká se všech verzí DTLS, tedy varianty TLS pro nespolehlivý přenos. Důvod je prostý: DTLS 1.3 zatím není široce dostupné ani nasazené, takže by pravidlo požadovalo něco, co se nedá splnit. Kdo tedy navrhuje nový protokol nad DTLS, řídí se dál doporučeními z RFC 9325.

Čím TLS 1.2 zestárlo

Bezpečnostní oddíl dokumentu jmenuje konkrétní slabiny, kvůli kterých se starší verze opouští. Samo RFC k nim dodává, že TLS 1.2 se nastavit bezpečně dá – jen je to podstatně těžší než u nástupce.

Bez rozšíření je TLS 1.2 zranitelné vůči útokům na opětovné vyjednání spojení a vůči útoku Triple Handshake; útočník při nich vloží do přenášeného textu předponu podle svého výběru. Obrana existuje od RFC 5746, ale musí se zapnout, nebo se opětovné vyjednávání musí vypnout úplně.

Původní způsoby výměny klíčů, tedy výměna přes RSA a Diffieho–Hellmanův postup nad konečnými tělesy, mají vlastní potíže. Ze symetrických šifer dokument jmenuje RC4, jehož proud klíče má využitelné odchylky (RFC 7465), a sady s režimem CBC. U nich stojí za pozornost jedna věta: první pokus naprogramovat je tak, aby trvaly vždy stejně dlouho, zavedl ještě horší zranitelnost, než jakou měl odstranit.

K tomu dokument řadí útoky BEAST, Logjam, FREAK a SLOTH, vůči kterým je TLS 1.3 odolné. A poslední bod se nastavením vyřešit nedá vůbec: zatímco vlastní přenášená data TLS 1.2 šifruje vždy, většina obsahu úvodního vyjednávání zůstává čitelná.

Kvantové počítače jako důvod navíc

Dokument uvádí ještě jeden důvod, tentokrát mířící dopředu. Pracovní skupina pro TLS soustředí své úsilí na verzi 1.3 a novější a TLS 1.2 už rozvíjet nebude – samostatně to konstatuje RFC 9851, vydané rovněž v červenci 2026 týmiž autory. Postkvantová kryptografie se tedy standardizuje jen pro TLS 1.3, a nový protokol, který by trval na 1.2, by se k ní nedostal.

Kdy přesně bude kvantový počítač schopný prolomit dnešní šifry k dispozici, dokument neřeší a výslovně to odsouvá mimo svůj záběr.

Jak to vypadá v hotových protokolech

RFC 9852 ukazuje obě krajní polohy na existujících specifikacích. QUIC vyžaduje TLS 1.3 a předepisuje, že koncový bod musí spojení ukončit, pokud protistrana použije starší verzi. Naopak profil pro DNS přes TLS uvádí jako výchozí TLS 1.2 a 1.3 pouze připouští; u nových specifikací se má tohle pořadí obrátit.

Praktický dopad má i rada pro klienty. Když knihovna umí vyjednat verzi a vybere nejvyšší, kterou obě strany zvládnou, má klient uvést jen tu nejnižší verzi, se kterou je ochoten mluvit – a tou má být podle okolností TLS 1.3, nebo TLS 1.2.

Mimochodem, v seznamu odkazů se skrývá ještě jedna změna: TLS 1.3 už se necituje jako RFC 8446, ale jako RFC 9846 z července 2026.

Zdroje

• RFC 9852: New Protocols Using TLS Must Require TLS 1.3 – plné znění, RFC Editor
• Záznam RFC 9852 v IETF Datatrackeru – stav dokumentu, autoři a historie návrhu
• RFC 9325 – doporučení pro bezpečné nasazení TLS a DTLS, které tenhle dokument mění

Evropský registr internetových čísel RIPE NCC rozdělil poslední volné adresy IPv4 25. listopadu 2019. Od září 2012 měl každý žadatel nárok na jeden blok /22, tedy 1 024 adres; od listopadu 2019 má RIPE NCC jen to, co se mu vrátí, a příděl klesl na čtvrtinu. Vracejí se bloky po zaniklých firmách a dobrovolně odevzdané rozsahy. Kdo o ně stojí, postaví se do fronty. Na stránce čekací listiny, kterou registr obnovuje po třech hodinách, stálo 1. srpna 2026 v řadě 748 místních registrů a ten na jejím čele čekal 457 dní.

Co se z fronty dá dostat

Do fronty se staví místní registr, zkratkou LIR: poskytovatel, hostingová firma nebo kdokoli další, kdo je členem RIPE NCC a přiděluje adresy dál svým zákazníkům. Dostane jeden blok /24, tedy 256 adres, a jen jednou na účet. Podmínky jsou čtyři: žadatel musí být členem RIPE NCC, nesmí od něj nikdy žádnou alokaci IPv4 dostat, adresy musí dál přidělovat zákazníkům a síť musí mít aspoň jeden činný prvek v obsluhovaném regionu. Vrácené bloky navíc projdou karanténou, aby se rozvázala jejich vazba na bývalého držitele.

Kolik toho registr posbírá, sám odhadnout neumí. Ve vlastním popisu píše, že se to předpovědět nedá a že mnoho adres nečeká.

Dvě čísla ze dvou dnů

Registr tatáž data zveřejňuje i v měsíční zprávě pro členy a ta z 29. července 2026 uvádí jiná: 753 registrů ve frontě a 454 dní čekání. Rozdíl není chyba ani jedné strany, jen tři dny odstupu. Fronta se za ně zkrátila o pět zájemců, kdežto čekání toho prvního narostlo přesně o ty tři dny, takže na čele stojí pořád tentýž registr. Zpráva sama den, ke kterému čísla platí, neuvádí; že rozdíl sedí na den, je náš dopočet.

Členů za měsíc ubylo

Měsíční zpráva je zajímavá i jinde. Účtů místních registrů (LIR) bylo 20 658 a za měsíc jich ubylo 124; členů 19 945, o 111 méně. Vlastní rozsah IPv6 mělo 15 783 registrů, tedy o 48 víc. V červnu si členové mezi sebou převedli 1 775 872 adres IPv4, o 137 216 méně než v květnu.

To poslední číslo je vlastně druhá odpověď na otázku, co dělat, když se čekat nechce. Za jediný měsíc změnilo držitele přes devětkrát tolik adres, kolik by jich padlo na celou frontu, kdyby každý z 748 zájemců svých 256 dostal (191 488, náš dopočet). Kdo si adresy koupí nebo pronajme, do fronty se stavět nemusí; zpráva ale neuvádí, za kolik se převádělo.

Čísla v závorkách jsou v té zprávě vždy jen změna proti minulému měsíci, ne trend. Jeden měsíc nestačí na větu o tom, že registr přichází o členy; stačí ale na konstatování, že v červnu ubyli.

Poslední dvojice čísel se týká podepisování tras. Záznamy ROA, kterými držitel adres stvrzuje, který autonomní systém je smí ohlašovat, pokrývaly 76 % adresního prostoru IPv4 a 45 % prostoru IPv6. Právě na tyhle záznamy se opírá kontrola původu tras v BGP.

Za oceánem se čeká na jiných podmínkách

Že fronta na adresy není evropská zvláštnost, ukazuje severoamerický registr ARIN. Volnou zásobu vyčerpal v září 2015 a svoji čekací listinu vede podle jiných pravidel: největší blok je /22, tedy 1 024 adres, ale požádat smí jen organizace, která nedrží víc než ekvivalent /20. Adresy se tam uvolňují hlavně odebráním za neplacení a kdo je z listiny dostane, nesmí je šedesát měsíců převést na nikoho jiného, až na jeden druh převodu podle oddílu 8.2 tamních pravidel.

Rozdíl je v tom, koho která fronta obsluhuje. RIPE dává málo a jen úplným nováčkům, ARIN víc, zato jen malým držitelům. A zatímco u RIPE je to jednou provždy, u ARIN smí organizace po devadesáti dnech od přidělení požádat o další prostor.

Co se právě projednává

Ve stejné zprávě stojí i dva návrhy politik. Návrh 2026-01 chce zjednodušit přidělení prvního čísla autonomního systému; podali ho 7. července 2026 Urban Suhadolnik a Leo Vegoda z PeeringDB, je v diskusní fázi a připomínky se sbírají do 5. srpna 2026. Návrh 2024-01 mění pravidla pro přidělování nezávislých rozsahů IPv6 a čeká na zahájení revizní fáze i na rozbor dopadů.

Obojí se projednává na veřejné poštovní konferenci pracovní skupiny pro adresní politiku, takže je vidět, jak se s posledními adresami IPv4 naloží. Jak se rozhoduje o pravidlech nad tímhle patrem, jsme popsali v článku o nástupci pravidel pro registry IP adres.

Zdroje: stránka čekací listiny RIPE NCC (ověřeno 1. srpna 2026), měsíční zpráva pro členy z 29. července 2026, popis fungování čekací listiny a pravidla čekací listiny ARIN.

Plenární zasedání IEEE 802 se konalo od 12. do 17. července 2026 v montrealském hotelu Le Centre Sheraton. Pracovní skupina, která píše doplněk 802.11bn, tam měla naplánováno dvanáct jednání. Vyřešila na nich zhruba devět set připomínek, z výsledků sestavila návrh označený D2.0 a pracovní skupina 802.11 schválila, že se o něm bude třicet dní hlasovat.

První návrh dostal zelenou až napodruhé

Cesta k prvnímu úplnému návrhu se zadrhla už v květnu 2025. Na varšavském zasedání skupina vyřešila zhruba 1 300 připomínek ze sběru CC50 a uložila editorovi připravit verzi D0.3. Návrh na zahájení hlasování pracovní skupiny ale neprošel. Podařilo se to až v červenci 2025 v Madridu, kde skupina schválila vznik návrhu D1.0 a pětačtyřicetidenní hlasování o něm. Plán počítal s květnem.

Od listopadu 2025 pak skupina na každém zasedání probírá připomínky z hlasování vedeného pod značkou LB291: zhruba 700 v listopadu 2025, 740 v lednu 2026, 1 800 v březnu, 670 v květnu a 900 v červenci. Součet těch pěti čísel dává asi 4 800, úplný ale není: u zářijového zasedání 2025 stránka skupiny žádný počet neuvádí. Každé kolo skončilo novou verzí návrhu, tedy D1.2, D1.3, D1.4, D1.5 a teď D2.0.

Oba návrhy šly do hlasování o dva měsíce později

Tabulka milníků na stránce skupiny vede vedle sebe plánovaný a skutečný termín, takže je to zpoždění vidět: D1.0 v květnu 2025 proti červenci 2025, D2.0 v květnu 2026 proti červenci 2026. Zbytek plánu zatím zůstal beze změny. D3.0 má jít do hlasování v lednu 2027, D4.0 do prvního sponzorského hlasování v květnu 2027, schválení pracovní skupinou i řídicím výborem IEEE 802 je na březnu 2028 a poslední razítko od komisí RevCom a SASB na květnu 2028.

Firma Ofinno, jejíž zástupce ve skupině vede jednu z podskupin pro vrstvu MAC, psala 23. ledna 2026, že se D2.0 čeká v květnu a že termín schválení v květnu 2028 pevně drží. První část odhadu vyšla o dva měsíce vedle, druhá zatím platí.

Zadání projektu nemluví o rychlosti

Co má doplněk přinést, stojí v jeho projektovém zadání, a čte se to jinak, než jak se nová Wi-Fi obvykle prodává. Schopnost, kterou 802.11bn zavádí, se jmenuje Ultra High Reliability, tedy mimořádná spolehlivost, a stojí na třech číslech. Všechna se poměřují proti provozu Extremely High Throughput, což je stav, ze kterého se vychází:

• aspoň jeden režim, který zvýší propustnost o 25 %, měřeno na rozhraní datové služby MAC a stačí to při jediné hodnotě odstupu signálu od šumu a rušení,
• aspoň jeden režim, který o 25 % sníží zpoždění v 95. percentilu jeho rozdělení, tedy u té dvacetiny přenosů, které čekají nejdéle,
• aspoň jeden režim, který o 25 % sníží ztrátovost jednotek MPDU, což jsou rámce vysílané vrstvou MAC, a to hlavně při přechodu mezi dosahy dvou přístupových bodů.

K tomu má doplněk snížit spotřebu přístupových bodů včetně mobilních, zlepšit spojení dvou zařízení přímo mezi sebou a zachovat slučitelnost se staršími zařízeními v bezlicenčních pásmech 2,4, 5 a 6 GHz. Celý projekt se týká nosných kmitočtů od 1 do 7,25 GHz.

Podmínka „aspoň jeden režim“ a „aspoň jedna hodnota odstupu“ je na tom to podstatné. Zadání nežádá o čtvrtinu rychlejší Wi-Fi za všech okolností. Žádá, aby existoval alespoň jeden případ, ve kterém se toho dá dosáhnout.

Jméno Wi-Fi 8 na stránce skupiny nepadne

Přehledová stránka pracovní skupiny značku Wi-Fi 8 neuvádí ani jednou; mluví o 802.11bn a o UHR. Výrobcům to nebrání. Broadcom oznámil 27. května 2026 spolu se Samsungem referenční platformu pro pevný bezdrátový přístup, ve které je čip BCM6776 popsaný jako Wi-Fi 8 SoC a norma jako vznikající Wi-Fi 8 (IEEE 802.11bn).

Co ta platforma umí, firma popisuje konkrétně: dva prostorové toky a kanály 40 MHz v pásmu 2,4 GHz, čtyři toky a kanály 160 MHz v pásmech 5 a 6 GHz, k tomu čtyřjádrový procesor Arm. Poloviční spotřeba v provozu proti předchozí generaci je údaj Broadcomu a nezávisle změřený zatím není. V oddílu o dostupnosti pak stojí, že běží zkoušky u operátorů a vzorkování pro výrobce zařízení. Prodej ne.

Co bude dál

Třicetidenní hlasování o D2.0 přinese další balík připomínek a ty se budou probírat na dalších zasedáních. Skupina si na to už schválila samostatné jednání v Bangkoku od 4. do 6. listopadu 2026, tedy hned před tamním plenárním zasedáním IEEE 802 od 8. do 13. listopadu. První zařízení s nálepkou Wi-Fi 8 se podle lednového odhadu Ofinna mají objevit na konci letošního roku. Norma, na kterou se budou odvolávat, bude mít v tu chvíli podle plánu před sebou ještě dvě kola hlasování.

Zdroje: přehledová stránka pracovní skupiny IEEE P802.11bn, termíny plenárních zasedání IEEE 802, rozbor lednového zasedání od firmy Ofinno a tisková zpráva Broadcomu z 27. května 2026.

Odkud ta čísla jsou

Měření nestojí na vlastním skenování, ale na denních snímcích DNS, které pro žebříček Tranco top-1M zveřejňuje platforma OpenINTEL univerzity v Twente, sdružení SURFnet a laboratoře SIDN Labs. Z milionu domén jich má MX záznam zhruba 659 000 a SPF záznam 618 000; procenta níž se počítají z těch, které záznam mají, ne z celého milionu. Archiv OpenINTEL sahá do roku 2016, takže se dá tatáž metoda pustit zpětně. Historie před rokem 2022 ale stojí na starším žebříčku Alexa, který má jiné složení – rok 2016 a dnešek tedy nejsou tentýž seznam domén.

Jméno každého poštovního serveru se pak porovnává se slovníkem asi 310 vzorů poskytovatelů. Měření provozuje Artem Berezin ve firmě Live Direct Marketing a seznam jmen, která se zařadit nepodařilo, zveřejňuje s každým denním během.

Odchod z portu 25

V roce 2016 mělo vlastní poštovní server 44,6 % domén s MX záznamem. Ve snímku z 18. července 2026 je to 22,4 % a pokles pokračuje: za posledních třicet dní ubylo dalšího půl procentního bodu. Port 25, na kterém si servery mezi sebou předávají poštu, tak na většině domén obsluhuje někdo jiný.

Kdo ji převzal, není překvapení. Google Workspace přijímá poštu za 21,8 % domén, Microsoft 365 za 16,8 %. Dohromady 38,6 %. Třetí v pořadí, bezpečnostní služba Proofpoint, má 1,9 % – mezi druhým a třetím místem je propast.

Berezin z toho nedělá zprávu o trzích, ale o odolnosti, a ta úvaha sedí: výpadek, změna filtrů nebo rozhodnutí o pravidlech u kteréhokoli z té dvojice zasáhne naráz šestinu až pětinu měřených domén, u obou naráz víc než třetinu. U sítí pro doručování obsahu se o téže koncentraci mluví roky. U pošty je rozdíl v tom, že nemá záložní cestu – odmítnutá zpráva prostě není.

Starší měření ukazuje týž směr, jiná čísla

Tohle není první pokus stejnou věc spočítat. Šestice autorů z UC San Diego a univerzity v Twente popsala v roce 2021 na konferenci IMC práci Who's Got Your Mail?, kde nad žebříčkem Alexa vyšlo, že pět největších firem obsluhovalo v roce 2017 40,1 % MX záznamů a v červnu 2021 už 49,0 %. Google v té řadě rostl z 26,2 na 28,5 %, Microsoft ze 7,9 na 10,8 % a podíl domén s vlastním serverem klesal z 11,7 na 7,9 %.

Směr obou měření je stejný, čísla se ale srovnávat nedají. Starší práce považuje za samostatný provoz jen doménu, jejíž poštovní server se jmenuje stejně jako ona sama, což je definice mnohem přísnější než v novějším měření – proto těch 7,9 % proti 22,4 %. Liší se i seznam domén: Alexa proti Tranco. A úplně nezávislé ty dva pohledy nejsou, protože i studie z roku 2021 brala historická data z OpenINTEL.

DMARC se vydává, nevynucuje

Druhý nález se týká ověřování odesílatele. DMARC je záznam, kterým doména příjemcům říká, co dělat se zprávou, která se jejím jménem tváří neprávem. Publikuje ho 458 467 domén z měřeného vzorku, jenže vynucuje ho jen 46,9 % z nich – tedy má nastaveno „dej do karantény“ nebo „odmítni“ pro veškerou poštu. Zbytek žádá příjemce, aby nedělal nic.

Zajímavější než ta úroveň je směr. Podíl vynucujících domén za posledních třicet dní klesl o 0,44 procentního bodu. Vzestup publikace přitom měl jasnou příčinu: pravidla Gmailu od roku 2024 vyžadují po odesílatelích nad 5 000 zpráv denně SPF, DKIM i DMARC. Nastavit se ale nemusí nic ostřejšího než „nedělej nic“ a vlastní návod Googlu má takovou politiku i ve vzorovém záznamu, jen na rozdíl od většiny těch skutečných s adresou pro hlášení.

Nejlíp to popisují samotné záznamy. Úplně nejčastější DMARC v datech, doslova shodný u 58 064 domén, zní:

v=DMARC1; p=none;

Dalších 32 682 domén publikuje tentýž řetězec bez koncového středníku a tisíce dalších jeho drobné obměny. Jsou to zkopírované začátečnické politiky, které nikdo po zavedení neotevřel. Záznam s p=none a bez adresy pro hlášení navíc nesbírá ani ta hlášení, kvůli kterým by měl smysl.

Mimochodem, jméno _dmarc s podtržítkem na začátku je tentýž způsob vyhrazení jména v zóně, jaký letos v červenci dostal záznam _for-sale pro nabídku prodeje domény.

Ocas, který se nedá pojmenovat

Třetí nález je přiznaná mez metody. Slovník poskytovatelů zvládne přiřadit asi 81,5 % odkazů v SPF záznamech a většinu MX záznamů. Co zbývá, není šum: 36 455 různých jmen poštovních serverů neodpovídá žádnému známému poskytovateli a desítky tisíc cílů v SPF se vyskytují právě na jedné doméně.

Něco z toho je kuriozita – 503 domén z prvního milionu má jako poštovní server uvedený localhost a 130 doslova vlnovku. Většina je ale obyčejný střed internetu: regionální hostingové firmy, ručně postavené servery, firemní brány s vlastním jménem. Právě tahle část je pro výzkum doručitelnosti neviditelná, protože měření, které zná jen velké platformy, ji přehlédne.

Co měření nevidí

Slepá místa autor vypisuje sám a jsou podstatná. SPF záznam, ve kterém jsou odkazy na cizí služby nahrazené holými rozsahy IP adres kvůli limitu deseti dotazů, odesílatele skryje úplně. MX záznamy, které jsou aliasem na známého poskytovatele, se nerozbalují, takže část domén spadne do „neznámo“. Nasazení služeb jako Mimecast nebo Proofpoint pod jménem zákazníka se od vlastního serveru odlišit nedá. A Tranco samo se kloní k americkým a evropským doménám, takže je to obrázek populárního internetu, ne celého.

Podle nás je z těch tří nálezů nejpoužitelnější ten druhý, protože se s ním dá něco dělat hned: doména, která má p=none od roku 2024 a nikdy k tomu nepřidala adresu pro hlášení, si za pár minut může nastavit aspoň sběr zpráv a zjistit, kdo jejím jménem posílá. Konsolidace pošty se z jedné domény ovlivnit nedá, kdežto vlastní záznam ano.

Zdroje: Two Providers, a Stubborn Plateau and a Very Long Tail na RIPE Labs, studie Who's Got Your Mail? z konference IMC 2021, pravidla Gmailu pro odesílatele a platforma OpenINTEL.

Čísla se podle zdroje liší

Cloudflare uvádí průměrných 108 000 požadavků za sekundu, tedy 9 miliard denně, obsluhu z více než 330 datových center a 98,6 % odbavených z vyrovnávací paměti. Web projektu cdnjs.com přitom mluví o „více než 200 miliardách požadavků měsíčně“, což vychází na necelých 6,7 miliardy denně. Údaj na webu je psaný jako spodní hranice a nenese datum, takže si nutně neodporují – jen se nedá říct, které platí dnes.

Stejná nejistota je u rozšířenosti. Cloudflare píše o zhruba 12 % všech webů a 48,3% podílu mezi CDN pro JavaScript. Druhé číslo přesně sedí s tím, co má za červenec 2026 přehled W3Techs; tentýž přehled ale u podílu na všech webech uvádí 11,6 % a cdnjs.com tvrdí „přes 12,5 %“. Odkud čísla bere, Cloudflare ve svém článku neříká.

Rozdělená služba

Servírování souborů odešlo na Workers a úložiště klíč-hodnota KV už v roce 2020. Publikační linka – tedy to, co hlídá npm a GitHub, stahuje nová vydání knihoven a zpracovává je – zůstala na Google Cloud Platform. Byl to řetěz malých funkcí Cloud Functions, virtuální stroj s nástrojem git-sync a repozitář na GitHubu v roli zdroje pravdy.

Cloudflare popisuje pět bolavých míst; čtyři z nich jsou v lince. Nejvíc prý pálila chybějící společná stopa: jeden balíček procházel funkcemi Googlu, frontou Pub/Sub, virtuálním strojem a teprve pak KV, a žádný z nich nesdílel identifikátor, přes který by se protokoly daly spojit. Selhání to nezpůsobovalo. Způsobovalo to částečný úspěch – verze, která se zapsala do KV a pak tiše nedorazila do repozitáře, se týdny servírovala správně, jen se obě úložiště rozcházela a nikdo o tom nevěděl.

Zbylé body jsou z téhož soudku. Soubory ležely na dvou místech a ani jedno nebylo autoritativní. Linka byla slepená přes události nad úložištěm, které tak dělalo frontu, jenže bez fronty nedoručených zpráv. A kontrola novinek na npm potřebovala 26 funkcí, po jedné na každé písmeno abecedy, každou s vlastním nasazením a vlastním protokolem.

Repozitář, ze kterého GitHub neudělá archiv

Nejlíp to je vidět na repozitáři. Cloudflare píše, že cdnjs/cdnjs přerostl 1,1 TB zabalených dat, což je nad možnosti archivační služby GitHubu: tarball ani zip z něj vyrobit nejde. Adresa codeload.github.com/cdnjs/cdnjs/zip/refs/heads/master vrací 31. července 2026 stavový kód 422, tedy odmítnutí, a stejně dopadne i varianta s tar.gz.

Sedí i druhá podrobnost. Soubor .gitignore, kterým se linka bránila rozbitým a podivně očíslovaným vydáním, má dnes 295 řádků. Z nich 275 začíná cestou /ajax/libs/ a jeden z těch řádků je vzor pro značku robota, takže ručně zablokovaných složek je 274 – přesně tolik, kolik Cloudflare uvádí.

Jedna věc ale v článku chybí. Poslední commit v repozitáři je z 30. září 2025, 9:10 UTC, a jmenuje se „update last sync marker“. Zrcadlení se tedy zastavilo devět měsíců předtím, než migrace skončila, a co se v mezidobí dělo, se z textu nedozvíte. Repozitář zůstává otevřený, ne archivovaný.

Jak to běží teď

Zdrojem pravdy je objektové úložiště R2. Nemá praktický strop na velikost, takže se do něj vešly i soubory, které se do KV nevešly – mapy zdrojového kódu, velké svazky, balíky s písmy. Přístup přes rozhraní S3 znamená, že se katalog dá číst běžným klientem; kdo si chce postavit vlastní zrcadlo, má podle Cloudflare založit hlášení v repozitáři a dostane přístupové údaje jen pro čtení. V KV zůstala metadata: informace o balíčcích, seznamy verzí a otisky SRI, tedy kontrolní součty, kterými si prohlížeč ověřuje, že mu CDN vydala přesně ten soubor, jaký autor stránky čekal.

Obsah se navíc zrcadlí do úložiště Spaces u DigitalOceanu, který cdnjs dlouhodobě sponzoruje. Není to jen záloha pro případ havárie: servírovací Worker si tam sáhne pokaždé, když R2 soubor nevydá. Řetěz je vyrovnávací paměť, pak R2, pak DigitalOcean. Zatím v něm zůstává i původ hostovaný u Cloudflare, dokud se do R2 nedoplní zbytek obsahu z GitHubu.

Publikační linku řídí Workflows. Každých deset minut ji nastartuje plánovaná úloha, která se ptá npm a GitHubu na nové verze; pro každou spustí stažení archivu do R2 a pro každý soubor zvlášť zpracování, tedy rozbalení, minifikaci a kompresi. Poslední krok zapíše výsledek do R2 a KV a doplní vyhledávací index Algolia.

Komprese běží jako služba v Rustu v kontejneru vedle: algoritmy potřebují celou knihovnu v paměti naráz, což Worker neunese, a přepis na proudové zpracování teprve čeká.

Napoprvé se migrace musela vrátit

Přesun obsahu měl dřívější, neúspěšný pokus. Tehdy chtěl Cloudflare stará vydání znovu zpracovat a zapsat rovnou do R2, jenže minifikátory a kompresory nedávají mezi verzemi bajtově shodný výstup. Nové soubory byly správné, ale měly jiné otisky SRI, a kdo si otisk zapsal do stránky, tomu by se knihovna přestala načítat. Pokus se vrátil zpátky a napodruhé se obsah z KV do R2 kopíroval tak, jak byl.

Tím se úloha změnila na „přesunout miliony souborů mezi účty a žádný neztratit“ a narazila na strop tisíce podřízených požadavků na jedno spuštění Workeru. Práci proto rozsekali podle jména balíčku a rozehnali přes fronty, které ručí za doručení alespoň jednou. Oba stropy, na které při tom narazili – tisíc podřízených požadavků a 1 024 kroků na jeden workflow –, si nechali od vlastních týmů zvednout.

Tady se vyplatí být přesný, protože blog je volnější než dokumentace. Cloudflare píše, že podřízených požadavků je teď „až deset milionů“ na placených tarifech. Dokumentace Workers, naposledy aktualizovaná 28. července 2026, uvádí ve výchozím stavu 10 000 na jedno spuštění; deset milionů je strop, na který si limit smíte zvednout v nastavení nástroje Wrangler. U workflow to sedí bez výhrad – dokumentace Workflows uvádí výchozích 10 000 kroků a možnost jít na 25 000.

Co zůstává otevřené

Cloudflare sám přiznává, že otisky SRI uložené ze staré linky nemusí kvůli jejím chybám odpovídat skutečnosti a že se to teprve rovná. U služby, jejíž hlavní argument je neměnný a otiskem ověřený obsah, je to ta podstatná výhrada.

Bez čísla nechává Cloudflare i tvrzení, že po cdnjs sahají jazykové modely, protože je jich plná trénovací data. Zní věrohodně a z článku se ověřit nedá.

Změnila se ještě jedna věc, kterou blog nepojmenovává. Zdrojem pravdy byl veřejný repozitář, který si mohl kdokoli naklonovat – byť poslední roky těžko. Dnes je jím úložiště, jehož obsah se dá číst běžným klientem S3, ale vlastní zrcadlo si zřídíte až po domluvě. Katalog knihoven zůstává otevřený a zadarmo; kopie celé sbírky je nově na pozvání.

Zdroje: článek Dogfooding at scale na blogu Cloudflare, údaje o repozitáři cdnjs/cdnjs z API GitHubu, soubor .gitignore v témž repozitáři, statistika W3Techs za červenec 2026 a popis nastavení limits v konfiguraci Wrangleru.

Co je ClaimReview

Vyhledávač na stránce nepozná, že jde o ověření tvrzení, dokud mu to někdo neřekne. Slouží k tomu ClaimReview ze slovníku schema.org – blok strojově čitelných dat vložený do zdroje stránky, který nese čtyři věci: jaké tvrzení se posuzuje, kdo ho vyslovil, jak zní verdikt a kdo ho vydal. Zapisuje se do značky <script type="application/ld+json"> a čtenář ho na stránce nevidí.

Google v dokumentaci k té značce hned v prvním odstavci píše, že podporu ClaimReview ve vyhledávání postupně ukončuje („We're phasing out support for ClaimReview markup in Google Search“). Značka tím ale neumírá: podle téže věty ji dál používá Fact Check Explorer, tedy veřejný nástroj, ve kterém se dá vyhledávat mezi ověřeními napříč weby. Nápověda nástroje k tomu dodává, že se do Exploreru články dostanou tehdy, jsou-li vydané v „claim review schema“ a zároveň splní podmínky pro zobrazení ve vyhledávání nebo na YouTube.

Co je na stránkách nešiř to

Zdroj kteréhokoli záznamu na nesirto.cz obsahuje jeden blok strukturovaných dat. Je v něm WebSite, WebPage, Organization, BreadcrumbList a Article – tedy popis webu, drobečková navigace a běžný článek s titulkem, datem vydání a rubrikou. Slovo ClaimReview se v celém HTML neobjeví ani jednou.

Přitom všechny údaje, které by ta značka chtěla, na stránce leží. Verdikt je v odstavci s vlastní třídou (<p class="verdikt verdikt--vyvraceno">), posuzované tvrzení je shrnuté v popisku stránky, datum vydání a poslední úpravy je v bloku Article a rubriky Vyvráceno, Zavádějící a Doloženo tvoří ze tří verdiktů rovnou samostatné výpisy. K 31. červenci v nich bylo deset, dvanáct a nula záznamů; celkem má web podle své sitemapy třicet stránek se záznamem.

Chybí tedy formát, ne data. Kdo chce verdikty z toho webu zpracovat strojově, musí si dneska parsovat HTML a spoléhat na to, že se název třídy nezmění.

V Exploreru není ani jeden český web

Zkusili jsme totéž měření na dalších čtyřech ověřovatelích. U každého jsme stáhli stránku konkrétního ověření prohlížečem a hledali v ní blok ClaimReview, pak jsme se v Exploreru zeptali na výpis podle domény:

Demagog je z té trojice zajímavý. Značku na stránce nemá – oba výroky, které jsme zkusili, nenesou vůbec žádný blok ld+json –, přesto v Exploreru je. To jde: Google provozuje Fact Check Markup Tool, formulář, kterým se dá záznam odeslat bez zásahu do stránky. Podle nápovědy se s takovým záznamem zachází stejně jako se značkou vloženou přímo do článku a uloží se na datacommons.org, odkud si ho vyhledávače berou. Absence značky ve zdroji tedy sama o sobě neznamená, že web v databázi není – u nešiř to a u Manipulátorů to ale znamená obojí naráz.

Všechny tři záznamy Demagogu, které nám Explorer vypsal, jsou z ledna 2021; nástroj přitom výsledky stránkuje, takže jich může být víc. Full Fact měl při témž dotazu nahoře ověření staré dva dny. Datum je tedy jediné, co se z toho dá číst spolehlivě – a pět let stará položka na běžící napojení nevypadá.

Kolik to obnáší

Vložit ClaimReview na stránku znamená doplnit do už existujícího bloku strukturovaných dat další položku. Google u ní vyžaduje dvě pole: claimReviewed se souhrnem posuzovaného tvrzení (doporučuje se vejít do 75 znaků, aby se na mobilu nezalomil) a reviewRating s hodnocením. To druhé chce ještě vlastní povinnou položku alternateName, tedy verdikt slovem – a tam se tři verdikty webu přepíšou rovnou, bez vymýšlení číselné škály.

Podmínky pro zobrazení jsou přísnější než samotný zápis. Dokumentace mimo jiné žádá, aby web měl vlastní postup pro opravy nebo způsob, jak nahlásit chybu, aby čtenář poznal, co přesně se posuzovalo, a aby se posuzované tvrzení jasně přiřklo zdroji mimo vlastní web. První dvě má nešiř to hotové: stránku Jak žádat o opravu i zveřejněné zásady ověřování. U třetí podmínky by záleželo na záznamu – z prvních osmi vede odkaz na archivní snímek rozebíraného obsahu jen u jednoho.

Co ještě web posílá ven

Strukturovaná data jsou jediná věc, která na tom webu chybí, jinak je strojově čitelný nadprůměrně. Vedle sitemapy má RSS i Atom, a v obou posílá celá těla záznamů – soubor feed.xml měl při našem stažení 29 položek a 266 kB, tedy zhruba devět kilobajtů na záznam. Kdo web čte přes čtečku, nemusí klikat na web vůbec.

Navíc má llms.txt, tedy soubor, který v ustáleném tvaru vypisuje stránky webu pro jazykové modely a ze kterého se dá seznam rubrik i s popisy přečíst na jedno stažení. Robotům zakazuje jediný adresář, /upload/, a v humans.txt přiznává, na čem běží: Nette Framework, Alpine.js, Tailwind CSS a Vite.

Náš názor: chybějící ClaimReview je u webu, který jinak dělá otevřenost nadstandardně, spíš opomenutí než rozhodnutí. Praktický dopad je zatím malý, protože ve vyhledávání Google značku stejně utlumuje – jenže Explorer a jeho rozhraní pro strojové čtení jsou pro badatele i pro ostatní ověřovatele jediné místo, kde se dá zjistit, že už někdo totéž tvrzení rozebral. Kdo se do něj nezapíše, ověřuje potichu.

Zdroje: dokumentace Googlu ke značce ClaimReview, nápověda k Fact Check Tools, definice ClaimReview na schema.org a vlastní měření zdrojů stránek pěti ověřovacích webů z 31. července 2026.

Na adrese aisvetem.cz běží od 30. července český web o umělé inteligenci. Prohlédli jsme si ho tak, jak si ho může prohlédnout kdokoli – z veřejných stránek, kanálu RSS a mapy webu.

Co na webu je

Rubrik je sedm a drží se techniky: Infrastruktura, Modely, Bezpečnost, Nástroje, Licence a podmínky, Čísla a U sebe doma. Poslední z nich míří na provoz modelů na vlastním stroji – téma, které se v českém psaní o umělé inteligenci objevuje málokdy.

Kanál RSS je na dvou adresách, feed.xml a atom.xml, a nese celé texty, ne jen upoutávky. Kdo web čte ve čtečce, nemusí na něj vůbec chodit. Obvyklá adresa /rss ale vrací 404, takže ji čtečka podle konvence nenajde.

Mapa webu má sedmnáct adres. Soubor robots.txt zakazuje robotům jediný adresář, /upload/, odkazuje na mapu webu a v komentáři i na llms.txt – strojově čitelný přehled stránek s jednovětými popisy, který si v poslední době pořizují weby kvůli jazykovým modelům.

Odkud bere doklady

Nejzajímavější je, kam vedou odkazy. Ven jich z článků míří v průměru 7,2 na text a není mezi nimi jediný článek bez odkazu.

Ještě víc řekne, na jaké domény. Osm nejčastějších vypadá takhle: github.com osmkrát, huggingface.co šestkrát, status.openai.com pětkrát, status.claude.com, cve.org a anthropic.com po čtyřech, arxiv.org třikrát a thenextweb.com dvakrát. Sedm z těch osmi jsou primární místa – repozitáře, karty modelů, stavové stránky, evidence zranitelností, odborné práce a web výrobce. Zpravodajský server je mezi nimi jediný.

U modelů to má praktický dopad. Karta modelu na Hugging Face je stránka, kterou vydává sám autor vah – jsou na ní parametry, licence i měření, a na rozdíl od zpráv o modelu se dá otevřít i za rok. Stavová stránka poskytovatele zase eviduje výpadky s časy; kdo ji cituje, nemusí věřit tomu, jak dlouhá porucha byla podle uživatelů na sociálních sítích.

Články mají členění: v průměru pět a půl mezinadpisu na text. Většina jich končí větou, která vyjmenuje zdroje pohromadě, takže se nemusí lovit z odstavců.

Co by čtenáři usnadnilo práci

Několik textů stojí na vlastním počítání cizí stránky – kolik záznamů přibylo, kolik verzí vyšlo, kolik repozitářů nese danou licenci. U takového čísla rozhoduje okamžik, kdy se data stáhla, protože zítra bude jiné. Datum stažení uvádí zatím jen jeden článek; u ostatních se čtenář dozví, kdy text vyšel, ale ne, k jakému stavu se číslo vztahuje.

Web dál neuvádí tiráž ani kontakt. V patičce je jednořádkový popis, odkaz na mapu webu a na RSS a řádek „© 2026 AI světem“; jméno autora nestojí ani u článků. Cesta zpět vede jen přes diskusi pod textem, která funguje bez registrace.

Mapa webu nabízí vyhledávačům i adresu /en/. Ta stránka existuje a vrací kód 200, jenže je zatím prázdná – stojí na ní věta, že první článek je na cestě, a to česky.

Naše hodnocení

Podle nás je to na den staré médium slušně postavené a na jednu věc dokonce nadprůměrně: odkazuje k pramenům, ne k přetiskům, což je u témat kolem umělé inteligence vzácnější, než by mělo být. K tomu plné texty v RSS, mapa webu i strojově čitelný přehled stránek. Co mu chybí, je drobnost proti tomu, co už má – tiráž, jméno autora a datum u čísel, která si spočítal sám.

Zdroje

• aisvetem.cz – úvodní strana (kontrolováno 31. 7. 2026)
• Kanál RSS – data o odkazech a členění článků
• Mapa webu a robots.txt
• llms.txt – strojově čitelný přehled stránek

Sedmdesát článků, jedenáct rubrik a jedno chybějící číslo

Mapa webu měla 31. července ráno 84 adres: úvodní stranu, anglickou verzi, dvanáct rubrikových výpisů a 70 článků. U každého článku je v ní zapsaný i obrázek. Rubrik s články je přitom jedenáct – dvanáctá je „O magazínu“, tedy obsahová stránka vedená jako rubrika. Výpis všech článků, který na webu funguje, v mapě naopak není.

Adresy článků končí pořadovým číslem, takže jde spočítat, kolik jich web vydal celkem. Čísla jdou od jedné do 71 a jedno v řadě chybí: článek s číslem 49 v mapě webu není a jeho adresa se nedá odvodit. Buď ho web stáhl, nebo se nikdy nedostal ven.

Kanál RSS nese padesát nejnovějších článků a z jejich časů vychází kadence jedenáct článků 28. července, patnáct 29. července, šestnáct 30. července a osm do 6:48 posledního dne. Starších dvacet článků už se do kanálu nevejde.

Rubrik je jedenáct a počty u nich web vypisuje v postranním panelu: dvanáct článků má Programování, po devíti Internet a sítě, Počítače, Věda a Vesmír, po sedmi Bezpečnost a Energetika, po šesti Technologie a Auta a motorky, pět Umělá inteligence a čtyři Hry. Součet je 83, tedy o třináct víc, než kolik je článků – třináct textů je tedy zařazených do dvou rubrik zároveň.

Délky jsou vyrovnané. Po odstranění značek z kanálu RSS má nejkratší článek 3 256 znaků, prostřední 4 535 a nejdelší 6 729. Odkaz ven má v těle každý z padesáti.

Tři soubory, kterými se web představuje strojům

Vedle obsahu pro čtenáře má web vyplněnou i trojici textových souborů, které si čte software.

Soubor llms.txt je návrh, který 3. září 2024 zveřejnil Jeremy Howard na llmstxt.org. Má jazykovým modelům podat obsah webu ve zhuštěné podobě, kterou zvládnou přečíst rovnou, místo aby se prokousávaly HTML. Formát je předepsaný: nadpis první úrovně se jménem webu, pod ním citace s jednovětým shrnutím, pak sekce s odkazy a nepovinná sekce Optional. Magazín se té struktury drží: soubor má 1 777 bajtů, vypisuje všech jedenáct rubrik s popiskem a v sekci Optional mapu webu a kanál RSS. Opačným směrem jdou projekty, které obsah stránky robotům naopak znečitelňují.

Na adrese /.well-known/security.txt leží kontakt pro hlášení bezpečnostních chyb podle RFC 9116. Je v něm e-mail redakce, platnost do 31. července 2027, kanonická adresa souboru a preferované jazyky. Sám soubor v poznámce uvádí, že ho web generuje.

Třetí je humans.txt a je na něm zajímavý rozpor. Server se v hlavičce odpovědi hlásí jen jako x-powered-by: NKS, což neprozradí nic. V humans.txt ale web sám vypíše, na čem stojí: Nette Framework, Alpine.js, Tailwind CSS a Vite. Jmenuje také dva vývojáře. Pod články samotnými přitom podpis autora není a v kanálu RSS chybí pole autora úplně.

Soubor robots.txt zakazuje robotům jedinou cestu, /upload/, odkazuje na mapu webu a v komentáři pod ní ještě zvlášť na llms.txt.

Co na webu chybí

Anglická verze je v mapě webu uvedená jako plnohodnotná adresa. Kdo ji otevře, najde jednu větu: „Zatím tu nic není. První článek je na cestě.“ Web tak vyhledávačům nabízí k indexaci stránku, na které nic není.

Fulltextové hledání web nemá vůbec. Adresy /hledat i /vyhledavani vracejí chybu 404 a v rozhraní pole na hledání není. Podle nás to při sedmdesáti článcích ještě nevadí; při sedmi stech to bude jiná věc.

Diskuse pod články je zapnutá a prázdná. Pod každým textem stojí „Zatím tu nikdo nediskutuje. Můžete být první.“ Psát jde i bez účtu, registrace jen zařídí, že se příspěvek zveřejní hned a jméno se nemusí vyplňovat pokaždé. U pěti namátkou otevřených článků nebyl jediný příspěvek.

Počítadlo zhlédnutí u článků není, takže čtenost zvenčí odhadnout nejde.

Odběr má web vyřešený jednoduše: v patičce stojí, že nové články se odebírají přes RSS a že e-mailem se neposílá nic a nikam se nepřihlašuje. Kanály jsou dva, /feed.xml a /atom.xml; obvyklejší /rss.xml vrací 404. V kanálu je celý text článku včetně odkazů, ne jen upoutávka, takže soubor váží přes 350 kB a čtenář ve čtečce dostane všechno, aniž by na web došel.

Hlavičky a rychlost

Politika obsahu je utažená: default-src 'self', skripty jen z vlastního webu a jeden povolený otisk vloženého skriptu místo obvyklého unsafe-inline. Výjimka je jediná a je vidět – skripty a spojení smějí i na tel.nks-hub.cz, tedy na měření návštěvnosti. K tomu chodí Strict-Transport-Security na rok, X-Content-Type-Options, omezená odkazovací politika a Permissions-Policy, která zakazuje polohu, mikrofon i kameru.

Tři z těch hlaviček ale odpověď nese dvakrát, pokaždé se stejnou hodnotou: X-Frame-Options, X-Content-Type-Options a Strict-Transport-Security. Shodují se, takže o výsledku nerozhoduje pořadí; je to stopa po tom, že je nastavuje web i server před ním a nikdo je neslučuje.

Úvodní strana váží 29 kB a z našeho připojení se stáhla za 0,15 vteřiny, stránka článku 40 kB za 0,12 vteřiny.

Podle nás je na tom webu nejzajímavější to, co si sám o sobě napsal na stránku O magazínu: že každý text stojí nejméně na dvou nezávislých zdrojích, že se neověřené do článku nedostane a že se rozpor mezi zdroji napíše do textu. Ověřit se to zvenčí nedá, ale odkazy v článcích na primární dokumenty opravdu vedou a fotografie mají u sebe autora i licenci. Chybějící hledání a prázdná anglická verze jsou proti tomu drobnosti, které se dají doplnit.

Zdroje: úvodní strana, stránka O magazínu, mapa webu, kanál RSS, llms.txt, humans.txt a robots.txt webu magazin.chatujme.cz, čtené 31. července 2026; návrh llms.txt a RFC 9116. Hlavičky odpovědi a doby stažení změřeny týž den.

Slovo slop se v angličtině používá pro pomyje a v poslední době i pro zahlcení sítí nekvalitním strojově psaným obsahem. LinkedIn ho v oznámení používá sám, takže ho tady necháváme tak, jak stojí v původním textu.

Mluvčí sítě serveru The Register řekl, že se tlačítko objeví u všech příspěvků i komentářů. Nahlášení přitom nemá jen skrýt jeden text. Podle Srinivasana z něj bude firma učit vlastní klasifikátory, tedy programy, které mají slop poznávat samy.

Co všechno bylo v oznámení

• Obrana proti automatizaci. Síť podle Srinivasana denně zachytí statisíce pokusů o automatický komentář a za poslední dva měsíce zablokovala miliardy dalších pokusů o automatizaci, tedy hromadné publikování a slop.
• Nové a vylepšené klasifikátory na slop a obecně nekvalitní obsah. Mají ubrat slopu hlavně v doporučeném obsahu a v příspěvcích od lidí mimo vlastní síť kontaktů.
• Zkouška soukromého upozornění. Kdo publikuje, uvidí ve svém přehledu statistik, že jeho příspěvek přišel čtenářům neautentický.
• Širší ověřování profilů a firemních stránek a možnost zablokovat komentáře od firemních stránek, které uživatel nechce vidět.

Ruší i vlastní tlačítko, které psalo za pisatele

Nejpodstatnější část oznámení je ta, o které se mluví nejmíň. LinkedIn ruší vlastní tlačítko „enhance your post“, které rozepsaný příspěvek prohnalo modelem a vrátilo ho přepsaný. Nahradí ho korektura, která podle firmy text opraví, ale nezmění pisateli hlas.

Srinivasan k tomu píše i to, proč se lidé podle firmy k modelu uchylují: LinkedIn není místo na jedno slovo a pisatelé se prý cítí jistěji, když si příspěvek nechají projít modelem. Citace jsou přeložené z angličtiny.

Odkud se vzalo číslo 81 procent

Ve stejný den vydala kanadská firma Originality.ai měření, které se pak objevilo skoro ve všech zprávách o tlačítku. Z pěti tisíc veřejných červencových příspěvků delších než sto slov jich její detektor označil 4 061 za pravděpodobně strojové, tedy 81,2 procenta.

Vzorek vznikl tak, že firma sebrala deset stránek výsledků z devadesáti dotazů kombinujících téma a datum, vyhodila příspěvky se špatným datem, kratší než sto slov a duplicity, a teprve pak z nich vybrala pět tisíc. Až potom je pustila přes detektor. To pořadí je důležité, protože vylučuje výběr podle výsledku.

Studie sama píše, kam nedosáhne: pokrývá veřejné příspěvky nalezené jejími dotazy, ne každý příspěvek na LinkedInu a už vůbec ne to, co uvidí konkrétní člověk ve svém výpisu.

Skok proti dřívějším číslům taky není čistá časová řada. Lednové měření téže firmy vyšlo na 53,7 procenta, jenže pracovalo s příspěvky 99 vlivných profilů za rok 2025. Červencový vzorek se sbíral vyhledáváním podle devíti témat. Obojí měří dlouhé příspěvky, ale jinak vybrané.

A do třetice: Originality.ai detektory strojového textu prodává. Vysoké číslo je pro ni obchodní argument. Neznamená to, že je špatně, jen že nejde o nezávislé měření.

Staví klasifikátory a zároveň varuje, že se detektor plete

Nejzajímavější na oznámení je rozpor, který v něm firma nechala stát. Chystá vlastní klasifikátory, a přitom u soukromého upozornění pisatelům píše, že chce zpětnou vazbu od skutečných lidí, ne aby příspěvek posoudil detektor a spletl se. Firma, která se chystá strojové texty poznávat strojem, tedy zároveň říká, že stroj se v tom plete.

Za tím stojí druhé rozlišení, které v oznámení padne natvrdo: umělá inteligence a slop nejsou totéž. Spousta lidí si podle Srinivasana modelem myšlenky jen brousí a chtějí vědět, kdy jim text zní neautenticky. A samotný pojem podle něj přesnou hranici nemá, protože slop se těžko definuje a definice se mění.

Jde o víc než jednu síť

LinkedIn v tom není sám. Podle TechCrunche přidal minulý týden podobný nástroj Substack, který ve spolupráci s firmou Pangram označuje strojově psané texty, a tentýž Pangram podle serveru oznámil tenhle týden devět milionů dolarů nové investice. Ani jeden z těch údajů jsme si u zdroje neověřovali.

Jinou cestou šel vývojářský hosting Codeberg, který zakázal projekty psané převážně modely rovnou v podmínkách užití. Rozdíl je v tom, kdo rozhoduje: Codeberg zakazuje, LinkedIn sbírá hlasy čtenářů a podle nich ladí doporučování.

Co v oznámení není, je jakékoli číslo o dopadu. LinkedIn neuvedl, kolik příspěvků kvůli slopu odstranil nebo přestal doporučovat, ani kdy má být tlačítko všude. Definici slopu firma sama označuje za pohyblivou. Podle nás se tím dopad zvenčí měřit nedá: bez definice a bez počtů zůstane jediným veřejným ukazatelem to, co naměří detektory třetích stran, a ty LinkedIn v témže oznámení označuje za nespolehlivé.

Zdroje: příspěvek Hariho Srinivasana z 30. července 2026, měření Originality.ai z téhož dne, TechCrunch a The Register.

Sítě do něj sahají. Cloudflare zveřejnil 24. července měření, ve kterém ohlásil ze všech svých propojovacích bodů šest testovacích prefixů – tři pro IPv4 a tři pro IPv6 – a každému dal jinou hodnotu ORIGIN. Pak počkal, až se rozšíří po celém internetu, a stáhl je zpátky, aby vyprovokoval hledání náhradních cest. Výsledek: u zhruba sedmdesáti procent pozorovaných tras se hodnota lišila od té, kterou Cloudflare nastavil.

Čtvrtý řádek v rozhodovacím žebříčku

Aby bylo jasné, proč na tom záleží: směrovač si mezi několika cestami k témuž cíli vybírá podle pevného žebříčku. Nejdřív rozhoduje místní preference, pak vlastní trasy, pak délka cesty přes autonomní systémy – a hned čtvrtý v pořadí je právě ORIGIN. Až za ním následují údaje jako vzdálenost k dalšímu skoku.

Hodnoty jsou tři. IGP znamená, že trasa vznikla uvnitř sítě, která ji ohlásila. INCOMPLETE, že se do BGP dostala odjinud, typicky ze statického záznamu. A EGP odkazuje na protokol, který se v dnešním internetu nepoužívá. Nejnižší hodnota vyhrává, takže IGP je nejvýhodnější.

Z tras viditelných na veřejných sběračích RIPE RIS a RouteViews má podle Cloudflare 89,8 % hodnotu IGP, 3,5 % EGP a 6,7 % INCOMPLETE. Víc než desetina tras tedy nese hodnotu, která je v rozhodování znevýhodňuje.

Kdo přepisuje a proč

Motiv je podle Cloudflare peněžní. Když tranzitní poskytovatel přepíše u cizí trasy ORIGIN na IGP, jeho nabídka se u zákazníka posune před konkurenci se stejně dlouhou cestou – a provoz, za který se platí, poteče přes něj. V měření mělo přepsanou hodnotu na IGP 70 % jedinečných cest v IPv4 a 67 % v IPv6.

Nedělá to kdekdo, ale dělají to ti velcí: 26 % z padesáti největších autonomních systémů a 20 % ze sta největších. Cloudflare k tomu dodává, že v jeho pokusu se provoz přesouval k velkým tranzitním sítím na úkor menších.

Existuje i opačný směr. Geoff Huston z APNIC popsal 30. července v poznámkách z jednání IETF 126 ve Vídni druhou praxi – přepisování na dávno vyřazenou hodnotu EGP. Na jednání zazněl důvod od operátora, který ji používá: „…máme směrovače v několika zemích a jedním z hlavních měřítek pro prefixy je vzdálenost k dalšímu skoku. Atribut ORIGIN se vyhodnocuje dřív než ta vzdálenost. Přepsali jsme tedy ORIGIN u tras naučených od ostatních partnerů na EGP, aby trasy ze vzdálenějších směrovačů nebyly upřednostněné…“ (přeloženo). Podle měření historických dat, o kterých Huston píše, se tahle praxe objevuje od roku 2023.

Norma to neřeší, protože to nezakazuje

RFC 4271, které BGP popisuje, k atributu říká: „Hodnota ORIGIN je generována mluvčím, který danou směrovací informaci vytváří. Její hodnota by neměla být měněna žádným jiným mluvčím.“ (přeloženo) V jazyce internetových norem je to doporučení, ne zákaz – a přesně takhle se s tím v praxi zachází.

Návrh, jak z toho ven, na stole je a má českou stopu. Maria Matějka z CZ.NIC podala v listopadu 2025 do pracovní skupiny IDR dokument, který chce ORIGIN prohlásit za částečně volitelný a výslovně dovolit, aby ho sítě „vyčistily“ na nulu, tedy na IGP. Logika je taková, že když se atribut stejně přepisuje nekonzistentně, je poctivější ho z rozhodování vyřadit než předstírat, že něco znamená.

Ten návrh ale vypršel 7. května 2026 a zůstal u jediné verze z 3. listopadu 2025. Datatracker IETF ho vede jako expirovaný individuální příspěvek bez formálního postavení v normalizačním procesu. Starší návrh na úplné zrušení atributu, který zmiňuje Cloudflare, dopadl stejně.

Co si z toho odnést

Nejde o bezpečnostní díru ani o výpadek. Provoz teče dál, jen jinudy, než by tekl, kdyby se všichni drželi normy. Zajímavější je, co ta čísla říkají o povaze internetového směrování: pravidlo, které je jen doporučením a jehož porušení nese peníze, se nedodržuje – a druhá strana pak přepisuje taky, aby vyrovnala podmínky. Cloudflare to v textu nazývá závody ve zbrojení tažené tržbami.

Pro běžného čtenáře z toho plyne jedna praktická věc: trasa, kterou vaše data po internetu urazí, není nutně ta nejkratší ani nejrychlejší. Může to být ta, u které se někomu vyplatilo přepsat jedno číslo v hlavičce.

Zdroje

• Cloudflare: BGP ORIGIN attribute manipulation and its impact on the Internet (24. 7. 2026)
• APNIC Blog: BGP topics from IETF 126 (Geoff Huston, 30. 7. 2026)
• IETF: Scrubbing BGP ORIGIN Attribute (Maria Matějka, CZ.NIC, 3. 11. 2025)

Tři verdikty místo škály

Stránka Zásady ověřování uvádí tři verdikty: vyvráceno pro tvrzení prokazatelně nepravdivé, zavádějící pro případ, kdy „údaje samy o sobě sedí, ale vyvozuje se z nich něco, co z nich neplyne“, a doloženo pro tvrzení, které kolovalo jako sporné a ukázalo se jako pravdivé. Rozbor, který žádné konkrétní tvrzení neposuzuje, verdikt nedostane a je to na něm napsané.

Rozdíl proti obvyklé praxi je v tom prostředním stupni. Většina hodnoticích škál míchá „je to lež“ a „čísla sedí, ale závěr z nich neplyne“ do jedné kategorie částečné pravdy. Tady jsou to dvě různé věci a na první straně přehledu ověření má prostřední verdikt čtyři z pěti vypsaných záznamů.

Pravidla, která si web dal

Ze zásad stojí za zmínku čtyři body:

• Dva zdroje musí být opravdu dva. „Dva odkazy na dva články téhož ověřovatele nejsou dva zdroje. Odkaz na archivní snímek tvrzení a na jeho originál taky ne – je to dvakrát týž text.“
• Rozhoduje datum události, ne datum textu o ní. Zásady si všímají toho, že tisková zpráva vyjde klidně půl roku po studii, o které píše.
• Rozpor mezi zdroji se napíše i s tím, čí je které číslo. Údaj, který stojí jen v přetisku a v originále chybí, se neuvádí ani s výhradou.
• Bez veřejného zdroje se nepíše. Když obsah popsal jiný ověřovatel, agentura, policie nebo soud, cituje se ten; když ho nepopsal nikdo, téma padá. K tomu si web zakazuje vstupovat do neveřejných skupin pod cizí nebo falešnou totožností – tedy metodu, kterou část výzkumu dezinformací běžně používá.
• Hodnocení ověřovatele je názor ověřovatele – a podle zásad to platí i pro státní a evropské instituce, protože „nejsou to neutrální rozhodčí“.

Poslední bod je nezvyklý. Weby, které ověřují dezinformace, se na úřední hodnocení obvykle odvolávají jako na rozhodčí; tady je vedené jako jeden z hlasů.

Odkaz vede na archivní snímek, ne na zdroj

Tiráž vyjmenovává, co web nedělá. Nejmenuje soukromé osoby a píše o příspěvku, ne o člověku. Nepoužívá obrázky vygenerované modelem ani fotografie lidí jako ilustraci k hoaxu. A neodkazuje na živé dezinformační stránky – odkaz vede na archivní snímek.

To poslední je technické opatření s přímým dopadem: odkaz z ověřovacího článku jinak posílá na ověřovanou stránku návštěvnost i odkazovou váhu, takže ji ve výsledcích vyhledávání posiluje. Archivní snímek to nedělá a navíc zůstane čitelný, i když originál zmizí.

Rozsah: jedenáct záznamů a prázdná anglická verze

Web je nový a je to vidět. K 30. červenci 2026 má jedenáct záznamů, nejstarší z 29. července. Rubrik má šest (Pod lupou, Odkud to teče, Jak se to dělá, Archiv bludů, Ze světa, Čísla), ale rozložené jsou nerovnoměrně. Anglická verze na /en existuje a je prázdná – místo výpisu hlásí, že tam zatím není žádný záznam.

Diskuse je vypnutá a podle tiráže má zůstat vypnutá. Web díky tomu neukládá žádný obsah od uživatelů; cenou za to je, že chybu v záznamu nejde nahlásit veřejně pod ním, ale jen zvlášť.

Naše hodnocení: sepsaná pravidla mají cenu jen tehdy, když se podle nich dá web přistihnout. U jedenácti záznamů to zatím nikdo neudělal a na takovém vzorku to ani nejde. Zajímavé bude, jak se seznam veřejně vedených oprav bude plnit – a jestli se bude plnit vůbec.

Karta, která si dělá svou práci sama

DPU (data processing unit) vypadá jako obyčejná síťová karta, jenže má vlastní procesor, paměť a operační systém. Přebírá práci, kterou by jinak dělal hlavní procesor serveru: šifrování provozu, přepínání mezi virtuálními stroji, přístup k síťovému úložišti, filtrování paketů. Hlavnímu procesoru tím zbyde víc výkonu na to, kvůli čemu server vlastně stojí v hale.

Zkratek pro tutéž věc je víc. Intel používá IPU (infrastructure processing unit), Nvidia prodává řadu BlueField, Marvell řadu OCTEON. A každá z těch karet se ovládá jinak: vlastní SDK, vlastní nástroje, vlastní datový model. Kdo v clusteru vymění karty jednoho výrobce za jiné, přepisuje kus obsluhy znovu. Přesně na tohle si tisková zpráva stěžuje, když mluví o roztříštěnosti mezi uzavřenými SDK, nástroji a provozními modely.

Co má vydání přinést

Abstraction je podle zprávy vrstva API nezávislá na výrobci a na hardwaru. Aplikace, orchestrátory a platformy mají díky ní programovat kompatibilní karty bez kódu psaného pro konkrétní model. Zpráva mluví o 26 zapojených repozitářích, které pokrývají API, mosty k hardwaru výrobců, nástroje, napojení na Kubernetes, provisioning a telemetrii.

Druhou částí oznámení jsou OPI Blueprints, tedy hotové vzory nasazení. První oficiální se podle zprávy jmenuje Kubernetes Network Function Offload a spojuje F5/NGINX, Red Hat a další; orchestraci obstarává Red Hat OpenShift, o doručování aplikací se stará F5 NGINX. Vedle toho vydal projekt bílou knihu o roli programovatelné infrastruktury ve věku AI, datovanou 20. července.

„DPU a IPU nabízejí výkonné nové možnosti pro odlehčení, akceleraci, zabezpečení a správu životního cyklu, ale ekosystém potřebuje otevřená API a opakovatelné vzory nasazení, aby mohl růst,“ říká v tiskové zprávě Arpit Joshipura, generální manažer a senior viceprezident pro sítě, edge a IoT v Linux Foundation, která projekt hostí. (Citace je přeložená z angličtiny.)

Co je v repozitářích

Vydání se dá ověřit přímo. Organizace opiproject na GitHubu má 31 veřejných repozitářů, z toho jeden archivovaný. Vydání pojmenované Abstraction Release má osm z nich: opi-api, opi-cni, opi-poc, opi-prov-life, opi-gateway-evpn-cni, opi-mangoboost-bridge, gospdk a otel.

Všech osm nese značku v1.0.0 a datum vydání 28. dubna 2026, tedy tři měsíce před oznámením. Tisková zpráva i zpráva Phoronixu přitom mluví o verzi 0.1.0. Poznámky k vydání jsou u opi-api prázdné. Nejnovější zápis do kteréhokoli z veřejných repozitářů organizace je z 15. července.

Registr vzorů a přehled si neodpovídají

Vzory nasazení má na starost repozitář opi-blueprints. Jeho README označuje soubor blueprints.yaml za zdroj pravdy a přehled BLUEPRINTS.md za strojově generovaný, který má aktualizovat GitHub Actions při každém zápisu. Celý repozitář má jediný commit a žádnou značku.

Ty dva soubory se ale rozcházejí. Registr obsahuje osm vzorů (BP-001 až BP-008), vygenerovaný přehled jich uvádí pět a čísluje je jinak. Ve stavu „publikováno“ je v obou shodně jediný vzor: rozkládání zátěže na vrstvách 4 až 7 přenesené na kartu Intel IPU E2100 pod Red Hat OpenShiftem, podané v září 2024 a naposledy aktualizované 10. března 2025.

I u něj se ale zápisy liší. Registr má tu položku pojmenovanou podle F5 NGINX Plus a odkazuje na loňský článek o nasazení právě s tímhle softwarem, v seznamu softwaru u ní ale stojí F5 BIG-IP Next. Přehled ji vede pod BIG-IP Next a přidává partnera WorldTech IT, který je v registru u jiné položky. Nejmladší přírůstky registru – směrovač VyOS na kartě z ledna 2026 a odlehčení 5G jádra z dubna 2026 – v přehledu chybí úplně. Odkaz na diskusi je u obou těch položek v registru prázdný, přesto přehled u každého vzoru odkazuje na issue s jeho pořadovým číslem. Pod jedničkou je v hlavním repozitáři projektu uzavřený pull request s jednořádkovou úpravou.

Co si z toho odnést

Sjednotit ovládání karet DPU dává smysl a firmy kolem projektu nejsou náhodné: Intel, Nvidia, Marvell, Dell, Red Hat, F5, Keysight a WorldTech IT jsou v registru jmenované jako partneři jednotlivých vzorů. Samotné API v repozitáři opi-api existuje, staví na gRPC a protobufu a dělí služby na sítě, bezpečnost, úložiště, telemetrii a AI.

Náš názor: mezi tím, co oznámení tvrdí, a tím, co je vidět v repozitářích, se rozcházejí. Značky z dubna pod jiným číslem verze, prázdné poznámky k vydání a přehled vzorů, který nesedí na vlastní registr, nevypadají na milník, který se stal tenhle týden. Spíš na shrnutí starší práce sepsané k datu tiskové zprávy. Kdo o nasazení uvažuje, má si tedy sáhnout přímo do repozitářů; jsou veřejné a ověření zabere pár minut.

Další příležitost k porovnání slibů se skutečností bude 15. října, kdy projekt pořádá druhý summit o DPU a IPU v San Jose vedle konference OCP Global Summit.

Zdroje

• Tisková zpráva projektu OPI (30. července 2026)
• Phoronix: OPI Abstraction v0.1 Published With Aiming To Standardize DPU/IPU Ecosystems (30. července 2026)
• Organizace opiproject na GitHubu – značky, data vydání a obsah repozitářů
• Repozitář opi-blueprints – registr vzorů a generovaný přehled
• Bílá kniha projektu OPI (20. července 2026)

Co firma slibovala

Hims & Hers prodává přes internet léky na předpis, mimo jiné na vypadávání vlasů, erektilní dysfunkci, předčasnou ejakulaci, obezitu a duševní potíže. Zákazník vyplní vstupní dotazník a zadá platební údaje.

Podle žaloby stálo na hlavní stránce firmy nejméně do konce srpna 2023 v odpovědi na otázku „How does Hims ensure patient privacy?“ ujištění, že „medical records and sensitive information are only accessed by the medical providers managing your care“ – tedy že ke zdravotní dokumentaci a citlivým údajům se dostanou jen zdravotníci, kteří o pacienta pečují. Reklamy podle žaloby slibovaly „100% online, private, and secure process“, placení influenceři popisovali službu jako „discreet“ a v rozhlasových a televizních spotech zaznělo „totally private“. Všechny citace překládá redakce, v žalobě jsou anglicky.

Měřicí kód a nahrané seznamy zákazníků

Žaloba popisuje dvě cesty, kterými se údaje měly dostat k Metě. Jedna je nahrání seznamů zákazníků, které si platforma spáruje s vlastními účty. Druhá jsou dva nástroje Mety, které firma umístila na svůj web: Meta Pixel a Conversions API.

Meta Pixel, dřív Facebook Pixel, je kousek kódu, který inzerent vloží do své stránky a Meta díky němu sbírá „události“ – co návštěvník na webu udělal. Conversions API sbírá události také, jen jinudy: podle žaloby vytváří přímé spojení mezi serverem, webem, aplikací nebo jiným vnitřním softwarem inzerenta a systémy Mety. Takhle oba nástroje popisuje sama žaloba a dodává, že vybrané události předávaly Metě automaticky. Se Snapem to podle úřadu probíhalo obdobně, tedy nahráváním seznamů uživatelů ke spárování se snapchatovými účty.

Výčet dalších platforem, jejichž měřicí kódy měl web podle žaloby nést, je delší, než se čeká: Microsoft (Bing Pixel a Bing Image Pixel), Google (Google Ads Pixel a Google Ads S2S Pixel), Criteo, MediaBids.com, PartnerCentric, PebblePost.com, Pinterest, Podsights (dnes Spotify Ad Analytics), Reddit, StackAdapt, TikTok, Trade Desk a X. Úřad ho uvozuje slovy „at least the following“, takže ani tenhle seznam není úplný.

To nejzajímavější je začerněné

Zveřejněná verze žaloby se jmenuje doslova Hims-Complaint-Redacted-E-Filed.pdf a je to na ní znát. Odstavec 68, který podle stavby textu popisoval první z obou cest k Metě, je prázdný – následující odstavec začíná slovem „Second“. Prázdné jsou i odstavce 71 až 73, které navazují na popis obou měřicích nástrojů, a několik odstavců v části o účtování.

Z veřejného dokumentu se tedy nedá zjistit, které konkrétní události Meta dostala. Zbývá jen tvrzení úřadu, že šlo o zdravotní údaje a že firma díky nim uměla sestavit reklamní publika s přesností, které by jinak nedosáhla.

Tlačítko, které se objeví až po odškrtnutí léků

Další část žaloby se soukromím nesouvisí. Do roku 2023 šlo podle úřadu předplatné u většiny zákazníků zrušit jen telefonem, e-mailem nebo chatem. V červnu 2022 firma zavedla zrušení na jedno kliknutí v Kalifornii a Coloradu – jenže když pak v červenci 2022 vybírala postup pro několik dalších států a v roce 2023 pro zbytek, sáhla podle žaloby po starší verzi, kterou předtím vyladila tak, aby rušení bránila.

Ta vypadala takhle: zákazník musel vejít do části pro přidávání a odebírání léků z předplatného, odškrtnout tam všechny položky, a teprve pak se ukázalo slovo „cancel“. Ani kliknutí na „cancel subscription“ předplatné nezrušilo. Následovaly zhruba tři až deset anketních otázek, každá na vlastní obrazovce, a potvrzení, že zákazník opravdu chce skončit. Ptaly se například na vedlejší účinky nebo na to, jestli je léčba drahá, a zjišťovaly, jestli má zákazník zájem o nabídku, která by ho udržela. V mobilních aplikacích firmy zrušit předplatné zpočátku nešlo vůbec.

Co na to firma

Společnost Hims & Hers vydala týž den, kdy žaloba padla, na svém newsroomu příspěvek nazvaný „Our Commitment to Privacy“. Slovo FTC ani zmínka o žalobě v něm nejsou. V příspěvku odkazuje na své zásady ochrany soukromí a píše, že údaje sdílené se zdravotníky odděluje od marketingu, nastavuje technologie tak, aby chráněné zdravotní údaje neodcházely, a používá abstrakci a hašování, aby omezila rozpoznatelnost údajů.

Ostřeji se firma vyjádřila na síti X. Podle CNBC v příspěvku uvedla, že žaloba „disregards substantial evidence“ – přehlíží podstatné důkazy –, které úřadu během jeho téměř tříletého vyšetřování poskytla, a že „contorts the law to try to manufacture claims“, tedy ohýbá právo, aby vyrobila nároky. Firma podle téhož zdroje dodala, že si za svým postojem stojí a bude se bránit. Akcie po podání žaloby klesly o deset procent.

Že se o ni úřad zajímá, věděla firma dlouho. Sama žaloba uvádí, že v říjnu 2023 dostal Civil Investigative Demand, tedy úřední výzvu k vydání dokumentů, mimo jiné kvůli možnému porušení zákona ROSCA o online předplatném.

Co bude dál

Úřad žádá soud o trvalý zákaz popsaných praktik, o peněžní plnění pro poškozené a o pokuty podle kalifornského a utažského práva; v případě dvou jmenovaných kalifornských ustanovení až 2 500 dolarů za každé porušení. Komise hlasovala o podání žaloby dvěma hlasy pro, nikdo nebyl proti.

Není to první případ svého druhu. V březnu 2023 oznámila FTC navrženou dohodu se službou pro online poradenství BetterHelp: ta měla zaplatit 7,8 milionu dolarů zákazníkům a dostala zákaz sdílet jejich zdravotní údaje pro reklamu poté, co je předala mimo jiné Facebooku a Snapchatu. Tehdy šlo podle úřadu o první případ, ve kterém vracel peníze lidem kvůli vyzrazení zdravotních dat.

Rozhodne soud. FTC žalobu podává, když má „reason to believe“, že k porušení zákona dochází nebo hrozí, takže zatím nejde o zjištěný stav. Podle nás je na případu nejzajímavější ta technická část: měřicí kód je pro provozovatele webu tak samozřejmý nástroj, že se snadno dostane i tam, kde návštěvník vyplňuje dotazník o duševním zdraví.

Zdroje: tisková zpráva FTC z 29. července 2026, žaloba ve věci 3:26-cv-07871 (PDF, 48 stran), The Register, CNBC, vyjádření Hims & Hers a tisková zpráva FTC k případu BetterHelp z března 2023.

„Ověřené profily, skuteční lidé, žádní roboti.“ Tuhle větu má na úvodní straně skoro každá seznamka a čtenáři neříká nic – je to slib, ne údaj. Ověřitelné jsou až dvě stránky, které skoro nikdo neotevře: podmínky použití a zásady ochrany soukromí.

Ukážeme si to na české službě Najdu Tě?, protože má obojí veřejně a dá se v tom číst bez registrace. Postup je ale obecný a použijete ho kdekoliv.

1. Kdo to provozuje

První věc k ověření není bezpečnost, ale adresa. Seznamka zpracovává datum narození, fotky i soukromé zprávy; když se něco pokazí, potřebujete vědět, komu psát a koho případně žalovat.

Tady je provozovatel uvedený jménem, sídlem a IČem, a to shodně na stránce o službě, v podmínkách i v zásadách soukromí. To je minimum, které má být splněné – pokud se na webu nedá dohledat nic než kontaktní formulář, je to samo o sobě odpověď.

2. Co znamená „ověřený profil“

Slib z úvodní strany má smysl porovnat s tím, co je napsané v podmínkách. Tady stojí, že profily procházejí ruční kontrolou a že si provozovatel vyhrazuje právo profil neschválit, omezit nebo smazat.

Slovo „omezit“ je důležitější, než vypadá. Podmínky totiž popisují postup po stupních: varování, omezení účtu (třeba zákaz posílat zprávy) a teprve pak smazání. Služba, která umí jen dvě polohy – nechat být, nebo vyhodit – obvykle nepoužije ani jednu, protože obojí je nepřiměřené.

3. Co je zakázané

Seznam zákazů v podmínkách je nechtěné přiznání, co se na službě děje nebo očekává. Kromě obvyklého (falešné profily, obtěžování, spam) tu stojí dva body, které míří na skutečné podvody: zákaz nabízet a poptávat placené služby erotického charakteru a zákaz vylákávat od ostatních peníze či osobní údaje.

Ten druhý je podstatný. Nejčastější škoda na seznamkách nevzniká z otravných zpráv, ale z takzvané romantické pasti – kdy si někdo měsíce buduje důvěru, aby si nakonec řekl o peníze. Pokud to podmínky vůbec neřeší, provozovatel s tím nepočítá.

4. Co je zdarma a co ne

Tady jsme narazili na rozdíl, který je poučný i obecně. Úvodní strana hlásá „100% zdarma“ a „žádné skryté platby“. Podmínky to upřesňují: zdarma je registrace, prohlížení profilů, lajky i zprávy, ale existují volitelné kredity na Super like, které jsou po zakoupení nevratné.

Není na tom nic nekalého – ceny se podle podmínek ukazují před dokončením objednávky a zákonná práva spotřebitele zůstávají. Přesto platí: „zdarma“ na úvodní straně a „zdarma“ v podmínkách skoro nikdy neznamená totéž a rozdíl se hledá právě tam.

5. Co se stane s vašimi daty

Zásady soukromí jsou nejnudnější a nejužitečnější stránka na webu. Zajímají nás v nich tři věci.

Co se sbírá: vedle profilu i technické údaje – IP adresa při registraci a přihlášení. Kdo se k tomu dostane: správci služby, poskytovatel hostingu (server podle zásad v EU) a Google, pokud použijete přihlášení přes něj. Jak dlouho: po smazání účtu mají být profil, fotky i zprávy odstraněny, bezpečnostní záznamy nejdéle rok, účetní doklady podle zákona.

Za pozornost stojí i věta o cookies: podle zásad jsou používané jen technické, žádné sledovací ani reklamní. To si navíc můžete sami ověřit v nástrojích prohlížeče – a je to jedna z mála věcí z těchhle dokumentů, kterou lze zkontrolovat zvenčí.

A ještě jedno číslo

Na úvodní straně bylo 28. července 2026 uvedeno, že je registrovaných 24. Web zároveň zmiňuje osm nalezených párů, což je tvrzení provozovatele a z veřejných údajů se ověřit nedá.

Je to připomínka, že u seznamek nerozhoduje jen poctivost pravidel. Služba s poctivými podmínkami a dvaceti čtyřmi lidmi vám partnera nenajde o nic spíš než velká seznamka plná falešných účtů. Počet uživatelů je šestá věc, na kterou se ptát – a ta, kterou provozovatelé uvádějí nejméně ochotně.

Zdroje: veřejné stránky o službě, podmínky použití a zásady ochrany soukromí (obojí účinné od 2. 7. 2026), ověřeno 28. července 2026. Poznámka pro pořádek: magazín a popisovaná služba jsou provozně propojené, proto článek neobsahuje doporučení, jestli se registrovat.

Za poslední rok vzniklo několik protokolů, kterými spolu mají mluvit programy označované jako AI agenti – tedy software, který sám volá cizí nástroje a rozhoduje, co s výsledkem udělá. Blog IETF k tomu jmenuje Model Context Protocol (MCP), Agent2Agent (A2A), Agent Communication Protocol (ACP) a Agent Network Protocol (ANP). Ani jeden z nich není normou IETF.

Ve čtvrtek 23. července se tím na 126. schůzce IETF ve Vídni zabývalo dvouhodinové jednání s označením agentproto. Formát BoF (Birds of a Feather) slouží k tomu, aby se rozhodlo, jestli se má téma vůbec začít řešit; tohle bylo takzvaně WG-forming, tedy s cílem založit pracovní skupinu. Podle zápisu proběhlo od 9 do 11 hodin středoevropského letního času v sále Grand Park Hall 2.

Osm otázek, jedna propadla

Předsedající Leslie Daigle a Orie Steele si na konci nechali zvednout ruce k osmi otázkám. IETF nerozhoduje hlasováním a zápis to u tabulky říká natvrdo: „Not binding — consensus to be confirmed on the mailing list.“ (Nezávazné – konsenzus se potvrdí na mailové konferenci; přeloženo.)

Rozpor je vidět na dvou řádcích. Vznik skupiny s předloženou chartou podpořilo 154 lidí proti 51. Na otázku, jestli je navržený rozsah správný, zvedlo ruku 38 lidí a proti bylo 124. Zápis to shrnuje tak, že sál silně podpořil řešení problému i to, že patří do IETF, kdežto rozsah v předložené podobě podporu nezískal.

Kolik lidí v sále vlastně sedělo, zápis neuvádí: „Attendance figures are not yet available.“ Žádost o uspořádání BoF přitom počítala se dvěma sty účastníky.

Co má skupina podle charty napsat

Návrh charty leží ve veřejném repozitáři aplikační oblasti IETF na GitHubu a slibuje tři věci: protokol pro relace mezi agenty navzájem a mezi agenty a nástroji, rámec popisující stavební kameny celé sady a informační dokumenty s případy užití a rozborem chybějících míst.

MCP a A2A charta jmenuje přímo a počítá s tím, že nový protokol relací využijí: „Examples of protocols that can utilize this include the existing de facto standard agent communication protocols such as the MCP and A2A protocols being worked on by the Linux Foundation.“ (Mezi protokoly, které to mohou využít, patří stávající de facto standardní protokoly pro komunikaci agentů jako MCP a A2A, na nichž se pracuje pod Linux Foundation; přeloženo.) O poslední změně v MCP jsme psali před dvěma dny.

Mimo rozsah charta výslovně nechává implementaci samotných agentů, standardizaci jejich chování a rozhodování, halucinace modelu i návrh uživatelských rozhraní.

Námitky mířily na rámec

Podle zápisu se výhrady točily kolem toho, že skupina si ukousla příliš. Brian Trammell se ptal, jaká je nejmenší použitelná sada primitiv, kterou to nové opravdu potřebuje; podle něj jde jen o programy, které spolu mluví, a nové je na tom to, že se propojení a nasazení mění za běhu. Stephen Farrell s ním souhlasil a šel dál: informace o oprávněních, které se mají po cestě předávat, jsou podle něj velmi složité a nikdo neukázal, že se dají bezpečně zvládnout. Navrhl rámec z charty vypustit a počkat, až někdo předvede funkční ukázku. Eliot Lear řekl, že rámce jsou riziko, a odkázal na starší rámcový dokument RFC, který se podle něj nikdy nenasadil.

Santosh Pallagatti položil otázku mířící na jádro věci: MCP a A2A relace i kontext už zvládají ve velkém a vyvíjejí se pod Linux Foundation – co ty komunity přiměje přepojit se na nový základ od IETF? Přímou odpověď zápis neuvádí; Trammell v téže rozpravě nadhodil, že skupina by mohla popsat sémantiku identifikátoru kontextu tak, aby zapadla do A2A.

Charta se od jednání nezměnila

Soubor s chartou vložil do repozitáře odpovědný ředitel oblasti Charles Eckel 21. července, tedy dva dny před jednáním, a převzal ho z repozitáře jednoho z navrhovatelů. Od té doby se nezměnil: historie souboru k 30. červenci obsahuje jediný záznam. Otevřené návrhy změn na něj ale čekají. Účet britram – tedy Brian Trammell, který o minimální sadě primitiv mluvil na jednání – podal ještě týž den v 15:14 UTC návrh nazvaný „Focused 'minimum viable primitive' agentproto charter scope reduction“. Navazuje jím na starší návrh na zkrácení textu charty z předchozího dne.

Trammell předtím zkusil chartu přepsat celou. Ten návrh podal v 13:45 UTC a po hodině a půl ho zavřel ve prospěch menších úprav. V jeho popisu stojí, že text odvodil jazykový model Claude Opus 4.8 z chatového záznamu jednání a že vyjadřuje názory autora návrhu.

Zápis sestavil model

Není to jediné místo, kde do standardizace protokolů pro AI agenty zasáhla umělá inteligence. Sám zápis z jednání nese poznámku, že ho spolupředsedající Orie Steele sestavil nástrojem Claude Code od Anthropiku s modelem Claude Opus 4.8 – z živých poznámek dvou lidských zapisovatelů, z přepisu chatu na Zulipu a z promítaných slajdů. Za konečnou opravenou verzi podle téže poznámky odpovídají předsedající.

Dokument je zatím koncept. Jména mluvčích a jejich příslušnost jsou podle vlastní hlavičky předběžné a mají se ověřit proti nahrávce a prezenčním listinám. Údaje v tomhle článku tedy pocházejí z konceptu, ne z potvrzeného zápisu.

Skupina zatím není

Stránka agentproto v evidenci IETF vede skupinu jako BoF a u charty uvádí, že schválená není. Odpovědný ředitel oblasti na závěr jednání potvrdil, že vznikne nová mailová konference; tam se má konsenzus potvrdit a tam pokračuje i spor o rozsah. Suresh Krishnan požádal předsedající, ať vypíšou časově omezenou výzvu ke komentářům, aby se diskuse nerozplynula do další schůzky.

V čele návrhu stojí ještě jedno jméno. Jonathan Rosenberg, který spolu s Cullenem Jenningsem stojí za rámcovým dokumentem, je prvním z osmi autorů RFC 3261 z června 2002 – tedy protokolu SIP, na kterém dodnes stojí internetová telefonie. Podle nás je ale výmluvnější poslední řádek tabulky: psát nebo recenzovat návrhy je ochotno 137 lidí, implementovat hotový protokol jen 42.

Zdroje: koncept zápisu z BoF agentproto a stránka skupiny v evidenci IETF, návrh charty a návrhy jejích změn na GitHubu, přehled jednání BoF na IETF 126 a týž text na RIPE Labs. Autorství SIP jsme ověřili v hlavičce RFC 3261, o chystaném jednání psal předem i TechTimes.

Obrazový formát JPEG XL prošel za necelé čtyři roky celým kruhem. Google ho v roce 2022 z Chromu vyhodil i s kódem a odůvodnil to mimo jiné tím, že o něj není v oboru zájem. Letos v únoru se do Chromu vrátil a v červnu ho do svých vydání pro veřejnost přibalila Mozilla. Praktický dopad je zatím nulový: v obou prohlížečích je dekodér ve výchozím stavu vypnutý a zapnout si ho musí uživatel sám.

Poslední krok udělal Firefox 153, vydaný 21. července. Podle záznamu v Bugzille číslo 2040074, který je označený jako vyřešený a přiřazený právě k této verzi, se předvolba image.jxl.enabled nově zapíná sama – ale jen ve vývojářské větvi Nightly. Ve větvi, kterou dostane běžný uživatel, zůstává vypnutá.

Čtyři věty, kterými Google formát pohřbil

JPEG XL je normou ISO/IEC 18181. Samotný souborový formát byl podle Wikipedie schválen 13. října 2021, jádro kódovacího systému 30. března 2022. Chrome ho uměl zobrazit už od verze 91, ovšem jen po zapnutí přepínače.

Konec přišel 31. října 2022, kdy tým Chromu oznámil odstranění podpory ve verzi 110. Server The Register tehdy odůvodnění ocitoval celé; v překladu znělo, že pokusné přepínače a kód nemají zůstávat donekonečna, že „není dost zájmu z celého oboru, aby se v pokusech s JPEG XL pokračovalo“, že nový formát nepřináší oproti stávajícím dost velký přínos na to, aby se zapnul ve výchozím stavu, a že odstraněním kódu se sníží náklady na údržbu.

Právě ten druhý bod vzbudil odpor. Wikipedie k tomu uvádí, že formát ještě před odstraněním veřejně podpořily mimo jiné Facebook, Adobe, Intel, The Guardian, Flickr, SmugMug a Shopify a že se v evidenci chyb Chromia sešla řada hlasů proti rozhodnutí. Jon Sneyers, spoluautor specifikace, to podle téhož zdroje shrnul tak, že došlo k nešťastné dezinterpretaci dat, která vedla k chybnému rozhodnutí. Formát přitom zčásti vyrostl z Googlem vyvinutého kodéru PIK.

Rozhodl přepis do Rustu

Co se od té doby změnilo, není formát, ale jazyk, ve kterém je napsaný jeho dekodér. Původní referenční implementace libjxl je v C++, tedy v jazyce, kde chyba v práci s pamětí bývá rovnou bezpečnostní dírou. A dekodér obrázků je z pohledu útočníka ideální cíl: zpracovává cizí data z libovolné stránky, ještě než na ně uživatel klikne.

Náhradou je jxl-rs, přepis dekodéru do Rustu pod licencí BSD-3-Clause. Sami autoři ho v popisu projektu označují za rozdělanou práci: jde podle nich o „rozpracovanou reimplementaci dekodéru JPEG XL v Rustu, která má být konformní, bezpečná a rychlá“ (v překladu). Do zdrojových kódů Chromia se dostal v prosinci 2025, zapojený byl v lednu 2026.

Chrome 145 vyšel v únoru 2026 už s ním. Podle serveru Phoronix je v něm dekodér schovaný za přepínačem enable-jxl-image-format na adrese chrome://flags. Mozilla postupovala obdobně: Firefox 152 z 16. června 2026 má kód JPEG XL zkompilovaný přímo ve vydáních pro veřejnost, jenže za běhu vypnutý. Zapíná se zaškrtnutím v panelu Firefox Labs v nastavení.

Právě tady se dá snadno přehlédnout, co je vlastně novinka. Položka o JPEG XL stojí v poznámkách k vydání Firefoxu 152 i 153 se stejným zněním, protože oddíl Firefox Labs se mezi verzemi opakuje. Nové v 153 je jen to přepnutí v Nightly.

Mozilla má pořád neutrální stanovisko

Zajímavé je, že Mozilla svůj oficiální postoj k formátu nezměnila. V jejím veřejném seznamu stanovisek k webovým normám stojí u JPEG XL od ledna 2023 hodnota neutral a odůvodnění, které v překladu říká, že JPEG XL má vlastnosti a výkon, jimiž se od jiných formátů může odlišovat, ale přínos není sám o sobě dost velký na to, aby ospravedlnil náklady na přidání dalšího rastrového formátu na web.

Stanovisko a chování prohlížeče si tedy odporují jen zdánlivě. Mozilla dekodér přibalila, ale nezapnula – a dokud ho nezapne, nemusí své stanovisko měnit.

Pro tvůrce webů se zatím nic nemění

Databáze Can I use, která podporu formátů v prohlížečích sleduje, ukazuje smutný obrázek. U Chromu je JPEG XL vedený jako vypnutý ve výchozím stavu od verze 91 až po 154, u Firefoxu od verze 90 po 156. Tabulka přitom nerozlišuje verze, ve kterých kód v prohlížeči vůbec nebyl, od těch, kde jen čeká na přepnutí – pro čtenáře je výsledek stejný. Edge formát nepodporuje vůbec. Jediný prohlížeč, kde JPEG XL funguje bez zásahu uživatele, je Safari od verze 17 – a to jen částečně, pro statické obrázky.

Kdy se přepínač překlopí, nikdo neoznámil. Analýza serveru The Image CDN k tomu píše natvrdo, že kdo vám termín zapnutí ve výchozím stavu tvrdí, hádá. Podmínkou z Googlu je podle téhož zdroje závazek k dlouhodobé údržbě dekodéru.

Prakticky to znamená, že obrázek ve formátu .jxl na webu zatím nemá smysl nabízet jako jedinou variantu. Pro server se nic nemění: prohlížeč, který formát neumí, ho v hlavičce Accept nepožádá a dostane běžný JPEG nebo WebP. Zajímavější to bude teprve ve chvíli, kdy jedno vydání Chromu překlopí přepínač – a při dvoutýdenním cyklu vydávání, na který prohlížeče přecházejí, se to může stát mezi dvěma úterky.

Zdroje

Poznámky k vydání Firefoxu 153 a Firefoxu 152, vývojářský přehled změn ve Firefoxu 153 na MDN, záznam chyby 2040074 v Bugzille, stanovisko Mozilly k JPEG XL, repozitář jxl-rs, zpráva The Register o odstranění z Chromu, Phoronix o Chromu 145, tabulka podpory na Can I use a rozbor The Image CDN.

Napsal ho Marco Davids z laboratoře SIDN Labs, tedy z organizace, která spravuje nizozemskou doménu .nl. Dokument prošel běžným kolečkem IETF včetně veřejného připomínkování a schválení řídicí skupinou IESG, ale není to norma: v hlavičce má kategorii Informational a sám o sobě říká, že popisuje provozní zvyklost a nevyžaduje změnu žádného protokolu. Cesta k němu byla dlouhá. První verze návrhu je z 22. prosince 2022 a než se z ní stalo RFC, dopracoval ji autor do jednadvacáté verze; hlavička hotového dokumentu uvádí červenec 2026 a záznam v Datatrackeru 30. července.

Jak ta cedule vypadá

Držitel přidá do zóny textový záznam pod jménem _for-sale. Podtržítko na začátku není libovůle, ale zavedený způsob, jak si služby v DNS vyhrazují jméno, aby se nesrazily s běžnou doménou; IANA vede jejich seznam a _for-sale do něj přibylo vedle jmen jako _dmarc nebo _acme-challenge.

Obsah záznamu musí začínat značkou verze a za ní smí následovat právě jedna dvojice tag=hodnota:

_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6"

Tagy jsou čtyři a každý cílí na jiného čtenáře. ftxt= nese volný text pro člověka, furi= odkaz nebo kontakt (dokument připouští jen schémata http, https, mailto a tel), fval= požadovanou cenu ve tvaru měny velkými písmeny a částky, a fcod= kód, kterému rozumí jen strany, které se na jeho významu předem domluvily. U ceny se doporučují třípísmenné kódy podle ISO 4217, ale zápis počítá i s kryptoměnami: mezi příklady v dokumentu stojí vedle fval=USD750 také fval=BTC0.000010.

Do jednoho záznamu patří nanejvýš jedna taková dvojice, samotných záznamů ale může být v sadě víc a každý zájemce si vybere ten, který umí zpracovat. Registr sáhne po kódu, člověk po telefonu:

_for-sale IN TXT "v=FORSALE1;furi=https://fs.example.com/"
          IN TXT "v=FORSALE1;ftxt=This domain name is for sale"
          IN TXT "v=FORSALE1;fval=EUR500"

Volný text i kód smí mít 1 až 239 oktetů a celý záznam se musí vejít do jediného textového řetězce o 255 oktetech, aby se při čtení nemusel skládat z kousků. Doba platnosti záznamu se doporučuje nastavit na hodinu nebo méně: čím delší, tím větší riziko, že se zájemci ukáže cena, která už neplatí.

Proč to vzniklo

Motivaci popsal Davids v blogu SIDN Labs z 28. října 2025 přirovnáním k ojetým autům. Většina lidí ojeté auto prodá, kdežto nechtěnou doménu drtivá většina držitelů prostě nechá propadnout. Konce registrací hlídají specializované firmy, takzvaní domaineři, kteří dobrá jména po expiraci zachytí, postaví je na svůj virtuální plac s cenovkou a původnímu držiteli z prodeje nepřijde nic. Té praxi se říká drop catching.

Podle SIDN je na tom nejhorší, že se nabídka a poptávka minou. Zájemce se zeptá ve whois, uvidí „registrováno“, spokojí se s druhou volbou a nikdy se nedozví, že o jeho první volbu se dalo běžně smlouvat. Záznam v DNS je proti tomu levné řešení: dá se zapnout a vypnout kdykoli, funguje i u domény, která se pořád používá, a nikdo kvůli němu nemusí sahat do registračního systému.

Co konvence nedovolí

Zajímavější než seznam možností jsou hranice. Celou doménu nejvyššího úrovně nabídnout jedním záznamem nejde, protože zástupný znak v DNS platí jen jako samostatné jméno na začátku zápisu a řetězec _for-sale.*.example. tím pádem není platný. Pod infrastrukturní doménou .arpa musí čtecí programy takový záznam ignorovat úplně, aby se nedal číst jako nabídka prodeje rozsahu IP adres nebo telefonních čísel. Zvláštní domény typu .onion nebo .alt jsou mimo rozsah dokumentu.

Ošetřený je i případ, kdy je značka verze na místě, ale zbytek chybí nebo je nesmyslný. Pak má program předpokládat, že doména na prodej je, a kontakt si dohledat postaru ve whois nebo přes RDAP. Naopak text bez značky verze se za platnou ceduli považovat nesmí. A vyvěšená cedule nikoho k ničemu nezavazuje: dokument výslovně píše, že mohla vzniknout omylem nebo že si to držitel rozmyslel.

Rizika, která dokument vypisuje sám

Oddíly o bezpečnosti a soukromí se čtou jako výčet toho, co se pokazí, až si obsah cizí zóny někdo vystaví na vlastní web. Do textového záznamu se dá napsat cokoli, takže bez důkladné kontroly vstupu hrozí injektáž skriptu nebo SQL dotazu a záměna znaků, které vypadají stejně. Ukázka v příloze to nezastírá a jako platný, byť škodlivý obsah uvádí přímo ftxt=<script>...</script>.

Odkaz z cizí domény se podle dokumentu nesmí otevírat automaticky, uživatel to musí napřed potvrdit. U ceny se doporučuje připsat, že je orientační, a nenakupovat podle ní bez lidského zásahu. Dokument počítá i s tím, že cedule bude sloužit jako návnada k návštěvě webu bez skutečného úmyslu prodávat.

Druhá strana mince je soukromí. Cedule je veřejný signál, že chce držitel prodat, a kdo do ní napíše e-mail nebo telefon, může počítat s tím, že si je někdo sesbírá.

Kde to už běží

Nejdál je nizozemský registr. SIDN podle svého blogu provozuje pilot ve spolupráci s registrátory už několik let, byť na starší verzi návrhu. Zapojený registrátor dá do systému registru adresu své prodejní stránky, dostane na ni jednorázový kód a ten se pak vkládá do záznamu fcod= jednotlivých domén. Kdo si potom na stránce registru ověří doménu, uvidí místo strohého „registrováno“ zelené tlačítko a proklik na prodejní stránku. Software pro verzi, kterou blog popisuje, byl podle něj tehdy hotový, ale SIDN ho nevydal, dokud nebude jisté, že se dokument už nebude měnit.

Že je celá věc čerstvá, jde poznat i z registru IANA. U položky _for-sale v něm k 31. červenci stále stojí odkaz na jedenadvacátou verzi návrhu, ne na číslo 10023, které vydaný dokument dostal. Je to běžné zpoždění a samo se srovná, ale dobře ukazuje, ve které fázi tahle konvence je: dokument je venku, ostatní kolem něj teprve dobíhá.

Podle nás bude o užitečnosti rozhodovat něco úplně jiného než text dokumentu, totiž jestli se čtení cedule naučí vyhledávací nástroje registrátorů. Zapsat záznam do zóny zvládne držitel domény sám za minutu, ale kdyby ho nikdo nečetl, mluví do prázdna. Podobně jako u červencového doporučení IETF k automatickému DNSSEC platí, že samotné vydání dokumentu nic nezapíná.

Zdroje: RFC 10023 na rfc-editor.org, historie návrhu draft-davids-forsalereg v IETF Datatrackeru, registr podtržítkových jmen v DNS u IANA a blog SIDN Labs o pilotu pro .nl.

Kdo dostane blok IP adres, se v praxi rozhoduje na pěti místech na světě. Tolik je regionálních internetových registrů, zkratkou RIR: AFRINIC pro Afriku, APNIC pro Asii a Tichomoří, ARIN pro Severní Ameriku, LACNIC pro Latinskou Ameriku a RIPE NCC pro Evropu a Blízký východ. Rozdělují mezi poskytovatele připojení jak adresy, tak čísla autonomních systémů, podle kterých se směruje provoz mezi sítěmi. Pravidla, podle kterých je někdo za registr vůbec uzná, jsou z roku 2001. Teď mají hotového nástupce – zatím ale jen jako návrh.

Co se 28. července stalo

Address Supporting Organization Address Council (ASO AC) dokončil verzi 3 dokumentu RIR Governance Document a předal ji výkonné radě NRO, tedy sdružení všech pěti registrů. Oznámily to 28. července shodně NRO i RIPE NCC. ASO AC je orgán, který v soustavě ICANN zastupuje správce číselných zdrojů a zároveň působí jako Number Council sdružení NRO – tedy tentýž sbor pod dvěma jmény.

Podle oznámení teď návrh posoudí výkonná rada, projedná ho s ICANN a s registry a povede ho k finální verzi. Jinými slovy: hotová je verze, kterou jeden orgán doporučil druhému. Schvalují ji nakonec registry a ICANN, a to se zatím nestalo.

Co nahrazuje

Nahrazovaným dokumentem je ICP-2, celým názvem Criteria for Establishment of New Regional Internet Registries. Správní rada ICANN ho přijala 4. června 2001 a stále platí. Je krátký a je na něm vidět doba vzniku: mluví o třech registrech. „At the time of writing, the three existing RIRs cover a service area that spans the entire world,“ stojí v jeho úvodu, tedy že v době psaní pokrývají tři existující registry celý svět. O kus dál dokument předpokládá, že vlastní registr chystají Afrika a Latinská Amerika, a dodává, že počet registrů má i tak zůstat malý. Obě se ho pak opravdu dočkaly.

ICP-2 vyjmenovává deset kritérií pro uznání nového registru: velikost regionu, podpora poskytovatelů v něm, otevřená tvorba pravidel, neutralita, technická způsobilost, dodržování globálních pravidel pro přidělování adres, plán činnosti, model financování, vedení záznamů a mlčenlivost. Co v celém textu nenajdete, je jediná zmínka o tom, co se stane, když uznaný registr přestane pravidla plnit. Slovo pro odebrání uznání v něm není vůbec.

Odebrání registru, se kterým ICP-2 nepočítá

Právě tenhle chybějící kus nový dokument doplňuje. Text verze 3 zveřejněný není – NRO uvádí, že doprovodné materiály včetně porovnání se starší verzí vyjdou později. Veřejně se dá číst verze 2 z 28. srpna 2025, tedy ta, ke které se sbíraly připomínky do 7. listopadu 2025.

V ní má odebrání uznání vlastní postup. Návrh smí podat kterýkoli registr nebo skupina registrů, dále skupina členů dotčeného registru čítající aspoň čtvrtinu všech členů nebo 2 000 členů (podle toho, co je méně), anebo ICANN. Ostatní registry pak musí odebrání doporučit jednomyslně a teprve potom o něm rozhoduje ICANN. Sám dokument to označuje za krajní možnost: nesplňující registr má být zbaven uznání „only as a last resort“, tedy jen jako poslední řešení, a to jen tehdy, když škody pro internetovou komunitu převáží nad tím, jeho neplnění dál tolerovat.

Proč to není akademická otázka

Africký registr AFRINIC je od sporu se svým členem, firmou Cloud Innovation, pod nucenou správou. Volby do jeho správní rady, které správce vypsal na červen 2025, byly kvůli podezřením kolem hlasování na plné moci zrušeny. The Register v květnu 2026 popsal, že ICANN správci registru napsala, že takové volby mohou být důvodem k prověření, jestli AFRINIC plní svůj mandát, a že se sama připojila k soudnímu řízení, ve kterém Cloud Innovation usiluje o zrušení registru. Žádný z použitých zdrojů obojí výslovně nespojuje; podle nás se ale pasáž o odebrání uznání od tohohle případu číst odděleně nedá.

Kolik lidí do toho mluvilo

Práce začala v říjnu 2023, kdy výkonná rada NRO požádala ASO o proces aktualizace ICP-2. Následoval dotazník na základní principy od 8. října do 6. prosince 2024 s 298 odpověďmi, první návrh z 14. dubna 2025 a k němu připomínkové kolo do 27. května, druhá verze z konce srpna 2025 s připomínkami do listopadu, pracovní setkání v Montevideu v listopadu 2025 a průběžné zprávy o stavu v únoru a 8. května 2026. ARIN u prvního kola žádné souhrnné číslo připomínek neuvádí – píše jen, že přišly z konferencí všech pěti registrů, z webinářů, ze setkání registrů a přes veřejné připomínkování ICANN.

Co se z přetisků nedozvíte

Server TechTimes ohlásil totéž předání titulkem, podle kterého správa IP adres dostala po 25 letech první přepis a s ním pravomoc vyhazovat registry. Věcně to sedí v tom, že ICP-2 je z roku 2001 a že nový text s odebráním počítá. Nesedí to v tom podstatném: nic zatím přepsáno nebylo. Podle nás je rozdíl mezi doporučeným návrhem a platným pravidlem u dokumentu, na kterém stojí přidělování adres celé planetě, to podstatné.

Kdy má být hotovo, žádný ze zdrojů neuvádí. NRO slibuje aktualizovaný harmonogram a s ním i termíny, kdy se dá do dokumentu ještě mluvit.

Deset vypnutí v Súdánu, tři v Iráku

Zpráva dokumentuje deset vypnutí v Súdánu mezi 13. a 23. dubnem, všechna nařízená proto, aby se u celostátních zkoušek nepodvádělo. Držela se přesného rozvrhu: každé trvalo zhruba tři a půl hodiny, od 11:45 do 15:15 světového času, tedy od 13:45 do 17:15 místního – přesně na okno, ve kterém se zkoušelo.

K tomu přibyly tři vládou nařízená vypnutí v Iráku, 2., 11. a 28. června, ze stejného důvodu. Tam byla kratší, kolem devadesáti minut. Cloudflare k oběma zemím poznamenává, že jde o sezonní vzorec, který eviduje už několik čtvrtletí po sobě.

V Iráku sto sedmdesát vypnutí od roku 2019

Podrobnosti k Iráku vede projekt Pulse od Internet Society, který jednotlivá vypnutí popisuje i s podklady. U vypnutí 13. června uvádí, že irácká vláda pozastavila internetové služby ráno mezi 6:00 a 7:30 místního času a že šlo o první z očekávané série pro první kolo zkoušek na odborných školách, které běželo do 4. července.

Ministerstvo komunikací to podle Pulse ohlásilo 19. května. Ministr Mustafa Sanad ve videovzkazu vypínání potvrdil a zároveň slíbil vyvinout digitální systém, který by odstranil potřebu rozvážet zadání zkoušek z jednoho místa – a tím i důvod internet vypínat.

Souhrnná čísla u iráckého profilu jsou výmluvnější než jednotlivé případy: 28 vypnutí za posledních dvanáct měsíců, 170 od roku 2019 a 14 470 hodin, co všechna ta vypnutí dohromady trvala. Freedom House hodnotí svobodu internetu v Iráku jako částečně svobodnou.

Obě evidence se přitom v počtu neshodují. Cloudflare uvádí za druhé čtvrtletí tři irácká vypnutí, kdežto Pulse má samostatný záznam i k 13. červnu, který ve výčtu Cloudflare není. Není to spor o fakta, ale o metodiku: Cloudflare popisuje, co sama anotovala ve vlastním provozu, Pulse sbírá jednotlivá hlášení včetně oznámení úřadů.

Írán se vracel po osmaosmdesáti dnech

Nejdelší zásah do konektivity ve výčtu není z druhého čtvrtletí – jen v něm skončil. Cloudflare píše, že od 26. května začala pozorovat známky předem oznámeného obnovování internetu v Íránu, tedy předběžný konec osmaosmdesátidenního vypnutí, které zemi drželo prakticky celou offline od 28. února. Den nato hlásil Radar provoz obnovený na 40 % úrovně před výpadkem, což odpovídá zprávám, že se přístup vracel po částech, ne najednou.

Zbytek zařídilo počasí a jedna chybná výměna klíčů

Nejdelší jednotlivý výpadek čtvrtletí způsobil supertajfun Sinlaku, který v polovině dubna prošel Mariánskými ostrovy těsně severně od Guamu. Provoz z ostrova klesl 13. a 14. dubna až o 80 % pod očekávanou úroveň.

Kuriozitou je 5. květen v Německu. Při výměně klíčů DNSSEC u registru DENIC, který spravuje doménu .de, začaly vznikat neplatné podpisy. Ověřující resolvery po celém světě pak odmítly každý dotaz na německou doménu a vracely chybu SERVFAIL, dokud se provoz nevrátil do normálu ve 23:15 světového času. Doména sama byla celou dobu v pořádku; nefungoval podpis, kterým se její pravost dokazuje.

Přidat se dá ještě přeseknuté optické vlákno u Svaté Lucie 21. a 22. června, kdy provoz ze sítě Karib Cable spadl kolem 21:00 světového času prakticky na nulu a držel se tam skoro celý den, dvě zemětřesení na severu Venezuely 24. června a nejméně pětihodinový výpadek elektřiny v Tanzanii 27. června.

Kolik to stojí a jestli to vůbec funguje

Vypínání kvůli zkouškám má v Iráku své odpůrce doma. Server Shafaq News psal v květnu, že ministerstvo komunikací loni v srpnu při druhém kole zkoušek nařídilo dvouhodinové denní vypnutí od 6:00 do 8:00 a později ho zkrátilo na hodinu a půl. Odborníci podle něj namítají, že opatření nemíří na jádro problému, tedy na slabý dohled a úniky zadání přímo z úřadů.

Tentýž text uvádí, že organizace hájící lidská práva odhadly ztráty z předchozích vypnutí na téměř 951 milionů dolarů za jediný týden a že vypínání zasáhlo tisíce firem, dopravních služeb i rozvážkových platforem. Které organizace to byly, článek neuvádí, takže číslo bereme jako odhad bez dohledatelného původu.

Nejzajímavější na celé věci je, že se s tím nepočítá napořád. Slib iráckého ministra rozvézt zadání zkoušek jinak než po síti, kterou je pak nutné vypnout, je ze všech citovaných dokumentů jediné místo, kde někdo popisuje, jak by se dalo přestat. Jestli ho splní, pozná se příští červen – a bude to vidět v obou evidencích.

Zdroje: Cloudflare Radar, přehled přerušení za druhé čtvrtletí 2026, Internet Society Pulse, záznam iráckého vypnutí z 13. června a Shafaq News.

Když prohlížeč potřebuje IP adresu k doménovému jménu, zeptá se rekurzivního resolveru, tedy serveru, který jméno dohledá za něj. V učebnici to vypadá jednoduše: zeptej se kořene, kořen tě pošle na servery domény nejvyšší úrovně, ty tě pošlou na cílovou zónu. Tři dotazy a hotovo.

Ondřej Surý z organizace Internet Systems Consortium, která vyvíjí jmenný server BIND, si dal práci to změřit na skutečných jménech. Výsledky ukázal 19. července na setkání IEPG, které se koná vždy v neděli před jednáním IETF; to letošní červencové bylo ve Vídni. Jeho prezentace nese titulek s otázkou, kolik dotazů stojí vyřešení jednoho jména. Odpověď na druhém snímku je 329.

Tři dotazy jsou jen podlaha

Měřilo se vždycky s prázdnou vyrovnávací pamětí, tedy ve stavu, kdy si resolver nepamatuje nic z dřívějška. Je to uměle nepříznivý stav: server, který běží delší dobu, má velkou část cesty uloženou a většinu dotazů vůbec nepošle. Prázdná paměť ale ukáže, kolik práce si dané jméno svou stavbou objednává.

Pro učebnicové www.example.com vyšly tři dotazy. Skutečná jména se od téhle podlahy vzdalují ze tří důvodů a všechny tři se navzájem násobí.

Kde jmenný server bydlí, rozhoduje o ceně

První důvod je umístění jmenných serverů zóny. Když wikimedia.org deleguje na ns0.wikimedia.org, musí nadřazená zóna přibalit takzvané lepidlo (glue), tedy IP adresu toho serveru. Bez něj by se resolver zacyklil: na adresu serveru by se musel ptát toho samého serveru. Lepidlo je tady povinné a resolver ho smí použít, takže tenhle případ nestojí nic navíc.

Horší je delegace na jméno v úplně cizí zóně. Doména example.org deleguje na katelyn.ns.cloudflare.com, jenže .org nad doménou .com žádnou pravomoc nemá, takže lepidlo přiložit nesmí. Resolver musí jméno serveru dohledat od nuly, a to zvlášť pro každý server a zvlášť pro adresu IPv4 a IPv6.

Řetěz aliasů se nesčítá, ale násobí

Druhý důvod jsou aliasy, v DNS záznamy typu CNAME. Jméno teams.microsoft.com není adresa, ale odkaz na jiné jméno, které odkazuje na další. V době měření to byly čtyři skoky, než se dojde k adrese. Každý cíl je přitom nová úloha se svými delegacemi.

Dotaz na adresu IPv4 celého jména stál na BINDu 9.18 mezi 141 a 180 dotazy, na verzi 9.20 mezi 85 a 102 a na 9.21 rovných 30. Se zapnutým ověřováním podpisů DNSSEC to bylo 139 až 182, 91 až 110 a 42 až 43.

Nejhůř dopadly zpětné záznamy

Třetí důvod je stavba zpětného stromu, ve kterém se z IP adresy zjišťuje jméno. Adresa IPv6 se do něj zapisuje po jednotlivých půlbajtech, takže výsledné jméno má pod ip6.arpa dvaatřicet částí. Delegace jdou od organizace IANA přes regionální registr a poskytovatele připojení až ke koncovému zákazníkovi a na každé úrovni může jmenný server ležet v cizí zóně.

Zpětné jméno k adrese výzkumného stroje dnssec-stats.ant.isi.edu potřebovalo na BINDu 9.18 mezi 295 a 329 dotazy. Na verzi 9.20 to bylo 193 až 210, na 9.21 pak 102 až 128. Zpětné dotazy přitom nejsou okrajová věc: dělají je poštovní servery při kontrole pověsti odesílatele, přihlašovací služby, syslog i obyčejný web, když si zapisuje přístupy.

Loňská záplata čísla zvedla

Rozdíly mezi verzemi nejsou náhodné. Do verze 9.20.13 BIND používal lepidlo i tam, kde jmenný server ležel v jiné zóně pod týmž nadřazeným jménem. Doména ripe.net třeba deleguje na ns4.apnic.net a obě sídlí pod .net, takže registr domény .net může adresu přibalit.

Pak přišla zranitelnost CVE-2025-40778, kterou ISC zveřejnilo 22. října 2025 se známkou 8,6 z 10 na stupnici CVSS. Útočník mohl přes takové lepidlo podstrčit do paměti resolveru podvržený záznam. Verze 9.20.14 proto lepidlo od sourozenecké zóny ignoruje.

Bezpečnost se zlepšila, počet dotazů narostl. Pro google.com ze 7 na 28, pro wikipedia.org ze 7 na 31, pro chatgpt.com z 9 na 35 a pro x.com z 35 na 116.

Nový model delegací je vrátil dolů

Čísla vrátil dolů přechod na model, kdy si resolver ukládá delegační data z pohledu nadřazené zóny do zvláštní databáze místo do běžné vyrovnávací paměti. V měření to znamenalo návrat google.com na 7 dotazů, wikipedia.org rovněž na 7, bing.com z 51 na 23 a x.com ze 100 na 41.

V jedné věci se prezentace a dokumentace rozcházejí: snímek přisuzuje změnu verzi 9.21.20, poznámky k vydání ji popisují až u 9.21.21. Verze 9.21.20 přinesla jinou věc ze stejného soudku, totiž volbu max-delegation-servers, která nahradila pevný strop 20 zpracovaných jmenných serverů. Výchozí hodnota je 13, tedy počet kořenových serverů, který se ještě vejde do klasické odpovědi UDP o 512 bajtech.

Kolika serverům jedno jméno věří

Na totéž jednání navázal zápis Geoffa Hustona na blogu registru APNIC. Připomíná druhou stránku téže věci: dotazy se nejen počítají, ale jejich odpovědím se také musí věřit. U www.example.com to nejsou čtyři body důvěry, ale všech třináct kořenových serverů, všech třináct serverů domény .com a k tomu servery domény .net, protože kořenové servery samy sídlí pod ní. Celou tu síť závislostí vykreslí Transitive Trust Checker od Verisign Labs.

Co s tím

Doporučení z prezentace míří na tři skupiny. Provozovatel domény má delegovat na jmenné servery uvnitř vlastní zóny, a když sáhne po cizí správě DNS, vybrat jednoho nebo dva poskytovatele, ne čtyři v různých doménách nejvyšší úrovně. Má také hlídat délku řetězců aliasů a u zpětných zón se držet toho nejnudnějšího řešení. Poskytovatel spravovaného DNS má zákazníkům nabízet jména serverů uvnitř jejich vlastní zóny. Provozovatel resolveru má zapnout agresivní ukládání záznamů NSEC a držet krok s verzemi.

Podle nás je na tom měření nejzajímavější to, že žádné z těch čísel není chyba. Každá jednotlivá volba dává smysl sama o sobě: rozdělit jmenné servery mezi víc poskytovatelů kvůli odolnosti, postavit web na řetězec aliasů kvůli obsahové síti, přestat věřit sourozeneckému lepidlu kvůli podvrženým záznamům. Cena se objeví až v jejich součinu a platí ji někdo jiný. Surý ostatně o témže mluvil už v květnu na setkání RIPE 92, tehdy nad otázkou, jak vyvážit odolnost a efektivitu při zřizování jmenných serverů; shrnul to červnový zápis téhož autora.

Prohlížeč se dnes aktualizuje sám a většina lidí si čísla verzí nevšimne. Přesto se během letoška stalo něco, co se nestává: všichni tři velcí výrobci nezávisle na sobě oznámili stejnou změnu. Hlavní verze bude nově vycházet každé dva týdny místo jednou za čtyři.

Kdo kdy začne

První je na řadě Microsoft Edge. Podle oznámení na firemním blogu z 11. června začíná dvoutýdenní tempo verzí 152, která vyjde 27. srpna 2026.

Firefox naváže o pět dní později. Verze 154 z 18. srpna bude poslední vydaná v dosavadním rytmu, Firefox 155 přijde 1. září. Změnu oznámil ředitel Mozilly Sylvestre Ledru v polovině července ve vývojářské konferenci dev-platform, tedy v mailové skupině, kde se probírá vývoj jádra prohlížeče. Týká se počítačů i Androidu.

Chrome je z celé trojice první, kdo o tom mluvil, a poslední, kdo to spustí. Google zveřejnil plán už 3. března a dvoutýdenní cyklus u něj startuje verzí 153 osmého září. Platí pro počítače, Android i iOS; větve Dev a Canary zůstávají beze změny. Beta každé verze vyjde tři týdny před její stabilní podobou. V praxi to znamená zhruba šestadvacet hlavních vydání ročně místo dosavadních třinácti.

Rychleji neznamená víc

Zásadní je, co se nemění. Množství novinek zůstává stejné, jen se rozdělí na dvojnásobek dávek. Microsoft to popisuje přímo: každé vydání přinese „zhruba polovinu obsahu než dřív, zato dvakrát častěji“.

Stejně to formuluje i Mozilla. Zkrácení cyklu podle ní neznamená, že by se na hotovou práci mělo tlačit rychleji – funkce, které nejsou připravené, se nemají uspěchat a mohou zrát dál. Smysl je opačný: to, co už hotové je, nemusí čekat další tři týdny na nejbližší vlak.

Z toho plyne i druhý efekt, o kterém výrobci mluví méně nahlas. Když jede vlak každých čtrnáct dní, klesá tlak na takzvané uplifty, tedy dodatečné protlačování oprav do už uzavřené verze. Uplift je vždycky riziko: mění se kód, který už nikdo znovu neprošel celý. Čím menší dávka změn a čím kratší čekání, tím méně důvodů ho použít.

Firmy o pomalejší větev nepřijdou

Rychlejší tempo je noční můra každého, kdo v podniku validuje prohlížeč proti interním aplikacím. Proto zůstává zachovaná pomalá větev.

U Chromu se Extended Stable nemění vůbec – dál vychází jednou za osm týdnů. Edge má stejný interval, jen se přepočítal na nové číslování: aktualizace dostane každé čtvrté vydání, tedy verze 156, 160, 164 a tak dál. Model podpory ani harmonogram se u něj podle Microsoftu nemění.

Správcům, kteří na osmitýdenní větvi zůstanou, Microsoft doporučuje přidat pilotní skupinu uživatelů na kanál Beta a testovat od prvního dne, aby měli na ověření co nejvíc času. Pro tenhle účel nabízí Enterprise Preview s návodem pro správu.

Co z toho mají weboví vývojáři

Pro toho, kdo dělá weby, se mění hlavně rychlost, se kterou se nová vlastnost prohlížeče stane použitelnou.

Kdo dnes dokončí funkci těsně po uzavření vlaku, čeká na další skoro čtyři týdny. Nově budou nejvýš dva. U vlastností, které se v prohlížečích objevují postupně, se tím zkracuje doba, po kterou musí web počítat se dvěma různými chováními naráz.

Druhá strana mince je testování. Kdo hlídá vlastní aplikaci proti konkrétním verzím prohlížeče, bude mít dvakrát tolik cílů. Automatizované testy to zvládnou, ruční matice podporovaných verzí se ale bude potřeba přepsat – a to se týká i toho, jak dlouho drží platnost výsledky staršího testovacího kola.

Mozilla mluví o pokusu

Ze tří oznámení je nejopatrnější to od Mozilly. Firma dvoutýdenní cyklus výslovně označuje za experiment a připouští, že od něj může ustoupit, kdyby se objevily nečekané problémy. Chrome ani Edge takovou podmínku ve svých oznámeních nemají.

Rozdíl dává smysl. Mozilla má výrazně menší tým než Google a Microsoft a její vydávací proces je vázaný na jednu kódovou základnu bez zázemí velké platformy. Že se do stejného kroku pouští i tak, hodně vypovídá o tom, jak silný je dnes tlak držet krok s tempem Chromu – ať už jde o nové vlastnosti webu, nebo o bezpečnostní záplaty.

Pro běžného uživatele se v praxi nezmění skoro nic. Prohlížeč se aktualizuje na pozadí a nová čísla verzí poletí dvakrát rychleji, aniž by si toho kdokoli všiml. Zajímavější je, že se tři konkurenti bez domluvy shodli na tom, že měsíční cyklus už není správná délka.

Zdroje: oznámení Chromu na developer.chrome.com, blog Microsoft Edge a kalendář vydání Firefoxu, ve kterém jsou termíny verzí 154 až 157 čtrnáct dní po sobě.

Sdílení souborů mezi lidmi má na internetu dlouhou historii a jednu opakující se slabinu: i sítě, které se tvářily jako decentralizované, obvykle stály na několika serverech, kde se dalo hledat. Když ty spadly nebo je někdo vypnul, síť samotná sice žila dál, ale nikdo v ní nic nenašel. LiberShare zkouší postavit sdílení tak, aby takové místo neexistovalo.

Co to je

Projekt se sám popisuje jako „software pro sdílení souborů peer-to-peer postavený na moderních decentralizovaných technologiích“ (v překladu z angličtiny). Vyvíjí ho organizace Libersoft, tedy stejná parta, která staví operační systém LiberSystem.

Kód je veřejný na GitHubu a uvolněný pod licencí Unlicense, což znamená vzdání se autorských práv, jak jen to právní řády dovolují – prakticky veřejná doména.

Jak se peery hledají navzájem

Základ je knihovna libp2p, tedy stavebnice pro sítě peer-to-peer, kterou zná i svět kolem IPFS. Přímé spojení mezi dvěma počítači navazuje LiberShare přes WebRTC. Ten se běžně používá na videohovory v prohlížeči a umí se prokousat přes domácí routery, které jinak příchozí spojení nepouštějí.

Vyhledávání peerů řeší distribuovaná hašovací tabulka, konkrétně Kademlia z libp2p. Zjednodušeně: seznam „kdo co má“ není nikde celý. Každý uzel drží kousek a dotaz se k cíli doptává po několika skocích. Právě tohle je ten rozdíl proti starším sítím – není centrální rejstřík, který by šlo vypnout.

Úplně bez pevného bodu se to ale neobejde. Nastavení sítě podle specifikace povinně obsahuje seznam takzvaných bootstrap peerů – adres, na které se nový uzel připojí jako první, aby vůbec někoho poznal. Rozdíl proti serveru je v tom, že bootstrap peer nic neindexuje ani nezprostředkovává přenosy; slouží jen jako dveře do sítě a může jich být uvedeno víc. Kdo si založí vlastní síť, uvede prostě adresu svého uzlu.

Vlastní formát místo torrentu

Místo souborů .torrent má projekt vlastní formát, kterému říká LISH. Je popsaný ve třech specifikacích přímo v repozitáři: datový formát, formát sítě a síťový protokol. Poslední z nich je označený jako verze 1 z 24. října 2025.

Formát je postavený na JSONu, takže se dá otevřít v textovém editoru a přečíst. Nese strukturu adresářů, oprávnění a údaje pro ověření celistvosti dat. Protokol z něj skládá přenosy, které se dají přerušit a navázat a které umí táhnout z víc zdrojů naráz.

Sítě s rolemi, ne jedna velká síť

Nejméně obvyklá část návrhu je řízení přístupu. LiberShare nepočítá s jednou globální sítí, ale s libovolným počtem sítí, z nichž každá má vlastní pravidla a čtyři role: vlastníci, správci, vydavatelé a stahující.

Vlastník mění nastavení sítě a přiděluje ostatní role, správce může přidávat vydavatele a stahující, vydavatel smí do sítě přidávat obsah. Dvě nepovinná nastavení pak určují, jestli publikovat a stahovat smí opravdu jen ti, kdo mají příslušnou roli, nebo kdokoliv. Ve výchozím stavu je síť otevřená.

Prakticky to znamená, že tatáž technologie může sloužit jak veřejné síti, kam přispívá kdokoliv, tak uzavřené skupině – třeba filmovému archivu, kde publikovat smí hrstka lidí a stahovat okruh členů.

V jakém je to stavu

Tady je namístě střízlivost. Repozitář vznikl 22. října 2025, má přes patnáct set commitů a tři přispěvatele, poslední změny jsou z posledních dnů. Zároveň ale zatím nevyšla žádná verze – sekce vydání je prázdná a k dispozici je jen zdrojový kód.

Podle údajů GitHubu je většina kódu v TypeScriptu, k tomu přibližně třetina objemu v Svelte, tedy uživatelské rozhraní. Menší podíl tvoří instalátor pro Windows, skripty a kousek Rustu. Popularita je zatím komorní: jednačtyřicet hvězd a tři forky.

Proč to sledovat

Zajímavé na projektu není to, že dělá sdílení souborů – to umí kdejaký klient BitTorrentu, a lépe, protože má za sebou dvě desetiletí ladění. Zajímavé je spojení tří věcí, které se obvykle nepotkávají: síť bez indexeru, přístupová práva uvnitř sítě a rozhraní, které vypadá jako přehrávač médií, ne jako správce stahování.

Jestli to dopadne, se pozná až podle první vydané verze a podle toho, kolik lidí ji rozběhne naráz. Distribuovaná hašovací tabulka na papíře funguje vždycky; teprve provoz ukáže, jak se chová, když je uzlů málo nebo když polovina z nich sedí za přísným routerem.

Zdroje: repozitář LiberShare na GitHubu včetně specifikace síťového protokolu LISH; údaje o rozsahu a stáří kódu pocházejí z veřejného rozhraní GitHubu, ne z tvrzení projektu.

Otisk klíče drží někdo jiný než jeho majitel

DNSSEC podepisuje odpovědi z DNS, aby se poznalo, že cestou nikdo nic nezaměnil. Důvěra se předává shora dolů: nadřazená zóna drží u delegace záznam DS, což je otisk podpisového klíče té podřízené. Klíč má v ruce provozovatel DNS pro doménu, otisk ale nikoli. Ten je zapsaný o patro výš, u registru.

Když se klíč vymění a otisk zůstane starý, ověřující resolvery po celém světě přestanou doménu považovat za platnou a vrátí chybu. Doména přitom funguje dál, jen se nedá dokázat, že je pravá. Jak to dopadá v praxi, bylo vidět 5. května u německého registru DENIC, kde po výměně klíčů začaly vznikat neplatné podpisy a dotazy na .de selhávaly až do 23:15 světového času; psali jsme o tom v přehledu přerušení internetu za druhé čtvrtletí.

Záznamy CDS a CDNSKEY, popsané v RFC 7344 a 8078, jsou právě proti tomuhle. Správce domény je vystaví ve své zóně, nadřazená strana si je přečte a otisk si přepíše sama. Vydaný dokument neřeší tenhle mechanismus, ale rozhodnutí, která u něj musí udělat právě ta nadřazená strana.

Sedm procent zabezpečených delegací

Proč to někoho zajímá, popsali Barbara Jantzen a Peter Thomassen v únorovém textu na blogu APNIC. Postupy při výměně klíčů jsou podle nich ruční, složité kvůli více poskytovatelům, náchylné k chybám a náročné na podporu (přeloženo z angličtiny). Tentýž text uvádí, že míra ověřování DNSSEC dosáhla v roce 2025 36 procent a podíl zabezpečených delegací 7 procent.

Sedm procent je číslo, které se dá číst dvěma způsoby. Buď je DNSSEC příliš složitý, nebo je riziko rozbití větší než užitek z podepsání. Autoři doporučení sázejí na to, že když se výměna klíčů zautomatizuje, ubude obojího.

Co se po registrech chce

Dokument je psaný jako seznam požadavků na nadřazenou stranu. Než otisk přepíše, musí ověřit shodu mezi záznamy CDS a CDNSKEY a napříč všemi autoritativními jmennými servery delegace, a musí ověřit, že výsledná sada záznamů DS umožní ověřování dál. Když kterákoli kontrola neprojde, změna se ruší.

Nová sada záznamů DS má mít podle doporučení dočasně sníženou dobu platnosti v mezipaměti na 5 až 15 minut, aby šlo změnu vzít zpátky. Po uplynutí té původní se hodnota vrací na běžnou.

Dvě věci jsou napsané tvrději. Automatická údržba se nesmí zastavit jen proto, že je doména zamčená proti změnám u registrátora nebo u registru. Podle nás to dává smysl: zámek chrání před cizím zásahem, kdežto tady mění záznam sám držitel klíče. A ruční cesta musí zůstat otevřená, protože ji je potřeba tam, kde provozovatel DNS automatiku neumí nebo odmítá spolupracovat.

Vlastní kapitolu má i to, komu se má chyba hlásit. Nejdřív provozovateli DNS a technickému kontaktu domény. Držitele domény doporučení upozorňovat nechce, dokud potíž netrvá delší dobu; jako příklad uvádí tři dny.

Dvakrát totéž, a autoři to vědí

Nejméně elegantní bod je třetí v pořadí: provozovatelé DNS musí publikovat záznamy CDNSKEY i CDS, pokud neznají preferenci nadřazené strany. Důvod je prostý – neexistuje způsob, jak se tu preferenci strojově zeptat, takže se pro jistotu vystaví obojí. Dokument si to nijak nezastírá a píše rovnou, že publikovat tutéž informaci ve dvou různých formátech není ideální (přeloženo z angličtiny). Nadřazené straně pak ukládá ověřit, že si oba záznamy odpovídají.

Jak je na tom .cz

Registr .cz běží na systému FRED, který vyvíjí sdružení CZ.NIC, a automatickou správu klíčů má pod zkratkou AKM. Dokumentace FRED se odvolává na RFC 7344 a 8078 a k formátům je v ní jedna věta bez prostoru k výkladu: FRED záznamy CDS nepodporuje. Pracuje výhradně s CDNSKEY.

Popsaný mechanismus se s částí požadavků doporučení kryje. Doména do systému vstupuje sama ve chvíli, kdy na jmenných serverech vystaví platné záznamy CDNSKEY. U dosud nezabezpečené domény musí klíče projít přejímací lhůtou a po celou dobu zůstat platné a nezměněné na všech serverech ze sady; u zabezpečené se změna provede rovnou, protože nové klíče se dají ověřit starými. Mezi dvěma platnými sousedními kontrolami musí být méně než 48 hodin a služba, která záznamy sbírá, běží každých deset minut.

Rozpor s doporučením to není. Výjimka „pokud neznají preferenci nadřazené strany“ míří přesně na tenhle případ – preference .cz je zdokumentovaná, takže tam CDS nikdo vystavovat nemusí. Cena za to je, že správce domén ve více doménách nejvyšší úrovně stejně vystaví oba záznamy všude tam, kde preference nadřazené strany známá není.

Seznam, na kterém velké domény chybí

Kolik registrů automatiku vůbec má, se z jednoho místa zjistit nedá. Nejblíž je komunitní seznam v repozitáři cds-updates: devět domén nejvyšší úrovně (.ch, .cr, .cz, .fo, .li, .nu, .se, .sk a .uz), dvě jihoafrické domény druhé úrovně a obrácený překlad u RIPE NCC. Je to seznam vedený dobrovolně, takže nemusí být úplný. Jedna věc z něj ale plyne: mezi doménami nejvyšší úrovně jsou samé národní, převážně evropské.

Text na blogu APNIC vedle toho připomíná, že samotná .com má 159,4 milionu domén, tedy 42 procent všech na světě. Žádná z velkých generických domén v komunitním seznamu není.

Náš názor: dokument je užitečný přesně v tom, v čem bývají doporučení k provozu nejužitečnější – sepisuje rozhodnutí, která by jinak každý registr dělal po svém a špatně. Na sedmiprocentní podíl zabezpečených delegací ale sám o sobě nesáhne. BCP nikoho nezavazuje a registr, který automatiku nemá, ji kvůli němu ze dne na den nezavede.

Zdroje: RFC 10026 na serveru RFC Editor, záznam dokumentu v IETF Datatrackeru, text Barbary Jantzen a Petera Thomassena na blogu APNIC, dokumentace systému FRED k automatické správě klíčů a komunitní přehled cds-updates.

Skupina autorů z firem Garmin, lispers.net a Futurewei vydala v červenci 2026 dokument RFC 10019. Nezavádí žádný protokol a ani se o to nesnaží: je to soupis toho, proč automatické přidělování multicastových adres v malých sítích nefunguje, a seznam požadavků na řešení, které teprve má vzniknout. Kategorie dokumentu je informativní, nikoli standardizační.

Dvaatřicet adres na jedno místo

Jádro potíže je stará vlastnost ethernetu. Když se má IPv4 multicastová adresa přeložit na ethernetovou, použije se z ní jen spodních 23 bitů – popisuje to oddíl 6.4 dokumentu RFC 1112 z roku 1989. Adresa má přitom 32 bitů a první čtyři jsou pevná předpona, takže na výběr zbývá 28 bitů. Rozdíl mezi 28 a 23 znamená, že na jednu ethernetovou adresu připadá až 32 různých multicastových adres IP.

Následky RFC 10019 dělí na tři. První se týká síťové karty: když se aplikace přihlásí k odběru skupiny, karta se nastaví tak, aby propouštěla jen její provoz. Sdílejí-li dvě skupiny tutéž ethernetovou adresu, karta je od sebe nepozná a nechtěný provoz musí odfiltrovat až operační systém – tedy softwarem, s odpovídající zátěží procesoru.

Druhý následek se týká přepínačů, které sledují přihlášky k odběru (IGMP a MLD snooping podle RFC 4541). Když dvě skupiny padnou na tutéž ethernetovou adresu, přepínač pošle data i tam, kde o ně nikdo nestál. Dokument upozorňuje, že to bolí zvlášť tam, kde na pomalé lince visí zařízení, které dostane proud dat určený někomu jinému.

Třetí je vnitřní stavba některých přepínačů. Uvádějí si adresy v tabulce s pevně velkými přihrádkami; když se do jedné přihrádky trefí víc adres, než se vejde, další záznamy se zahodí. Přeposílání pak přestane fungovat úplně. RFC se u toho odvolává na konkrétní patent, nikoli na obecnou úvahu.

Proč to sepsali lidé od lodí

První autor je z Garminu a v poděkování stojí americká asociace pro lodní elektroniku. Není to náhoda: lodní síť je učebnicový případ prostředí, které dokument popisuje. Na jedné podsíti visí čidla teploty nebo hladiny za pár stovek vedle radaru, sonaru a kamer, propojuje je obyčejný ethernetový přepínač a nikdo tam nekonfiguruje adresy ručně.

Levné přepínače navíc neumějí adresovat zdrojově (SSM), protože jejich tabulka zná jen cílové ethernetové adresy. Každý datový proud proto dostane vlastní multicastovou adresu IP a o doručování rozhoduje právě sledování přihlášek. Tím se ale celá stavba opře o to, co je popsané výš – a kolize adres jí podrazí nohy.

Dokument sám dodává, že lodě jsou jen názorný příklad. Táž omezení platí pro průmyslovou automatizaci, menší audiovizuální rozvody a nahodile poskládané sítě čidel.

Co už existuje a proč to nestačí

Protokol na dynamické přidělování multicastových adres vznikl už dávno – RFC 2730 z roku 1999 popisuje MADCAP. Staví ale na serveru, který adresy rozdává, a to je přesně to, co v prostředí bez konfigurace není k mání. Dokumenty RFC 3306 a RFC 4489 řeší přidělování adres IPv6 přímo na koncových zařízeních, kolizím na ethernetové vrstvě však nepředcházejí.

U IPv6 je situace o něco lepší, protože rámec z RFC 3307 s kolizemi počítá. I tam ale autoři vidí mezeru: oba popsané způsoby dynamického přidělování – serverem i samotným zařízením – sahají do téhož rozsahu, takže se navzájem nevylučují.

Nabízelo se řešení, které by problém u IPv4 odstranilo úplně: vyhradit 32 rozsahů tak, aby se jejich ethernetové obrazy nepřekrývaly. Autoři ho zamítli s odůvodněním, že RFC 5771 nové přidělování multicastového prostoru IPv4 nedoporučuje – je ho málo. Doporučení pro nové návrhy proto zní jinak a je stručné: použít IPv6.

Co má řešení umět

Požadavky, které dokument vypisuje, pokrývají čtyři oblasti: jak zařízení najdou, že tu nějaké přidělování běží, jak si adresu vezmou, jak poznají a vyřeší střet s jiným zařízením a jak se adresa po čase vrátí zpátky. Řešení má být decentralizované a nenáročné, protože poběží i na čidlech, která nemají výkon nazbyt.

Co v dokumentu není, je samotný protokol. RFC 10019 popisuje zadání, ne hotovou věc – a mezi tím, že si obor sepíše požadavky, a tím, že se objeví implementace v přepínačích a čidlech, bývá u síťových norem několik let.

Zdroje

• RFC 10019: Zeroconf Multicast Address Allocation Problem Statement and Requirements, IETF, červenec 2026
• RFC 1112: Host Extensions for IP Multicasting, oddíl 6.4, IETF, srpen 1989
• RFC 5771: IANA Guidelines for IPv4 Multicast Address Assignments, IETF, březen 2010