Vlákno názorů k článku DNSSEC s BIND 9.9 snadno a rychle od Žito - Díky za pěkný návod, je to hezky shrnuto....
-
Díky za pěkný návod, je to hezky shrnuto. Dovolím si tady položit dotaz, který se možná netýká jenom mě. Asi před rokem jsem nad inline-signingem také bádal. Rád bych již také zavedl DNSSEC na naši firemní doménu, ale je to komplikováno takovou nepěknou historickou věcí - split horizon DNS. Je to prostě tak, že kdysi v hluboké minulosti jsme se rozhodli, pro použití stejného doménového jména uvnitř fy i vně směrem do Internetu. Prasárna je, že některé služby mají v interní síti jméno s RFC1918 interní adresou a vně pak totéž jméno s externí adresou (provoz jde například přes web rev proxy apod.) Problémy vznikají samozřejmě ve chvílích, kdy si někdo při přechodu mezi interní sítí a Internetem zaklapne/uspí notebook a přejde na druhou stranu (fyzicky) nebo si zapne VPN. Notebook si chvíli drží v DNS cache nevhodný záznam z druhé strany. Je to samozřejmě špatně a jednak by se služby veřejně přístupné měly pokud možno umisťovat do DMZ a druhak by se vnitřní DNS mělo zřejmě dávat do subdomény, např. int.example.com nebo lan.example.com apod, ale už to tak je a teď s tím asi těžko něco udělám. Záznamů je moc a asi nepřipadá v úvahu nějak rychle tohle změnit (ano to možná nepůjde snadno ani v horizontu let).
No a teď tedy jak na tohle nejlépe nasadit DNSSEC? Vnější a vnitřní DNS leží na fyzicky oddělených name-serverech. Mě se to jeví tak, že bude nejlépe zřídit dalši "hidden" master, kde se budou všechny zóny udržovat a podepisovat a současné name-servery si budou zóny stahovat z tohoto hidden mastera. DNS views se při zone transferu na slave rozliší pomocí TSIG klíče (to mám již vyzkoušeno). Pokud se použije takto pouze jeden klíč ZSK, tak by mohl podepsat shodně zóny pro různé pohledy zone views - tedy podpisy shodných záznamů budou shodné také ve vnitřním i vnějším DNS. Nějaká jiná cesta nebo zádrhele tohoto řešení?
-
Taky možnost, ale motivace k tomu jednomu masteru je mít všechny data na jednom místě a jednou asi přejdeme na systém, že zóny generujeme z databáze a proč řešit distribuci těch DNS dat, když to samo DNS má vyřešené. Ještě to rozvážím čím začít. Snížit TTL u těch měňavých záznamů - to je správná poznámka - to musím zkontrolovat.
-
M. (neregistrovaný)
Ano, podepisovat obě verze zóny stejným klíčem je řešení, pokud je to na různých fyzických serverech, tak ten hidden master je asi nejvhodnější řešení a rozlišení dle TSIG pro AXFR funguje (používáme taktéž).
Jinak problém s tím, že někteří debilní klienti neflushnou DNS cache při přechodu vnitřek/vnějšek řešíme tak, že servery, které mají veřejnou IP adresu ve veřejném DNS, tak jsou i ve vnitřním DNS na stejné veřejné adrese a vnitřní DNS je bohatší tak o to, co je jen uvnitř na neveřejných adresách. Od té doby je s tímto přechodem klid. -
Njn, vono použít tu veřejnou adresy vždy nejde. Protože mě třeba napadá jedna nejmenovaná aplikace, která má doménovou autentizaci (Active Directory) přes tu neveřejnou adresu a přes tu veřejnou adresu se lidi hlásí jménem heslem a tak podobně :-/. Taky to má trochu nižší dostupnost, protože kdyby nedejbože padl cluster firewallu... tak přes vnitřní adresy by mohla nějaká důležitá aplikace jet dál, kdežto pád firewallu ji znepřístupní na veřejné adrese. No ano, asi dost nepravděpodobný scénář doufám ;-).
