Onderwerp: DA Multiserver setup voor 2nd nameserver

Normaliter zit ik niet zo in mijn maag met DNS maar in dit geval krijg ik het "bomen en bos" gevoel.
De situatie is als volgt:
Server A
ns1.domeinA.nl ip 1234
ns2.domeinA.nl ip 5678

Server B
ns1.domeinB.nl ip abcd
ns2.domeinB.nl ip efgh

Qua cijfers klopt het natuurlijk niet maar het is om het voorbeeld makkelijk te maken.
Op beide servers draait DA en wat ik wil bereiken is dat ik de beide ns2 kan omwisselen dus als volgt:
Server A krijgt ns2.domeinA.nl ip efgh
Server B krijgt ns2.domeinB.nl ip 5678

Mocht server A dan uitvallen kan het domein ip in elk geval nog geresolved worden via server B en omgekeerd.

Dit probeerde ik te doen via de multiserver setup van DA:
http://help.directadmin.com/item.php?id=97

Verbindingstesten gaan goed dus so far so good.

Verder heb ik de PTR record aangepast voor de beide 2e ip adressen.
Ook bij de registar het glue record van de 2de naamservers naar het 2de ip gezet zoals in dit voorbeeld.

De /etc/named.conf is toen nog aangepast en de allow_transfer op het 2de nameserver ip van de andere server gezet.

Maar nu de nameservers zelf in DA. Moeten die handmatig aangepast worden in DNS management?
En een reseller kan virtuele nameservers maken, maar die neemt dan de beide ip adressen die reeds in DA aanwezig zijn dus 1234 en 5678 (volgens dit voorbeeld) in plaats van als tweede naamserver efgh te nemen?
Want als ik de ip's ga toevoegen op beide servers ontstaan er uiteraard allerlei problemen.

Hoe los ik dit op?

P.s.
Deze regel heb ik nog niet gedaan, is die wel nodig voor mijn doeleinde?

Code:

echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue

Je nameservers die de je hebt ingesteld bij je klanten staan niet op IP ingesteld. Die hebben alleen ns1.domeinnaam.nl en ns2.domeinnaam.nl, dus als je domeinnaam.nl naar de juiste IP's forward hoef je voor de rest van de domeinen niets te veranderen.

Maar waarom heb je die allow transfer toegepast? Voor zover ik weet is dat niet nodig?

Dat van de klanten is me bekend, maar een reseller kan virtuele naamservers maken. Ook de admin kan dus "create ns1 en ns2" doen. Maar die gaat DA dan maken van de aanwezige ip's dus niet van het externe ip als 2de ns.

Vandaar mijn vraag of ik die dingen dan handmatig even moet aanpassen.
Bijkomende vraag is of DA nu automatisch alles blijft bijhouden en daarmee nu voldaan wordt aan de geografisch externe 2de naamserver want de tweede staat in Duitsland.
En uiteraard of ik die datatasq.qeue regel ook moet uitvoeren, al dan niet met regelmaat.

De allow transfer had ik omgezet omdat het in eerste instantie niet lukte, dus gewoon voor de zekerheid, als het niet hoeft gaat ie subiet weer weg.

Ja DA blijft alles nu voor je doorsturen. Daar hoef je verder niets voor te doen.

Jij laat de resellers zelf nameservers aanmaken? Dan zou je ze kunnen vragen om de 2e nameserver van hun een ander IP te geven?

Die datasq regel is alleen bedoeld om de bestaande domeinen om te zetten naar de slave server. Die hoef je nu niet meer te gebruiken

Jij laat de resellers zelf nameservers aanmaken?

Ja da's een standaard optie in DA. Virtuele nameservers wel te verstaan he.
Dat 2de ip mogen ze dan zelf wijzigen inderdaad, zal ik zel wel even doorgeven.

Maar de naamserver moet ik dus gewoon even handmatig doen. Prima.

Die datasq regel is alleen bedoeld om de bestaande domeinen om te zetten naar de slave server. Die hoef je nu niet meer te gebruiken

Oh. Maar hoe kan de slave server (2nd nameserver dus) dan nog een domein resolven naar ip adres als de master server bijv. uitgevallen is als de zonefiles niet op de slave aanwezig zijn?

Raar he, ik wijzig dus de secondary nameservers en dan komt het volgende bij SIDN:
Nameserver ns1.domeinA.nl (78.46.xx.xx) geeft geen antwoord op queries via UDP.
Zefde melding voor TCP. Terwijl de poorten wel open staan.
Als ik gewoon van thuis uit telnet naar ns1.domeinA.nl op poort 53 krijg ik netjes een zwart venster, dus verbinding.

Er draait csf/lfd en poort 53 staat ook gewoon open op tcp en udp. Wat doe ik fout?

Oorspronkelijk geplaatst door Blacky

Oh. Maar hoe kan de slave server (2nd nameserver dus) dan nog een domein resolven naar ip adres als de master server bijv. uitgevallen is als de zonefiles niet op de slave aanwezig zijn?

Deze functie kopieert toch alle zones. Daar is ie immers voor bedoeld?
En die opdracht is dus enkel om alle bestaande zones op server 1 te kopiëren naar server 2:

If you need to transfer all of your zones from your current machine to the servers listed in your multi-server IP list, then you can type:

Raar he, ik wijzig dus de secondary nameservers en dan komt het volgende bij SIDN:
Nameserver ns1.domeinA.nl (78.46.xx.xx) geeft geen antwoord op queries via UDP.
Zefde melding voor TCP. Terwijl de poorten wel open staan.
Als ik gewoon van thuis uit telnet naar ns1.domeinA.nl op poort 53 krijg ik netjes een zwart venster, dus verbinding.

Heb je gecontroleerd of alle zones zijn omgezet naar de 2e server? Heb je DNS check gedaan of alles werkt bij SIDN?

Wellicht eens het ip adres of de hostname delen met ons?
Dan kunnen we zelf ook kijken of we respons krijgen van je server. Sommige van ons kijken naar andere zaken dan dat jij zou doen.

Je hebt toch niet speciaal een 2de server in duitsland genomen alleen voor de DNS he?

Deze functie kopieert toch alle zones. Daar is ie immers voor bedoeld?

Dat doet hij dus klaarblijkelijk alleen bij wijzigingen, niet bij reeds bestaande domeinen. Ik heb nu 2 wijzigingen uitgevoerd en van die 2 domeinen zijn nu ook zonefiles op de 2nd server.

Heb je DNS check gedaan of alles werkt bij SIDN?

?? In de quote staat net dat ik het antwoord van SIDN krijg, dus die foutmelding komt uit de SIDN check.

Never mind... het is al fixed. De originele DB was klaarblijkelijk weg, die had ik teruggekopieerd maar kwam niet meer goed terug in DA zelf onder dns management, dus even opnieuw aangemaakt in DNS management en nu doet de SIDN check het wel goed.


Edit: Misschien maakt het niet uit, maar vind het ook wel apart dat op de hosting server in /var/named de domeinen op root:root staan en op de server010 op root:named als eigenaar.