Vlákno názorů k článku Návod: Bind 9 jako DNS resolver pro domácí síť nebo testovací prostředí od Dan Ohnesorg - Nemam rad, kdyz se pro domaci sit pouzivaji...

Nemam rad, kdyz se pro domaci sit pouzivaji vymyslene top level domeny a to predevsim protoze:

Nemuzete ziskat SSL certifikaty pro pouzivana jmena. Pred 10 lety to vypadalo, ze to nebude nikdy potreba, dneska bych rekl, ze je to potreba napul a za 10 let to pocitam bude zcela nezbytne, prohlizece se budou vzpouzet poslat heslo nesifrovanym kanalem/na IP adresu bez jmena.

Bude hodne tezke v te siti pouzivat DNSsec, bez nej nefunguji ruzne pokrocile DNS zaznamy jako napr. SSHFP.

Kdyz budete mit "stesti" tak vznikne top level domena stejneho jmena. Jak moc je to pravdepodobne je tezko rict, ale treba pro .home se radeji vsichni shodli, ze jeji registrace je vyloucena. Jestli vznikne DOMA corp. velikosti Google tezko odhadovat.

A pokud nekdo chce namitnout, ze nechce aby jeho pocitace byly videt na internetu, tak rovnou rikam, ze to ze je domena zalozena na existujici top level domene vubec neznamena, ze budou vsechna domenova jmena verejne dostupna. Vsechny nameservery umi omezit rozsah IP adres, ktere se mohou ptat na domenove jmeno. I samotnou informaci o tom, kam je dana domena delegovana lze omezit jen na vlastni sit. Na druhou stranu nekoho muze potesit, kdyz bude mit na mobilu permanentne spojeny wireguard domu a bude moct pouzivat verejne DNS a pritom se pripojovat na zarizeni doma. Kdyz to totiz otocite a budete pouzivat domaci DNS skrz VPN, tak bude jednak pomale a jednak kdyz doma nepujde net, tak jste bez internetu i na tom externim zarizeni.

Jinak ten koncept je samozrejme spravny, nikdo si nebude pamatovat IP adresy vsech IoT zarizeni co ma doma, natoz kdyz to budou IPv6 adresy.

Díky jednomu ze "starých bardů" českého Internetu (proslul např. svými
fundovanými příspěvky v někdejší e-konferenci net@cs.felk.cvut.cz již
v 1. pol. 90. let) za zajímavé poznámky a podněty.

Tady se trochu cervenam.... ;-)

Dane, pamatuji si vás i jako správce serveru power.feld.cvut.cz , kde jsem měl možnost si udělat první webové stránky. Rok 1996. A také vzpomínám na PC učebnu dole v Halových laboratořích. Díky za ty časy.

Diky za diky. Ten server stale jeste bezi a ucebna take. Na CVUT mam uz jen minimalni uvazek, ale stale tam chodim.

Kazdy normalny resolver dokaze zvolit DNS server podla domeny, plus zvolit default DNS. Clovek by musel byt blazon aby pri homeoffice posielal vsetku prevadzku cez firemnu VPN...

1. 2. 2022, 10:07 editováno autorem komentáře

Někdy je právě tohle (všechen provoz skrz VPN) podmínkou práce z domova. Že pak kromě zpomalené DNS lezete přes firemní proxy/firewall je jen "bonus".
Na "pracovním" stroji nemá soukromý provoz co dělat.
Na soukromém zařízení je naopak nevhodné připojovat se na firemní síť.

Njn, firmy kde sa preferuje svarc a sef je postih ktory kontroluje aj to ako dlho clovek cural je to "normalne". Pre mna je normalne stanovit si ako dlho mi riesenie bude trvat, dodrzat ten cas a na zaklade toho casu fakturovat. Ak s danym casom ten ktory darmozrac nesuhlasi, tak moze skusit stastie a oslovit niekoho kto mu to urobi za kratsi cas, v porovnatelnej kvalite.

Mohou být i jiné důvody.
Já jsem třeba obyčejný "zaměstnanec" (klasický, plnoúvazkový), ale firma si extrémně potrpí na bezpečnost (což v tomto případě chápu) - nejen z pohledu možného ohrožení infrastruktury, ale taky třeba prevence úniku dat. Takže pro práci z domova je v podstatě jedinou věcí, kterou si každý zajišťuje sám, připojení k Internetu. Zbytek je prostě plně ve firemní režii.

Asi jsem to nenapsal dostatecne jasne, zkusim vic vysvetlit.

Mame domaci sit, kde mame napr. instalaci home assistant na IP 192.168.1.2. A cheme k ni pristupovat mimo jine z mobilu pres VPN. Neresim ted korporatni sit.

A mame bezny mobilni telefon, kam si instalujeme wireguard (nebo cokoliv jineho, ale wg mi prijde jako prvni VPN rozumne pouzitelna pro trvaly provoz na mobilu). Nastavime si split rezim, kdy do te VPN posilame jen provoz pro sit napr. 192.168.1.0/24.

A ted potrebujeme aby ten mobil nejak vedel, ze home assistant ma IP 192.168.1.2. Ja si dokazu na mobilu rozbehnout bind (nebo mozna knot resolver) a forwardovat dotazy podle domeny, ale myslim, ze se do toho nebudu poustet. Takze budu muset pouzit "beznou" konfiguraci meho OS, tedy nastavit IP adresy nameserveru. A bud pouziju IP nameserveru co mam (ma autor clanku) doma a ta bude vedet jakou IP na muj home assistant, ale az mi vypadne spojeni domu tak budu bez DNS a nebo pouziju bezne verejne DNS, jen budu muset zajistit, aby to verejne DNS vedelo, kde je name server, ktery zna IP meho home assistanta. V tuhle chvili mi nevadi, ze ve verejnem DNS ma delegaci zony na privatni IP, protoze ta je bud dostupna pres mou VPN a nebo neni, ale potom tezko bude dostupny ten home assistant, ktery je na stejne siti.

Dovolim si predpokladat, ze 90% zdejsich navstevniku by se do rozbehnuti split DNS na mobilnim zarizeni take nepoustelo. Samozrejme na notebooku by to bylo neco jineho, ale kdo spousti notebook, aby si zapnul cestou domu topeni.

A samozrejme rovnou rikam, ze vim ze 99.9% lidi to vyresi tak, ze si home assistant povesi pod verejny cloud a nebude jeho IP zkoumat vubec nijak. Takze to berte jako stesky nekoho, koho v mladi ucili, ze Internet je sit vzajemne komunikujicich pocitacu a ne sit hloupych terminalu pripojenych k mainframe, pardon cloudu.

Ještě jedno řešení lze použít, byť nevím, nakolik to bude jednoduché na mobilech (omlouvám se, ale můj mobil umí akorát telefonovat, síťařinu na něm neprovozuji): nastavit si dvě DNS, primární z "domácí" sítě, backupový "veřejný". Pokud je domácí síť dostupná (VPN), funguje i překlad adres, ne-li, postačí to, co umí běžná DNSka.
Směrování provozu pak lze nastavit routingem: domácí síť na VPN gateway, zbytek... - ten je "default".

Defaultni timeout je 5s, takze cekani nez by se pouzil zalozni server by se trochu protahlo, zvlast kdyz dnesni webove stranka stahuje obsah z nekolika domen soucasne a jake budou ty dalsi zjistuje postupne jak natahuje obsah. Ale obecne by to asi ve vetsine situaci fungovat mohlo.

Děkuji za konstruktivní názory. Popsané řešení řeší pouze vnitřní přístupy po vnitřní síti. neřeší spojení zvenku. Moje registrovaná doména prý není vhodná k použití v mé vnitřní síti. Doporučen běh u registrátora s přesměrováním na moji veřejnou IP adresu. Názor technické podpory poskytovatele internetu. Možný konflikt ze systémy providera. Raději jsem se nepřel. Popsané řešení ale není problém upravit pro běžnou registrovanou doménu.

Snažím se pochopit, jak tohle nastavit, když mám doma 1 veřejnou IP adresu. Třeba u active24 si nastavím pro internal.mydo­main.tld NS záznam na home.mydomain.tld. Když se mobil bude chtít dostat na homeassistant­.internal.mydo­main.tld, tak se pokusí získat adresu z home.mydomain.tld. To bych však musel provozovat DNS server veřejně, je to tak? Z textu jsem nabyl dojem, že bych mohl zadat do NS záznamu rovnou IP adresu openwrt z interní sítě, ale to neprojde validací (a podle google správně).

Co mi uniká?

Ano, to neprojde, protože tu adresu nezískává mobil, ale rekurzivní DNS server, který má nastavený - což je typicky DNS server u aktuálního ISP, který dostaneš z DHCP, nebo natvrdo nastavený veřejný typu 8.8.8.8. A ten DNS server samozřejmě nemá přístup do té VPN a nemůže se na tu adresu připojit. Musel by sis pustit na mobilu vlastní rekurzivní DNS server (což někteří lidé dělají když chtějí aby jim fungoval DNSSEC).

Ma vubec vyznam delat si interni DNS? Tim myslim jak doma tak ve firme. Vzdy s tim byli jenom problemy. Mam tuseni, ze kdyz vase zabezpeceni spoleha na tajne DNS zaznamy, tak mate neco zle.

Proc nepouzivat verejne DNS?

1. 2. 2022, 16:23 editováno autorem komentáře

Pokud budu mít doma rozsah třeba 192.168.0.0/24, vlastnit domenu domena.cz, a dám si do veřejné dns že pc1.domena.cz je .2, a pak přijdu na návštěvu k sousedovi, který má doma taky 192.168.0.0/24, a mobil se připojí na jeho wifi, najednou se při pc1.domena.local dostanu úplně jidne. To je asi hlavní důvod.
A ne opravdu doma každý nemá ipv6 nebo blok veřejných adres.

Vadi, ze bude u souseda poslouchat na stejnem DNS jiny PC?
Kdyby ano, tak mame SSL.

Co je to „interni DNS“? Server, nebo doména? Jestli myslíte tu doménu, tak protože něco.lan je kratší než něco.moje_domé­na.eu.

No, pri vsi ucte, dnestni manie zbytecneho sifrovani/pode­pisovani uplne vseho "duveryhodnymi" certifikaty neduveryhodnych CA koupenych pres pofiderni zprostredkovatele se spatlanym web-ui a preoperovanou blonckou na telefonu, navic s maximalni platnosti na 1 rok (certifikat i bloncka), minimalni delkou klice, kterou hromada zarizeni ani nemusi podporovat, nebo dokonce ziskanych ze zatim bezplatnych sluzeb typu "hackni cizi web, a my ti vystavime 3 mesice platny a validovany certifikat", se mi s LAN fakt v hlave zatim tak nejak vubec nepotkava.

Uprimne je mi jedno, jestli bez QUIC, DoH, DNSSEC, sifrovani a vynuceneho podepisovani kdejakych public web stranek (bez bezici aplikace a bez moznosti prihlaseni) je mi kazda CDN nebo ISP schopen s minimalnimi naklady a maximalnim ziskem on-fly nahradit NEVYZADANOU reklamu a sledovani uzivatelu kooperatem Google+Facebook nejakou jinou, stejne nechtenou "sluzbou" - a o nic jineho vetsinou dnestnim progresivistum na poli "security" (jako Google a Facebook) bohuzel ani nejde. Smutny, kolik lidi to nevidi nebo videt nechce.

Pritom zrovna ten google a chromium based edge si vesele stahuji sve objemne a frekventovane updaty ve formatu .exe z CDN bez https ... mozna i proto, ze ty CDN maji zhusta na https nasazene invalid certifikaty ...

K te vnitrni siti: naopak, vzdy kdyz je to mozne (nova LAN) tak i vlastni oddelena domena, obvykle s TLD ".local". Pak se to totiz teprve neplete.
Jen bacha na patlala z RH, co tu ".local" domenu pouzil interne uvnitr avahi sluzby. Ale avahi mi na system NESMI (a RH taky ne).

Dokonce i Microsoft do nastupu O365 doporucoval domnivam se totez - pro lan oddelenou domenu (a CA microsoftu, navic s on-fly generovani cert pro zarizeni i servery, s vazbou na NPS a 802.1x ....)

Neprodavam certifikaty, a kupovat si tuny kvalifikovanych kazdy rok pro pouziti v LAN a nebo strkat stejny wildcard na vsechny interni servery, tak to fakt delat nehodlam a ani nikomu nedoporucuju. Generovat si cert req treba na cisco SMB L3 switchi za 1500 kc, a pak pro nej za par set kazdy rok kupovat certifikat, nebo se (marne) do nej pokouset dostat jiz existujici wildcard pouzity i na verejnych serverech v internetu, a pak premyslet, kterymu volovi z dodavatelu utekl ze ktere nesifrovane zalohy private key bez hesla ? Fakt mi to za ty problemy a prachy stoji ?

Osobne odpojeny sifrovany disk, na nem data vlastni CA pro LAN, openssl. Na online zarizeni jen Sub-CA pro generovani certifikatu pro vpn, hlavne kvuli revokacim (pfsense implementace s UI je celkem slusna).

Cerifikaty pro servery vzdy fqdn hostname, short, a IP. Servery na statice.

K bindu na doma: na malou LAN hw router obvykle podporuje forwarding na ISP s registraci do interniho "DNS" pro interni klienty, nebo lip na sw reseni casto staci unbound ci pdnsd.

Pokud neverim svemu ISP, tak je jedno, jestli forwarduju nebo se nechavam sledovat "dobrotisky" provozujicimi public DNS sluzby jako je Cloudflare nebo Google. Spis pro DNS servery vyrobcu telefonu se mi zhusta muze fake zaznam v domacim DNS, nebo lepe redirekce na fw, + blokace DoH, + DNSBL ....

Bind + DNSSEC by to sice take resil, ale na home a small LAN usera je to dost kanon na vrabce. Treba pfsense balicek bind implementuje UI i s kontrolou syntax, ale stejne je to "nadoma" zbytecne slozity a uzivatel musi znat i principy a terminologii kvuli designem primitivne jednoduche, 35-let stare zakladni pomocne sluzbe nad IP.

Kdyz uz se nekdo IT zivi, nebo ho bavi si hrat, pak proc ne, jen at si "jednim prsten vladne vsem" i doma.

Pokud je komunikace šifrovaná zbytečně, je to zbytečná komunikace.

Zase tvoj extremisticky postoj.
Nemozem suhlasit.
Sifrujes svoju beznu komunikaciu mimo digitalneho sveta?
Urcite nesifrujes. Je to zbytocna komunikacia? No nieje. Len je to komunikacia, ktoru nieje potrebne nijak chranit.
A taka komunikacia existuje aj v tom digitalnom svete a dnes je clovek nuteny ju sifrovat(je sifrovana zbytocne).

Do běžné komunikace mimo digitální svět není tak triviální vstoupit a neděje s to. Do digitální komunikace občas vstupují i ti největší ISP. Možná si myslíte, že TLS slouží jen k utajení komunikace. Ale ono slouží i k zajištění integrity. To, že by někdo zjistil, že si čtete článek na Rootu, který je veřejný, to vás opravdu trápit nemusí. To, že by vám někdo k článku přibalil JavaScript na „těžení“ kryptoměn by vám vadit mohlo.

Nešifrovaná elektronická komunikace nemá žádnou podstatnou výhodu. Za to má podstatnou nevýhodu – musíte u každé komunikace znovu a znovu rozhodovat, jestli musí být šifrovaná nebo jestli tahle komunikace je zrovna dostatečně zbytečná na to, aby šifrovaná být nemusela. K čemu je to dobré? A hlavně tohle rozhodování nemusí dělat jen provozovatel nějaké služby, ale hlavně to musí dělat každý její konzument. Každý uživatel webu by u každé webové stránky měl přemýšlet o tom, zda má být šifrovaná a kontrolovat, zda šifrovaná je. Proč, k čemu je to dobré? Dokáží to uživatelé posoudit? A dělají to reálně?

Mno avahi, mdns a pod + .local ide na triko applu, nie RH. Viz https://datatracker.ietf.org/doc/html/rfc6762

> Jen bacha na patlala z RH, co tu ".local" domenu pouzil interne uvnitr avahi sluzby. Ale avahi mi na system NESMI (a RH taky ne).

To bol patlal z Apple, nie RH. Patlal z RH implementoval to, co podla RFC implementovat mal.

> Dokonce i Microsoft do nastupu O365 doporucoval domnivam se totez - pro lan oddelenou domenu (a CA microsoftu, navic s on-fly generovani cert pro zarizeni i servery, s vazbou na NPS a 802.1x ....)

Oni aj patlali v Microsofte si eventualne precitali RFC a zistili, do akych problemov doviedli svojich zakaznikov, ked im odporucali best practices pouzivat .local.

> Na druhou stranu nekoho muze potesit, kdyz bude mit na mobilu permanentne spojeny wireguard domu a bude moct pouzivat verejne DNS a pritom se pripojovat na zarizeni doma.

Tohle jsem si taky myslel, ale minimálně s IPv4 to pak v praxi nefunguje, protože různá DNS v různých sítích odmítají přeložit domény na RFC1918 adresy, které ve své VPN/doma nejspíš používáte. Například dnsmasq to dělá (tj. všechna OpenWRT zařízení v defaultní konfiguraci) https://serverfault.com/questions/419828/dnsmasq-swallows-local-a-entries