DNS server pro intranet

DNS server pro intranet
« kdy: 08. 03. 2020, 05:24:12 »
Prosim o "nakopnuti" spravnym smerem pri volbe implementace lokalniho DNS serveru.

Co by mel umet:
 - "doplnek" k verejnym autoritativnim DNS pro vlastni domenu
 - resolving vsech ostatnich domen
 - podpora DNSSEC
 - podpora IPv6
 - idealne podpora dynamic DNS z LDAPu, ale neni nutne, mohu vytvorit nejaky script pro aktualizaci

K cemu by mel slouzit: pro zarizeni na LAN / WLAN / VPN by mel poskytovat cache + pro vlastni domenu poskytovat intranetove adresy, napr. pro lokalni sluzby (staticke zaznamy) a idealne i dynamicke z LDAPu (frantuv-notebook.moje-domena.cz), vcetne PTR.

Dosud jsem pouzival bind9, ale zvazuji Knot. Lze uvedene dosahnout napr. pomoci Knot DNS poslouchajiciho na localhostu + Knot Resolver poslouchajiciho na eth, ktery by pro vlastni domenu dotazoval lokalni Knot DNS a zbytek predaval napr. na DNS server providera? Nebo napr. Knot DNS + tinydns proxy modul? Nemam prilis zkusenosti s DNSSEC - je toto realizovatelne, nebo musi byt i intranet zaznamy v hlavni sade nameserveru?

Predem diky za jakekoli relevantni informace.
« Poslední změna: 08. 03. 2020, 09:02:52 od Petr Krčmář »


Re:DNS server pro intranet
« Odpověď #1 kdy: 08. 03. 2020, 09:29:43 »
Myslím, že toho kombinací Knot DNS a Knot Resolveru jde dosáhnout.

S DNSSEC máte dvě možnosti – buď mít jednu zónu (veřejnou) a v ní všechny záznamy. Nebo to rozdělíte, budete mít jinou veřejnou a interní zónu, pak musíte podepisovat každou zvlášť. Osobně jsem v tomhle případě obě zóny podepisoval stejným klíčem – pak ale musíte vypnout automatickou rotaci klíčů a zařídit si to sám. Asi by byla i možnost mít dva různé klíče, pro každou zónu jeden, a oba dva mít v nadřazené zóně (podobě, jako když jste v procesu výměny klíčů). Ale to jsem neověřoval, zda nebude někde problém, třeba s kešováním (neměl by být, ale implementace jsou různé).

Re:DNS server pro intranet
« Odpověď #2 kdy: 09. 03. 2020, 10:00:45 »
Powerdns + powerdns-recursor ty pozadavky urcite splni.

Re:DNS server pro intranet
« Odpověď #3 kdy: 09. 03. 2020, 16:32:16 »
buď mít jednu zónu (veřejnou) a v ní všechny záznamy
To bych videl az jako jednu z poslednich moznosti - slo by o nekolik desitek zaznamu z nekolika privatnich subnetu a velmi nerad bych poskytoval pripadnym utocnikum takove informace "zcela zdarma".

budete mít jinou veřejnou a interní zónu, pak musíte podepisovat každou zvlášť

Chapu-li to spravne, pak je treba, aby nadrazena zona obsahovala informaci o klicich. Tedy v mem pripade by slo napr. o zony mojedomena.cz (NS registratora) a zonu napr. kancl.mojedomena.cz (interni NS). Je pro zasjisteni validniho podepisovani kancl.mojedomena.cz dostatecne nastaveni podepisovani (vygenerovani klicu, zonefile, podepsani) a umistetni nejakych TXT zaznamu do NS mojedomena.cz (mohu zautomatizovat pres API registratora) nebo je nutna nejaka specialni podpora na jeho strane? Konkretne jde o joker.com, kde jedine moznosti k DNSSEC jsem nalezl na urovni ON/OFF.

Re:DNS server pro intranet
« Odpověď #4 kdy: 09. 03. 2020, 16:57:01 »
DNSSEC funguje tak, že jednotlivé záznamy podepisujete svým privátním klíčem. Veřejný klíč od tohoto klíče máte také uložený ve své zóně. To by samozřejmě bylo k ničemu, protože útočník by se vyrobil celou novou zónu se svým klíčem. Takže pro ověření platnosti veřejného klíče je v nadřazené zóně otisk toho veřejného klíče (v záznamu DS). Takže vy máte v zóně example.com záznamy podepsané svým klíčem, odpovídající veřejný klíč máte také v zóně example.com v záznamu typu DNSKEY a v nadřazené zóně (tedy com) je uložen v záznamu DS otisk tohoto veřejného klíče (podobně, jako jsou tam v záznamech NS uložené odkazy na DNS servery pro doménu). Abyste mohl plnohodnotně použít DNSSEC, musí tedy správce nadřazené domény umožňovat editaci DS záznamů pro vaši doménu (buď přímo, nebo přes KEYSETy, jak to dělá CZ.NIC pro doménu cz).

Těch DS záznamů pro vaši doménu v nadřazené zóně může být víc, čímž říkáte „všechny tyhle otisky veřejného klíče jsou platné pro podepisování této zóny“. Používá se to především při rotaci klíčů (potřebujete, aby současně platily dva, protože díky kešování DNS odpovědí někdo vidí ještě staré podpisy a někdo už nové). Můžete mít dva otisky v zóně trvale, mělo by to fungovat, jenom bych se lehounce bál, jestli s tím nebude mít problém nějaká implementace, která by špatně řešila kešování. Ale nezkoušel jsem to, třeba bude vše OK.

Žádná speciální podpora ze strany registrátora není potřeba, je to stejné, jako když provádíte rotaci klíčů. Teda je potřeba, aby vám registrátor umožnil použití vlastních klíčů. Pokud registrátor funguje tak, že máte vše na jeho DNS serveru a on sám řeší i veškeré podepisování, pak máte smůlu – svoje klíče vám samozřejmě nevydá, a vy nemáte jak dostat do nadřazené zóny svůj klíč. Ale registrátorů je spousta, pokud nějaký neumí DNSSEC pořádně, přejděte k jinému…


vcunat

  • ***
  • 122
    • Zobrazit profil
    • E-mail
Re:DNS server pro intranet
« Odpověď #5 kdy: 09. 03. 2020, 17:51:48 »
Je otázka jestli chcete vůbec ta lokální data podepisovat, pokud potečou jen po LAN a málokdo přímo na klientech (znovu) validuje.  Pokud ne, nevidím ani potřebu extra autoritativního serveru.  Třeba na Turrisech to tak je: samotný (Knot) Resolver + skript který reaguje na změny v DHCP a aktualizuje podle toho seznam lokálních záznamů.

Celkově nevím o žádném existujícím řešení pro ta LDAP data, ale nikdy jsem se nesnažil hledat.  Pokud to umíte vytáhnout skriptem, přijde mi že řešení se (samotným) Knot Resolverem půjde dobře (celý seznam požadavků).  Ale ani v plánu s autoritativním serverem navíc nevidím problém, jen je to trochu složitější.

Re:DNS server pro intranet
« Odpověď #6 kdy: 09. 03. 2020, 19:00:32 »
Je otázka jestli chcete vůbec ta lokální data podepisovat
Ta "potreba" podepisovani i internich pramenila z obavy, aby nyni ci v budoucnu nebyl problem s tim, ze cast domeny podepisuje, cast nikoliv. Jestli napr. nebude zavedena obdoba HSTS, kdy napr. browser si "postavi hlavu" a rekne "mojedomena.cz ma zaznamy podepsane, ale kancl.mojedomena.cz nikoliv, tak smula". Ano, vim, ze chovani HSTS si ovlivnuji sam a nemusim jej zapinat pro celou domenu, a stejne tak ze browser nyni sam nic neresolvuje a minimalne na "nasich" systemech jde o obsah nsswitch. Jen se snazim delat veci co nejcisteji a vyvarovat se pripadnych problemu v budoucnu a dalsi praci. ;) Ale diky za tip, neuvedomil jsem si, ze validaci uz nikdo za mnou pravdepodobne delat nebude. I kdyz je pravda, ze minimalne u road warriors by asi lokalni validace byla na miste.

Celkově nevím o žádném existujícím řešení pro ta LDAP data, ale nikdy jsem se nesnažil hledat.  Pokud to umíte vytáhnout skriptem, přijde mi že řešení se (samotným) Knot Resolverem půjde dobře (celý seznam požadavků).  Ale ani v plánu s autoritativním serverem navíc nevidím problém, jen je to trochu složitější.
OpenLDAP nove pouzivam pro overovani uzivatelu pro vice sluzeb (NextCloud, OpenProject, ...) a protoze nemam rad veci na mnoha mistech, chtel jsem jej vyuzit i pro spravu zarizeni, kde je lze snadno propojit s uzivateli (Franta ma sveren ThinkPad12) a zaroven i jako uloziste pro souvisejici sitova data (DHCP prideli pro ThinkPad12 IP x, DNS umozni ssh admin@franta.mojedomena.cz, at bude mit IP z LAN, WLAN nebo VPN subnetu a ruzne logy budou obsahovat info, ze pristupoval Franta, protoze PTR zaznam. Ano, slo by to resit i jinak, napr. nejaky agent na user systemech. Pro bind byl napr. bind-dyndb-ldap, ale asi nebude problem pouzit pripadne hooks a spachat nejaky script, v hrosim pripade dotazovani na novinky pres cron.

DNSSEC funguje tak, že (...)
(...) musí tedy správce nadřazené domény umožňovat editaci DS záznamů pro vaši doménu (buď přímo, nebo přes KEYSETy, jak to dělá CZ.NIC pro doménu cz).
Diky za upresneni, nebyl jsem si jist, zda je nutne pouzit DS nebo zda je mozne pouzit i TXT (podpora "nepuvodnich features" byla u nekterych veci resena pres TXT).

Žádná speciální podpora ze strany registrátora není potřeba (...)
Tou "specialni" podporou jsem myslel prave napr. umoznit editaci DS. Joker.com DS nenabizi, minimalne ne na urovni zaznamu typy CAA, zkusim jejich support. Umoznuje samozrejme nastavit si vlastni NS, ale tou cestou bych sel nerad.

Re:DNS server pro intranet
« Odpověď #7 kdy: 09. 03. 2020, 19:49:24 »
Je otázka jestli chcete vůbec ta lokální data podepisovat, pokud potečou jen po LAN a málokdo přímo na klientech (znovu) validuje.  Pokud ne, nevidím ani potřebu extra autoritativního serveru.
To je ale nepochopení DNSSEC. Jakmile je v nadřazené zóně DS záznam, je pro validující resolver podpis povinný – bez podpisu adresu nepřeloží. Takže vůbec nejde o to, zda je to v LAN, nebo zda je validujících klientů málo – jakmile máte alespoň jednoho validujícího klienta, buď podepisujete, nebo mu překlad přestane fungovat. A upřímně řečeno, pokud spoléháte na to, že se DNSSEC nevaliduje, proč pak chcete mít zónu podepsanou?

Tou "specialni" podporou jsem myslel prave napr. umoznit editaci DS. Joker.com DS nenabizi, minimalne ne na urovni zaznamu typy CAA, zkusim jejich support. Umoznuje samozrejme nastavit si vlastni NS, ale tou cestou bych sel nerad.
Nastavení vlastních NS nestačí, musíte mít možnost vložit DS záznamy do nadřazené zóny. Nicméně to s tím nastavením vlastních NS může souviset – pokud používáte NS Joker.com, nedává moc smysl, abyste jim dával vlastní klíče, kterými to mají podepisovat. Jednodušší je, když to podepisují svými klíči. Takže je možné, že volba nastavit vlastní DS záznamy by se vám zpřístupnila až po nastavení vlastních jmenných serverů.

vcunat

  • ***
  • 122
    • Zobrazit profil
    • E-mail
Re:DNS server pro intranet
« Odpověď #8 kdy: 09. 03. 2020, 21:09:03 »
Je otázka jestli chcete vůbec ta lokální data podepisovat, pokud potečou jen po LAN a málokdo přímo na klientech (znovu) validuje.  Pokud ne, nevidím ani potřebu extra autoritativního serveru.
To je ale nepochopení DNSSEC. Jakmile je v nadřazené zóně DS záznam, je pro validující resolver podpis povinný – bez podpisu adresu nepřeloží. Takže vůbec nejde o to, zda je to v LAN, nebo zda je validujících klientů málo – jakmile máte alespoň jednoho validujícího klienta, buď podepisujete, nebo mu překlad přestane fungovat. A upřímně řečeno, pokud spoléháte na to, že se DNSSEC nevaliduje, proč pak chcete mít zónu podepsanou?

Měl jsem na mysli použití nepodepsané zóny, to je čistší.  Například kancl.mojedomena.cz může být hranice nové nepodepsané zóny (tedy bez existence DS na tom jméně).

U "road warriors" mi není jasné jak se k těm datům dostávají.  Tipoval bych VPN, tedy tam by už zabezpečení bylo.  Celkově jsem vycházel z toho předpokladu, že ta data "volně po internetu" téct nemají.


Tou "specialni" podporou jsem myslel prave napr. umoznit editaci DS. Joker.com DS nenabizi, minimalne ne na urovni zaznamu typy CAA, zkusim jejich support. Umoznuje samozrejme nastavit si vlastni NS, ale tou cestou bych sel nerad.
Nastavení vlastních NS nestačí, musíte mít možnost vložit DS záznamy do nadřazené zóny. Nicméně to s tím nastavením vlastních NS může souviset – pokud používáte NS Joker.com, nedává moc smysl, abyste jim dával vlastní klíče, kterými to mají podepisovat. Jednodušší je, když to podepisují svými klíči. Takže je možné, že volba nastavit vlastní DS záznamy by se vám zpřístupnila až po nastavení vlastních jmenných serverů.

Ano, doplnil bych, že pokud podepisovat, tak je dobré nepoužívat stejný klíč navždy a tedy i ten DS jednou za čas přerotovat.

Re:DNS server pro intranet
« Odpověď #9 kdy: 09. 03. 2020, 22:02:32 »
Je otázka jestli chcete vůbec ta lokální data podepisovat, pokud potečou jen po LAN a málokdo přímo na klientech (znovu) validuje.  Pokud ne, nevidím ani potřebu extra autoritativního serveru.
To je ale nepochopení DNSSEC. Jakmile je v nadřazené zóně DS záznam, je pro validující resolver podpis povinný – bez podpisu adresu nepřeloží. Takže vůbec nejde o to, zda je to v LAN, nebo zda je validujících klientů málo – jakmile máte alespoň jednoho validujícího klienta, buď podepisujete, nebo mu překlad přestane fungovat. A upřímně řečeno, pokud spoléháte na to, že se DNSSEC nevaliduje, proč pak chcete mít zónu podepsanou?

Měl jsem na mysli použití nepodepsané zóny, to je čistší.  Například kancl.mojedomena.cz může být hranice nové nepodepsané zóny (tedy bez existence DS na tom jméně).
Ano, je-li toto mozne, bylo by to zrejme dostacujici. Primarne DNSSEC pozaduji pro "vnejsi svet", pro verejne dostupne sluzby, vcetne napr. www.mojedomena.cz a pripadne moznost vyuziti DANE. Na vlastnich strojich jsem schopen zajistit, ze pro celou mojedomena.cz bude dotazovan jen lokalni DNS server s vlastnim zonefile, kteremu duveruji. Presto, pokud by bylo mozne pouzivat DNSSEC pro vlastni domenu i v lokalni siti, byl bych radeji. V takovem pripade mi slo o to, jak zajistit, ze budou validni zaznamy podepsane jak klici na NS registratora, tak klici na lokalnim NS. Moznemu riziku s vice klici v nadrazene zone bych se rad vyhl. Tedy chapu-li to spravne, musim ted u jokera zajistit, aby mojedomena.cz obsahovala DS pro kancl.mojedomena.cz s hashem klice, ktery pouziji na loklanim NS a joker si zajistuje, ze .cz ma v DS jeho klice pro mojedomena.cz. Chapu to spravne? Nebude-li joker schopen toto zajistit, budu rad za tip na registratora, ktery toto umoznuje na vlastnich NS (nejen pro .cz domenu, ale zejmena pro .at - napr. WEDOS uvadi moznost DNSSEC jen pro .cz a .eu), poskytuje API vyuzitelne napr. s acme.sh (pro jokera jsem si napsal jednoduchy script s cURLem), umoznuje spravu s uzitim vice uzivatelskych uctu a idealne s vlastni implementaci forwardovani, vcetne mailu.

U "road warriors" mi není jasné jak se k těm datům dostávají.  Tipoval bych VPN, tedy tam by už zabezpečení bylo.  Celkově jsem vycházel z toho předpokladu, že ta data "volně po internetu" téct nemají.
U road warriors jsem mel na mysli to, ze by bylo vhodne, aby na nich byl vlastni lokalni validujici resolver, protoze ne vzdy jsou jen ve VPN a v takovem pripade by byl resolving zavisly napr. na DNS serveru ziskanem pres DHCP od mobilniho operatora.

Re:DNS server pro intranet
« Odpověď #10 kdy: 09. 03. 2020, 22:54:07 »
Měl jsem na mysli použití nepodepsané zóny, to je čistší.  Například kancl.mojedomena.cz může být hranice nové nepodepsané zóny (tedy bez existence DS na tom jméně).
Ano, pokud vám nevadí použití subdomény, je to nejčistší řešení. Na druhou stranu, pak odpadají všechny problémy se split horizon, prostě si tuhle subdoménu oddelegujete na svůj DNS server, a tam si můžete dělat, co chcete. A klidně tam i můžete podepisovat DNSSEC, bez ohledu na to, co umí váš DNS registrátor (tedy pokud uí alespoň vložit DS záznamy do vaší hlavní domény).

Tedy chapu-li to spravne, musim ted u jokera zajistit, aby mojedomena.cz obsahovala DS pro kancl.mojedomena.cz s hashem klice, ktery pouziji na loklanim NS a joker si zajistuje, ze .cz ma v DS jeho klice pro mojedomena.cz.
Ano.

Nebude-li joker schopen toto zajistit, budu rad za tip na registratora, ktery toto umoznuje na vlastnich NS (nejen pro .cz domenu, ale zejmena pro .at - napr. WEDOS uvadi moznost DNSSEC jen pro .cz a .eu), poskytuje API vyuzitelne napr. s acme.sh (pro jokera jsem si napsal jednoduchy script s cURLem), umoznuje spravu s uzitim vice uzivatelskych uctu a idealne s vlastni implementaci forwardovani, vcetne mailu.
Pro registraci domén používám SubReg, přecházel jsem k nim právě kvůli lepší podpoře DNSSEC. Nevím, co myslíte vlastní implementací forwardování, používám SubReg jen pro domény, ale poskytují i další služby.

Re:DNS server pro intranet
« Odpověď #11 kdy: 10. 03. 2020, 00:21:22 »
Diky za potvrzeni pochopeni. ;)

Nevím, co myslíte vlastní implementací forwardování, používám SubReg jen pro domény, ale poskytují i další služby.

Joker v cene domeny nabizi to, ze teba neco-jineho.cz presmeruje na moje-hlavni-domena.cz/cesta-k-neco-jineho. Obdobne u emailu se pri pouziti FWD nastavi MX na jejich server a je mozne zadat MAILFW "zaznamy" (tak je nazyvaji) napr. postmaster@neco-jineho.cz -> postmaster@moje-hlavni-domena.cz Samozrejme neni nic sloziteho mit treba na VPS vlastni nginx a postfix, ktery tohle bude resit, ale zvykli jsme si mit tohle na jednom miste se skutecnymi DNS zaznamy. Delam tohle pro dva nekomercni subjekty a obcas zaskoci kolega, ktery se jinak stara spise o grafiku, takze jednoduchost spravy oceni.

Re:DNS server pro intranet
« Odpověď #12 kdy: 10. 03. 2020, 04:58:48 »
Tak jsem si na osobni domene overil, ze kombinace lokalni Knot DNS + Knot Resolver je pouzitelna, joker zatim umoznuje pridat NS zaznam, coz by melo byt dostacujici pro nepodepisovanou subzone a DNSSEC by melo byt mozne pro subzonu pridat, az joker umozni pridat i DS, pripadne po prechodu k jinemu registratoru. Mam k tomu ale jeste dve otazky:
  • Predstavuje problem, kdyz NS pro tu subzonu kancl.mojedomena.cz nebude verejne dostupny? Je samozrejme, ze nikdo "z venku" nebude schopen ziskat zaznamy subzony, ale nebude to problem pro zonu mojedomena.cz? Jestli to napr. neodporuje nejakym kontrolovanym pozadavkum.
  • Ackoli do budoucna planuji cosi jako HA, vcetne druheho NS pro subzonu, nebude vyhodnoceno jako problem, kdyz bude pro subzonu uveden pouze jeden NS? Mam dojem, ze pokud nejsou alespon 2 NS, muze to snad i vest k vyrazeni ci podobne restrikci.

Re:DNS server pro intranet
« Odpověď #13 kdy: 10. 03. 2020, 05:39:48 »
Sakra, napadl mne jeste negativni dusledek. Pokud nebudu mit verejne dostupny DNS pro subzonu, zrejme nebudu schopen vystavovat LE certifikaty overovane pomoci DNS. Je tedy vubec mozne nejakym "cistym zpusobem" pouzivat interni DNS zaznamy, ktere nebudou "propagovany do sveta" a zaroven s moznosti vystavovat LE certifikaty overovane pres DNS? Nebo se musim smirit s tim, ze verejne budou pouzivany NS registratora s plne funkcnim DNSSEC a celou zonu mojedomena.cz pro lokalni sit "prekryji" lokalnim validujicim resolverem, ktery bude mit vynucene potlaceni validace pro danou domenu? Mam dojem, ze Knot Resolver toto umi, na nejake prednasce jsem zaslechl, ze snad prave to melo byt vyuzivano pro "obejiti" napr. tehdejsi chyby HBO GO. Jeste mne napada otevreni lokalniho NS jen pro servery LE, ale mam dojem, ze hodlaji pouzivat pro validaci i vice "neznamych" serveru.

Re:DNS server pro intranet
« Odpověď #14 kdy: 10. 03. 2020, 07:46:05 »
Je tedy vubec mozne nejakym "cistym zpusobem" pouzivat interni DNS zaznamy, ktere nebudou "propagovany do sveta" a zaroven s moznosti vystavovat LE certifikaty overovane pres DNS?
DNS nic do světa nepropaguje – někdo musí znát doménové jméno a na to se pak zeptá. „Propagaci“ doménového jména ale zajistí vystavení důvěryhodného certifikátu (pokud nepoužijete hvězdičkový certifikát) – název se objeví v certificate transparency logu vydaných certifikátů.

Ale pokud by vám opravdu vadilo, že si někdo z venku může přeložit váš privátní záznam, můžete použít opět split horizon a do venkovního DNS vystavovat jen ověřovací TXT záznamy pro ACME, ale A/AAAA záznamy mít jen ve vnitřním pohledu na zónu.