Názory k článku
ICANN navrhuje doménu .internal pro vnitřní použití v neveřejných sítích

Ten název je moc dlouhý.

Tohle nemá smysl psát do diskuse na Rootu. Pokud vám to vadí, pošlete připomínku do ICANN.

Ve vetsine siti je to prakticky stejne tak nejak jedno - malokdy pisete cele FQDN, naopak v DHCP option si naopak bezne poslete domain search-list, takze staci se pripojovat na hostname.

Do chvíle, než na těch věcech je něco se SSL/TLS, kde potom kvůli nekompletnímu jménu neprojde validace certifikátu. Sice s interní zónou to chce vlastní CA, což je v dnešní době LE spíš komplikace, co za to nestojí, ale riziko tam je :-)

1. 2. 2024, 10:08 editováno autorem komentáře

S vlastni CA neni problem vygenerovat certifikat, co ma v SAN i hostname bez domeny (a jde tam nacpat i primo IP adresa).

tak vlastní CA je poměrně nutnost pro interní systémy, protože např. certificate transparency pak na tebe práskné všechny domény a kdoví jestli LE dovolí pro .internal vydávat certy, tipuji si, že nikoliv.

S internal doménou ne. S veřejnou doménou to lze (pokud jsem schopen na tom veřejně dostupném NS zveřejnit TXT záznam s challenge).

Tak zrovna tohle práskání naštěstí už pár let řeší wildcard certifikate.

Ale je pravdou, že úplně stačí si vyrobit neznámý hostname, a nejpozději do hodiny po získání LE certu se člověk obvykle dočká návštěvy googlebota - tolik k motivaci Google, který CT dost tvrdě prosazoval.

To jiste, treba v tech windowsich, tam se totiz neda normalne pouzit ani cname.

FQDN se pise do 100% vsech konfiguraci.

Domena .local byla pouzivana a v dokumentacich odkazovana davno pred nejakym mDNS, vcetne doporuceni a labu Microsoftu. Jeji zneuziti pro mDNS a interne v avahi vedlo spoustu lidi k tomu, ze jako jeden z prvnich kroku po instalaci zakazali mDNS a odinstalovali avahi.

To je jen další argument, proč to takhle nedělat a nepoužít náhodně nějaké slovo, které mě zrovna napadlo nebo mi ho někdo (třeba v dokumentaci) poradil. Pokud není doména pro tento účel vyhrazena, může se snadno stát, že bude později zaregistrována v globálním stromu a použita k něčemu jinému.

mDNS a doména .local se dnes v sítích rutinně používá například k objevování tiskáren či televizí a oznamování různých dalších zařízení poskytujících služby. Pokud ji tedy máte zároveň v místní DNS, máte tam kolizi. Avahi dnes není k použití na klientské straně potřeba, moderní distribuce používají systemd-resoved, který umí mDNS používat.

Pozor, systemd-resolved už třeba v Ubuntu 22.04 a vyšším není, místo něj je resolvectl, a formát výstupů u něj je jiný.

resolvectl je alespoň na Fedoře konfigurační nástroj právě pro systemd-resolved.

Coz se muze snadno stat i v pripade, ze vyhrazena je, ze?

Ne, nemůže. To, že je vyhrazena, znamená, že ICANN slibuje, že se to nestane.

No jistě. A když to někdo udělá, tak od ICANNu dostane rákoskou na holou?

Jistě, že se to STANE. Stejně, jako se to mnohokrát, i ve velkých firmách, stalo s tím pro mDNS už přes 20 let vyhrazeným .local

Přesně proto mám už léta registrovanou jednu rozumně pojmenovanou doménu, která ale vlastně vůbec není veřejná. Používám ji na takové ty domácí počítače v rodině a okolí a do domácích sítí.
Těch pár stokorun jednou za pár let mi za ten klid stojí.

mDNS je s nami od roku 2002; takze "davno pred nejakym mDNS" asi tazko. Ze to nepodporoval Windows, je ina vec.

Dokumentacia Microsoftu to odporucala este pred par rokmi (konkretne este v 2015). Ani v tomto pripade si Microsoft s koliziou zjavne tazku hlavu nerobil. Ale to je problem tych, co si .local AD domenu vytvorili a nepocuvali, ked boli varovani, aka je to blbost.

Prvi verze AD byla ve win 2k, coz je rok 1999. Ve skutecnosti ale predchudce existoval uz ve win NT, coz je rok 1993.

Takze davno pred mDNS asi zcela urcite.

Vsechny implementace mDNS byly jeste pred 10lety tak maximalne polonefunkcni hokuspokusy.

NT domain v 1993 ale nepouzival DNS ze ano.

V roku 2002 bolo mDNS produkcne v OSX 10.2 a existoval hw, ktory to podporoval (prevazne tlaciarne).

Pokud si pamatuju, tak s několika ale (věci jako PDC<1b> do lmhosts apod) používaly. Resp mohly používat (byť dost neoptimálně)
https://networkencyclopedia.com/netbios-name-resolution/

1. 2. 2024, 20:34 editováno autorem komentáře

A proč ne home.arpa z RFC 8375 ?

Protoze home.arpa se nehodi do firemnich siti.

Tam se moc nehodi ani ta .internal :-) Aneb je lepsi pouzit nejakou regulerne registrovanou domeny te firmy (treba na AD, kdy to ve vysledku muze usnadnit pozdejsi spojovani - kdyz to vsichni ve firmach nacpou po internal, tak merge v pripade akvizice bude slusny bolehlav).

Naopak je bolehlav mít local dns svázané s AD doménou a nebo dokonce s veřejnou doménou DNS ...
Budete mít spoustu statických úprav na které musíte myslet a někdy budete muset dělat SplitDNS ... a to fakt nechcete. Automatizace pomůže, ale stejnak je to vopruz.

Bolehlav je pouzit priamo domenu druheho radu namiesto poddomeny (t.j. firma.cz namiesto intra.firma.cz). Ked sa pouzije poddomena, vsetko je v poriadku a netreba ziadne split dns.

Protože většina lidí vůbec netuší co je arpa a navíc je to dlouhé a není to doména prvního řádu (což asi nevadí, ale taky proč by to být neměla). Není jediný rozumný důvod, proč by to nemohlo být prostě jenom .home (kromě toho, že to chce někdo zpeněžit).

U nás sa zaužívala „.lan“. Hádam v budúcnosti nebude kolidovať.

Naše firma už 20 let používá jako interní doménu <zkratka názvu firmy>.int
Ano, vím, že int je zároveň veřejná TLD, ale nikdy s tím problém nevzniknul, v int doméně se toho moc neregistruje. :-)

No, ono je to v pohodě dokud se na využití dané domény nic nezmění. Třeba .dev se všude možně používala dlouho, a pak ji Google uvolnil pro veřejnost a zapl na ní hsts preload. Byla jsem u opravování následků v jedné velké firmě a nebyla to sranda...

2. 2. 2024, 00:13 editováno autorem komentáře

.krakonosovo

To budou firemní ajťáci milovat.
Kam se může poslat návrh?