Názory k článku
Revoluce je tu, aneb nové typy DNS dotazů: SVCB a HTTPS

Nevypadly náhodou autorovi z ukázek nějaké mezery? Konkrétně "1." na více místech podle mě má být "1 ."

Jinak bych od článku čekal, že když v titulku uvádí revoluční SVCB, tak také popíše, čím se tedy liší od SVC, a proč je revoluční. V textu je popsán jen HTTPS záznam, a po pravdě, sice chápu, proč byl vytvořen, ale osobně mi přijde trochu zvláštní vytvářet speciální záznam jen pro jeden (byť velmi rozšířený) aplikační protokol.

Rovněž bych v článku uvítal informaci, jak je to s podporou tohoto záznamu v prohlížečích, to může být v současnosti limitující pro případné nasazení.

Článek obsahuje několik nepřestností. Předně DNS over TCP a DNS over HTTPS jsou v podstatě paralelně schvalované. Rozhodně neplatí, že DoH je nadstavbou nad DoT, která přišla evolučně poté. Stejně tak není pravda, že DNS over QUIC je v podstatě DNS over HTTP. Ne, to je DNS over HTTPS3. DoQ je v podstatě DoT, jenom kanál běží přímo nad UDP. Teoreticky se může rychleji zotavit. Bohužel implementací jej ovládajících je zatím jako šafránu.

Myslím, že autor nějak opomenul asi nejdůležitější věc. HTTPS záznam umožní v podstatě CNAME v kořeni zóny, jenom týkající se HTTPS služeb. Podobně jako MX záznam. Bez speciálních hacků na straně serveru. Můžete tak přesměrovat example.net na example.com bez speciální podpory serveru. www. prefix je už poněkud z módy.

Trochu nepříjemné je, že sesterský SVCB záznam byl úplně vynechán. Nejsou mu jmenovány ani 2 věty v článku. Přestože většina dnešních služeb je pochopitelně založena na HTTP, stále tady máme i jiné zabezpečené protokoly. Které se pomocí běžného SVC záznamu nedají plně specifikovat, pomocí SVCB už ano. Třeba i ty šifrovaná DNS, můžete si zkusit např. dig SVCB _dns.dns.google.

Každopádně, low-level API pro navazování spojení zatím v operačních systémech přímou podporu HTTPS ani SVCB běžně nemají. Bude zajívamé zkoumat, jak běžné se tyhle záznamy stanou i mimo prohlížeče.

Autore autore... co takhle si neco o tom nejdriv zjistit.

Prakticky odjakziva existuje SRV zaznam, ktery prave rika, kde ze dana sluzba pro danou domenu roste. A to vcetne portu. A kdyby raceli ponekud pohledat, tak kuprikladu v bugzille je to jiz nejakych +- 25 let. Tedy to, ze fox a spol to neumi.

Tudiz se zadna revoluce nekona ze?

Takovych RFC, ktere nikdo nikdy neimplementoval, existuji stovky. Dalsi stovky takovych, ktere mozna existuji v nejake demoimplementaci, ale nikdo to realne nepouziva.

Treba dns over https si procpal google kvuli smirovani provozu. Nikde jinde to nikdo nepouziva a nikdy nebude. Proc by jako mel?

V tomto pripade ... uzasna vyhoda zmeny protu === nikomu to nebude fungovat, protoze firewally. Typickej korporatni FW pusti 80/443 a i to typicky jen pres nejakou proxy. Ostatne, nedavno se to tady resilo v souvislosti se seznamem a tim, ze to pres prave ty proxy neproleze pres ten jejich paywall.

BTW: getaddrinfo je presne to misto kde by to melo byt.

Konečně pěknej článek, jen tak dál.

Jak v SRV záznamu určíte, který protokol se má použít (HTTP/2 nebo HTTP/3) nebo prioritu záznamu? Dokážete do toho jednoho SRV záznamu dát i otisk certifikátu?

Nj, kdyby mr Jirsak jako ve 100% svych blabolu alespon zbla take neco vedel, tak by treba vedel, ze protokol je primo soucasti toho zaznamu.

https://en.wikipedia.org/wiki/SRV_record

_sip._tcp.exam­ple.com
takze ...

_http3._tcp.e­xample.com

Napriklad, ze, ale to by bylo jedno kliknuti navic.

Což je právě ten problém. SVCB a HTTPS umožní pro jednu službu definovat víc protokolů a stanovit jejich vzájemné priority. Pro každý protokol jinou, aby si klient správně mohl vybrat. Přitom i výčet protokolů, které službu nabízí. Tedy klient podporující HTTP 1.1, 2 i 3 si vybere jenom jedinou, kterou zkusí. Jedním DNS dotazem. Včetně dodatečných parametrů, jako je dohpath (https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml#dns-svcparamkeys). Tedy nemusí bombardovat DNS server sadou requestů pro každý hostname a jedinou URL.

Ovšem SRV záznam se pro web nikdy nepoužíval, pokud mi je známo. Takže i kdyby to teoreticky umělo zachytit všechno potřebné, bude to pomalejší, než současný stav. Což je u prohlížečů, které honí každou milisekundu, těžko akceptovatelné. HTTPS záznam jednak řeší náhradu ANAME, jednak umožní rychlejší odpověď pro IPv4 i IPv6. Protože počet dotazů se sníží, ne naopak.

Nicméně urážet neanonymní uživatele je zřejmě lepší, než si nastudovat a pochopit rozdíly. Ostatně RFC to popisuje poměrně důkladně: https://www.rfc-editor.org/rfc/rfc9460.html#name-goals

Dobrý den,

omlouváme se za chybu, mezery skutečně vypadly, redakce během dopoledne provedla opravu.

Quantcom

Musíte samozřejmě získat DNS záznam typu HTTPS (např. pomocí res_query) a pak se připojit na vybranou IP adresu. getaddrinfo použít nemůžete, to používá A/ AAAA záznamy. Stejně jako getaddrinfo nepoužívá třeba SMTP relay, který se potřebuje řídit MX záznamy, nebo to nepoužívají aplikace používající protokoly, které používají SVR záznamy.

srv zaznam se pro web pouziva zcela bezne, jen prohlizece jaksi neumi dns pouzivat vubec. Co tak mam v pameti tak srv pouziva treba exchange pro nejakou tu autokofiguraci outlooku.

Je mnohem akceptovatelnejsi posilat 100 radove bajtovych query do DNS, protoze to je na to vylozene navrzeno, nez posilat MB v jednom.

DoH/DoQ si muzete zprovoznit i na svem serveru a svuj browser nechat komunikovat primo s nim :-) Pripadne si vybrat z ruznych dalsich poskytovatelu. Opet se potvrzuje, ze ty vase noticky z ruske trolli farmy maji proste fatalni trhliny - tohle fakt neni jen o Google.

srv zaznam se pro web pouziva zcela bezne, jen prohlizece jaksi neumi dns pouzivat vubec.
Takže to používají weby, které nechtějí, aby jim tam chodili lidi? Protože web se používá v drtivé většině případů pomocí webových prohlížečů (nějaké indexovací roboty můžeme pominout), takže když webové prohlížeče SRV záznamy nepodporují, znamená to, že se pro web nepoužívají.

Nebo když je to podle vás „pro web zcela běžné“, dokážete dát odkaz na nějaký web, který má SRV záznam?

Co tak mam v pameti tak srv pouziva treba exchange pro nejakou tu autokofiguraci outlooku.
Jenže to není web.

Je mnohem akceptovatelnejsi posilat 100 radove bajtovych query do DNS, protoze to je na to vylozene navrzeno, nez posilat MB v jednom.
Za prvé to s těmi velikostmi velmi přeháníte. Za druhé tu muž hezkou řádku let máme DNSSEC, takže o něco větší odpovědi jsou už dávno realitou. Za třetí, podstatnější je síťový roundtrip. Když je komunikace požadavek–odpověď, je tam síťový roundtrip jednou. Když to bude požadavek–odpověď–požadavek–odpověď, bude tam síťový roundtrip dvakrát, i kdyby jinak velikost dat byla stejná (jako že by nebyla, protože v druhém případě byste tam měl třeba také druhý podpis).

Jo, takže byste poslal dotazy třeba na tři adresy (až bude i protokol HTTP/4), a pak byste čekal, až vám přijde negativní odpověď na _http4._tcp.e­xample.com, a_http3._tcp.e­xample.com, abyste konečně mohl použít protokol HTTP/2. To by se fakt vyplatilo – zejména když negativní DNS odpovědi s kešováním nejsou nejlepší přátelé.

Součástí SRV je služba (protokol také, ale to jde o TCP/UDP), ale ne verze služby.

Navíc SRV odkazuje na hostname, které by se muselo překládat dalším dotazem. HTTPS záznam umožňuje vložit IPv4 i IPv6 adresy přímo do něj.

Nadáváte ostatním, že něco neznají, ale zatím to vypadá, že jste článek ani nečetl.

To je tak kdyz nekdo nicemu nerozumi, o nicem nic nevi a protoze nema naprosto zadny argument, tak tu posila lidi do ruska, ze ktereho s holou riti sam prisel.

No prave jste uspesne popsal sam sebe. Nerozumite totu, ale vyjadrujete se. Ja narozdil od vas tyhle veci zprovoznit umim.

Fajn, chci navázat https spojení s nějakým serverem
Mám k dispozici linuxový socket a openssl s certifikátama (kořenonovýma)

Jak tohoto využiju? socket -> getaddrinfo -> connect -> ssl_client
nikdě po cestě tam nevidím možnost to využít

21. 5. 2024, 13:11 editováno autorem komentáře

Opravte mě, jestli se pletu. Outlook není nástroj k prohlížení *webu* a to ani přibližně. Ani jako aplikace interně používající web, např. jako Slack. Já ho teda nepoužívám a neznám poslední verzi, ale vážně pochybuju, že se to změnilo.

Mimochodem, autokonfigurace mailu pomocí SVCB dává mnohem větší smysl. Umožňuje definovat všechny protokoly pro přístup k jedné službě pomocí jména. Tedy pokud podporujete IMAPS i IMAP+StartTLS na různých portech, SRV neumožňuje říct, který z nich je preferovaný. Protože jeho priorita definuje váhu a prioritu jenom pro konkrétní protokol a mezi jeho různými endpointy.

Nepsal jsem, že se SRV nepoužívají na internetu. Rozhodně se běžně nepoužívají pro webové stránky ani v populárních prohlížečích, ani v knihovnách vestavěných v aplikacích. A samozřejmě DNS má omezenou velikost odpovědi, ale 100 samostatných query rozhodně není stejných, jako jedna query obsahující vše potřebné. I když je větší, ovšem pořád dost pod 1KB. Myslím, že lidé na IETF dnsop WG o tom ví dost na to, aby to nepustili do finále, pokud to vůbec nedávalo smysl.