Bekijk Volledige Versie : DNS servers wijzigen
We draaien nu een aantal jaar secondary DNS bij een externe partij, maar we willen dit graag intern gaan onderbrengen. Er bestaat alleen wat twijfel over de juiste aanpak en welke software de voorkeur gaat krijgen.
Er zijn weinig eisen:
- Platform/control panel onafhankelijk;
- Automatisch toevoegen en verwijderen zones;
- Geen master op control panel: externe DNS moeten dus zowel master als slave draaien.
PowerDNS lijkt geschikt. Al lukt het nog niet helemaal om supermaster op te zetten, is dit wel wat we zoeken. Alleen bestaat er nog wat twijfel over het verwijderen van zones. Er is verloop in de domeinen en het kan vervelend worden als een domeinnaam blijft hangen in de DNS server. Hoe gaat PowerDNS hier mee om? Het platform moet ook worden gebruikt voor externe klanten. Het moet zonder al teveel poespas werken.
Dan nog een ander praktisch probleem. We maken al jaren gebruik van dezelfde nameservers. Voor bestaande domeinnamen gaan we de nameserver hostnames niet aanpassen, eigenlijk moet dit aan de hand van een A record wijziging volstaan. Voor nieuwe domeinen gaan we nieuwe hostnames gebruiken. Kan dit?
Ik ben benieuwd naar jullie ideeën.
Tim.Bracquez
27/05/11, 16:03
PowerDNS lijkt geschikt. Al lukt het nog niet helemaal om supermaster op te zetten, is dit wel wat we zoeken. Alleen bestaat er nog wat twijfel over het verwijderen van zones. Er is verloop in de domeinen en het kan vervelend worden als een domeinnaam blijft hangen in de DNS server. Hoe gaat PowerDNS hier mee om? Het platform moet ook worden gebruikt voor externe klanten. Het moet zonder al teveel poespas werken.
Dit doet powerDNS niet out of the box. Echter met een scriptje kan dit wel. Hier ooit aan begonnen en had dergelijke functionaliteit
- Script check elke x uur of de domein nog resolved op je master
- Na xx failures ging hij de zone verwijderen
Echter is dit manueel allemaal en berust je nog altijd op de goede werking van dat script, eens aan verder werken en hier posten
dennis0162
27/05/11, 16:21
Wij gebruiken ook PowerDNS en zaten met hetzelfde probleem.
Met dit scriptje opgelost:
#!/bin/bash
#### Config ################################
DBUSER="pdns"
DBPASS="****"
#### End of Config #########################
MYSQL="mysql -u $DBUSER -p$DBPASS --skip-column-name --silent -e"
check() {
AUTH=`dig @$1 $2 | grep "status" | awk -F , '{print $2}' | awk -F ': ' '{print $2}'`
if [ $AUTH = "REFUSED" ] || [ $AUTH = "NXDOMAIN" ]; then
echo "$1 $2: Server not AUTH or SERVfail - removing zone..."
DOMAIN_ID=`$MYSQL "USE pdns; SELECT id FROM domains WHERE name='$2' AND type='SLAVE' AND master='$1' LIMIT 1;"`
$MYSQL "USE pdns; DELETE FROM records WHERE domain_id='$DOMAIN_ID';"
$MYSQL "USE pdns; DELETE FROM domains WHERE id='$DOMAIN_ID';"
fi
}
MASTERS=(`$MYSQL "USE pdns; SELECT DISTINCT ip FROM supermasters;"`)
for m in "${MASTERS[@]}"; do
NAMES=(`$MYSQL "USE pdns; SELECT name FROM domains WHERE type = 'SLAVE' AND master = '${m}';"`)
for d in "${NAMES[@]}"; do
check ${m} ${d}
done
done
Ooit eens op internet gevonden.
Wij gebruiken ook PowerDNS en zaten met hetzelfde probleem.
Met dit scriptje opgelost:
nu nog even attachen ;)
dennis0162
27/05/11, 16:24
Ik was al bezig ging even fout:)
Tim.Bracquez
27/05/11, 18:23
Wij gebruiken ook PowerDNS en zaten met hetzelfde probleem.
Met dit scriptje opgelost:
Ooit eens op internet gevonden.
Hier nog even wat snel geschreven met een betere check, xx timouts, dan pas deleten... Want in jouw scriptje gaat die het gelijk weg halen. Lijkt me niet leuk als je servers down zijn, dan resolved geen enkele domein meer.
Tim.Bracquez
28/05/11, 22:02
Ooit eens op internet gevonden.
Heb er hier nog ééntje: http://files.fusa.be/clean_pdns.sh (het doet zijn werk)
Deze gaat meermaals proberen alvorens er gedelete wordt, zo voorkom je dat al je domains weg zijn al een server down is.
Zoals ik het goed lees gaat dat scriptje ook niet de overbodige records (domeinen die niet meer resolven) uit de database halen als je in de master tabel een master weghaalt (het script baseert zich op de masters tabel).
Dit scriptje gaat het automatisch verwijderen doen, het automatisch toevoegen moet je gewoon instellen in je dns software.
dennis0162
28/05/11, 22:27
Nu is het domeinnaam als nog weg als je server x uur down is.
Misschien een extra veld met de timestamp wanneer het domein niet resolvde.
En dat de volgende dag mee nemen als het nog steeds niet resolvt?
Ik zal vanavond is kijken of ik die aanpassing kan maken:)
Tim.Bracquez
28/05/11, 22:31
Nu is het domeinnaam als nog weg als je server x uur down is.
Misschien een extra veld met de timestamp wanneer het domein niet resolvde.
En dat de volgende dag mee nemen als het nog steeds niet resolvt?
Ik zal vanavond is kijken of ik die aanpassing kan maken:)
Dat scriptje laat ik draaien 1x per dag... dus je kan instellen na hoeveel failed tests die het delete. Hier staat het op 5, dus na 5 dagen is die uit je pool. Te snel/te traag... geen idee loopt vlotjes. Wanneer de domein terug resolved zal die counter terug op 0 gezet worden in dat script.
dennis0162
28/05/11, 22:41
Waar sla je dat op? Want dat kan ik niet terug vinden of kijk ik eroverheen?
Tim.Bracquez
28/05/11, 22:51
Waar sla je dat op? Want dat kan ik niet terug vinden of kijk ik eroverheen?
Staat in de working dir...
Heb er hier nog ééntje: http://files.fusa.be/clean_pdns.sh (het doet zijn werk)
Deze gaat meermaals proberen alvorens er gedelete wordt, zo voorkom je dat al je domains weg zijn al een server down is.
Zoals ik het goed lees gaat dat scriptje ook niet de overbodige records (domeinen die niet meer resolven) uit de database halen als je in de master tabel een master weghaalt (het script baseert zich op de masters tabel).
Dit scriptje gaat het automatisch verwijderen doen, het automatisch toevoegen moet je gewoon instellen in je dns software.
Heb het juist ook even gedownload en even bekeken maar heb toch een paar opmerkingen voor in mijn geval dan. Je doet een "host domain master" check, maar is het niet beter om een dig check te doen op NS records en te controleren of de NS van de slave er tussen staat. Indien ja dan is het ok, indien niet dan is het failed, kwestie dat ik niet op elke slave server alle domains heb staan.
Vb:
domain1.tld => ns1 (master) - ns2 (slave) - ns3 (slave) - ns4 (slave)
domain2.tld => ns1 (master) - ns2 (slave) - ns4 (slave) - ns7 (slave)
domain3.tld => ns1 (master) - ns2 (slave) - ns5 (slave) - ns6 (slave)
Als je dan je script runt op ns5 dan zegt hij dat domain1 & domain2 ok zijn maar in feite klopt dit niet aangezien deze domeinnamen geen gebruik maken van de server. Idem als je klant bvb eerst gebruik maakt van volledige dns structuur en dan later beslist om bvb andere slaves te gaan gebruiken (bij andere partij) maar jou als master te behouden, dan krijg je dus ook domeinnamen die in de slaves blijven staan omdat de master ze nog in de lijst heeft staan. Ondanks dat er geen ns records meer bestaan voor die slave server.
En ja ik weet het dat het meer specifiek is voor mij, maar er zullen hier waarschijnlijk nog WHT-ers zijn met gelijkaardige setups en/of problemen.
Tim.Bracquez
29/05/11, 08:50
Heb het juist ook even gedownload en even bekeken maar heb toch een paar opmerkingen voor in mijn geval dan. Je doet een "host domain master" check, maar is het niet beter om een dig check te doen op NS records en te controleren of de NS van de slave er tussen staat. Indien ja dan is het ok, indien niet dan is het failed, kwestie dat ik niet op elke slave server alle domains heb staan.
Dan raad ik je aan dit aan te passen en te delen op wht ;)
Hier met MySQL replication een setup dus dit zit iets anders
Top, bedankt voor het script. Daar gaan we morgen mee testen. Wat betreft het supermaster verhaal: ik zou graag zien dat de check of het SOA record klopt, oftewel de 'nameserver' in de supermasters table, geskipt wordt. Of mis ik een voordeel hier van?
Tim.Bracquez
29/05/11, 12:41
Top, bedankt voor het script. Daar gaan we morgen mee testen. Wat betreft het supermaster verhaal: ik zou graag zien dat de check of het SOA record klopt, oftewel de 'nameserver' in de supermasters table, geskipt wordt. Of mis ik een voordeel hier van?
Het command waar die de check doet is het 'host' command. Dit kan je vervangen door iets wat het beste past. Zoals een dig op de NSen of de dig op het SOA record. Als je het uitvoert op de slave heb je het voordeel dat je alle records kan inzien omdat AXFR aanstaat... Dus dan kan je het zo sluitend mogelijk maken.
Het scriptje dat ik gaf checkt gewoon of de domein nog resolved op je master / hidden DNS.
Hier draait 1 PDNS slaaf die het scriptje draait. Dit scriptje loopt alle domeinen af en check op alle masters / hidden DNSen (die niet gebruikt worden) of dit nog bestaat, zoniet dan gooit die dat er uit. De andere servers krijgen dit mee met de MySQL replication.
Dingen waar het faalt zijn zoals Dennis aangeeft, stel een klant past de NS records aan, dan blijft die in je PDNS setup zitten ook al maakt die er niet meer gebruik van. Het is echter wel zo dat dit met een check op de omgeving maar 6 domeintjes waren op de 50k waar dit het geval was. Uiteraard beter dat je dit dus nog aanpast, echter hoe het nu is geeft het me al een beter gevoel om de omgeving clean te houden. Na meerdere run's hier zijn er een hoop weg, meer dan 10k
Graag zie ik anderen dit verbeteren, hopelijk zijn jullie er wat mee!
Ho, wacht even, we gaan de verkeerde kant op :-)
Ik doel op de check die PowerDNS doet om te kijken of er een supermaster is voor de notifies die het ontvangt. Als ik het goed begrijp controleert deze het IP en de primaire nameserver die in het SOA record staat aangegeven. Dat is natuurlijk wel zo veilig, maar maakt het wat complex voor resellers met eigen nameservers bijvoorbeeld. Deze records worden niet meegenomen zover ik nu kan zien.
dennis0162
29/05/11, 12:56
Zelfs dat is op te lossen:)
pdns.conf:
gmysql-supermaster-query=select account from supermasters where ip='%s'
Dan raad ik je aan dit aan te passen en te delen op wht ;)
Hier met MySQL replication een setup dus dit zit iets anders
Zal even kijken of ik jouw script daarvoor wat kan aanpassen, ik heb zelf ook scripts draaien maar die zijn in php (cli) gemaakt in plaats van bash/shell wegens wat meer compatibiliteit van bepaalde functies.
Maar inderdaad als je mysql replication draaid heb je het probleem niet zo als ik het heb, echter heb je dan andere punten waar je moet op letten. Als de mysql database f*ck up is of domain per ongeluk gedelete wordt dan is dat voor je volledige pool/cluster die in de mysql replication zit. Dan is het voordeel van je slaves eigenlijk weg omdat ze allemaal zelfde data gebruiken. Idem als je master slave down is of je mysql down (op die server), dan blijven de andere slave met oudere data draaien.
Maar dat zijn dus afwegingen die iedere hoster voor zichzelf moet nemen, zowel de voor als nadelen van hun setups.
Bij deze Tim zijn script wat aangepast met gebruik van NS record check + extra scriptje om AXFR records te forceren. Indien er nog fouten zouden inzitten gelieve dit even te melden.
http://dennis.dehoux.be/files/pdns-tools.tar.gz
Ah, top! Ondertussen draait het. Ik zal er morgen logging bij maken zodat verwijderde domeinen in een log bestand terecht komen. Maakt debuggen misschien wat gemakkelijker.
Ah, top! Ondertussen draait het. Ik zal er morgen logging bij maken zodat verwijderde domeinen in een log bestand terecht komen. Maakt debuggen misschien wat gemakkelijker.
Dat zit er al bij ;) check config.cfg en source anders eens
Sorry, helemaal over het hoofd gezien. Ik ga het eens proberen.
Tim.Bracquez
30/05/11, 16:33
Dat zit er al bij ;) check config.cfg en source anders eens
Is al geen klein scriptje meer ;) Mooi werk !
Thks, dat is inderdaad al geen klein scriptje meer, maar had al iets gelijkaardig maar dan op php basis (cli) dus ben nu even bezig mij eigen scripts aan het porten naar bash/shell. Dus kan ik het net zo goed even delen met de community.
dennis0162
30/05/11, 19:04
Dat ziet er al een stuk beter uit dan het scriptje wat ik poste.
Thanks Dennis!
websiteondemand
31/05/11, 08:45
Wel jammer "ooit ergens op internet gevonden", wel jammer dat je de makers niet even noemt ;-) no hard feelings
http://blog.hostingondemand.nl/2010/12/10/pdns-clean-up-script/
Origineel dus door: Mike de Weijer van Hosting on Demand, support@hostingondemand.nl
Wij gebruiken ook PowerDNS en zaten met hetzelfde probleem.
Met dit scriptje opgelost:
#!/bin/bash
#### Config ################################
DBUSER="pdns"
DBPASS="****"
#### End of Config #########################
MYSQL="mysql -u $DBUSER -p$DBPASS --skip-column-name --silent -e"
check() {
AUTH=`dig @$1 $2 | grep "status" | awk -F , '{print $2}' | awk -F ': ' '{print $2}'`
if [ $AUTH = "REFUSED" ] || [ $AUTH = "NXDOMAIN" ]; then
echo "$1 $2: Server not AUTH or SERVfail - removing zone..."
DOMAIN_ID=`$MYSQL "USE pdns; SELECT id FROM domains WHERE name='$2' AND type='SLAVE' AND master='$1' LIMIT 1;"`
$MYSQL "USE pdns; DELETE FROM records WHERE domain_id='$DOMAIN_ID';"
$MYSQL "USE pdns; DELETE FROM domains WHERE id='$DOMAIN_ID';"
fi
}
MASTERS=(`$MYSQL "USE pdns; SELECT DISTINCT ip FROM supermasters;"`)
for m in "${MASTERS[@]}"; do
NAMES=(`$MYSQL "USE pdns; SELECT name FROM domains WHERE type = 'SLAVE' AND master = '${m}';"`)
for d in "${NAMES[@]}"; do
check ${m} ${d}
done
done
Ooit eens op internet gevonden.
Tim.Bracquez
31/05/11, 11:02
Wel jammer "ooit ergens op internet gevonden", wel jammer dat je de makers niet even noemt ;-)
Dat is waar, vind het ook leuk dat Dennis(The-Boss mijn vermelding er nog heeft in staan in het script. Denk dat dennis0162 het niet meer wist ;)
Wat gebeurd er eigenlijk binnen PowerDNS wanneer we domeinx.nl van supermaster1 naar supermaster2 verhuizen, oftewel, we gaan domeinen migreren tussen twee servers. Wordt de master overschreven in de domains tabel of gaan er zaken overstuur raken?
Tim.Bracquez
31/05/11, 11:45
Wat gebeurd er eigenlijk binnen PowerDNS wanneer we domeinx.nl van supermaster1 naar supermaster2 verhuizen, oftewel, we gaan domeinen migreren tussen twee servers. Wordt de master overschreven in de domains tabel of gaan er zaken overstuur raken?
Dat wordt niet overschreden naar mijn weten, je moet die eerst deleten. Mogelijk het scriptje nog eens aanpassen en er een --force MASTER bijzetten zodat je die master forced gaat checken voor een migratie :-)
websiteondemand
31/05/11, 13:30
ja dat denk ik ook, puur vergeten .. zodoende ook mijn melding: "no hard feelings" kan gebeuren !
Dat is waar, vind het ook leuk dat Dennis(The-Boss mijn vermelding er nog heeft in staan in het script. Denk dat dennis0162 het niet meer wist ;)
dennis0162
31/05/11, 13:31
Wist ik inderdaad niet meer:)
websiteondemand
31/05/11, 14:01
Wist ik inderdaad niet meer:)
u is vergeven :-)
Dat is waar, vind het ook leuk dat Dennis(The-Boss mijn vermelding er nog heeft in staan in het script. Denk dat dennis0162 het niet meer wist ;)
Lijkt me maar fair ook aangezien het gebaseerd is op jouw script/idee, alleen is het wat beter uitgewerkt.
Dat wordt niet overschreden naar mijn weten, je moet die eerst deleten. Mogelijk het scriptje nog eens aanpassen en er een --force MASTER bijzetten zodat je die master forced gaat checken voor een migratie :-)
Dit is nog hokus pokus voor mij, zelfs na twee dagen spelen :-)
Wat Googlen vertelt me inderdaad dat de domeinnaam eerst uit PDNS gehaald moet worden en dan op de nieuwe supermaster geplaatst kan worden. Blijkbaar is het niet anders.
Wat Googlen vertelt me inderdaad dat de domeinnaam eerst uit PDNS gehaald moet worden en dan op de nieuwe supermaster geplaatst kan worden. Blijkbaar is het niet anders.
Dus als ik het goed versta wil je op je pdns slave de domainnamen van master X veranderen in master Y, als het zo is kan ik daar ook wel nog een scriptje voor schrijven.
Uiteindelijk wel, maar dat is nu nog in mindere mate belangrijk. Ik zit een beetje met het volgende. Een deel van de servers gebruikt de oplossing uit DirectAdmin, deze schrijft dus alle zones weg naar 1 server, laten we deze server A noemen. Deze server synchroniseert naar een externe server, zegge DNS A, die we momenteel huren bij een derde partij. En nu dus ook naar de 2 DNS servers die via PowerDNS draaien, laten we beide servers bij elkaar voor het gemak DNS B noemen. Op server A draaien ook gewoon websites trouwens. Er zijn uiteindelijk maar 2 nameserver hostnames.
So far so good. De servers die nu synchroniseren naar server A moeten gaan synchroniseren naar DNS B. Dat is geen probleem. Kwestie van supermasters toevoegen en named.conf wijzigen. In dit geval komen we wel in de knoei met dubbele zones. Deze staan namelijk op server A en bijvoorbeeld server B. Als we eerst alle zones uit DNS B verwijderen, notify op server A uitschakelen, dan alle andere servers synchroniseren naar DNS B. Dan is DNS B up to date wat betreft deze servers.
Maar nu komt het probleem. Server A moet ook gesynchroniseerd worden. Als we de zones uit server A verwijderen zijn de domeinnamen niet meer bereikbaar (ik ga uit van het slechtste geval), aangezien DNS A de domeinnamen eveneens verwijdert. Doen we dit niet, worden de zones dubbel gerepliceerd naar DNS B en raakt het beestje in de war.
Het liefste had ik gezien dat op server A natuurlijk geen websites draaiden en alleen DNS, dan was het een kwestie van synchroniseren van DNS B en hostnames aanpassen. Maar nu kom ik een beetje in de knoei. Of ik maak het weer eens moeilijker dan het daadwerkelijk is.