Zpětné jméno k adrese IPv6 stálo server BIND s prázdnou pamětí 329 dotazů
Učebnice říkají tři dotazy. Měření Ondřeje Surého z organizace ISC ukázalo, že skutečná jména stojí desítky až stovky dotazů a nejhůř dopadají zpětné záznamy k adresám IPv6. Podíl na tom mají delegace mimo vlastní zónu, řetězce aliasů i jedna loňská bezpečnostní záplata.
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.
