Názory k článku Veřejné DNS resolvery CZ.NIC podporují také DNS-over-HTTPS
-
Vladimír ČunátStříbrný podporovatelV UI je výběr ze seznamu "CZ.NIC (TLS)" - jen jim budou přiřazeny jiné IP (ty ani ukázány nejsou). Nevidím nic špatného. Zvlášť když se ty staré IP budou vyřazovat.
-
Dobrý den,
DNS dotazy jdoucí na ODVR servery nelogujeme, nefiltrujeme a nezpracováváme. Pouze na základě interních statistik démona (viz https://knot-resolver.readthedocs.io/en/stable/modules.html#built-in-statistics) počítáme součet některých metrik ze všech serverů, abychom měli představu, jak je prostředí využíváno. Konkrétně tedy je o součet všech requestů, nakešovaných odpovědí, DoH a DoT.
VS.
-
Android od verze 9 Pie umí DNS-over-TLS. Nastavení - Síť a internet - Rozšířené - Soukromé DNS. Tam se vybere třetí možnost a vyplní odvr.nic.cz nebo jiný poskytovatel služby.
-
Vladimír ČunátStříbrný podporovatel
Ano, tak by to tam mělo fungovat. A obecně to rozhodně považuji za mnohem lepší přístup než když si každý program řeší vlastní DNS.
-
> I při použití protokolu DoH platí, že nefiltrujeme žádné DNS dotazy, vyjma privátních IPv4 a IPv6 rozsahů.
Co to znamena? Bezne pouzivame ve verejnem DNS neverejne IP adresy.
Takze pak mame napr. "intranet.firma.cz A 10.20.30.1". Jakmile je uzivatel ve VPN, web mu funguje. A VPN server nemusi podvrhavat vlastni DNS servery.Tohle bude fungovat, nebo ne?
-
Vladimír ČunátStříbrný podporovatel
Fungovalo by to, ale záměrně je to odfiltrováno. Proč? Například: https://en.wikipedia.org/wiki/DNS_rebinding
-
BobTheBuilderStříbrný podporovatel"should not"
Kdo to použije, tak musí s nejednoznačností počítat.
Vzhledem k tomu, že jsem taky v situaci, kdy je to pro mě nejjednodušší řešení, tak prostě odvr.nic.cz nepoužiju, a když nebudu ochoten snášet resolver providera, použiju třeba Google.
Je otázka, zda je to ze strany CZ.NIC rozumné, protože po pár potížích z tohoto vyplývajících získají nálepku "CZ.NIC nebrat, raději použijte Cloudflare nebo Google".
Ostatně, když používáte privátní IPv4 adresy (jako že téměř každý klient ISP to používá), tak se vám stane, že VPN do firmy nefunguje, protože máte ve firmě i doma stejnou neveřejnou síť - dokud si to na jedné straně nezměníte.
IPv6-only zatím pořád není řešení, protože si tím odříznete klienty z našich mobilních sítí. -
Filip JirsákStříbrný podporovatelPodle mne je to vaše řešení v době nedostatku veřejných IPv4 adres nejlepší možné, nicméně jakési doporučení praví, že by se ve veřejném DNS neměly používat IP adresy z privátních rozsahů. Ona ta vaše adresa fakticky není veřejná, to doporučení podle mne zaspalo dobu, bohužel se jím ale spousta správců DNS resolverů řídí. KnotDNS Resolver ty adresy ve výchozím nastavení blokuje, Unbound myslím také. Podle předchozího komentáře soudím, že se tímhle doporučením řídí i ODVR CZ.NICu. Vám asi nezbývá, než podvrhávat vlastní DNS servery pro VPN připojení. Holt na internetu se rozbité věci ne vždy opravují, místo toho se na tu rozbitou věc vymyslí nějaký vohejbák, který celou situaci ještě zhorší…
Ale CZ.NIC je v tomto nevinně, oni to doporučení nevymysleli a zdaleka nejsou jediní, kdo se jím řídí – takže teď jste se akorát dozvěděl, že vaše řešení by nemuselo ve spoustě jiných sítí fungovat. Leda že by CZ.NIC vymyslel nějaký DNS flag day #2, aby se s tímhle doporučením skoncovalo (když už se snažíme prosadit IPv6, všude HTTPS – a privátní IP adresy ve veřejném DNS jsou nejsnazší cesta, jak se k těmto věcem přiblížit, když musíte podporovat IPv4). -
Privátní adresové bloky pro IPv4 jsou definovány v RFC 1918, a každý, kdo je používá, by se měl touto specifikací řídit. Je tedy chyba, když privátní adresy prosakují do veřejného internetu. O tom, že by se s tímto principem skoncovalo, nemůže být ani řeč.
Takzvané duální DNS, v němž jsou oddělené zóny pro intranet a internet, je dávno známý a osvědčený postup popsaný už ve zmíněném RFC 1918.
-
Jenze jak vyresim problem uzivatele, ktery potrebuje byt na svem PC ve vice VPN soucasne a mit pristup do serveru ve vnitrnich sitich?
Pak nejde pouzit, ze VPN nastavi uzivateli vlastni DNS server.Na tohle uplne nevim jak (a jestli vubec) jde dualni DNS pouzit.
Nastaveni privatni IP do verejneho DNS se mi v tomto pripade zda, jako nejmensi zlo.
Zajimave taky je, ze 8.8.8.8 i 1.1.1.1 mi neverejne IP bez problemu vraci. Sice proti RFC, ale vraci.
-
Filip JirsákStříbrný podporovatel
Vyřešíte to tak, že budete používat v DNS privátní IPv4 adresy a DNS unesete na vlastní resolver, který to filtrování dělat nebude. Pak bude fungovat připojení do všech VPN, které používají tohle řešení. Nebude to fungovat pro síť, kde se používají oddělené DNS zóny – pokud tedy vyhraje rozumně nakonfigurovnaý DNS resolver. Ale to není váš problém, že nefunguje nějaká cizí VPN :-)
Zajimave taky je, ze 8.8.8.8 i 1.1.1.1 mi neverejne IP bez problemu vraci. Sice proti RFC, ale vraci.
Oni se ti velcí hráči přeci jen snaží rozbít toho co nejméně. A když je to doporučení zastaralé… Navíc to není proti RFC, to doporučení neříká, že se to dělat nesmí – je tam použité should, tedy nemělo by se to dělat, ale mohou existovat důvody, proč to udělat. -
Při použití více VPN současně se vám ale může taky snadno stát, že se budou překrývat jejich adresové prostory.
Je asi třeba říct, že RFC 1918, všechny možné NATy apod. znamenaly pro architekturu internetu docela velkou ránu, i když vynucenou okolnostmi.
Veřejné resolvery ty privátní adresy samozřejmě filtrovat mohou, ale nemusí, to je věc politiky. Je asi přirozené, že pro komerční poskytovatele, jako je Cloudflare nebo Google, platí „náš zákazník, náš pán”, zatímco CZ.NIC více dbá na dodržování standardů.
-
Filip JirsákStříbrný podporovatel
Překryv adresních prostorů se stát samozřejmě může – ale to, že může nastat jeden problém, neznamená, že si mám přidělávat jiný problém s DNS. Nedostatek IPv4 adres a z toho plynoucí NATy jsou pro internet velká rána, podle mne ale filtrování v DNS tu ránu akorát prohlubuje. Já jsem velký zastánce dodržování standardů, ale některé zastaralé standardy by to chtělo změnit.
-
Ondřej CaletkaZlatý podporovatelJenze jak vyresim problem uzivatele, ktery potrebuje byt na svem PC ve vice VPN soucasne a mit pristup do serveru ve vnitrnich sitich?
Přesně tohle dokáže řešit
systemd-resolved. -
Uplne jednoducho:
* V Linuxe, NetworkManager s dns=dnsmasq umoznuje mat DNS pre kazdy interface a zadefinovat, ktore domeny sa cez neho maju resolvovat
* Pod macOS, to iste umoznuje aj resolver na macOS, pomocou /etc/resolver/*, resp. scutil.
* Pod Windows to umoznuje NPRT (Name Resolution Policy Table) - Add-DnsClientNrptRule -Namespace "intranet.domena.cz" -NameServers "10.0.0.1" a priradenim prislusnych DNS na prislusnych interace.
Takze vas problem nie je limit DNS, ale problem vasej konfiguracie.
-
Filip JirsákStříbrný podporovatel
Jenže o prosakování do veřejného internetu nebyla řeč. Jak víte, DNS zóna nemusí být veřejná, takže pokud nějaké jméno nezveřejním jiným způsobem, je to pouze privátní věc – ten DNS záznam znají pouze „zasvěcení“, kteří se vyskytují v dané síti (ať už přímo nebo přes VPN), takže ta privátní adresa je pro ně dostupná.
Oddělené zóny pro intranet a internet byly vždycky prasárna a mají mnohem horší důsledky, než privátní IP adresy ve „veřejném“ DNS. RFC 1918 pochází z února 1996 – kolik bylo v únoru 1996 chytrých mobilních telefonů, které jsou chvíli připojené přes WiFi, pak ztratí signál, připojí se přes mobilní síť, a za pár minut se zase připojí zpět? Oddělené zóny pro intranet a internet byly použitelné v době, kdy každý počítač byl kabelem přivázán k místní síti a do jiné sítě se za celou svou životnost nedostal. Dnešní realita je úplně jinde a oddělené zóny to rozbíjí.
Dneska můžete mít zařízení připojené do více sítí a skoro každý má takové zařízení v kapse. Potřebujete vystavovat certifikáty na veřejné DNS názvy. Můžete mít jedno zařízení připojené do několika VPN zároveň. To všechno funguje dobře, pokud se používá normální veřejný DNS strom (žádné
.local; neznamená to ale, že všechny DNS záznamy musí být veřejné), funguje to tam, kde je dostatek veřejných IP adres. S privátními IPv4 adresami je v tomto případě jediný problém – je potřeba pro dané zařízení zajistit odpovídající konektivitu, např. přes VPN. To by také fungovalo, a jediný problém je to filtrování na DNS resolverech. Které je k ničemu.Záměr s filtrováním DNS odpovědí (v onom doporučení – chápu, že když to doporučení existuje, bylo by obtížné se jím na veřejném serveru neřídit) je sice bohulibý, ale řeší problém na špatném místě – a co je podstatné, bohužel rozbíjí nejlepší způsob, jak dnes s DNS pracovat. Že je to opatření nesmyslné je vidět už z porovnání IPv4 a IPv6. Pokud příslušná síť bude mít IPv6 konektivitu, bude to neveřejné zařízení mít IPv4 adresu z privátního rozsahu a veřejnou IPv6 adresu. Přes filtrující DNS resolver se DNS záznam přeloží na IPv6, ale na IPv4 se nepřeloží. Celá ta „ochrana“ v DNS je tedy k ničemu.
Když tedy budete počítat s tím filtrováním v DNS, je dnes asi nejčistší použít IPv6 a VPN použít jako nástroj pro dodání IPv6 konektivity. A nebo používat ty privátní IPv4 adresy ve veřejném DNS a při připojení přes VPN unést DNS na svůj resolver, který filtrování nebude provádět. Kdo bude používat stejné řešení, bude v pohodě. Únosem DNS to rozbijete jenom těm, kteří používají „osvědčený“ postup s oddělenými zónami pro intranet a internet.
-
Vláďa Čunát výše popsal jeden konkrétní problém, který je s takovou praxí spojený – DNS rebinding.
Pokud mluvíme o prasárnách, neváhal bych tímto slovem označit i samotné použití globálně nejednoznačných privátních adres (jak už jsem napsal v předchozí odpovědi). Kvůli takovým hackům je IPv4 internet zanesen neuvěřitelným množstvím různých middleboxů, takže o původním end.-to-end principu se dnes vůbec nedá mluvit. Je to podle mne jeden z důvodů, proč zavádění IPv6 tolik drhne.
-
Filip JirsákStříbrný podporovatel
DNS rebinding je přesně ten případ, kdy se někdo v DNS snaží řešit problém, který v DNS nevzniká a ani ho tam vyřešit nelze. Kdyby internet fungoval normálně, tedy všechny IP adresy byly veřejné (tak to bylo a doufám že zase bude), bude ochrana před DNS rebindingem k ničemu.
Že největší prasárnou na současném internetu jsou způsoby, kterými se obchází nedostatek veřejných adres, na tom se shodneme. Jenže zrovna to filtrování DNS odpovědí tomu drhnutí zavádění IPv6 napomáhá.
Podle mne typická síť, kde dnes nejvíc zavádění IPv6 vázne, jsou sítě, které mají desítky až stovky počítačů – moc velké na to, aby správce obešel pár PC a vše nastavil ručně, a moc malé na to, aby měly už vlastní firemní „internet“ (navzájem propojené různé sítě v mnoha různých lokalitách). V takové síti na experimenty s IPv6 moc není prostor, ISP často ani neumí dodat IPv6 konektivitu, ani se nepoužívá všude důsledně DNS, možná je zavedená VPN a nejspíš se používá nějaká síťová doména, v lepším případě
.local. Teď začnou chodit požadavky, že je potřeba všude zavádět HTTPS, samozřejmě se na to chce dostat i ředitel z iPhone, do toho je potřeba nějak začít řešit zprovoznění IPv6. Logické je začít právě od DNS – přejít na standardní veřejnou doménu a začít ji všude důsledně používat. Tím se vyřeší HTTPS, vyřeší se napevno zadané IPv4 adresy. Jenže filtrující DNS resolver bude způsobovat problémy tomu ředitelskému iPhone. -
DNS rebinding je forma zneužití DNS, takže v DNS jednoznačně vzniká. Uznávám, že není omezen na privátní adresy, ovšem tyto adresy může útočník celkem snadno uhádnout a na těchto adresách také běží spousta zařízení, která mají minimální nebo žádnou ochranu (zejména IoT krabičky). Filtrování privátních a loopback adres při rezoluci DNS je doporučenou metodou ochrany.
Pokud máte své návrhy promyšlené, doporučuji je sepsat a podat jako Internet-Draft, který bude updatovat RFC 1918.
-
Filip JirsákStříbrný podporovatel
DNS rebinding není forma zneužití DNS. Když si ve své doméně nastavím A+AAAA záznamy třeba na server Seznamu, je to čistě moje věc, záleží jen na mně, jestli je mi to k něčemu dobré, a Seznam s tím nic neudělá. Obrana je na tom koncovém serveru – pokud má poskytovat službu na mail.exmaple.net a klidně odpovídá i na požadavky na www.example.com, je to problém toho serveru. Filtrování je sice doporučenou metodou obrany, ale není to funkční metoda. To, že se tváříme, že privátní IPv4 adresy jsou nějakou ochranou, je také jeden z důvodů, proč drhne přechod na IPv6. U IPv6 se pořád opakuje „nepoužívejte privátní IP adresy, akorát si tím komplikujete život“, jenže někteří správci věří tomu, že privátní IPv4 adresy je chrání, a proto nechtějí přejít na nechráněné IPv6. Nemyslím si, že je správné podporovat tu představu, že privátní IPv4 před něčím chrání.
Že vaše ODVR servery privátní IPv4 adresy filtrují chápu, i když s tím nesouhlasím – přiklonit se k bezpečnějšímu řešení je legitimní postup. Ale myslím si, že by to mělo ruku v ruce jít s osvětou – popsat proč to filtrujete, jak mohou vypadat útoky, jak se těm útokům bránit a že spousta serverů to nefiltruje a je to v pořádku, že to nefiltrují. Pro reálnou bezpečnost by to podle mne bylo mnohem přínosnější, než to filtrování.
-
DannyStříbrný podporovatelStejne tak ale nikdy nejde zabranit tomu, aby uzivatel omylem natukal URL do browseru, aniz by tu VPN mel vytocenou. Tedy nikdy nejde spolehlive zamezit tomu, aby ono tajne DNS jmeno neuniklo.
-
> Stejne tak ale nikdy nejde zabranit tomu, aby uzivatel omylem natukal URL do browseru, aniz by tu VPN mel vytocenou. Tedy nikdy nejde spolehlive zamezit tomu, aby ono tajne DNS jmeno neuniklo.
To je ale neco jineho. Stejna chyba bude, i kdyz nebude pripojeny k WiFi.
Proste chce-li na tu sluzbu pristupovat, musi mit VPN. Ale nemohu poucovat zakaznika (navic treba jeste s windows), ktery potrebuje najednou 3 vpn, jak si ma provozovat vlastni dnsmasq.Na DNS jmenu s privatni IP neni nic tajneho. Bez VPN se proste nikam nedostanete.
Jak se netaji Dell s intranetem, tak se nebudu tajit ani ja:martin@martin:~$ dig +short intranet.dell.com
intranet2010.ins.dell.com.
10.143.254.93
martin@martin:~$ dig +short passwd.vancl.eu
10.84.84.1
martin@martin:~$ -
Vladimír ČunátStříbrný podporovatel
> Bez VPN se proste nikam nedostanete.
Bez své VPN (obecně v jiné síti) se právě na takové jméno/adresu taky můžete dostat... jen to přirozeně bude jiný stroj než "jste chtěli", protože ty adresy jsou z definice lokální. To samotné už mi zavání zneužitelností, stačí zapomenout zapnout VPN. Většinou se takové adresy myslím dostanou k ISP a je na něm kam je posílá. No, tak jako tak je dobré ověřovat identitu serveru i pokud jde o službu "ve VPN", čímž se tohle a další rizika značně omezují :-)
-
Filip JirsákStříbrný podporovatel
Pokud někdo zkusí zaútočit na to „zapomenu zapnout VPN“ a vystaví v síti falešný „firemní server“, s největší pravděpodobností bude mít i možnost unést DNS dotazy, takže zase filtrování DNS odpovědí někde v internetu ničemu nepomůže. Co pomůže je důvěryhodný certifikát, který už ten útočník nezíská. Samozřejmě to ale nemůže být „jo, používáme doménu .local s naší firemní autoritou, tu hlášku o nedůvěryhodném certifikátu v prohlížeči prostě odklepněte“.
-
Filip JirsákStříbrný podporovatel
Jenže ten DNS název není tajný, on je jen neveřejný. Pokud se bude používat veřejný DNS server nebo DNS server ISP (což je cíl), „unikne“ to jméno i při připojení přes VPN. Podstatné ale je, že to není jméno, které byste odkazoval z veřejného webu, měl ho na vizitce nebo ho našel Googlem. Uživatel, který to jméno zná, by tedy měl vědět, co je to zač, a že k tomu, aby mu to fungovalo, potřebuje třeba firemní VPN. Pokud někdo z venku „uhodne“ třeba jméno
intranet.example.coma bude to zkoušet, nebude mu to fungovat – což je ale jeho problém. -
Filip JirsákStříbrný podporovatel
Míchají se tu dva různé útoky. Jedno je DNS rebinding – cíl útoku je připojen v privátní síti (přímo nebo třeba přes VPN), přijde s prohlížečem na
www.example.com, po nahrání stránky útočník přesměrujewww.example.comna adresu serveru v privátní síti. Pokud ten server má náhodou privátní IPv4 adresu, filtrování DNS odpovědí to může překazit – ale spoléhat se na to nedá. Ale hlavní problém je v tom, že ten interní server klidně odpovídá i na požadavky nawww.example.com.Druhý útok je vlastně opačný – DNS záznam
intranet.example.compovede na privátní IPv4 adresu, uživatel nebude mít zapnutou VPN a útočník na tu privátní IPv4 adresu podvrhne svůj server. Jenže pokud si útočník může v síti na danou IP adresu dát svoje zařízení, s největší pravděpodobností tu síť ovládá a může tam dát i svůj DNS resolver. Tomuhle útoku brání používání a validace certifikátů. -
Taky me to zaskocilo.
Zrovna nedavno jsem s podporovou resil nefungujici prehravani sledovanitv.cz
Dostali jsme se k tomu, ze mi router blokoval preklad neverejnych adres:$ host jmnet1-priv.mtv.cdn.moderntv.eu
jmnet1-priv.mtv.cdn.moderntv.eu has address 10.38.0.255$ host jmnet1-pub.mtv.cdn.moderntv.eu
jmnet1-pub.mtv.cdn.moderntv.eu has address 185.91.168.40Predpokladam tedy ze pri pouziti DoH to take nebude fungovat.
-
DannyStříbrný podporovatel
Toto je vcelku standardni chovani dnsmasq. Je potreba upravit jeho konfiguraci tak, aby tyto odpovedi prochazely (jestli se nepletu, jde o volbu bogus-priv, kterou je treba v konfiguraci vypnout, casto byva implicitne zapnuta). Pokud je uzivatel v siti nejakeho mensiho "wifi" poskytovatele, kde se houfne pouzivaji privatni rozsahy, pak celkem bezne muze byt snaha usetrit zdroje na NATu tim, ze se nektere sluzby honi uvnitr site rovnez na privatnich adresach.
ČLÁNKY DO MAILU