Split DNS - používáte to někdo?

20.8.2018 10:39 | Přečteno: 3891× | plky | poslední úprava: 20.8.2018 10:52

Celkem to vypadá jako špatná věc.

Split DNS

Stejné dns jméno pro komunikaci na interní síti i na veřejné. Tj. v interní síti se přes "sluzba.corp.domena.cz" dostaneme na web serveru 192.168.1.1
Z veřejné sítě se dostaneme přes "sluzba.corp.domena.cz" na veřejnou IP (třeba i s port forwardem) na ten stejný server / stejnou službu.

Letsencrypt

Pokud nemáme k dispozici dns API (nebo neumíme emulovat editování txt přes web interface), tak jediné rozumné ověření v současné době je přes "http-01", tj. server, kde generujeme žádost, musí být přístupný z venku. Resp. musí být přístupný ověřovací klíč/acme žádost v kombinaci s dns jménem. V tomto případě pak vypadá Split DNS jako nezbytnost.

Informační naťuknutí

Pokud je nějaký web dostupný jen z interní sítě, tak by i nebylo špatné informovat uživatele o tom, že se na něj dostanou jen z VPN. Tzn., pokud zadají url z veřejné sítě a nejsou na vpn, dostanou hlášku, ať se na vpn připojí.

Problém : dns cache

Zkusil jsem nasadit Split DNS právě kvůli LetsEncrypt, ale i kvůli informační hlášce a kvůli tomu, že nějaké aplikace jsou dostupné jak z interní sítě, tak z veřejné a nechci dělat uživatelům zmatek s různými dns jmény. Velký problém je ale dns cache. Uživatel není na vpn, otevře web, zjistí z hlášky, že musí na vpn, tak se přihlásí, ale stále se mu adresa překládá s veřejnou IP, prostě se tahá z cache.

Windows mají by default službu, která si dělá dns cache. Dále Chrome je v tomto ještě horší, protože má v sobě vlastní mechanismus a drží si vlastní dns cache. Nicméně ta by měla být maximálně 1min (chrome://net-internals/#dns ), nicméně má další fce, které zřejmě občas ignorují nastavené dns v systému. Jednou z těch fcí je u mobilní app "Async DNS resolver" (chrome://flags), v desktop verzi se to jmenuje "preconnect predictor". Další fce v mobilní app je "spořič dat". Dokud neexistuje pro jméno veřejné dns, tak se o těchto fcí člověk nedozví, ale jakmile se dns záznam vytvoří, tak se postupně začnou všechny možné super cool featurky ozývat.

V kombinaci s BYOD je řešení nějaké cache docela blbě řešitelné. Zkusil jsem to nahodit jako FAQ v error hlášce, ozvalo se asi 10 lidí z 300 a postupně se vše vyřešilo a FAQ upravilo. Nicméně toto nevypadá jako ideální cesta. Možná to půjde, možná ne.
Proto přemýšlím, zda touto cestou jít, nebo se na to vykašlat, požádat si o 2r. wildcard cert od nějaké CA, držet ho na jednom místě na jednom proxy serveru a finýto. A zbytek věcí neřešit.

Závěr

Jak jste na tom vy? Používáte někdo Split DNS? Případně pokud ano, jak řešíte dns cache a problémy s tím spojené? Nebo všechno máte přístupné i z venku a tak je vám jedno, jak se dns přeloží?

Zdar Max        

Komentáře

[Michal Kubeček]

Moc nerozumím, v čem má být problém. Od určení, jak dlouho smí být DNS záznam z cache používán, je především jeho TTL. Takže máte problémy s tím, že špatně napsaní klienti TTL ignorují, nebo jste si ji nastavil na příliš vysokou hodnotu?

[Max]

Ono i 15min TTL je jaksi moc. Pokud se uživateli přeloží public, pak se připojí na vpn, tak 15min na to, aby to fungovalo, je moc. A menší hodnoty nejsou moc podporovány.
Konkrétně jedeme web aplikace, takže stránka v prohlížeči.
Zdar Max

[Michal Kubeček]

TTL může být klidně i nulová a přinejmenším linuxový resolver to respektuje (nebo spíš respektoval, když jsem to naposledy zkouše). Ale zrovna webové prohlížeče dělají podivné věci a třeba Firefox už dlouho podezírám, že má nějakou svou vlastní cache (a od doby, co implementovali "capture portal detection", dělá ještě mnohem šílenější věci).

[Max]

A to je právě to, na co narážím. Chrome má vlastní dns cache, má async dns resolve, což údajně občas i ignoruje systémové nastavení DNS. Teď se do prohlížečů dostává dns over https atd. Celý koncept web prohlížečů jde proti Split DNS.
Ohledně podpory nízkých TTL, narážel jsem na poskytovatele dns serverů.
Zdar Max

[elenril]

Není lepší řešit tyto věci forwardem na úrovni routeru/firewallu?

[Max]

Pokud myslíš to, že by byl vytvořen jeden DNS záznam a všichni by šli na veřejnou IP s tím, že firewall by měl nastavený loopback pro lidi v interní síti, tak to tento problém neřeší.
Resp. takhle, lidi s VPN nemají směrovaný veškerý provoz do interní sítě, ale do interní sítě jde jen provoz, který tam patří. Tím se i šetří latence klientů (když přistupují někam jinam) + se ulevuje trafik v centrále (vpn klientů je kolem 400, iOS, Win10, Android).
Musel by se veškerý provoz těchto zařízení tahat do vpn + na firewallu nastavit loopback pravidla. To mi aktuálně také nepřijde úplně ok.
Zdar Max

[Martin Mareš]

Mělo by stačit přes VPN naroutovat veřejné adresy vašich serverů.

[Max]

To je pravda. Promyslím to.
Zdar Max

[Lyco]

U nás se split DNS používá jen pro pár věcí, a stejně je to opakovaně zdroj problémů. Celý svět prostě předpokládá, že DNS je jenom jedno, a kdykoli se tenhle předpoklad poruší tak je zle.

Kdybych měl na výběr, tak bych taky věci řešil síťově, a DNS nesplitoval.

[Max]

My máme několik MPLS sítí + externí fw + spoustu IPSEC tunelů. Moc se mi v takovém prostředí nechce řešit routing public IP v rámci všeho toho + s podporou řešit loopback na fw.
To to radši opustím úplně a public dns nechám zrušit.
Na win stanicích je pak třeba distribuovat nastavení, aby se nedělala negative cache (win standardně dělají i cache toho, když se jméno nepřeloží).
S tím se pak dá žít.
Zdar Max

[aaa]

V praci pouzivame velku reverznu proxy, cez ktoru ide pristup k internym serverom a jej IP je vystavena v DNS zaznamoch. Tie su verejne. Ked niekto pristupuje z firmy z 802.1x autorizovaneho ethernet portu, tak sa nemusi dalej overovat. Inak sa k proxy overuje klientskym certifikatom alebo menom a heslom a podla kombinacie overenia dostane pristup.

Proxy vynucuje https a ma wildcard certifikat pre vsetky interne domeny. Celkovo je to jednoduche, umoznuje to kontrolovany a bezpecny pristup aj bez VPN.

Verejny popis: https://ai.google/research/pubs/pub43231

[Max]

Ne, všichni jedou VPN, není to jen o webu, ale přistupuje se ke spoustě jiných služeb, ani mailové služby nejsou vystavený ven.
Mít loopback na firewallu pro public IP vypadá dobře, ale naše síť je značně komplikované a toto také není zrovna dobrý nápad. Test proběhl, přišel jsem na spoustu věcí, které nejde jednoduše vyřešit a nejspíše tedy veřejná dns zruším a celé top pojede jako doposud přes wildcard cert od nějaké CA.
Jinak já mám rozjetý dva proxy clustery, jeden pro public přístup, druhý pro interní.
Zdar Max

[Bedňa]

Používáte někdo Split DNS?

Nie.

Čo tak firemná Android/iOS appka aby to bolo userfriendly aj spolahlivé. Na desktope NWjs aplikácia.

[Max]

Nejde jen o jednu službu, jde o desítky dalších. Na jedné jen testuji nastavení.
Zdar Max

[V.]

Neni tohle lepší řešit veřejnou / privátní DNS doménou?
Z venku je to firma.cz, zevnitř je to třeba mojefirma.cz. A zároveň mám oboje registrované na sebe.

[Max]

To pak ale není z pohledu uživatelů moc transparentní a nejen kvůli tomu. Jak už jsem psal, v takovém případě je problém třeba i s Let'sEncrypt. Každopádně řešení jsou dvě. Buď přistupovat na veřejnou IP i v rámci interní sítě, nebo to řešit v rámci jiných dns jmen. Split DNS je nepřekonatelný problém. Nakonec půjdu do jiných dns jmen. Tj. z vnitřní sítě půjdu na "*.corp.firma.cz" a z venku asi na "*.corp.firma.eu", případně "*.pub.corp.firma.eu".
A na to pak všechny služby postupně zmigruju.
Zdar Max

[Käyttäjä 11133]

Tak na zabezpečení interních aplikací snad jedině vlastní enterprise PKI, ne? Na co Let's encrypt?

[Max]

Já používám svoje CA, to je jasný. Ale také se vyskytují někteří s BYOD a VPN a tam jsem chtěl minimalizovat problémy s distribucí CA. Resp. aktuálně žádné problémy s distribucí nemám, ale chtěl jsem tím některým BYOD uživatelům ušetřit jeden krok.
Na druhou stranu, instalace CA do Androidích zařízení nutí uživatele k nastavení si zámku zařízení (pin, gesto atd.) a spousta lidí ho nastavený nemá a nechce. Když pak mají i přístup do vpn k nám k některým službám, tak je toto celkem dobrý donucovací prostředek k nějakému minimálnímu zabezpečení :).
Zdar Max

[Dramon]

Jo, normálně to používám.

Historicky to byl trochu opruz zmínit každému uživateli, že pokud chce jít na server, musí si nejdříve pustit VPNku, ale kupodivu to nezpůsobovalo ani moc problémů. Respektive si nyní nevybavuji jediný. Jen jsem to holt všem novým uživatelům prostě důrazně zmínil.

Jelikož používám víceméně výhradně OpenVPN, tak mně to již nepálí, neboť od nějaké doby mají pro Windows klienta parametr, aby vyprázdil cache při připojení. Na Linuxu to dělá NetworkManager automaticky a z mobilů se zatím nikdo nepřipojuje, takže nevím jak to tam funguje.

Ovšem výše uvedený nápad s routováním veřejných adres zní zajímavě. Také nad tím popřemýšlím :)

[Max]

Problém je ale web prohlížeči, které mají vlastní cachovací politiky a některé fce mohou ignorovat systémové nastavení dns. Další problém může nastat s AV, kdy třeba Avast má Secure DNS. Těch problémů s dns je tolik, že to jde vyřešit jen tím, že se split nebude používat. My těch app máme dost, takže fakt velká různorodost, pokud používáš nějaký desktop app, tak asi ok.
Každopádně já to zrušil a peču na to, usoudil jsem, že v dnešní době to prostě není dobrý návrh :-/. V menší síti s vlastními prvky bych to řešil routingem veřejných IP, ale naše síť je trochu komplikovanější, takže do tohoto nejdu.
Zdar Max

[Dan Ohnesorg]

Overovat LE certifikaty pres DNS neni zdaleka takovy problem jak to vypada a pak muzete mit klidne certifikaty pro servery na privatnich IP adresach a ve verejnem DNS jen CNAME pro overeni. https://www.root.cz/clanky/certifikaty-let-s-encrypt-validovane-pres-proxy-dns/

[Luboš Doležel (Doli)]

Já to používám.

Jeden problém je v tom, že Chrome na Androidu občas ignoruje nastavené DNS servery, dotazuje se těch googlích, takže použije vnější (IPv6) adresu namísto lokální (fd00::...).

[Josef Kufner]

Používám to už dlouho doma. Mam v bindu nastavené jedno view z LAN a druhé z Internetu, takže když vypadne připojení, tak místní služby stále fungují. (To vnější view se už nepoužívá, neboť teď používám cizí DNS servery, ale jeden čas se používalo.)

Žádné problémy jsem zatím nepozoroval. Když se počítač připojí na jinou síť (např. z WiFi na LTE) a jde k domácímu serveru z druhé strany, tak zahodí DNS cache a vše funguje ihned správně. (Teď jsem si to na telefonu ověřil.)