Názory k článku Principy fungování DNS: doménový strom, kategorie TLD a alternativní stromy

.test taky není dobrá volba, je určen právě pro testy...

Co taková ".lan" ... ?

Nebo všude povolit/nastavit mDNS/Avahi/ne­vím_jak_tomu_ří­ká_Apple(asi Bonjour) a jet dynamicky na .local

Pokud chcete mít něco v domácí síti dostupné natrvalo, dříve či později (spíš dříve) narazíte na něco, co bude vyžadovat zabezpečenou komunikaci. Třeba cokoli, co bude mít webové rozhraní. Takže budete potřebovat certifikát od důvěryhodné autority, a pro něj budete potřebovat normální veřejnou doménu. Vytvářet si v malé síti alternativní DNS strom se nevyplatí, víc problémů si tím vytvoříte.

Dříve ISP nabízeli k připojení automaticky e-mailovou schránku, později ještě webhosting. Bylo by na čase, aby se odborná IT veřejnost přestala tvářit, že je normální, když koncoví uživatelé používají IP adresy, a ISP začali svým zákazníkům k internetové přípojce standardně dávat doménu třetího či čtvrtého řádu.

Ne, to RFC rika... we do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks. Coz volne prelozeno znamena - kdyz uz mate tak blbej napad, pouzijte tohle... ale porad plati prvni cast - tedy pokud mozno se tomu vyhnete.

Lze to tedy chápat tak, že v rámci DNS není definovaný ekvivalent privátních rozsahů IPv4/6 a jsou jen jakási méně a více vhodná doporučení?

Nebo je snad myšlenka privátních DNS větví špatně?

Očekával bych že bude:

* doména prvního řádu, která by se resolvovala pouze pomocí prostředků dostupných v lokálním počítači, např. přes /etc/hosts
(například: localtld., localhosttld., ne localhost., aby se to nepletlo)

* doména prvního řádu, která by se neresolvovala přes primár ani sekundáry ale očekávala by spešl server určený v /etc/resolv.conf, pokud by nebyl nastavený, zapsala by se do logů smysluplná chybová hláška, ze které by bylo jasné o co jde.
(například lantld.)

* doména prvního řádu, která by šla pouze k prvnímu DNS (primár případně sekundáry) a ten by defaultně nepředával dotaz nadřazenému DNS serveru. Buď by překlad znal, nebo by měl nastavenou cestu k serveru, který to má resolvovat, nebo by vrátil, že nezná.
(například privatetld.)

Ano, není definovaný žádný. Zatím.

Poslední roky se tady aktivita zvýšila, takže brzy možná. Např.: https://www.icann.org/en/public-comment/proceeding/proposed-procedure-for-selecting-a-top-level-domain-string-for-private-use-13-01-2023

Pro slovo "brzy" je potřeba vzít v úvahu konzervativnos­t/opatrnost ICANN a tedy pomalost procesů pro podobné změny které nejde dobře vzít zpět.

Vzdyt to je vyse - pro domaci pouziti mate dnes akorat home.arpa. V prostredi organizace (ktera beztak urcite nejakou tu domenu mit bude) neni duvod nepouzit nejakou subdomenu tretiho radu. Z praktickeho hlediska je to koneckoncu asi i fuk, zda-li to mam bezprostredne pod TLD nebo o rad nize - klientum nastavite search-list (typicky pres DHCP) a jake je FQDN koncoveho uzivatele trapit ani nijak zvlast nemusi.

V obecne rovine si tenhle problem IETF a ICANN mezi sebou dlouhodobe prehazuje jak horky brambor, historie nejake pokusy standardizovat privatni TLD i pamatuje - jen to uplne nedopadlo.

Ano, vypadá to tak, že home.arpa. je v současné době asi "nejstandardnější" řešení, byť to IMHO, není pěkné a na první pohled pochopitelné.
Pokud někdo bude mít jen základní informace a doménách 1/2/x úrovně, tak se nejspíš podiví, "Proč si něco sahá do home TLD Arpy?".

Použití vymyšlené domény xtého řádu, bez toho aby to autoritativní server pro tu doménu správně překládal na LAN adresy a zároveň dotazy z vnějšku nebyly resolvovány, to už je režie navíc.

Z toho RFC 8375 vyplývá například:
4.3: One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. For an administrative domain that uses subdomains of 'home.arpa.' ...

4.4.A: Recursive resolvers at sites using 'home.arpa.' MUST transparently support DNSSEC queries: queries for DNSSEC records and queries with the DNSSEC OK (DO) bit set.

4.4.C: C. In addition to the behavior specified above, recursive
resolvers that can be used in a homenet MUST be configurable
to forward queries for 'home.arpa.' and subdomains of
'home.arpa.' to an authoritative server for 'home.arpa.'

Takže v prostředí, kdy nemáte plnou kontrolu nad sítí se to "správné nastavení" komplikuje.

Že je to místy nevyhovující a je zájem s tím něco dělat vyplývá z https://www.icann.org/en/system/files/files/sac-113-en.pdf
Snad to časem dokonverguje do stavu, který se i mě bude zdát OK. Do té doby: "S home.arpa. na věčné časy a nikdy jinak". :)

Ano, myšlenka privátních DNS větví je špatně. Protože vychází z předpokladu, že zařízení je připojené jen do jedné sítě (což není pravda, zařízení připojené do více sítí má dnes každý v kapse). Dále vychází z předpokladu, že v jedné síti se používají jen DNS resolvery dodané správcem sítě, což také není pravda.

Navíc privátní DNS větve pro použití v místní síti se používají jen proto, aby se ušetřilo za opravdovou doménu. Což nedává smysl tam, kde už opravdovou doménu mají. A ten zbytek (většina domácích sítí, ale zdaleka ne všechny) by byl daleko lépe řešitelný doménou třeba 3. řádu delegovanou třeba od ISP. Navíc pokud už by se někdo dělal z rozchozením domácí privátní domény, asi nebude mít problém zaplatit pár korun za reálnou doménu.

Pripojeni do vice siti soubezne problem fakt neni - ta pripojeni se daji bez vetsich obtizi priorizovat. Takze kabel vyhraje nad wifi... a kdyz neni wifi, porad je tu fallback v podobe mobilnich dat. No problema... ostatne tak i ty zarizeni "v kapse" funguji - kdyz maji wifi, tak na mobilni data dlabou, ze? ;-)

Privatni domeny v principu nesmysl nejsou - stejne jako nejsou nesmysl privatni adresy - oboji samozrejme muze byt a byva zdrojem kolizi. Ale zatimco privatni adresni prostor "s moznymi kolizemi" kodifikovany mame (jak u IPv4, tak i u IPv6), tak u DNS se tomu z nedefinovaneho duvodu branime - argument zarizeni pripojeneho do vice siti jde samozrejme ekvivalentne pouzit i u tech IP adres, ze...? A tam pripadna kolize nadela vetsi paseku, nez zrovna ve specifickych use-case nefungujici DNS.

Spekulovat muzeme spis o tom, proc se nektere "gTLD" nechteji pro privatni uziti rezervovat. A dost bych podeziral ICANN z toho, z takto rezerovane domeny uz nikdy zadne prachy nikdy nevytriska... zatimco udrzovat okoli "ve strachu", ze treba takovou .local muze nekomu legitimne za penize pridelit (coz muze a v pripade jinych gTLD i dela) je pro ne proste z politickeho uhlu pohledu vyhodnejsi....

Nehledal bych za tím hned nějaký nekalý záměr. Podle mě, stačí starý dobrý problém, vzájemně se domluvit.

Síť se používá na různých místech, různým způsobem. (Tím nemyslím evidentně špatné způsoby.) Není jedno jediné řešení. Problémem může být vůbec pochopit, prostředí těch druhých.
Když se pohybujete v prostředí středních a velkých firem, je to dost jiné než prostředí malých firem, živnostníků, v domácnostech nebo ve vzdělávání.

Pokud si někdo myslí, že je běžné mít vlastí doménu, tak v řadě případů tomu tak není. Pokud si myslíte, že je běžné, mít kontrolu nad nastavením DHCP, místním DNS, routingem a bránou, tak to tak také být nemusí.

Realita bývá košatější než pravidla a technologie, které se ji snaží podchytit.

Ano, nemusi kazdy porozumet vsemu - ale to, ze tomu nerozumim neospravedli fakt, ze davno existujici navrh se proste nenecha projit... a argument proc by to projit melo jste zminil sam - prostredi a potreby jsou ruzne. Zrovna v tomhle pripade je to myslim celkem jednoduche - staci par tech jmen zarezervovat podobne, jako mame ruzne rezervovane nektere IPv4/IPv6 prefixy.

Jedina "skoda", ktera muze vzniknout je maximalne to, ze to v budoucnu bude hure monetarizovat - a muzeme si vypujcit ze sveta IPv4, kde s vidinou penez lezicich ladem se objevuji snahy vzit dnes rezervovane adresni prostory zrecyklovat - o miliardach dolaru se v prezentaci mluvi hned na druhem slide... aneb za vsim hledej prachy :)

Prioritizace sítí neřeší problém, že se uživatel nedostane k DNS názvu, u kterého by právem očekával, že se tam dostane, protože je k dané síti připojen.

Význam privátních DNS i privátních IP adres je jenom v tom, že ušetříme za veřejné. Protože není problém mít veřejné IP adresy a neroutovat je do internetu, a mít veřejnou doménu a nepropagovat ji (nebo některé záznamy) do internetu). Takové řešení má výhodu, že nehrozí konflikty. Nebo můžete něco zveřejnit selektivně, jen pro někoho.

Spravne implementovana priorizace to samozrejme vyresi - staci se zeptat resolveru, ktere k siti se zrovna nevyssi prioritou nalezi - coz se musi udelat tak jako tak. Ani samotna globalni unikatnost DNS jmena vam zrovnatak nezaruci, ze stejnou (tu ocekavanou) odpoved dostanete bez ohledu na to, jakeho DNS serveru se zrovna zeptate. Jako prakticky priklad ze zivota muzeme vypichnout treba views u binda, ze?

Privatni, nebo tedy presneji lokalne unikatni adresy mate definovane i pro IPv6. A duvodem jejich existence rozhodne neni jen nejaka uspora adres, jak se tu snazite podsouvat.

Hezky jste popsal, proč to samozřejmě nefunguje. Představte si to třeba tak, že budete připojený do dvou VPN. Použije se DNS resolver VPN s nejvyšší prioritou, který vám samozřejmě nedokáže přeložit privátní DNS názvy z té druhé VPN.

To, že vám různé servery budou vracet různé odpovědi, je rozhodnutí správce dané domény. Když nechce, používat to nemusí. (Bavíme se samozřejmě o dlouhodobém pohledu – ne o tom, že po změně záznamu bude někde ještě nakešovaná stará hodnota a někde už bude nová.)

Jsem zvědav na vaše vysvětlení, co můžete dělat s privátními IP adresami, co by nebylo možné s veřejnými adresami.

Z bezpecnostnihu uhlu pohledu je nesmysl do verejneho DNS vystavit detaily o vnitrni infrastrukture. Takze samozrejme cely vas scenar "spravce nechce/nemusi" v praxi pochopitelne ve vetsim meritku nenastava.

A ze nerozumite obsahu vyse odkazaneho RFC 4193 je vas problem, ja vam to vysvetlovat nebudu. Odpoved na vas hloupy dotaz tam mate.

Security by obscurity není považována za dobrý způsobe řešení bezpečnosti. Navíc do DNS nemusíte nic vystavovat – DNS může fungovat tak, že jenom ten, kdo zná DNS název, ho dokáže přeložit. A pořád je split horizon v prostředí více sítí řešitelný, i když to běžné resolvery nepodporují. Ale když budete mít ve dvou různých sítích stejně pojmenované DNS záznamy, tak nezařídíte, aby fungovaly oba dva, ani kdybyste se na hlavu postavil.

Když napíšete, že existují případy, kdy se bez X neobejdete, není hloupý dotaz ptát se na příklad. Hloupé je naopak vymlouvat se, když máte příkald uvést.

Ale uznávám, moje chyba, neměl jsem se pouštět do diskuse s trollem. Howgh.

Definici privatnich DNS najdete mj. v RFC 8499, pripadne si muzete udelat historicky odskok az k RFC 2775, kde se o split DNS pojednava. Z RFC 8499 je ale zrejme, ze takovy postup je akceptovany v souladu s internetovymi standardy, takze to nemuze byt vnimano jako security through obscurity. A kdyz se pozorne zactete do RFC 2826, zjistite ze mit "privatni" DNS hiearchii pripousti a nezapovida ani IAB (nebrani tomu).

Za domaci ukol se muzete zamyslet nad tim, jak jsem prisel na existenci vaseho zaznamu _github-pages-challenge-Czechitas-podklady-WEB.existuje-mimozemsky-zivot.cz ci 9pds4-check.prvnido­jem.cz, prece jste to nikomu nesdeloval, ze? :-) A mozna vam pak secvakne, proc neni dobry napad do verejne dostupneho DNS cpat treba IP adresy vnitropodnikoveho domenoveho radice a proc se v obecne rovine silne z pohledu bezpecnosti doporucuje mit vnitrni DNS oddelene (a neresolvnutelne zvenci) - ostatne toto odrazi treba i text RFC 6950. Za kecy o trollech se snazite zamaskovat fakt, ze o tech standardech toho sam moc nevite a jejich znalost nahrazujete jen svymi dojmy ;-)

takovy postup je akceptovany v souladu s internetovymi standardy, takze to nemuze byt vnimano jako security through obscurity
Některé vaše hlášky jsou fakt vtipné, to se musí nechat.

Ano, vase hlasky jsou vtipne... zejmena ty o security through obscurity. Jeste ze jen programujete v Jave a bezpecakum do prace moc nefusujete :D

Souhlasím s vámi.
Jinak chci hlavně dodat, že u správců Windows sítí založených na Active Directory byla (je) zažitá praxe pojmenovávat Windows doménu jako firma.local. Doménové stroje pak mají FQDN např. server1.firma­.local. Už dlouho ale Microsoft doporučuje např. ad.firma.cz

Zvláštní, že tam není microsoftem kdysi defaultne doporucovana .local. Nebo na linuxu často používaná .localdomain.

Jak uz tu nekdo psal, ".local" fakt neni dobry napad na tohle pouzivat, ta se pouziva v mDNS. Ze ji nekdy "doporucoval" Microsoft by mne neprekvapilo, kdyz mel mDNS funkcni asi jako posledni (myslim ze az od Win10, a to jeste omezene).

A pouziti ".localdomain" osobne beru spis aby "localhost" mohl mit FQDN. A pac se zda, ze toho nazoru jsou i nektery appky, boxy a sluzby, tak jeji pouziti mimo by mohlo skoncit dost neprijemne.

20. 10. 2023, 10:51 editováno autorem komentáře

Microsoft používal .local. Jako výchozí tld pro active directory u small business servru. Potkal sem se s tim na vice mistech. Přitom vzdy tam byla možnost použití domény 3. Řádu (např. Corp.firma.cz.)

Na prasarny clovek narazi vsude. Cim vetsi enterprise to je, tim je i vyssi pravdepodobnost nejake prasarny.
Takova vsphere se by default cpe taky jako “.local”, i kdyz tam nema co delat.

.local používá i Apple.
Myslel jsem, že je to obecná doména lokální sitě, aby to bylo jasně rozlišené.
Když napíšete jen hostname v DNS nastavení klienta mohou být záznamy výchozích domén, kde se má hledat, pokud se samotný hostname nenajde.
tj. "myPC" se pak může hledat třeba v doméně "google.com".

Apple to pouziva, ale prave v mDNS (v jeho zeroconf implementaci Bonjour). Tedy ze neni zadny nameserver, ktery by drzel obsah zony ".local", na ten dotaz "kdo je XY(.local)?" odpovida prave ten XY, ne NS (a ten dotaz je poslan pres multicast IP, nepta se zadnyho konkretniho NS) . Je to proste jina sluzba nez klasicky DNS.
Jakmile je nejaka domena pridelovana, pak uz to neni ta ".local" (v ramci ktery ten strojek ale porad na svoje jmeno odpovida, pro ostatni strojky v te same LAN).

20. 10. 2023, 14:55 editováno autorem komentáře

Vzhledem k tomu, že Apple je primárním autorem MDNS, tak skoro určitě používá .local pouze pro multicast. Tedy jen tam, kde má. Je to doména pro hledání pouze v místní síti na stejné lince. Schválně si zkus monitorovat port 53 nebo 853, jestli tam tyhle dotazy půjdou. Apple systém nemám, ale v tomhle jim věřím.

A naopak, search domény se používají před tím, než se zkusí samotný hostname. Tedy v případě, že neobsahuje tečku. S tečkou se search domény obvykle nepoužívají, alespoň na linuxu.