Jak se to vezme.
Ja nase dns treba provozuji v rezimu primarni databaze (administrace) a replikovanych databazi (dns server). Jedine riziko tohoto provozu je, pokud dojde k poskozeni primarni databaze tak, ze se skody zreplikuji.
Na druhou stranu, odpadaji veskere problemy s prenosem zmen/zon. Replikace jsou velmi spolehlive, snadno monitorovatelne.
Spise dneska vnimam problem se schopnostma administracniho rozhrani. Nekdy je fakt tezke neco sehnat...
Předpokládám, že používáte na veškeré DNS pouze jednu SW implementaci. V praxi je častý problém, když operátoři používají jako sekundární servery třeba Knot DNS, BIND a NSD a musí to všechno nějak jednotně konfigurovat.
Mimochodem jeden z dalších dílů se bude věnovat katalogovým zónám, které zjednodušují některé problémy s konfigurováním více serverů.
Co se týče administračního rozhraní, tak souhlasím, že je situace složitá. Bohužel každý má různé požadavky nebo unikátní integraci ve své infrastruktuře a osobně neznám dostatečně univerzální zadání. Pokud máte rozumnou představu, klidně se s námi o ní podělte.
Ano, pokud je tam vice implementaci dns, tak je se to tezce komplikuje. Nakonec se ukaze, ze stejne nekdo musi napsat prechodove mechanismy/skripty/administraci. Ale my jsme mala firma, tak i kdyz narazim na urcite problemy s moznym nasazenim nekterych technologii vuci soucasne implementaci dns, tak nastesti to business jeste nevyzaduje, tak to nemusim resit (a staci mi treba cli).
K te administraci, rozvadet to nebudu, to byl jen povzdech - v nasem pripade vyvojari daneho dns poskytuji pouze api/cli administraci...
Samozřejmě každý si může zvolit software, který mu vyhovuje. Nicméně bych uvítal trochu konstruktivnější kritiku. Celkem se snažíme vyjít vstříc uživatelům, ale nějaký vážný zájem o SQL jsme dosud nezaregistrovali. Mohl byste prosím popsat vaše použití DNS serveru? Nepochopil jsem, zda řešíte konfiguraci serveru v databázi nebo zónová data v databázi. Jak už někdo komentoval, databáze jde proti výkonu. Takže to není naše zaměření. Ostatně i DB backendy u BIND mají různá omezení. Například s DNSSEC to bývá problém. Další nepříjemností je, že když měníte obsah databáze, tak o těch změnách musíte nějak server informovat, aby mohl efektivně pracovat jen s rozdílem. Jinak je to bude zoufalé pro větší nasazení. V podstatě, kdybychom přidávali nějakou takovou podporu, tak to bude jen další vrstva nad současnou implementací. Klidně se nám ozvěte přímo, rádi sbíráme zkušenosti a požadavky uživatelů a někdy nás i napadne nějaké řešení.
Nase nasazeni je velmi jednoduche. Pro interni site mame IPA servery s integrovanym DNS a pro externi domenu mame v DMZ server s Bind pripojenym do LDAPu pomoci bind-dyndb-ldap. Nevim jak to interne funguje, ale zmeny jsou na vsechny servery propagovany okamzite a ani s DNSSEC neni problem. Cela konfigurace vcetne dnssec klicu je v ldapu, neni problem migrovat DNSSEC master na novy server. Nektere speciality nejdou naklikat ve web. interface, ale zatim jsme nenarazili na nic co by neslo nakonfigurovat pres cli. Jeste jsme k tomu pridali do ldapu navic DHCP a jednoduchym skriptem zajistujeme synchronizaci DNS/DHCP zaznamu (vetsinu dhcp rezervaci mame statickych podle MAC). Kdyz se k tomu prida jeste centralni identita pomoci ipa-clienta, je z toho skoro AD domena pro Linux servery ;-).
Díky za odpověď. Přiznám se, že z pohledu technického mi to nepřijde velmi jednoduché. Jestli myslíte Free IPA, tak to je projekt do jisté míry nezávislý na BIND a koukněte se, z čeho všeho se skládá. Podobně by asi šel integrovat i Knot, ale dosud nás tento směr moc nezajímal. Patrně cílíme na jiný druh uživatelů. Možná časem, až budou hotové, pro nás důležitější, části.
Vy jste zmínil i sql, předpokládám, že jde o https://bind9.readthedocs.io/en/latest/advanced.html#dynamically-loadable-zones-dlz Tam jsou uvedeny i nevýhody, včetně nepodpory DNSSEC.
S tim ze je cela IPA slozita souhlasim, sam bych to dohromady z jednotlivych komponent asi nedal, ale ve skutecnosti se vse nakonfiguruje jedinym prikazem a funguje to prekvapive dobre. Mate pravdu i v tom ze DNS je v IPA jen jedna z komponent, v podstate je tam hlavne pro to, ze je nutne mit dobre nakonfigurovane DNS pro spravne fungovani kerberosu. SQL jsem tam jen tak placnul, ve skutecnosti jsem videl bind napojeny na sql jen jednou.
Nicmene si nedovedu predstavit jak bych tech cca 70 serveru (az na par vyjimek jsou na kazdem jine aplikace) a 500 uzivatelu spravoval bez centralni identity a napojeni prakticky vsech aplikaci na ldap.