PDA

Bekijk Volledige Versie : PowerDNS caching serials en axfr



DoMMeL
10/03/09, 19:46
Hallo wht

Wij zijn sinds kort overgestapt na een mysql replicatie PowerDNS op 3 nameservers naar een supermaster setup.
Dit ivm dataverlies als een replicatie verbroken wordt.

PowerDNS gebruikt de serial om de records te updaten.
Als er een record wordt verwijderd en opnieuw wordt toegevoegd maakt de master een nieuwe serial aan en plaatst deze ook in cache, met als gevolg dat er een notify uitgaat naar de slave en een axfr tot stand wordt gebracht.
Edit je een record dan maakt PowerDNS gebruik van de serial in de cache en die is hetzelfde als in de database van de slave , de slave krijgt alleen een notify en geen axfr en de records worden niet geupdate
Weet iemand een oplossing?

DiedX
11/03/09, 12:53
Die is er niet. PowerDNS houdt zich (zoals het hoort) aan het protocol, en de slaves zien geen nieuwe serial.

De serial zal geupdate moeten worden. Even een goor scriptje schrijven om die serial te updaten, en daarna een pdns_control notify erachter aan.

Wat je zou kunnen overwegen is van Master-Slave naar MySQL-Replicatie over te stappen. Dus MySQL laten repliceren, en de master op de master-MySQL en slave op Slave-MySQL laten luisteren. Dan heb je directe updates en dit gezeur niet.

Mikey
11/03/09, 13:58
Precies, en wanneer je op de master de serial update dan announced pdns dit automatisch naar alle slaves. Zonder een extra commando.

Tim.Bracquez
11/03/09, 15:03
Wij zijn sinds kort overgestapt na een mysql replicatie PowerDNS op 3 nameservers naar een supermaster setup.
Dit ivm dataverlies als een replicatie verbroken wordt.


Wat je zou kunnen overwegen is van Master-Slave naar MySQL-Replicatie over te stappen. Dus MySQL laten repliceren, en de master op de master-MySQL en slave op Slave-MySQL laten luisteren. Dan heb je directe updates en dit gezeur niet.

:lovewht:

Wanneer wordt de replicatie verbroken?
ID's die niet kloppen? (zou bij een master - slave niet mogen voorvallen)
Server die een timout geeft? (neemt normaal terug gewoon op)
Of na herstart dat die de replicatie niet mooi opneemt?

Zelf ben ik meer voor replicatie tussen deze systemen(kan ook gemonitord worden als deze 'breekt'), en met andere DNS systemen even met axfr laten doorsturen.

Bij elke update aan de master (serial) zou dit normaal door moeten worden gestuurd en je slaves zouden dit moeten opnemen / updaten.

Mikey
11/03/09, 15:27
Dan heb je directe updates en dit gezeur niet.

Je kan de tijden inkorten, binnen 5 seconden zijn bij ons alle records uptodate ;)

slave-cycle-interval

En om verdere discussies te voorkomen, alles heeft zowel zijn voordelen als zijn nadelen. Totdat sidn accepteerd dat je kan reggen op nog niet helemaal complete nameservers houden we dit aan. Als ze om zijn schakelijk we terug naar default.

Pur
11/03/09, 15:28
Gezien de "auto-serial" functie (als je een 0 invoert in het SOA record zou PowerDNS automatisch een serienummer 'verzinnen' naar aanleiding van de meest recente change_date van dat domein) al een paar versies kapot is en met die bug niks wordt gedaan zijn wij juist overgestapt van een Master-Slaves setup naar een setup van MySQL replicatie en hebben we ons interne systeem overgezet naar de PowerDNS::Backend::MySQL API die de normale 'standaard' serial yyyymmddxx serial omhoog gooit na elke change. Iets dat we sowieso al van plan waren trouwens.

Lijkt mij in ieder geval wel logisch om bij elke wijziging die plaats vindt de serial omhoog te gooien anders heb je sowieso een issue met je slaves.

Wij hadden sowieso eigenlijk meer issues met AXFR dan met MySQL replicatie. Slaves die hun notify nog niet hadden omgezet in het doen van een AXFR en dus even niet up to date waren.

Mikey
11/03/09, 15:33
Gezien de "auto-serial" functie (als je een 0 invoert in het SOA record zou PowerDNS automatisch een serienummer 'verzinnen' naar aanleiding van de meest recente change_date van dat domein) al een paar versies kapot is en met die bug niks wordt gedaan zijn wij juist overgestapt van een Master-Slaves setup naar een setup van MySQL replicatie en hebben we ons interne systeem overgezet naar de PowerDNS::Backend::MySQL API die de normale 'standaard' serial yyyymmddxx serial omhoog gooit na elke change. Iets dat we sowieso al van plan waren trouwens.


Heb je bert daar rechtsreeks al eens over gemaild ?

Pur
11/03/09, 15:53
Heb je bert daar rechtsreeks al eens over gemaild ?

Nope wel twee keer aangekaart op de mailing list. Waarna iemand mij ook direct benaderde die hetzelfde probleem had en die zou Bert direct benaderen. Maar dat is inmiddels ook alweer een behoorlijk tijdje geleden.

En we waren dus sowieso al van plan om een keer over te schakelen naar MySQL replicatie + reguliere serials want het is imho niet de allermooiste oplossing om de auto-serial functionaliteit te gebruiken.

DiedX
11/03/09, 16:39
:lovewht:

Wanneer wordt de replicatie verbroken?
ID's die niet kloppen? (zou bij een master - slave niet mogen voorvallen)
Server die een timout geeft? (neemt normaal terug gewoon op)
Of na herstart dat die de replicatie niet mooi opneemt?

Zelf ben ik meer voor replicatie tussen deze systemen(kan ook gemonitord worden als deze 'breekt'), en met andere DNS systemen even met axfr laten doorsturen.

Bij elke update aan de master (serial) zou dit normaal door moeten worden gestuurd en je slaves zouden dit moeten opnemen / updaten.
Ik snap je eerste zin niet: de replicatie met een nieuwere versie van MySQL ging bij mij goed. Ook als de server enige tijd niet beschikbaar is.

Zelf ben ik er geen voorstander van. Bij een van mijn vorige werkgevers hadden we deze setup, en het werkt, maar ik vind het relatief ingewikkeld. DNS heeft dit "replicatie"-principe in zich, en kan daarom goed gebruikt worden.

Zelf heb ik PDNS met serial-updates (dus geen MySQL) in gebruik, en overweeg unbound eens te testen.

Tim.Bracquez
11/03/09, 16:59
Ik snap je eerste zin niet: de replicatie met een nieuwere versie van MySQL ging bij mij goed. Ook als de server enige tijd niet beschikbaar is. ...
Welke eerste zin?

Alles heeft zijn voor en nadelen...

DiedX
11/03/09, 17:55
Dat is inderdaad de samenvatting ;)

DoMMeL
11/03/09, 18:15
Precies, en wanneer je op de master de serial update dan announced pdns dit automatisch naar alle slaves. Zonder een extra commando.


En dat is nu het probleem.
De serials worden na een edit van een record geupdate in de database van de master, deze zijn ook verschillend en als master hoger dan de slaves.
Dus zou een notify moeten werken, op de slave komt een notify binnen maar ziet de serials als niet veranderd en doet geen axfr
Als ik in de database van de master kijk zie ik een andere serial staan.
Dus wat doet de master, die zend een notify naar de slaves met de serial die in cache staat, dus ziet de slave een gelijke serial en doet geen axfr.
Als ik een record verwijder en daarna weer toevoeg dan gaat het goed.

Mikey
11/03/09, 18:46
Pdns stuurt helemaal geen serial vanuit de cache, doorgaands wordt er om de minuut gecontrolleerd of er wijzigingen zijn, indien ja wordt er een notify verstuurd vanuit de waarde die in de database staat, en niet diegene die hij al wist.

Maar zet anders eens beide nameservers in monitor mode, dan krijg je precies te zien wat hij doen en waar hij struikelt.

DiedX
11/03/09, 20:00
Heb je je soa-serial wel geupgrade?

DoMMeL
12/03/09, 00:01
upgraden van soa serial?
Ik weet niet wat je bedoelt :o

DiedX
12/03/09, 00:40
mysql> select * from domains where name='diedx.nl';
+----+----------+--------+------------+--------+-----------------+---------+
| id | name | master | last_check | type | notified_serial | account |
+----+----------+--------+------------+--------+-----------------+---------+
| 8 | diedx.nl | NULL | NULL | MASTER | 20080901 | NULL |
+----+----------+--------+------------+--------+-----------------+---------+
1 row in set (0.00 sec)

mysql> select * from records where domain_id=8;
+------+-----------+---------------------+------+-------------------------------------------------+------+------+-------------+
| id | domain_id | name | type | content | ttl | prio | change_date |
+------+-----------+---------------------+------+-------------------------------------------------+------+------+-------------+
| 81 | 8 | diedx.nl | SOA | ns1.diederik.nl hostmaster@diederik.nl 20080901 | 3600 | 0 | 1220450492 |
| 82 | 8 | diedx.nl | NS | ns1.diederik.nl | 3600 | 0 | 1166618281 |
| 83 | 8 | diedx.nl | NS | ns2.diederik.nl | 3600 | 0 | 1166618281 |
| 84 | 8 | www.diedx.nl | A | 84.243.234.210 | 3600 | 0 | 1166618281 |
| 85 | 8 | diedx.nl | A | 84.243.234.210 | 3600 | 0 | 1166618281 |
| 86 | 8 | mail.diedx.nl | A | 84.243.234.210 | 3600 | 0 | 1166618281 |
| 87 | 8 | localhost.diedx.nl | A | 127.0.0.1 | 3600 | 0 | 1166618281 |
| 88 | 8 | diedx.nl | MX | mail.diederik.nl | 3600 | 10 | 1166618281 |
| 1115 | 8 | jl.diedx.nl | A | 84.243.234.210 | 3600 | 0 | 1175777391 |
| 844 | 8 | passionata.diedx.nl | A | 84.243.234.210 | 3600 | 0 | 1166618281 |
| 1077 | 8 | ns1.diedx.nl | A | 84.243.234.210 | 3600 | 0 | 1166618281 |
| 1078 | 8 | ns2.diedx.nl | A | 217.195.118.38 | 3600 | 0 | 1166618281 |
+------+-----------+---------------------+------+-------------------------------------------------+------+------+-------------+
x rows in set (0.00 sec)

mysql>



Check dat soa-record maar eens ;)

Pur
12/03/09, 00:49
http://www.zytrax.com/books/dns/ch8/soa.html

DoMMeL
12/03/09, 01:05
Ik weet wat SOA is na al die jaren, pur ;)
thnx diedx helaas kan ik hier weinig mee, alles staat zoals het hoort te staan.
thnx voor de hulp idgv!

DiedX
12/03/09, 09:49
En als je de SOA ophoogt? Gebeurt er dan wat?

DoMMeL
12/03/09, 15:11
Als ik de SOA verhoog dan doet hij een axfr naar de slaves

DiedX
12/03/09, 15:28
Dat lijkt mij redelijk de bedoeling. Maar is daarmee ook je probleem opgelost?

DoMMeL
13/03/09, 14:12
Nee, niet echt.
Ik ben het nog aan het testen, nogmaals bedankt voor je hulp!

DiedX
13/03/09, 14:26
As always. We horen het wel als je nog meer vragen hebt.

Pur
13/03/09, 19:38
Het probleem was dat de slaves soms geen AXFR wilden uitvoeren (omdat je de serial niet ophoogde). Als je de serial omhoog gooit doen de slaves wel een AXFR. Ergo probleem opgelost lijkt me.

Ben benieuwd naar waarom het probleem dan nog niet is opgelost :-)

Stefan Mensink
14/03/09, 19:59
Als de serial niet wordt opgehoogd, zit het probleem dan niet gewoon in het web based tooltje dat je gebruikt in plaats van in de PDNS-server zelf?

QBell
14/03/09, 21:17
En als je de SOA ophoogt? Gebeurt er dan wat?

[WAY OFFTOPIC]
Dan krijg je een geen druiper maar een spuiter :X
[/OFFTOPIC]

DoMMeL
15/03/09, 03:18
Dan krijg je een geen druiper maar een spuiter

:pinch: Biertje?


Als de serial niet wordt opgehoogd, zit het probleem dan niet gewoon in het web based tooltje dat je gebruikt in plaats van in de PDNS-server zelf?

Het webbased tooltje is een compleet DRS systeem met een standaard PDNS template.
Ik heb nogmaals getest en zie de serial ophogen op de master doet een AXFR naar de slave en de slaves zien een gelijke serial met de master
Wazig maar waar, het is alleen bij een record (A ipadres) editen.
Iedereen kan zijn records wijzigen dat is geen probleem, de laatste record wordt verwijderd en de axfr wordt in gang gezet en de slaves zijn geupdate.
Om alles perfect te laten lopen zou het mooi zijn als een edit goed zou werken zonder handmatige aanpassingen.

Misschien toch weer terug naar mysql replicatie....

Mikey
15/03/09, 11:55
Als de serial niet wordt opgehoogd, zit het probleem dan niet gewoon in het web based tooltje dat je gebruikt in plaats van in de PDNS-server zelf?

De serial wordt vanuit het webbased gedeelte wel opgehoogd, daar zit het probleem niet.

DiedX
15/03/09, 13:12
Mikey heeft het systeem geschreven?