[debian] file server issue icm bind config

[nzyme]

zomaar even een vraagje tussendoor:

Om bind over verschillende servers uit te smeren is het mogelijk om zonetransfers te doen, echter moet je dan voor ieder domain een config instelling hebben en in een dynamische omgeving (hosting) is dat niet echt te doen natuurlijk. Zodoende kreeg ik een geweldig id
Waarom niet het config bestand en alle zone files op NS1 beschikbaar maken via nfs voor NS2 en NS3.... Via een cron op NS2 en 3 laat je ieder uur bind herstarten om zo de gegevens op de nfs share opnieuw in te lezen en dus alles up2date te houden.

Is dit een goed hersenspinsel of mis ik iets ?

We gaan voor het gemak even uit van een onsterfelijke fileserver

[JackBol]

Wat is er mis met een frontend die alles automatisch voor je regelt? Het zone-transfer systeem is naar mijn mening erg goed ontwikkeld.

[nzyme]

zoals welke frontend dan ? mijn cp (vhcs) heeft er _nog_ geen ondersteuning voor....

[JackBol]

nzyme schreef op donderdag 21 september 2006 @ 23:32:
zoals welke frontend dan ? mijn cp (vhcs) heeft er _nog_ geen ondersteuning voor....

thank god for bash

[nzyme]

owzo, ja ik zat al te denken aan het volgende:

een bash script die via cron eens per X uur aangeroepen word. Dit script zal vanaf een nfs share de zone bestanden + het named.conf (waarin staat DAT die zonebestanden er uberhaupt moeten zijn) bestand binnenhalen en copieren naar de juiste plaats (en dus oudere bestanden overschrijven). Aan het eind van de rit moet hij bind herstarten en klaar

Uiteraard moet dit voorzien worden van wat log gebeuren, desnoods een nieuwe /var/log/zonetransfers.log.

scp is ook een optie, maar dan zou het vanaf de NS1 moeten gebeuren en dan zou het alsnog iets moeilijker worden denk ik.... (hoewel..)

[bakkerl]

Bind vervangen voor PowerDNS.

Deze gebruiken in combinatie met een mysql backend, zodat je mysql replica kunt gebruiken.
Of in powerdns gebruik maken van superdns server(s) opties, zodat elk nieuw (aangemaakt) domein uit een superdns automatisch overgenomen wordt.

[nzyme]

mysql replica is sowieso al de bedoeling, maar ik ben altijd een beetje huiverig om de gevestigde orde te vervangen door iets anders/nieuws...

maar is mijn ideetje niet te doen.. ?

[Sendy]

Ik dacht dat je tegen bind kon zeggen dat de secondary servers automatisch een zone moeten gaan serveren als de primary server een NS record voor die sec. nameserver heeft. Ik weet niet hoe de optie heet; lees de bind9 manual even.

Dit zou jouw ideetje volledig overbodig maken.

[nzyme]

sterker, dan zou er dus geen probleem meer zijn zal het even opzoeken...

edit:
nsupdate ?

[ Voor 12% gewijzigd door nzyme op 22-09-2006 11:29 ]

[sariel]

Tsja, maak een hidden primary (ns0), met de dns gegevens in de database, en laat de secondaries (waarvan een 'primary' speelt) (ns1 en ns2) de gegevens daar vanaf halen: bash/perl/whatever cron scriptje bouwen dat de database uitleest en daar dns-config-scripts van maakt. reload bind om de nieuwe config in te stellen, en je bent klaar.

[nzyme]

sariel schreef op vrijdag 22 september 2006 @ 11:30:
Tsja, maak een hidden primary (ns0), met de dns gegevens in de database, en laat de secondaries (waarvan een 'primary' speelt) (ns1 en ns2) de gegevens daar vanaf halen: bash/perl/whatever cron scriptje bouwen dat de database uitleest en daar dns-config-scripts van maakt. reload bind om de nieuwe config in te stellen, en je bent klaar.

dat ben ik dus ook van plan, ik kan zo niets vinden over het dynamisch toevoegen van zones...

maar waarom een hidden primary ? dat ding kan toch gewoon normaal primary (NS1) zijn

[Sendy]

Na ook wat gezocht te hebben lijkt toch dat bind niet kan wat ik het toedicht. Misschien had ik het over een andere DNS server.

[Verwijderd]

Je zou ook op je (hidden) master alle zones kunnen defineren, deze exporteren als "." (root zone) waarna je 1 stub op je slaves aanmaakt waarin je de root zone defineerd om zo dus alle zones van de master met 1 transfer over te zetten.

[ Voor 16% gewijzigd door Verwijderd op 22-09-2006 13:08 ]

[nzyme]

Verwijderd schreef op vrijdag 22 september 2006 @ 13:08:
Je zou ook op je (hidden) master alle zones kunnen defineren, deze exporteren als "." (root zone) waarna je 1 stub op je slaves aanmaakt waarin je de root zone defineerd om zo dus alle zones van de master met 1 transfer over te zetten.

die volg ik niet helemaal, maar het lijkt me dan makkelijk om gwoon een nfs share te pakken...

de zones staan allemaal in hun eigen zone bestand trouwens, dus <domain1.tld> <anotherdomain.tld> <newdomain.tld> etc. Hoe ik die op jou manier dan moet overbeuken naar NS2 en NS3 begrijp ik niet helemaal....