[BIND] Secondary DNS wordt niet goed bijgewerkt

[BacardiBreezer]

Ik zit een beetje te spelen met Bind9. Opzich werkt het allemaal naar behoren echter het bijwerken na een wijziging niet.

De beide DNS-servers zijn aan elkaar "ge-allowed" om van elkaar gegevens te krijgen. Eigenlijk anders gezegd is het zo dat NS2 de zonefiles ontvangt wanneer er op NS1 een zonefile wordt aangemaakt in webmin en "ge-applied" wordt.

Nu gebeurd er alleen het volgende:

Wanneer ik een wijziging op NS1 doe wordt deze niet direct bijgewerkt op NS2, opzich best wel vervelend want zo kloppen beide DNS-en niet en die moeten gewoon gelijk zijn.

De enige manier hoe ik het wel voor elkaar krijg is om de zonefile op NS1 geheel weg te gooien met webmin, te applien en daarna opnieuw met de goede wijziging aan te maken. Blijkbaar wordt de zonefile dan wel van NS2 verwijderd.

Het lijkt er dus op dat de rigoureuze handelingen als aanmaken en verwijderen prima werken richting NS2, alleen het bijwerken, een wijziging wordt niet doorgevoerd naar NS2.

Als het goed is kan ik toch ook met een commando NS2 de info van NS1 op laten halen zodat deze hem wel bijwerkt ?

[ Voor 5% gewijzigd door BacardiBreezer op 14-01-2005 18:21 ]

[Equator]

Wel eens van TTL gehoord..

Time To Live. Een secondaire DNS server zit niet de gehele godganse dag te pollen op zijn primary om te kijken of er een wijziging is..
Dat zou zo verschrikkelijk veel verkeer veroorzaken dat je het nut van een secondary DNS eigenlijk al voorbij loopt.

Een DNS record heeft een bepaalde tijd dat hij actief blijft. Pas als deze periode is verlopen, dan gaat hij kijken of er bij zijn pimaire DNS voor die zone een verhoging is van het serienummer. Indien ja, dan zal hij een zone transfer aanvragen. anders niet.

Ik geloof dat de standaard ttl in de buurt van 24 uur ligt (maar dat kan ik fout hebben) en het kan verschillen.

[BacardiBreezer]

CyberJ schreef op vrijdag 14 januari 2005 @ 20:12:
Wel eens van TTL gehoord..

Time To Live. Een secondaire DNS server zit niet de gehele godganse dag te pollen op zijn primary om te kijken of er een wijziging is..
Dat zou zo verschrikkelijk veel verkeer veroorzaken dat je het nut van een secondary DNS eigenlijk al voorbij loopt.

Een DNS record heeft een bepaalde tijd dat hij actief blijft. Pas als deze periode is verlopen, dan gaat hij kijken of er bij zijn pimaire DNS voor die zone een verhoging is van het serienummer. Indien ja, dan zal hij een zone transfer aanvragen. anders niet.

Ik geloof dat de standaard ttl in de buurt van 24 uur ligt (maar dat kan ik fout hebben) en het kan verschillen.

Klopt helemaal wat je zegt maar je zou het ook via een command kunnen doen. Ik wil gewoon handmatig kunnen zorgen dat het ding bijgewerkt word.

Ik heb al vaker gehoord dat men hun DNS-en om de 5 minuten bij laat werken, NS2 dan.

Het zal wel via een cronjob gaan die dat command uitvoert.

[Verwijderd]

Move PNS > SA

[BacardiBreezer]

Verwijderd schreef op vrijdag 14 januari 2005 @ 20:17:
Move PNS > SA

Didn't know for sure

[BacardiBreezer]

Ik heb nog even wat tests uitgevoerd. Bind herstarten werkt iig niet. Ik kan dit euvel overigens ook niet vinden in de documentatie van Bind.

[elevator]

Weet je zeker dat het serial number opgehoogd wordt van de aangepaste zone file?
Heb je in de config file van bind wel staan dat je notifies stuurt naar de andere DNS server?
Hoe lang wacht je om te zien ofdat de wijzigingen mee genomen worden?

[CyBeR]

CyberJ schreef op vrijdag 14 januari 2005 @ 20:12:
Wel eens van TTL gehoord..

Time To Live. Een secondaire DNS server zit niet de gehele godganse dag te pollen op zijn primary om te kijken of er een wijziging is..
Dat zou zo verschrikkelijk veel verkeer veroorzaken dat je het nut van een secondary DNS eigenlijk al voorbij loopt.

Een DNS record heeft een bepaalde tijd dat hij actief blijft. Pas als deze periode is verlopen, dan gaat hij kijken of er bij zijn pimaire DNS voor die zone een verhoging is van het serienummer. Indien ja, dan zal hij een zone transfer aanvragen. anders niet.

Ik geloof dat de standaard ttl in de buurt van 24 uur ligt (maar dat kan ik fout hebben) en het kan verschillen.

De TTL is iets anders, dat is hoe lang records gecached mogen worden. D'r is inderdaad wel een mechaniek dat dat doet wat jij beschrijft, maar dat is gewoon het SOA refresh veld.

Anyway, dat is niet bepaald relevant aangezien men om de lange periode tussen refreshes en handwerk te vermijden de NOTIFY heeft bedacht, waarmee een primary dns server een secondary kan melden dat 'ie de zone onmiddelijk moet refreshen.

[BacardiBreezer]

elevator schreef op zondag 16 januari 2005 @ 11:13:
Weet je zeker dat het serial number opgehoogd wordt van de aangepaste zone file?

Ik krijg geen melding bij een SIDN-check dat de SOA-serials verschillen dus dat zou goed moeten zijn. Eerder had ik dit wel en heb ze op de Secondary DNS handmatig aangepast wat prima werkte maar wat mij door iemand sterk afgeraden werkd omdat BIND zelf ook bijhoudt wat hij draait en dan de serials niet meer overeen komen ? Lijkt me onwaarschijnlijk.

elevator schreef op zondag 16 januari 2005 @ 11:13:
Heb je in de config file van bind wel staan dat je notifies stuurt naar de andere DNS server?

Yep, ze mogen babbelen.

elevator schreef op zondag 16 januari 2005 @ 11:13:
Hoe lang wacht je om te zien ofdat de wijzigingen mee genomen worden?

Nu inmiddels 2 dagen, lijkt me voldoende


Maar wat ik nog steeds niet snap is dat hij bij het bijwerken niet meewerkt en met het totaal verwijderen van een zone blijkbaar wel.

[elevator]

BacardiBreezer schreef op zondag 16 januari 2005 @ 13:29:
Yep, ze mogen babbelen.

Mogen babbelen (zone transfers toestaan denk ik dat jij bedoelt?) is altijd nog iets anders dan notifies - ("notify yes;" geloof ik in je named.conf) waarmee je ervoor zorgt dat de slave(s)'s op de hoogte gesteld worden als de master updates heeft.

[BacardiBreezer]

elevator schreef op zondag 16 januari 2005 @ 13:47:
[...]

Mogen babbelen (zone transfers toestaan denk ik dat jij bedoelt?) is altijd nog iets anders dan notifies - ("notify yes;" geloof ik in je named.conf) waarmee je ervoor zorgt dat de slave(s)'s op de hoogte gesteld worden als de master updates heeft.

Dus jij zegt in principe:

Als er zone transfers plaats mogen vinden dan hoef je alleen op de slave in te stellen met "notify yes;"

Ik heb dit even gegoogled en zag dat die optie nog niet in mijn named.conf stond, vamdaar dat ik er geen weet van had. Ik heb hem toegevoegd, in webmin op ns1 alles ge-applied en zie direct in de bind-dir meerdere domeinen staan (ik had helaas clear gedaan dus weet het bijna 100% zeker)

Nu heb ik een SIDN-check gedaan en NS2 geeft nog wat errors. Werkt dus al wel beter ! Wat zal ik nog meer checken ?

Dit is trouwens de regel die ik toegevoegd heb:

// allows notify from the defined IPs
allow-notify { 192.168.1.32; };

Ik heb het ook op beide servers getest of het werkte om daar "notify yes;" (zonder quotes uiteraard) in de named.conf te zetten maar geen resultaat.

Ook bind herstart !

[ Voor 21% gewijzigd door BacardiBreezer op 16-01-2005 16:07 ]

[BacardiBreezer]

Ik doe hier even een nieuwe reply omdat het anders zo rommelig wordt, geen KICK dus !

Ik heb de daemon.log files eens even bekeken en zie dat er duidelijk communicatie is, dat is dus uitgesloten.

Wat blijkt nu. Er staan nog wat zonefiles gedefiniëerd op NS2 in de named.conf die op NS2 totaal niet bestond als hostfile en op NS1 wel.

Ik heb op NS1 de hele hostfile weggehaald in webmin en hierna bekeken wat er gebeurde. Op NS1 is alles verdwenen, ook in de named.conf maar op NS2 staat deze file nog steeds gedefinieerd in named.conf.

Er is dus wel communicatie maar er wordt niets uitgevoerd.

Ik blijf zoeken, als iemand iets weet, graag !

[BacardiBreezer]

Ik heb nu alle mogelijkheden gehad. De named.conf op NS2 wordt totaal niet bijgeschreven wanneer ik een nieuwe zone op NS1 aanmaak.

Ik heb per zonefile "notify yes" aanstaan !

Ik zal de configs even posten:

NS1

options {
directory "/etc/bind";
// spoof version for a little more security via obscurity
version "100.100.100";
// no forwarders defined
// zone transfer access denied
// recursion allowed
// notify yes;
also-notify { 192.168.1.3; };
};


NS2

options {
directory "/etc/bind";
// spoof version for a little more security via obscurity
version "100.100.100";
// no forwarders defined
// zone transfer access denied
allow-transfer { 192.168.1.1; };
// recursion allowed
// allows notify from the defined IPs
allow-notify { 192.168.1.1; };
};

[BacardiBreezer]

Opgelost even NS2 opnieuw gesynced