Bekijk Volledige Versie : Powerdns replication
Beste mensen,
Wij hebben een nieuw aantal dns servers geinstalleerd op basis van powerdns.
onze DA server (supermaster) geven de dns records door naar een powerdns (master)
en deze is doormiddel van mysql replication weer op een powerdns (slave) ook ge-update.
echter als wij nu een SIDN dns check uitvoeren (undelegated)
geeft deze aan dat de Consistentheid niet goed is.
------------------
melding:
2 verschillende volgnummers (serials) gevonden.
Het SOA volgnummer (de serial)is niet op alle name servers gelijk. Dit kan duiden op een configuratiefout, maar kan ook het gevolg zijn van het traag propageren van mutaties naar de secondary name servers.
2 verschillende SOA records gevonden.
Het SOA record is niet op alle name servers gelijk. Dit duidt normaal gesproken op een configuratiefout.
-------------------
dit terwijl beide servers perfect repliceren? waarom dan wel een verschillend SOA nummer?
Iemand ervaring hiermee.. (of beter een oplossing ;-) )
gr.
Marco
T. Verhaeg
30/10/10, 12:55
Als je de PDNS monitor start, komt er dan iets concreets uit?
systemdeveloper
30/10/10, 13:23
Check eens of je mysql slave geen errors heeft? Misschien repliceert ie gewoon niet en komen de wijzigingen niet eens door.
dreamhost_nl
30/10/10, 19:12
Is recursie wel op alle DNS servers ingesteld voor alle (DNS) servers in het cluster?
Wat geeft onderstaande?
dig SOA [domeinnaam] [naamserver]
Dit dat even doen voor alle naamservers en kun je verschillen hier melden?
@dreamhost_nl: Waarom zou recursie in dit geval vereist zijn? Het gaat neem ik aan gewoon om PowerDNS auth.
Wanneer je PDNS zelf laat repliceren hoef je toch geen MySQL-replicatie te hebben ?
T. Verhaeg
31/10/10, 15:49
Wanneer je PDNS zelf laat repliceren hoef je toch geen MySQL-replicatie te hebben ?
Het kan met MySQL of AXFR
systemdeveloper
31/10/10, 16:01
DNS ga je over het algemeen ook niet met mysql replicatie consistent houden :)
T. Verhaeg
31/10/10, 16:07
DNS ga je over het algemeen ook niet met mysql replicatie consistent houden :)
Zucht, ben jij nou alweer wakker? Probleem bij MySQL replicatie is wel dat de services moeten draaien om de updates te ontvangen. Is je slave down, dan ga je geen goede consistentie houden, maar het behoort tot de mogelijkheden.
systemdeveloper
31/10/10, 16:14
Zucht, ben jij nou alweer wakker? Probleem bij MySQL replicatie is wel dat de services moeten draaien om de updates te ontvangen. Is je slave down, dan ga je geen goede consistentie houden, maar het behoort tot de mogelijkheden.
Is een slechte optie. Als je zelf goed wakker was, zou je dat ook kunnen bedenken :)
Maar het heeft niks te maken met down of niet down zijn van je slave. Wel met het inrichten van nieuwe slaves, tijdelijk vervangen van nameservers, ingewikkeldere setup die niet nodig is, etc.
Het kan met MySQL of AXFR
AXRF of gebruik maken van replicatie binnen de backend (MySQL/PGSQL/Bind files/etc.) en via AXFR is mogelijk. Echter gezien het verhaal vervalt de optie om vanaf 1 PowerDNS server via AXFR de gegevens richting de overige PowerDNS servers te verspreiden. Replicatie via de backend wordt ook als het wel een optie is AXFR te gebruiken geadviseerd. Niet alleen is het vaak sneller met het verspreiden van wijzigingen, tevens worden de slaves opgeschoond indien een domein wordt verwijderd.
Voor meer informatie hierover kun je ook naar #powerdns (irc.oftc.net) gaan.
AXRF of gebruik maken van replicatie binnen de backend (MySQL/PGSQL/Bind files/etc.) en via AXFR is mogelijk. Echter gezien het verhaal vervalt de optie om vanaf 1 PowerDNS server via AXFR de gegevens richting de overige PowerDNS servers te verspreiden. Replicatie via de backend wordt ook als het wel een optie is AXFR te gebruiken geadviseerd. Niet alleen is het vaak sneller met het verspreiden van wijzigingen, tevens worden de slaves opgeschoond indien een domein wordt verwijderd.
Voor meer informatie hierover kun je ook naar #powerdns (irc.oftc.net) gaan.
Zolang dat iedere slave dan ook dezelfde zone's heeft, wat bij mij alles sinds al niet het geval is met 7 nameservers. En als we het dan toch over vluggere methodes hebben gebruik dan IXFR ipv AXFR.
T. Verhaeg
31/10/10, 17:50
Is een slechte optie. Als je zelf goed wakker was, zou je dat ook kunnen bedenken :)
Maar het heeft niks te maken met down of niet down zijn van je slave. Wel met het inrichten van nieuwe slaves, tijdelijk vervangen van nameservers, ingewikkeldere setup die niet nodig is, etc.
Heb je gelijk in, feit is alleen dat het tot de mogelijkheden behoort. Zou het zelf ook niet doen denk ik, maar voor kleinschalige oplossingen voldoet het prima.
ErikKosters
01/11/10, 12:06
volgens mij kan je een opzet van 2 aparte DNS servers toch beter anders doen... zoals ik nu begrijp is het:
webserver > dns1 > dns2
Lijkt mij slimmer om het gewoon zo te doen;
webserver > dns1, dns2
Mocht dns1 wegvallen en iemand een update doorvoeren dan wordt het gewoon via dns2 gepakt. Op deze manier hebben wij het ook ingesteld, via PowerDNS werkt dat prima. En zoals The-Boss al zegt, gebruik inderdaad IXFR ipv AXFR.
Wij hebben in het bedrijf ook nog mysql replication gebruikt voor de powerdns servers maar hebben hier nooit problemen mee gehad. Al denken wij er wel over om van powerdns naar BIND over te gaan wegens het ontbreken van dnssec in powerdns op dit moment.
Check eens bij de configuratie (ik meen master) welke soort je record heeft. Je hebt de mogelijkheid om een MASTER, SLAVE en NATIVE te maken. Ik vermoed dat je nu een MASTER en SLAVE hebt, waar je NATIVE moet gebruiken bij MySQL replicatie.
Check eens bij de configuratie (ik meen master) welke soort je record heeft. Je hebt de mogelijkheid om een MASTER, SLAVE en NATIVE te maken. Ik vermoed dat je nu een MASTER en SLAVE hebt, waar je NATIVE moet gebruiken bij MySQL replicatie.
Het is geloof ik al opgelost (datum = november)
Grrrrrrrrr. Van die omhooggeschopte topics...
Mocht de TS nog meekijken: wat was nu uiteindelijk het probleem?