Onderwerp: Powerdns / directadmin problemen

Wij hebben de laatste paar dagen rare problemen met onze powerdns slave. Wij weten even niet of dit sinds de update naar 3.4.0 is. Als ik op een directadmin server een nieuw domein aanmaak, dan zien wij het volgende:

Oct 27 16:21:00 Received NOTIFY for domein.nl from xxx.xxx.xxx.xxx for which we are not authoritative
Oct 27 16:21:00 Created new slave zone 'domein.nl' from supermaster xxx.xxx.xxx.xxx
Oct 27 16:21:00 1 slave domain needs checking, 0 queued for AXFR
Oct 27 16:21:00 While checking domain freshness: Query to 'xxx.xxx.xxx.yyy:53' for SOA of 'domein.nl' produced no results (RCode: Query Refused)
Oct 27 16:21:00 While checking domain freshness: Query to 'xxx.xxx.xxx.zzz:53' for SOA of 'domein.nl' produced no results (RCode: Query Refused)


Als we vervolgens in de database kijken zien we bij de master ns bijna alle IP adressen van onze supermasters maar niet die van xxx.xxx.xxx.xxx . Er staat er dan zoveel in dat hij niet eens alle supermasters erin kan zetten.

Vervolgens blijft uiteraard deze zone zonder records omdat de master NS niet klopt. Dit doet hij trouwens niet vanaf alle Directadmin servers. In de named file op de directadmin server zie ik niets vreemds.

Zodra ik handmatig de master ns goed zet wordt de zone netjes geladen. Heeft iemand een idee waar dit in kan zitten?

Gebruik je de officiele 3.4.0? Dit was namelijk een bug in 3.4.0 RC1, zie: https://github.com/PowerDNS/pdns/issues/1703

Jouw probleem heb ik in dat issue ook aangekaart (niet alle super masters passen in database veld) maar ik heb hun oplossing nooit kunnen testen. Ik raad je aan een nieuwe bug te rapporteren met de verwijzing naar mijn link en het probleem dat jij ervaart.

Ja wij gebruiken de 3.4.0 maar waarom doen niet alle directadmin servers dit? Jij geeft aan dat hij de supermaster tabel afloopt, is dit de normale manier hoe powerdns dit doet? Waarom zet hij daar niet gewoon het adres is van de server waarvan hij de transfer krijgt?

Dat is precies mijn argument

Wat hij doet: SOA record geeft ns1.bla.nl aan, hij pakt vanuit super masters alle IP adressen die geregistreerd staan bij record ns1.bla.nl (kunnen dus meerdere servers zijn). Als die lijst met IPs langer is dan de grootte van hey database veld dan vallen er IP adressen weg ja. Ze hebben dat gefixt door niet alleen naar SOA record te kijken maar ook naar het account in de supermasters tabel. Gebruik je daar misschien voor alle super masters dezelfde waarde in de kolom "account"?

Oorspronkelijk geplaatst door robheid

Ja wij gebruiken de 3.4.0 maar waarom doen niet alle directadmin servers dit? Jij geeft aan dat hij de supermaster tabel afloopt, is dit de normale manier hoe powerdns dit doet? Waarom zet hij daar niet gewoon het adres is van de server waarvan hij de transfer krijgt?

Dat is wat hij in het verleden deed. Met bv migraties en bepaalde failover setups is dit echter niet handig. Verder kan wat DutchTSE zegt mogelijk de oorzaak (en indirect oplossing) zijn. Als dat zo is dan is mijn advies het veld voor het IP groter te maken en te kijken of dat helpt.

Oorspronkelijk geplaatst door Mark17

Dat is wat hij in het verleden deed. Met bv migraties en bepaalde failover setups is dit echter niet handig. Verder kan wat DutchTSE zegt mogelijk de oorzaak (en indirect oplossing) zijn. Als dat zo is dan is mijn advies het veld voor het IP groter te maken en te kijken of dat helpt.

Het was juist super handig met migraties. Je deed een migratie, update domains set master = nieuw IP where master = oud IP. Vervolgens named restant op nieuwe server en klaar vind de nieuwe setup geen verbetering daarin.

ok, dan heb ik dat stuk gemist. Maar het deel met de accounts hebben wij nooit gebruikt dus dan moeten we daar iets mee gaan doen blijkbaar, buiten het vergroten van het veld. Bedankt!

De achtergrond van de wijziging is overigens om zowel IPv4 als IPv6 gelijktijdig toe te staan staat me iets van bij. Als je het als bug ziet zou ik adviseren om het snel (liefst binnen 24 uur) te rapporteren op Github aangezien 3.4.1 er waarschijnlijk op korte termijn alweer aankomt.

Oorspronkelijk geplaatst door Mark17

De achtergrond van de wijziging is overigens om zowel IPv4 als IPv6 gelijktijdig toe te staan staat me iets van bij. Als je het als bug ziet zou ik adviseren om het snel (liefst binnen 24 uur) te rapporteren op Github aangezien 3.4.1 er waarschijnlijk op korte termijn alweer aankomt.

Het zou dus al opgelost moeten zijn n.a.v. mijn bugmelding, maar ik heb dit niet meer kunnen testen. Wanneer je gebruik maakt van het "account" veld in de supermasters tabel dan zou alleen het IP dat de notify doet als master vermeld moeten worden, mits de waardes in het account veld uniek zijn. TS maakt geen gebruik van het account veld en loopt via die weg mogelijk tegen het oude probleem aan, er vanuit gaande dat het inderdaad juist gefixt is.

Maar meld het zeker aan want de huidige oplossing is ook niet je van het.

Oorspronkelijk geplaatst door DutchTSE

Het zou dus al opgelost moeten zijn n.a.v. mijn bugmelding, maar ik heb dit niet meer kunnen testen. Wanneer je gebruik maakt van het "account" veld in de supermasters tabel dan zou alleen het IP dat de notify doet als master vermeld moeten worden, mits de waardes in het account veld uniek zijn. TS maakt geen gebruik van het account veld en loopt via die weg mogelijk tegen het oude probleem aan, er vanuit gaande dat het inderdaad juist gefixt is.

Maar meld het zeker aan want de huidige oplossing is ook niet je van het.

Reactie die ik vanuit PowerDNS heb gekregen is dat het verstandig is om het account veld uniek te maken of te beperken per server. Dit staat voor zover mij bekend niet gedocumenteerd en ik ken geen web interface die zo werkt/dit forceert. De interface die wij hebben gemaakt gaat dit waarschijnlijk later dit jaar wel krijgen.

Bedankt, dat heb ik nu voor beide servers aangepast en dat blijkt te werken. Ik kwam erachter dat het script wat snachts loopt om de domeinen te verifiëren op de masters ook hierdoor steeds de domeinen verwijderde omdat het master IP er wel ergens in stond maar er meerdere IP's stonden waar het domein niet op staat.