Nová norma DNS dovoluje přiobjednat další typy záznamů. Dvě starší cesty selhaly
Kdo chce k doméně adresu IPv4, IPv6 a záznam HTTPS, musí se dnes ptát třikrát. Norma RFC 10029 z července 2026 přidává do DNS dvojici voleb, kterými si klient k požadovanému typu záznamu přiobjedná další. Obě starší cesty k témuž skončily špatně: víc otázek v jednom paketu protokol formálně uměl, ale v praxi to nefungovalo, a dotaz ANY nezaručuje vůbec nic.
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.
