I když to vypadá, že svět DNS se narozdíl od třeba světa HTTP(S) příliš nevyvíjí a jedinou jeho změnou je, že DNS se pozvolna mění podvozek (nejdříve jím bylo UDP, pak TCP, pak TLS nad TCP a pak HTTPS nad TCP, abychom nakonec skončili u DoQ, DNS over QUIC, což je de-facto HTTPS nad UDP), je to zdání klamné a změn je více.
Z poslední doby zmíním třeba katalogové zóny, meziprocesovou komunikaci DNS a BGP software (velmi praktické zejména na instancích anycastových autoritativních DNS serverů), zapomenout nemůžeme ani na vnitřní modernizaci a zvyšování výkonu jednotlivých DNS software platforem (BIND, NSD, Knot atd.).
Zbyněk Pospíchal
Autor působí ve společnosti Quantcom (dříve Dial Telecom), kde se zabývá rozvojem páteřních sítí a návrhem a implementací nových síťových služeb. Kromě toho se snaží jako člen kolegia CZ.NIC, z.s.p.o. o to, aby peníze vlastníků domén byly užívány pouze na provoz systému TLD .cz a ne na nesouvisející projekty a financování pofidérního „veřejného blaha“. Povinnosti ukládané státní správou telekomunikačním společnostem považuje za zbytečné, škodlivé a poškozující především zákazníky.
Nyní přichází další velká změna. Záznamy typu IN A a IN AAAA s námi sice ještě zůstávají, ale vyloženě nutné už nejsou.
Co bylo dlouhá léta považováno za neměnné, to byla také čísla TCP nebo UDP socketů, lidově „portů“, pro různé služby. O ty se DNS, kromě toho, že každý věděl, že DNS samotné běží na portech udp/53 a tcp/53, dosud nikdy nestaralo. Nicméně právě toto tento neměnný kamenný základ DNS, bez kterého si to skoro nikdo nedokáže představit, rok 2023 změnil.
Nejprve, už od roku 2018, existovaly drafty draft-schwartz-httpbis-dns-alt-svc, draft-nygren-httpbis-httpssvc a draft-nygren-dnsop-svcb-httpssvc – tyto se postupně přetransformovaly v oficiální IETF drafty draft-ietf-dnsop-svcb-httpssvc a draft-ietf-dnsop-svcb-https, aby na konci celé cesty schvalovacím kolečkem vzniklo RFC 9460. Bylo schváleno na zasedání IETF 118 v pražském hotelu Hilton v listopadu 2023 a Quantcom byl, jako už tradičně, dodavatelem a sponzorem internetové konektivity tohoto zasedání.
Co přináší? Mnohé. Jednak již výše zmíněné přesměrování na jiné TCP nebo UDP sockety. RFC 9460 umožňuje provozovat http na portu tcp/70 stejně dobře, jako https na portu tcp/444. Nebo udp/444. Nebo na jakémkoli jiném. Klientovi můžete sdělit, zda cílový stroj využívá http/2 ( alpn="h2") nebo http/3 ( alpn="h3"), případně též obojí.
Takhle jednoduše třeba zprovozníte váš web na portu 8002, aniž by to uživatel v URL vůbec musel jakkoli řešit – už žádné URL končící :8002:
example.com. 7200 IN HTTPS 0 svc.example.net.
svc.example.net. 7200 IN CNAME svc2.example.net.
svc2.example.net. 7200 IN HTTPS 1 . port=8002
svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2
Další věcí jsou priority. Ty jsme doposud znali z MX záznamů. Záznam IN HTTPS tento druh funkcionality ale podporuje také. Pokud se nepodaří navázat spojení na server s nejnižší hodnotou, TCP/IP stack nebo browser s podporou RFC 9460 navazuje následně spojení na server s hodnotou vyšší:
www.example.cz. 7200 IN CNAME server05.example.cz.
server05.example.cz. 7200 IN HTTPS 1 . alpn="h2,h3"
server05.example.cz. 7200 IN HTTPS 2 zalozni-server06.example.cz. alpn="h2,h3"
A teď k tomu, jak nahradit A a AAAA záznamy. Třeba takhle (skutečný příklad z reálné živé DNS zóny):
www.quantcom.cz. 86400 IN HTTPS 1 . mandatory=ipv4hint,ipv6hint port=443 ipv4hint=212.24.128.17,212.24.128.19,185.24.237.69 ipv6hint=2001:4de8:b0ba::1:1:1
Nyní můžete vesele přistupovat na web https://www.quantcom.cz, i kdyby pro takové FDQN už neexistoval ani A, ani AAAA, ani CNAME záznam, jak po IPv4, tak také po IPv6. Kdybychom uvedli jiné číslo portu než 443, browser by se pochopitelně připojil na onen jiný port.
Stačí vám to? Ne? Chcete zrychlit i otevírání TLS spojení tím, že už zahájení HTTPS resp. TLS spojení bude kryptované, protože příslušný veřejný klíč získáte už z DNS? Technologie se jmenuje Encrypted Client Hello a pěkně je popsána, včetně názorných obrázků, například zde. Teď to celé bude mnohem snazší díky klíči ech v IN HTTPS záznamu vašeho webového serveru v DNS:
www.mojedomena.cz. 3600 IN HTTPS 1 . alpn="h3,h2" ech="4282FCA7345223" ipv4hint="192.0.2.1" ipv6hint="2001:db8::1" port=4444 mandatory=ipv4hint,ipv6hint
3600 IN HTTPS 2 . alpn="h3,h2" ech="A4534FC43721FA" ipv4hint="192.0.2.2" ipv6hint="2001:db8::2" port=4444 mandatory=ipv4hint,ipv6hint
To celé opět bez A záznamů, AAAA záznamů, CNAME záznamů atd.
Zní vám to jako příliš velká pohádka? Inu, tak trochu to zatím pohádka je. Browsery ani DNS resolvery v operačních systémech RFC 9460 zpravidla ještě jako celek neimplementují, naimplementované jsou některé předchozí drafty, a to ještě ne na všech platformách. Čili něco někde funguje a něco někde ne. Podporu technologie Enhanced Client Hello pro svůj prohlížeč si můžete vyzkoušet například zde.
Příchod RFC 9460 tedy znamená podobnou revoluci v DNS, jako znamenal příchod IPv6 pro revoluci na třetí vrstvě referenčního modelu ISO/OSI. Je to velká, komplexní změna, která může (ale nemusí) radikálně měnit zažité pořádky. Na druhou stranu, používání nových funkcionalit rozhodně není povinné, a díky tomu je možné, za cenu jistých omezení, i zachování zpětné kompatibility.
