Fórum Root.cz
Hlavní témata => Server => Téma založeno: RDa 30. 06. 2025, 13:23:08
-
Ahoj - mám dotaz - co za SW nasadit pro interní DNS systém, který bude resolvovat privátní adresy v lokální síti, nebo pro připojené klienty skrze VPN.
Buď jako overlay (prioritu mají pak lokální záznamy), nebo jako dedikovaný pro konkrétní subdomény.
A co není obslouženo/definováno.. tak se doptá zvenku. Plus bych čekal cachování dle TTL a nějaké to logování / statistiky.
-
Co si vyberete v ramci veskerych pozadavku, co mate.
Lokalni unbound, dnsmasq, systemd-resolved, atd.
Z centralnich ja pouzivam dlouhodobe powerdns recursor ve firemnim prostredi.
-
Co si vyberete v ramci veskerych pozadavku, co mate.
Lokalni unbound, dnsmasq, systemd-resolved, atd.
Zatim jsem mel vybran unbound, protoze knot neni rekurzivni.
Ale chci slyset treba co si zdejsi useri a admini mysli nebo provozuji - co je dnes in.
dnsmasq spis ne (v popisku baliku je to kobinace s dhcp a buhvi cim.. a to mam jiz poreseno ke spokojenosti - tj vcetne netbootu na cokoliv od legacy po uefi)
systemd-* nevedu a nebudu.
Nejake extra pozadavky dale nemam.. konfiguraci si vygeneruji, a preferuji vec napsanou v C, at se to da normalne vybuildit ze zdrojaku (gentoo).
Dival jsem se na wikipedii:
https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
tak jsem koukal treba po tom "Technitium DNS Server" (jakoze ma nejvice zelenych/yes), ale to je C# a .net .. tak to ne, dik.
Z featur je pak pro me snad zajimava jen ta split-horizon, takze by slo ridit preklad adres podle toho kdo se pta (LAN vs VPN, vs Guest vs Externi).
Z centralnich ja pouzivam dlouhodobe powerdns recursor ve firemnim prostredi.
Ten powerdns vypada taky zajimave - bych si mohl usetrit generovani configu z DB, kdyz to tam jde napojit rovnou.
-
Zatim jsem mel vybran unbound, protoze knot neni rekurzivni.
Rekurzivní resolver od CZ.NICu se jmenuje Knot Resolver (https://www.knot-resolver.cz).
-
Zatim jsem mel vybran unbound, protoze knot neni rekurzivni.
Rekurzivní resolver od CZ.NICu se jmenuje Knot Resolver (https://www.knot-resolver.cz).
A lze to nakonfigurovat v paru na ucel ktery potrebuji? (tj idealne overlay - anebo se jedna jen o ciste reseni a deleni bude vzdy podle poddomen?)
-
Zatim jsem mel vybran unbound, protoze knot neni rekurzivni.
Rekurzivní resolver od CZ.NICu se jmenuje Knot Resolver (https://www.knot-resolver.cz).
A lze to nakonfigurovat v paru na ucel ktery potrebuji? (tj idealne overlay - anebo se jedna jen o ciste reseni a deleni bude vzdy podle poddomen?)
Ano, lze. Knot Resolver má docela dost možností manipulace s dotazy a odpověďmi, případně lze napsat vlastní modul.
Každopádně přepisování DNS přináší různé problémy. Nemůžete validovat DNSSEC, budete mít problémy s keší odpovědí, když uživatel přechází mezi interní sítí a venkovním světem…
-
Každopádně přepisování DNS přináší různé problémy. Nemůžete validovat DNSSEC, budete mít problémy s keší odpovědí, když uživatel přechází mezi interní sítí a venkovním světem…
Ta cache bude ale stejny problem pokud bych vyuzival "split-horizon", ne? (je jedno zda se prepisuje cela poddomena nebo jen konkretni zaznamy - pokud koncove zarizeni bude cachovat vysledky resolveru ktery nasadim).
Jinak je to celkem orisek no.. LAN je ok, kdo je doma, ten je soucasti korporatu a dane politiky.
Kdo prijde ale z VPN, tak neni uplne moralni mu ukrast DNS, jen kvuli vlozeni nasich "tajnych" zaznamu, protoze pokud by se pripojil na dvoje VPN (rekneme jako power user), tak mu timto stylem nepojede jedna z veci kam se pripojuje.
Takze reseni spis bude - verejne delegovat poddomenu tak ze jeho autoritativni server bude ve VPN rozsahu.. kdo je pripojenej ten bude videt na ta tajemstvi, kdo neni, ten nic krome existence delegace neuvidi, protoze na vpn adresy se nedostane?
(tj. pro VPN postaci nasadit "knot", a pro LAN "knot-resolver" v roli cache?)
-
Ta cache bude ale stejny problem pokud bych vyuzival "split-horizon", ne?
Ano. Jakékoli řešení, kde poskytujete různé DNS záznamy, které nejsou navzájem zaměnitelné, je problém.
Jinak je to celkem orisek no.. LAN je ok, kdo je doma, ten je soucasti korporatu a dane politiky.
Kdo prijde ale z VPN, tak neni uplne moralni mu ukrast DNS, jen kvuli vlozeni nasich "tajnych" zaznamu, protoze pokud by se pripojil na dvoje VPN (rekneme jako power user), tak mu timto stylem nepojede jedna z veci kam se pripojuje.
Nebo se vykašlat na tajné záznamy. Za prvé nemusíte zpřístupňovat přenos celé zóny, nemusíte názvy nikde zveřejňovat – takže pak název přeloží jenom ten, kdo bude název znát. A i kdyby se někdo k názvu nějak dostal a přeloží ho – no a co? Snad nemáte síť zabezpečenou tím, že nikdo neuhádne nějakou IP adresu.
-
Jinak je to celkem orisek no.. LAN je ok, kdo je doma, ten je soucasti korporatu a dane politiky.
Kdo prijde ale z VPN, tak neni uplne moralni mu ukrast DNS, jen kvuli vlozeni nasich "tajnych" zaznamu, protoze pokud by se pripojil na dvoje VPN (rekneme jako power user), tak mu timto stylem nepojede jedna z veci kam se pripojuje.
Nebo se vykašlat na tajné záznamy. Za prvé nemusíte zpřístupňovat přenos celé zóny, nemusíte názvy nikde zveřejňovat – takže pak název přeloží jenom ten, kdo bude název znát. A i kdyby se někdo k názvu nějak dostal a přeloží ho – no a co? Snad nemáte síť zabezpečenou tím, že nikdo neuhádne nějakou IP adresu.
Opravdu nechci zverejnovat interni strukturu, topologii, technologie, sluzby, projekty - do verejne site.
Z pohledu bezpecnosti je porad to "uneseni DNS" (vnuceni vlastniho DNS, kdyz je nekdo pripojen zvenku) to nejlepsi reseni, tj. tak jak jsem to puvodne zamyslel.
A zvenku, pro verejnost - se existence ani neprizna.
-
Jinak je to celkem orisek no.. LAN je ok, kdo je doma, ten je soucasti korporatu a dane politiky.
Kdo prijde ale z VPN, tak neni uplne moralni mu ukrast DNS, jen kvuli vlozeni nasich "tajnych" zaznamu, protoze pokud by se pripojil na dvoje VPN (rekneme jako power user), tak mu timto stylem nepojede jedna z veci kam se pripojuje.
Nebo se vykašlat na tajné záznamy. Za prvé nemusíte zpřístupňovat přenos celé zóny, nemusíte názvy nikde zveřejňovat – takže pak název přeloží jenom ten, kdo bude název znát. A i kdyby se někdo k názvu nějak dostal a přeloží ho – no a co? Snad nemáte síť zabezpečenou tím, že nikdo neuhádne nějakou IP adresu.
Opravdu nechci zverejnovat interni strukturu, topologii, technologie, sluzby, projekty - do verejne site.
Z pohledu bezpecnosti je porad to "uneseni DNS" (vnuceni vlastniho DNS, kdyz je nekdo pripojen zvenku) to nejlepsi reseni, tj. tak jak jsem to puvodne zamyslel.
A zvenku, pro verejnost - se existence ani neprizna.
navrh k zamysleni - nsec3 a nic neunaset. je to mrzeni. doporucuju knihu pavla satrapy DNS - dokonce se i zasmejes ;)
-
navrh k zamysleni - nsec3 a nic neunaset. je to mrzeni. doporucuju knihu pavla satrapy DNS - dokonce se i zasmejes ;)
Obavam se, ze to resi jen tu cast, ze "to neni videt na prvni dobrou". Split-horizon DNS ma pomerne dost uziti (napr. stejny record, ktery vede na backend s NTLM vevnitr vede venku na nejakou F5-ku, ktera si tam vynuti 2FA je dost bezne pouzivane vec), takze radit OPovi aby predelal celou sit jenom aby byl resolver jednodussi neni zrovna ideal.
-
navrh k zamysleni - nsec3 a nic neunaset. je to mrzeni. doporucuju knihu pavla satrapy DNS - dokonce se i zasmejes ;)
Obavam se, ze to resi jen tu cast, ze "to neni videt na prvni dobrou". Split-horizon DNS ma pomerne dost uziti (napr. stejny record, ktery vede na backend s NTLM vevnitr vede venku na nejakou F5-ku, ktera si tam vynuti 2FA je dost bezne pouzivane vec), takze radit OPovi aby predelal celou sit jenom aby byl resolver jednodussi neni zrovna ideal.
Ono nejde o to, aby byl resolver jednodušší. Ve skutečnosti je kešující DNS resolver jedna z mála věcí, která si s tím poradí bez problémů.
Podstatné je to, že se postupně upouští od představy „privátní sítě, která je připojená přes jeden router do internetu“ vrací se to k původní myšlence internetu, kde je nějaká síť součástí internetu. Takže představy jako že je nějaké zařízení připojené buď v mé privátní síti nebo je mimo ni přestávají fungovat. Dnes je naprosto běžné, že je zařízení připojené do několika sítí současně. A v čase se to průběžně mění. To, že zajdu v baráku do místa, kde je horší pokrytí WiFi a mobil se přepne na mobilní síť, nebo vyjdu před barák, není důvod, aby mi nějaká aplikace přestala fungovat. (Občas má někdo pocit, že k tomu důvody jsou. A pak se hrozně diví, proč jeho uživatelé radši začnou používat Google Docs, Microsoft365 a jiné cloudové služby. Protože ty prostě fungují všude.)
-
Roaming at si poresi VPN vrstva, pokud nekdo bude pendlovat mezi wifi a mobilni siti, to me nezajima a povazuji to za vyresene.
Resim to, ze kdyz se nekdo pripoji pres VPN do chranene lokace, tak by mu mel byt zpristupnen dalsi jmenny prostor skrze DNS.
A pokud uvazuji univerzalne, tak takovych lokaci muze byt soucasne aktivni vice nez 1 zaroven - kazda s vlastnim a nekolidujicim jmennym prostorem.
Muzeme rovnou vyloucit, ze by se resolving mel konat skrze verejny/ISP/google DNS system.
Idealni pripad by byl, kdyby klientska stanice neleakovala informace ani jednim smerem (tj. dotazy na nase jmena nesli ven, ale taky nechci videt, ci zpracovavat jine dotazy a narusovat soukromi klientu, ani co se dns tyce, ani co se dat tyce).
Takze prozatim to nejlepsi reseni vypada, ze ve verejne siti budou definice delegaci subdomen podle lokaci - a OS/resolver na strane klienta tedy bude posilat verejne dotazy mimo vpn, tam kde to user mel nastaveny (isp/google), ale jakmile to chytne neco pod jmenem nasich lokaci, tak bude rekurze resolvingu probihat uz skrze konkretni VPN adresni prostor?
Pochybuji ze bych nasel vpn klienta, ktery multiplatformne dokaze poeditovat prioritu resolvingu (to by ten resolver musel byt na klientske strane od nas a dodat ho tam je snad nemoznejsi nez poresit samotnou vpn).
-
Roaming at si poresi VPN vrstva, pokud nekdo bude pendlovat mezi wifi a mobilni siti, to me nezajima a povazuji to za vyresene.
Sice to vyřešené není a spousta věcí je rozbitá, ale OK.
Resim to, ze kdyz se nekdo pripoji pres VPN do chranene lokace, tak by mu mel byt zpristupnen dalsi jmenny prostor skrze DNS.
Což se ovšem nijak nevylučuje s tím, aby ten jmenný prostor byl dostupný odkudkoli.
Muzeme rovnou vyloucit, ze by se resolving mel konat skrze verejny/ISP/google DNS system.
To vyloučit nemůžete. Co když má uživatel ve svém systému některý z veřejných DNS serverů nastavený napevno a nedovolí jejich obcházení? Nebo to nemusí mít v systému, ale třeba jen v prohlížeči.
Idealni pripad by byl, kdyby klientska stanice neleakovala informace ani jednim smerem (tj. dotazy na nase jmena nesli ven, ale taky nechci videt, ci zpracovavat jine dotazy a narusovat soukromi klientu, ani co se dns tyce, ani co se dat tyce).
To ale nedokážete zajistit, pokud nemáte nad tím zařízením plnou kontrolu. Nastane úplně jednoduchá situace – klient se z vaší sítě odpojí, tím se zruší přesměrování na vaše DNS. Ale jména zůstanou někde nakešovaná – třeba otevřená stránka v prohlížeči. Pak bude chtít prohlížeč stránku znovu nahrát, nebo jen zavolá načtení aktuálních dat ze stránky – a prohlížeč se pokusí adresu znovu přeložit, tentokrát už mimo vaši síť a s úplně jiným DNS resolverem.
Pochybuji ze bych nasel vpn klienta, ktery multiplatformne dokaze poeditovat prioritu resolvingu (to by ten resolver musel byt na klientske strane od nas a dodat ho tam je snad nemoznejsi nez poresit samotnou vpn).
Přesně tak. Musel byste to zařízení mít plně pod kontrolou.
Samozřejmě se můžete vydat touto cestou. Ale pokoušíte se vyřešit nemožné a zaděláváte si na spoustu problémů. Když se smíříte s tím, že vaše síť je součástí internetu, budete to mít mnohem jednodušší.
-
Idealni pripad by byl, kdyby klientska stanice neleakovala informace ani jednim smerem (tj. dotazy na nase jmena nesli ven, ale taky nechci videt, ci zpracovavat jine dotazy a narusovat soukromi klientu, ani co se dns tyce, ani co se dat tyce).
Nesmysl. DNS leakuje vsemi moznymi aplikacemi, a to i proto, ze po odpojeni/padu VPN jsou ty aplikace casto stale aktivni a pak se dotazuji verejnych rekurzoru.
Nemluve o tom, ze v dobe MFA, ZTNA apod. principu se na split-horizon muzete slusne vybodnout. Slozitost konfigurace firewallu a siti tim jen narusta. A jeste v dobe ipv6.
Pokud chcete "omezit" dotazy pres "security by obscurity" na "lan/vpn domeny", tak si pred sve verejne dns dejte balancer s acl (napr. dnsdist). Ale google/microsoft/etc uz o vasich domenach davno vi.
-
Mam ten dojem nebo se od zacatku ptas uplne zcesty?
1) mas DNS server = ten je nekde vevnitr site a resolvuje interni jmena. Je uplne jedno co to bude, to muze byt widli dns, bind, knot, ... proste cokoli. Jen to musi znat ty interni nazvy.
2) ten stejny DNS typicky resolvuje i venkovni jmena, protoze ty interni stroje se chteji dostat do netu.
Kupodivu kazdy jeden dns server presne takhle funguje od prirody = jmena ktera nativne zna jako svoje, ti prelozi lokalne, bez ohledu na to, jestli stejny jmena existujou nekde venku.
Mnohem vetsi sranda je klientska strana. Typicky nejjednodussi reseni je forwardnou na ty interni DNS veskery provoz. Pokud to tak nechces, potrebujes (per konkretni system/vpn) nejak poresit prirazeni jmena ty vpnce.
Chovani cache zalezi na tuposti. Pokud se bavime o tom, ze mas corp.com a ma to jiny IPcka zvenku a jiny zevnitr. Ty ale primarne mluvis o nazvech, ktery zvenku neexistujou = zadnej problem s cache.
Jelikoz sem to celkem nedavno resil na widlich, tak jen pripodoktnu, ze na nich musis vypnout "chytristiky" ... ktery to rozbijou zcela spolehlive.
Turn off smart multi-homed name resolution Enabled
Turn off smart protocol reordering Enabled
A pak to co chces udelas takhle.
Set-VpnConnection -Name "mojeVPN" -DnsSuffix "corp.com"
Ale pozor, jak je u MS tradici, chova se to s kazdou verzi widli jinak.
-
Dovolil bych si upozornit na pdnsd: http://members.home.nl/p.a.rombouts/pdnsd/ (http://members.home.nl/p.a.rombouts/pdnsd/). Používáme už léta v našich systémech u zákazníků k naprosté spokojenosti.
-
tl;dr
bind a v něm views - https://kb.isc.org/docs/aa-00851 (https://kb.isc.org/docs/aa-00851)?
Používáme pro resolving ve vnitřní síti/VPN a pro freewifi (guest síť) - z IP rozsahu freewifi nelze překládat záznamy hostované lokální domény (ta je dostupná jen z LAN a VPN), současně je společná cache pro všechny ( https://kb.isc.org/docs/aa-00835 (https://kb.isc.org/docs/aa-00835) ). Nebo se tazatel ptá na něco jiného, možná jsem to špatně pochopil. ;-)
-
Ptal jsem se na to, jen to pak sklouzlo k obecnejsimu obrazu a politice nasazeni / konfigurace jmen / uziti.
-
Mam ten dojem nebo se od zacatku ptas uplne zcesty?
1) mas DNS server = ten je nekde vevnitr site a resolvuje interni jmena. Je uplne jedno co to bude, to muze byt widli dns, bind, knot, ... proste cokoli. Jen to musi znat ty interni nazvy.
2) ten stejny DNS typicky resolvuje i venkovni jmena, protoze ty interni stroje se chteji dostat do netu.
Kupodivu kazdy jeden dns server presne takhle funguje od prirody = jmena ktera nativne zna jako svoje, ti prelozi lokalne, bez ohledu na to, jestli stejny jmena existujou nekde venku.
Mnohem vetsi sranda je klientska strana. Typicky nejjednodussi reseni je forwardnou na ty interni DNS veskery provoz. Pokud to tak nechces, potrebujes (per konkretni system/vpn) nejak poresit prirazeni jmena ty vpnce.
Chovani cache zalezi na tuposti. Pokud se bavime o tom, ze mas corp.com a ma to jiny IPcka zvenku a jiny zevnitr. Ty ale primarne mluvis o nazvech, ktery zvenku neexistujou = zadnej problem s cache.
Jelikoz sem to celkem nedavno resil na widlich, tak jen pripodoktnu, ze na nich musis vypnout "chytristiky" ... ktery to rozbijou zcela spolehlive.
Turn off smart multi-homed name resolution Enabled
Turn off smart protocol reordering Enabled
A pak to co chces udelas takhle.
Set-VpnConnection -Name "mojeVPN" -DnsSuffix "corp.com"
Ale pozor, jak je u MS tradici, chova se to s kazdou verzi widli jinak.
Provozovat v jedné instanci autoritativní server a zároveň i rekurzivní DNS resolver je velmi problematické a typicky to vede k chybám. Snažil bych se tomu vyhnout a použít to jedině v případě, kdy opravdu není zbytí (a nenapadá mne, kdy by reálně taková situace mohla nastat).
Problém je, že takový server obvykle odpovídá jako autoritativní na dotazy na zóny, o kterých si myslí, že jsou jeho – a ony přitom jeho dávno být nemusí. Typicky pak zmigrujete zónu někam jinam, ale na původním serveru ji necháte. Nejdřív kvůli souběžnému provozu, pak kvůli možnosti rychlého rollbacku. Vždyť to přece nevadí, nikdo se toho serveru na tu zónu nebude dotazovat, a že tam leží zóna navíc server nepoloží. Pak to nějakou dobu funguje, protože byl jenom přestěhován autoritativní server, ale DNS záznamy se nijak neměnily, takže i starý server odpovídá správně.
Pak se po několika měsících nějaký DNS záznam změní – a začnou se dít věci. V jedné konkrétní síti (třeba u nějakého ISP) se změna neprojeví, ani po vypršení platnosti záznamů ve všech keších. Až po složitém pátrání se ukáže, že si prostě nějaký resolver v dané síti pořád myslí, že je pro danou zónu autoritativní a odpovídá sám starými záznamy.
-
Ano, ty separatni budou urcite lepsim resenim (hlavne kvuli servisovatelnosti).
Zatim tedy jako sw stack to vidim na knot + knot-resolver (a taky fajn ze to je cesky, ze)
-
Provozovat v jedné instanci autoritativní server a zároveň i rekurzivní DNS resolver je velmi problematické a typicky to vede k chybám. Snažil bych se tomu vyhnout a použít to jedině v případě, kdy opravdu není zbytí (a nenapadá mne, kdy by reálně taková situace mohla nastat).
Zase meles jirsaku o vecech o kterych nemas ani paru? To je zajimavy vid, ze to tvoji soudruzi z MS presne takhle delaji uplne vsude. A fakt by me zajimalo, jaka vysvetlujes klientovi, kteryho dns se ma zrovna zeptat ... pripadne jeste lip, jak tomu dns serveru vysvetlujes, porad dokola, ze na vyjmenovay seznam se nema ptat verejnych tld, ale ma je hledat jinde, to je totiz jeste mnohem lepsi ... lol.
Autoritativni dns s rekurzorem je zcela standardni, a pro neblby zcela funkcni konfigurace.
-
Provozovat v jedné instanci autoritativní server a zároveň i rekurzivní DNS resolver je velmi problematické a typicky to vede k chybám. Snažil bych se tomu vyhnout a použít to jedině v případě, kdy opravdu není zbytí (a nenapadá mne, kdy by reálně taková situace mohla nastat).
Zase meles jirsaku o vecech o kterych nemas ani paru? To je zajimavy vid, ze to tvoji soudruzi z MS presne takhle delaji uplne vsude. A fakt by me zajimalo, jaka vysvetlujes klientovi, kteryho dns se ma zrovna zeptat ... pripadne jeste lip, jak tomu dns serveru vysvetlujes, porad dokola, ze na vyjmenovay seznam se nema ptat verejnych tld, ale ma je hledat jinde, to je totiz jeste mnohem lepsi ... lol.
Autoritativni dns s rekurzorem je zcela standardni, a pro neblby zcela funkcni konfigurace.
že tomu nerozumíte nemusíte dávat najevo nadávkami. Ono se to pozná i bez nich.
Klient se vždycky ptá rekurzivního resolveru, který má nakonfigurovaný. Klientovi tedy nemusíte vysvětlovat vůbec nic. Rekurzivní resolver se může na všechny domény doptávat standardně od kořenové domény, nebo může používat nadřazený rekurzivní resolver. Takto se nakonec může dostat k autoritativnímu serveru, který klidně může běžet na stejném zařízení, jako ten rekurzivní resolver, akorát na jiné IP adrese. A i když chcete pro některé domény používat jako autoritativní server nějaký, který není uveden v globálním stromu (třeba používáte lokální doménu nebo split horizon), pořád to znamená jenom to, že na tom jednom resolveru nakonfigurujete, pro které domény se má dotazovat jinde. Takže fakt není potřeba, aby ten rekurzivní server byl zároveň primárem pro jakoukoli doménu.
-
Tady má Filip Jirsak pravdu, mám to úplně stejně. Neběží to na stejném serveru, ale to je jen implementacni detail.
-
Pokud clovek vi, co dela a rozumi tomu, osobne nevidim zadny problem mit autoritativni i rekurzivni dns v jednom, a tim nemyslim instance na ruznych ip. Provozujeme to tak mnoho let, funguje to dle predstav a ocekavani. :)
-
Já jsem si zvykl na Knot DNS jako autoritativni a Knot Resolver, co ma pro vyjmenované domény ten DNS natvrdo.