Vlákno názorů k článku DNS over HTTPS: nový standard pro bezpečné a soukromé DNS od me - "DNS over HTTPS" se mi zda jako dobry...
-
me (neregistrovaný)
"DNS over HTTPS" se mi zda jako dobry napad pro mobilni telefon, ale predstava, ze prohlizec na domacim PC bude ignorovat lokalni DNS server ziskany z DHCP a bude se dotazovat primo nejakeho globalniho DNS serveru me prilis netesi. Pro pristup na lokalni zdroje budu nucen pouzit IP adresy, v budoucnu pak dlouhe IPv6 adresy. Snad to pujde v prohlizeci manualne vypnout a snad bude dostupny modul DoT pro router, ktery bude sluzbu bezpecneho DNS nabizet zbytku lokalni site....
-
Filip JirsákStříbrný podporovatelV budoucnu dlouhé IPv6 adresy používat nebudete muset, protože k nim budete mít normálně záznamy v DNS. Lokální DNS jsou jedním z problémů, které způsobuje nedostatek veřejných IPv4 adres.
-
Petr M (neregistrovaný)
Sorry, ale NECHCI si platit doménu a NECHCI mít ve veřejné DNS svoje lokální stroje jenom proto, abych si nemusel pamatovat IP adresy. Je to bezpečnostní riziko a nepotřebuju, aby někdo viděl, že na 2001:abcd:ef12:5600::7 je tiskárna s webovým rozhraním. A musí se s tímhle tvým modelem řešit statisíce vypnutí/zapnutí strojů v desetititsících LAN v domácnostech ve veřejné DNS infrastruktuře (protože i domácí krabička za 500 by se stala veřejným serverem).
Takže svoje stroje mám (zatím) v doméně .local na lokálním unboundu a nic na tom měnit nehodlám. I když po 6ce chodí 80% trafficu.
Chce to nějaký "LNS - Local Naming System":
- Komunikace po TLS se zařízeníma, co budou mít registrovaný klíče (soukromí je soukromí)
- Každý zařízení se tam ohlásí při přidělení IPv6
- S timeoutem (například pro případ pádu systému nebo přerušení napájení)
- S formátem dat klasickýho DNS
- S volitelnou možností přidání odkazu na LNS do DNSPak by z pohledu uživatele byl počítač normálně vidět přes jméno jako z DNS ( např. tiskarna.local ), ale kdo nemá klíč k LNS, ten se k tomu prostě nedostane. A když chceš jít na server zvenčí, buďto si na stroji zadrátuješ LNS server natvrdo, nebo služba zkusí lns.mojedomena.tld
-
Filip JirsákStříbrný podporovatel
V době, kdy ISP poskytovali připojení k internetu, bylo běžné, že svým zákazníkům poskytli doménu (třetího nebo čtvrtého řádu) a e-mailovou schránku. Není důvod, proč by to tak nemohlo fungovat i nyní. I dnes existují na ISP nezávislí poskytovatelé DNS služeb, kde máte nějaký základ zdarma.
Mít ve veřejném DNS lokální stroje není bezpečnostní riziko. Například proto, že nemusíte povolovat přenos zóny, takže se z DNS nikdo nedozví, že daný záznam existuje, pokud předem nezná jeho jméno. A už vůbec se z DNS nikdo nedozví, že na nějaké IP adrese je tiskárna s webovým rozhraním.
Proč by se tím měly řešit statisíce vypnutí/zapnutí strojů? To se vypnutím nebo zapnutím změní DNS záznam?
Takže svoje stroje mám (zatím) v doméně .local na lokálním unboundu
To je váš problém.Chce to nějaký "LNS - Local Naming System"
Nechce, žádné takové komplikování a rozbíjení funkčnosti sítě není potřeba. Tohle řeší DNS už od okamžiku, kdy DNS vzniklo. Jiná věc je, že jsou lidé IPv4 NATy už tak zblblí, že ani nevědí, jak funguje internet – a trvají na tom, že ty problémy s NATem potřebují i v normálním internetu.Lidé chtějí používat zařízení normálně připojená k internetu, nechtějí řešit, že teď mají mobil, tablet nebo notebook připojený k domácí WiFi a k NASu nebo televizi se mají připojovat lokálním DNS názvem, a když přejdou o pár kroků dál, WiFi signál se jim ztratí, zařízení se přepne na mobilní síť a musí se přepnout na veřejné DNS názvy.
-
ja. (neregistrovaný)
V tej dobe sme tiez pouzivali dial-up. Dalsia vec, ku ktorej sa vraciat nebudeme.
V praxi je to tak, ze:
1. split horizon DNS existuje a bude existovat, bez ohladu na to, co si niektori ludia okolo DNS zelaju; existuje na to dostatocny pocet subjektov s dostatocnym impactom.
2. rovnako budu existovat lokalne resolvery;
3. pokial niektory software nebude podporovat lokalny resolver, bude v organizaciach z bodu 1 vyradeny zo zoznamu podporovaneho software a nahradeny takym, ktory lokalny resolver podporuju.
4. goto 1
PS:
a) Samozrejme, ze z DNS sa moze dozvediet, na akej IP adrese je tlaciaren alebo ine zariadenie. Staci resolvovat SRV zaznam z _ipp._tcp.domena, t.j. DNS-SD, ktoru pouzivatelia tiez chcu. Analogicky pre dalsie sluzby.
b) kazde priradenie adresy cez SLAAC alebo DHCPv6 moze mat za nasledok zmenu IP adresy. Uz len spomenuty pripad: pouzivatel sa dostane mimo dosahu wifi, preroamuje do inej siete, dostane inu IP adresu... a uz je DNS neaktualny.
c) "local naming" existuje, vola sa mDNS, ale jeho obmedzenie je, ze funguje iba link-local. Kedze existuje dostatocny pocet organizacii, spomenutych v bode 1 vyssie, ktore chcu, aby im to fungovalo cez viacero subnetov, napriklad z routovanej VPN, tak to celkom neriesi problem, ktory riesit treba.
d) ked sa niekomu strati signal, a je preroamovany do inej siete, je to pre neho signal, ze uz nema opravnenie pristupovat k danemu zdroju. Aby to opravnenie ziskal naspat, potrebuje mat VPN. VPN kludne moze byt na mobilnych zariadeniach always-on, s vynimkou definovanych AP, takze pre pouzivatela sa nic nemeni, ale prevadzkovatel bude kludnejsi, pretoze komunikacia bude vzdy sifrovana bez ohladu na aplikaciu.
-
Petr M (neregistrovaný)
V době, kdy byl dostatek IPv4, tak domácí PC byla vzácnost a pokud lezlo někam ven, tak přes modem a místo IP adresou se identifikovalo telefonním číslem. Teď jsme v situaci, kdy byt s čtyřčlennou rodinou má 2-3 smart TV, multifunkční tiskárnu s LAN, minimálně dva tablety a čtyři smartfouny + 1-3 PC. A "router" k tomu. Takže kdyby to chtěl tatínek propojit s NASem dohromady, má DNS 10-15 záznamů, který se dynamicky mění (nehledě na příchozí návštěvy atd.). Takových bytů máš v paneláku klidně 30 a takových paneláků na jenom sídlišti 50. Počítej 150 domén jenom pro takový sídliště. A hodně přehledný domény jako novak35445.zakaznik.isp.cz. A u ISPíka pěkně velký DNSko, který bude resolvovat doménu .zakaznik.isp.cz a reagovat na každý vykopnutý kabel z modemu, aby záznamy byly aktuální. Fakt super.
LNS by totiž řešilo dva problémy IPv6. Zkus automaticky narvat stroje do DNSka, když mají jenom IPv6 adresu a nemáš v síti DHCPv4 ani AHCP. Ani s *HCP na IPv6 totiž nemáš vyhráno. A domácí zónu jsem ještě nikde implementovanou neviděl.
Takhle stačí zapnout zařízení, to se spojí s domácím routerem, pošle mu podepsaný záznam, kde je a po ověření je vzdálený zařízení dostupný z domova a sosne aktuální stav. Hned vidí jména strojů v lokální síti např. file manageru. Jak když lezeš v LAN na Sambu. A to včetně těch, kdo jsou v divočině.
-
Filip JirsákStříbrný podporovatel
Vycházíte z mylného předpokladu, že se IP adresy musí přidělovat dynamicky a že DNS záznam musí existovat pouze v případě, kdy je dané zařízení dostupné. Naštěstí se věci dají dělat i podstatně jednodušeji.
-
Petr M (neregistrovaný)
IP adresa může být statická, ale v dnešní době to je spíš výjimka. Stejně jako je výjimka, že zařízení bude zapojovat někdo, kdo ví, co dělá. Takže ideální instalace je:
1) Zapojit síťový kabel, nebo vybrat WiFi a heslo.
2) Zadat jméno zařízení a zaškrtnout, že smí komunikovat ven.
3) Přihlásit se na server a potvrdit, že zařízení přidal uživatel.Že na pozadí proběhne výměna RSA a stroje si domluví práva a konfiguraci, updatuje firewall atd. přece uživatel nemusí řešit. Stejně jako konflikty IP adresy atd.
Vynucovat pevnou IP adresu a ručně přečíslovávat (rozuměj měnit /64 prefixy na 20+ strojích ), pokud ISP hrábne do infrastruktury, je přece zbytečný. A i v domácí síti si můžeš chtít zazálohovat data z jednoho komplu na druhý pomocí RSYNCu...
-
Filip JirsákStříbrný podporovatel
Když už si ten router pamatuje, že dané zařízení může komunikovat ven, jaká pro něj platí pravidla firewallu a konfiguraci, může si přece pamatovat i tu IP adresu. Statické adresy jsou pro všechny jednodušší na používání, a pokud někdo má pocit, že potřebuje proměnnou IPv6 adresu, použije IPv6 privacy extension.
Ručně přečíslovávat je opravdu zbytečné, když se změní prefix, router se to automaticky dozví a akorát rozdistribuuje počítačům v síti nové IPv6 adresy s neměnnou adresou zařízení a s novým prefixem sítě.
Nechápu, proč pořád chcete něco komplikovat, proč jednoduše nevyužijete to, co je už v IPv6 navržené – je to původní myšlenka Internetu „síť umožňuje, aby spolu kterákoli dvě zařízení v celém Internetu mohla komunikovat“, doplněná o možnosti autokonfigurace, mobilních sítí, multihome atd.
-
Petr M (neregistrovaný)
Ok. Tak zkusme triviální věc.
Mějme IPv6 only síť. V ní je vrátný s VoIP u vchodu, připojený do LAN. Uživatel má tablet s Androidem a na něm aplikaci a chce dostat notifikaci v případě, že někdo zazvoní na zvonek. Jak to jednoduše uděláš?
- Řešení s DHCPv6 + resolverem nemůžeš použít, nepodporováno Androidem
- Periodický dotazování tabletem ti bude zbytečně vybíjet baterku a generovat nepotřebný provoz na WiFi včetně kolizí atd., přímá notifikace je v tomto ohledu lepší.
-
Filip JirsákStříbrný podporovatel
Petr M: Vážně si myslíte, že můžete vyhrát porovnávání konkrétních implementací, když ten váš LNS protokol vůbec neexistuje? Co asi bude jednodušší – doimplementovat do Androidu podporu DHCPv6, nebo do celého internetu vaše LNS? Navíc pokud někdo chce používat dynamické IPv6 adresy a registrovat je v DNS, nic mu v tom nebrání, je spousta služeb, které to podporují – akorát je potřeba počítat s tím, že DNS obecně s rychlými změnami nepočítá, DNS záznamy se různě cachují, takže někdy nemusí být zařízení s novou IP adresou pod daným názvem hned dostupné.
-
ja. (neregistrovaný)
Vzhladom na principialny postoj Google k DHCPv6* bude lahsie doimplementovat ten jeho LNS do celeho internetu.
Lokalny DNS vie pomerne rychlo reagovat, staci skocit do lubovolnej firmy kde maju Active Directory a vyskusat si to.
* Google odmieta DHCPv6, pretoze umoznuje pridelit jednemu zariadeniu jedinu /128, cim by umoznil mobilnym operatorom vykastrovat tethering.
-
Ad lokal (neregistrovaný)
V prohlížeči to vypnout (zatim) jde (firefox). Dokonce šla nastavit preference zda zkoušet první dns a pak dnsohttps, a preference ipv6 prvni a dokonce i url, kde dnsohttps dotazovat (klidne lokal).
Skrývání lokálních strojů za nat mi připadá vždy jako security by obscurity. Tohle má imho řešit správně nastavený firewall. Tím, ale neříkám, že obhajuju globalni dns. A vzdy si svoje zarizeni muzete pridat docasne treba do /etc/hosts, nez si rozjedete vlastni instanci.
Btw je uz podpora dns over https v majoritních implementacích dns?
-
Security nesecurity by obscurity, pomněte, že pro domácí uživatele je základním plusem jednoduchost řešení. A NAT je výrazně jednodušší než "správně nastavený firewall", přitom pětadevadesáti procentům uživatelů stačí. já to neobhajuju, ale na SOHO se musíte dívat trochu jinou optikou než na firemní sítě.
-
j (neregistrovaný)
Ona platba za domenu je stejna pitomost jako platba za IP. Bohuzel se to takhle zmrvilo, ze si z toho par vyvolenych udelalo kseft. Protoze provoz HW by meli platit ISP z penez od zakazniku (stejne jako platej provoz routeru, switchu atd atd) a at si pak kazdej regne co chce.
Naopak, nejakou bydefault (sub)domenu se kterou si pak muzes delat co chces bys mel dostat pridelenou automaticky s podepsanim libovolny smlouvy na pripojeni.
-
Filip JirsákStříbrný podporovatel
Nedostatek IPv4 adres způsobuje, že se používají IPv4 adresy z privátních rozsahů. A tyhle IP adresy se správně nemají vyskytovat ve veřejném DNS, navíc jsou ty IP adresy z internetu běžně nedostupné – takže se to začalo „řešit“ tím, že se provozují lokální DNS servery, které poskytují DNS záznamy pro ty IP adresy z privátních rozsahů. Buď na samostatné doméně (např.
example.local), nebo na hlavní doméně (example.com), pak se ale do vnitřní sítě poskytují jiné záznamy, než do internetu. Obojí má spoustu nevýhod, v prvním případě musí uživatel rozlišovat, zda je ve vnitřní síti nebo v internetu, nejde na ty záznamy vystavit DV certifikáty od všeobecně uznávaných autorit; v druhém případě jsou zase problémy s nacacheovanými DNS záznamy při přechodu mezi vnitřní sítí a internetem.V době, kdy IPv4 adres byl dostatek, si správci sítě zbytečně nekomplikovali život dvojím DNS (a to byly řádově menším problémem jak DV certifikáty tak mobilní zařízení) a prostě se používala hierarchická struktura DNS, tj. lokální síť měla DNS zónu třetího, čtvrtého pátého řádu a v téhle zóně přidělovala názvy místním počítačům.
-
j (neregistrovaný)
Jisaku, neblabol, zase zvanis vohovne kterymu nerozumis.
Cetifikatu je upne uprdele jestli ma seznam.cz IPcko 77.75.77.53 nebo 192.168.1.2.
Stejne tak vis hovno o .local, to je automaticky pridelovana domena v pripade, ze v siti ZADNY DNS ... NENI!!!
Lokalni DNS se ty trotle pouzivaji predevsim proto, ze kdyz chcipne ta linka ven, tak se kupodivu ocekava, ze unitr vse pobezi dal. A ne ze chcipne cela firma.
A tusis ty vubec ze DNS muze IPcek poslat i vic? A ze kazda normalni aplikace vyzkousi ... vsechny? A tusis ze ti i to verejny DNS posle uplne jinou IP klidne s kazdym dotazem? Protoze se tak resi load balance?
-
Filip JirsákStříbrný podporovatel
Zase čím méně toho víte, tím více nadáváte.
Cetifikatu je upne uprdele jestli ma seznam.cz IPcko 77.75.77.53 nebo 192.168.1.2.
Což není v rozporu s ničím, co jsem napsal.Lokalni DNS se ty trotle pouzivaji predevsim proto, ze kdyz chcipne ta linka ven, tak se kupodivu ocekava, ze unitr vse pobezi dal. A ne ze chcipne cela firma.
Což závisí akorát na tom, zda máte resolver v lokální síti.A tusis ty vubec ze DNS muze IPcek poslat i vic? A ze kazda normalni aplikace vyzkousi ... vsechny? A tusis ze ti i to verejny DNS posle uplne jinou IP klidne s kazdym dotazem? Protoze se tak resi load balance?
Což opět není v rozporu s ničím, co jsem napsal. -
Petr M (neregistrovaný)
"Což závisí akorát na tom, zda máte resolver v lokální síti."
Přesně tak, lokální počítače má ve správě on. Když ho zná, vrátí IP adresu. A je mu jedno, jestli tě má má jako jirsak.blazinec.cz, nebo jako jirsak.name, nebo jako jirsak.local. Akorát použitím .local na vnitřní síti se vyhnu platbě za doménu, kterou nepotřebuju, když tam nelezu zvenčí a kterou ne každý ISP poskytne. Globální doména tam je totiž jenom na to, abych stroje vystrčil na veřejnost. A pokud změním ISPíka, nemusím měnit doménu na DNS. Proto to tak mám.
K certifikátům - https není jediná věc, kterou v LAN máš. Já tohle používám na SSH, RDP, CUPS, NFS a SMB. Router a switche jednou na HTTP, ne na HTTPS. A existuje plno dalších věcí, který na certifikáty kašlou, jako SQL. Web sever v LAN jsem zatím (mimo konfigurace krabiček po http) doma nikdy nepotřeboval a firma beztak doménu má, takže .local není problém ani tady.
-
me (neregistrovaný)
S temi certifikaty je to slozitejsi. Jeste pred cca 2 lety slo vystavit certifikat na libovolnou domenu, treba i lokal. To pred casem padlo, verejna CA dnes vystavi certifikat jen na verejnou domenu. Ale porad funguje, ze i server v lokalni siti muze mit certifikat s verejnym DNS jmenem. Takto se to dela treba v AWS, kde mate na VPC lokalni adresy z rozsahu 10.0.0.0/8, a mate lokalni DNS server (ROUTE53), ktery tyto adresy preklada na jmena jako server1.mojefirma.com. A zakaznik se na servery pripojuje pres load balancery (ELB), ktere uz maji verejnou IP adresu. Pro zakaznika je dulezity certifikat na ELB ale nektere interni sluzby mohou vyzadovat certifikaty na sluzbach ve vnitrni siti, takze dnes se musi tem strojum priradit "verejne" DNS (ktere vsak nemusi byt z internetu routovatelne/dohledatelne). Jinym resenim by bylo vytvorit si vlastni CA a mit vydavani cerifikatu plne pod kontrolou, a obejit tak omezeni, ze CA autorita jiz nemuze vystavit certifikat na domenu "*.mojefirma.local".
-
Filip JirsákStříbrný podporovatel
S temi certifikaty je to slozitejsi. Jeste pred cca 2 lety slo vystavit certifikat na libovolnou domenu, treba i lokal.
Jak ta autorita ověřila, že jste opravdu vlastníkem té domény?Ale porad funguje, ze i server v lokalni siti muze mit certifikat s verejnym DNS jmenem.
Samozřejmě. Protože certifikáty nemají nic společného s IP adresami, DV certifikáty se vystavují na doménová jména. Co s tím doménovým jménem budete dělat autoritu nezajímá a ani nemá možnost to nijak ovlivnit. -
Filip JirsákStříbrný podporovatel
Jasně, takže to selhání Symantecu, kvůli kterému teď jejich certifikáty přestávají být důvěryhodné v prohlížečích, vlastně byla běžná praxe. Vy jste docela šprýmař, že? A na důvod, proč nám žádný takový certifikát nemůžete ukázat, taky najdete nějaký vtip?
-
me (neregistrovaný)
V tom certikatu bylo samozrejem napsano komu byl vydan (firma, adresa), atd, a ty udaje se kontrolovaly a pokud by byla domena nesmyslna, tak by to asi neproslo. Ale pro domenu".local" jsme bezne certifikaty kupovali. Jedina vyhoda takto vydanych certifikatu byla, ze root CA certifikat byl pritomen v keystore klientu, takze se nemusel importovat vlastni root certifikat, coz by jsme museli delat pokud by jsme meli vlastni CA; a to bylo pohodli, za ktere jsme byli ochotni zaplatit. Ano, asi to byl bezpecnostni problem, proto se to globalne zakazalo a dns uz takovy certifikat koupit nejde....
-
me (neregistrovaný)
Tady jsou nejake odkazy popisujici, proc CA prestavaji vydavat certifikaty pro lokalni domeny a jak ma zakaznik reagovat:
https://www.ssl247.co.uk/about/blog/Deprecation-of-ssl-certificates-securing-internal-domains-why-when-and-what-to-do#.W9CJv05fjmE
https://blog.comodo.com/e-commerce/phase-ssl-certs-internal-names-reserved-ip/Kdyz nad tim premyslim, certifikat porad muze obsahovat IP adresu. Kontroluje certifikacni autorita, zda zakaznik je majitelem te IP adresy? A jaka je zaruka, ze zakaznik bude vlastnikem IP adresy i za par dni? Je nejaka garance, ze zakaznikovi IP adresa zustane do konce platnosti certifikatu??
-
Filip JirsákStříbrný podporovatel
OK, bylo to s CA horší, než jsem si myslel, o tom vydávání certifikátů na lokální domény jsem nevěděl. Doufám, že to byly alespoň OV nebo EV certifikáty, tj. že bylo jasné, komu byl ten certifikát vydán.
Pro vydání DV certifikátu na IP adresu snad pořád musíte dokázat to, že jí můžete ovládat, stejně jako u DNS. Že tu IP adresu druhý den nemusíte mít je stejné, jako u DNS – doménu můžete také druhý den prodat nebo může expirovat a koupí ji někdo jiný.
-
j (neregistrovaný)
2me: Jak CA zjisti ze ses majitelem domeny? Mno ... nijak. Proc by mela. LE staci, kdyz jim umis poslat odpoved z DNS. Coz umi ledackdo (alternativne, ze umis umistit nejakej soubor na uz existujici web ... na kterej ukazuje, co jinyho nez ... DNS). A oni tomu DNS verej. Ale browsery prej tomu DNS verit nemuzou, protoze neni duveryhodny, ale cert podepsanej LE na zaklade toho DNS je prej OK .... chmm.
BTW: Zmenit drzitele domeny je otazka ... 10s? Zhruba stejne dlouho trva vymenit zcela koser appku v nejakym storu za zcela nekoser .... at zije bezpecnost.
-
Argumenty lze předkládat i slušně!
local. Není přidělovaná doména. Je to doména pro link-local mdns, kteří tu někteří chtějí i mimo link. Není nijak závislá na přítomnosti DNS v síti. Jenom se bez něj nejvíce hodí.
Certifikát těžko obnovíte automaticky z Lets Encrypt, pokud je použitý pouze na privátních adresách. Bez dodatečných berliček ne.
A ne, DNS určitě neposílá jinou IP s každým dotazem. Obvykle jenom náhodně rotuje stejnou sadu adres. Kvůli cachování a DNSSEC by to jinak nefungovalo.
Zdá se mi to, nebo doporučujete míchat privátní adresy s veřejnými v jednom DNS záznamu? To snad není myšleno vážně?
-
SB (neregistrovaný)
Úplně nechápu, co jste tímto příspěvkem měl na mysli, každopádně správu poddomén globálními DNS považuju obecně za nekoncepčnost, to by si měla vždy řešit sama síť, na kterou by měly být dotazy DNS na poddomény delegovány. Dělení sítě a jejích adresních prostorů taky neřešíte kdesi v pr-deli v Americe. A důvodem k tomu určitě není bezpečnost, ale centralizace správy sítě do jednoho místa a rychlost, jednoduchost a možnosti správy.
-
j (neregistrovaný)
2SB: Jenze takovej system se blbe centralne kontroluje, a jeste hur direktivne ridi. Dost tezko totiz muzes naprosto komukoli zabranit, aby si tohle https://www.mfcr.cz/cs/soukromy-sektor/hazardni-hry/seznam-nepovolenych-internetovych-her dal do svyho lokalniho DNS ... a voiala, vse funguje jak ma.
Stejne tak dost blbe zaridis, aby si nekdo sracky typu bbelements.com (zdravim root) na svym DNS neposlal do /dev/null.
