29/08/17 21:30
Ik heb 2 DNS servers, namelijk:
192.168.10.10 en .20.
Beide hebben ze dezelfde zones, maar ieder zijn eigen records.
Bijvoorbeeld:
Zone foo.bar.nl
De ene DNS server heeft records
abc.foo.bar.nl
abcd.foo.bar.nl
Terwijl de andere DNS server deze records niet heeft, maar wel de volgende records:
xyz.foo.bar.nl
xyz2.foo.bar.nl
Ik wil een forwarder opzetten en via de forwarder wil ik dus altijd resultaat krijgen.
Iemand tips?
30/08/17 03:31
Oorspronkelijk geplaatst door xaban
ja : het niet op deze manier doen .
Een authoritieve nameserver is precies dat - authoritief voor z'n zones . Als deze server een naam kent , dan is het dat . En als deze server expliciet een negatief antwoord geeft (NXDOMAIN) - naam bestaat niet , dan bestaat die naam ook niet en hoef je het niet bij een andere DNS te proberen.
Daar ben je authoritief voor , om een definitief antwoord te geven.
Zorg dus dat beide servers de hele zone kennen.
30/08/17 10:22
Je zet een recursor op (of meer) en zet daar per zone de forwarder in:
https://doc.powerdns.com/md/recursor...#forward-zones
30/08/17 14:15
Moet dat ook werken voor de vraag van de TS , waarbij *dezelfde* zone (foo.bar.nl) op twee servers een verschillende inhoud heeft, en hij de gecombineerde versie (union) wil bevragen ?
30/08/17 15:09
Ah, nee, ik ging er vanuit dat dat subzones waren.
Overigens vraag ik me af wat er gebeurd als je die 2 ip's toevoegd aan de forwarder regel en bij een query de ene zegt "NXDOMAIN" en de andere geeft het record terug. Wat doet een recursor dan?
30/08/17 16:37
"implementation defined" denk ik .
In elk geval is heel duidelijk dat een authoritief antwoord "bestaat niet" evenzeer definitief is als een DNS record .
Het zou bijzonder slecht zijn voor DNS loadsharing wanneer elke NXDOMAIN zou leiden tot het queryen van alle NS'en voor een zone omdat er eentje misschien een andere zone heeft.
Het lijkt me aannamelijk dat de recursor het eerste antwoord dat binnenkomt teruggeeft . Of met een ingestelde forwarder voor een zone de recursor die in een primaire/backup volgorde gebruikt of erover round-robined zal ook variabel zijn.
Zelfs als het gedrag van een bepaalde versie recursor toevallig overeenkomt met je gewenste effect zou het heel fragiel zijn om je design daarop te baseren , wanneer dat niet het gevolg is van DNS rfc of hard ingestelde configuratie .
30/08/17 20:16
Ik denk dat de beste tip is: Niet doen, want dns is daar niet voor bedoeld.
Dat betekent niet dat je niet 2 dnsservers kunt hebben met verschillende records voor eenzelfde domein. Dat wordt vaker gedaan om bv intern bij een bedrijf meer subdomeinen te laten resolven en aan de buitenkant alleen het broodnodige. Maar die gaan niet alle ns servers nalopen om te kijken of er ergens een record bestaat natuurlijk.
SystemDeveloper.NL - 64BitsWebhosting.EU : Softwareontwikkeling & Hosting freaks
30/08/17 22:52
Hmm, jammer niemand heeft echt een oplossing zonder af te wijken van de huidige setup.
Er bestaan namelijk 2 gescheiden netwerken, echter maken ze beide gebruik van dezelfde zone met ieder een eigen inhoud. Hmm, hoe ga ik hier omheen werken zonder de zone aan te passen....
30/08/17 23:23
Gewoon alle records op beide dns-servers zetten?
SystemDeveloper.NL - 64BitsWebhosting.EU : Softwareontwikkeling & Hosting freaks
31/08/17 11:08
Je kunt m.i. drie dingen doen :
1 - de twee zone files mergen en daarmee zorgen dat beide servers alle informatie hebben.
Zolang de namen wel uniek zijn is dat vrij goed automatiseerbaar . (En als het slechts eenmalig is, en daarna updates centraal bijgewerkt worden is dat helemaal makkelijk).
Als het om organisatie/politieke redenen niet kan zou je zelfs nog een gemergde zonefile elders kunnen maken, zolang je met zonetransfers de beide versies kunt ophalen . Dit vergt al weer ietwat meer script werk, maar zolang je via zonetransfers de data kunt dumpen kun je een gecombineerde zonefile maken en die bevragen
2 - zien dat je de verschillen in een subdomein kunt krijgen xyz.foo1.bar.nl en abc.foo2.bar.nl . Als deze wijziging mogelijk is, kan de ene server primary zijn voor foo1.bar.nl en secondary voor foo2.bar.nl , en de andere andersom .
Of met de forwarders optie zoals vDong beschreef .
DIt is uiteindelijk heel normale delegatie wanneer een domein decentraal beheerd wordt . (denk : host.land.globalenterprise.com , waarbij de land zone beheerd wordt door het betreffende land )
3 - schrijf je eigen resolver(tje) in Perl of Python dat altijd beide serves bevraagd en een enkele NXDOMAIN negeert wanneer de andere server wel een record levert.
Natuurlijk laat je dit resolvertje alleen gebruikt worden voor foo.bar.nl queries . (forwarder entry voor foo.bar.nl naar localhost:5053 ofzo waar je script luistert)
Deze optie zou ik echt als allerlaatste overwegen, en dan alleen nog wanneer de queries alleen maar van 'intern' komen, bijvoorbeeld een management server die beide 'domeinen' moet zien .
Voor gewone records zou het moeten kunnen (even kiezen wiens antwoord je neemt voor bv SOA of NS record, die bij beiden aanwezig zullen zijn ). Ik durf niet te zeggen of het ook nog doenbaar is als de zones DNSSec doen.
Je moet het schrijven, debuggen en onderhouden, en zo'n constructie is totaal onverwacht voor iedere (nieuwe)collega die ook iets moet beheren of troubleshooten.
Ik zeg nog steeds: Niet Doen . Je setup is verkeerd, dat repareren is heel veel makkelijker.
02/09/17 17:52
De records zijn uniek, maar ik vraag mij af hoe een BIND bijvoorbeeld omgaat wanneer het 2 zones ophaalt van 2 verschillende servers met verschillende inhoud. Gaat het dan niet overschrijven ipv mergen?
Heeft mijn voorkeur, maar gaat helaas niet.2 - zien dat je de verschillen in een subdomein kunt krijgen xyz.foo1.bar.nl en abc.foo2.bar.nl . Als deze wijziging mogelijk is, kan de ene server primary zijn voor foo1.bar.nl en secondary voor foo2.bar.nl , en de andere andersom .
Of met de forwarders optie zoals vDong beschreef .
DIt is uiteindelijk heel normale delegatie wanneer een domein decentraal beheerd wordt . (denk : host.land.globalenterprise.com , waarbij de land zone beheerd wordt door het betreffende land )
Is ook een oplossing, maar dan ga ik nog liever met scp oid de zonefiles binnenhalen en mergen op een 3e server.3 - schrijf je eigen resolver(tje) in Perl of Python dat altijd beide serves bevraagd en een enkele NXDOMAIN negeert wanneer de andere server wel een record levert.
Natuurlijk laat je dit resolvertje alleen gebruikt worden voor foo.bar.nl queries . (forwarder entry voor foo.bar.nl naar localhost:5053 ofzo waar je script luistert)
Deze optie zou ik echt als allerlaatste overwegen, en dan alleen nog wanneer de queries alleen maar van 'intern' komen, bijvoorbeeld een management server die beide 'domeinen' moet zien .
Voor gewone records zou het moeten kunnen (even kiezen wiens antwoord je neemt voor bv SOA of NS record, die bij beiden aanwezig zullen zijn ). Ik durf niet te zeggen of het ook nog doenbaar is als de zones DNSSec doen.
Je moet het schrijven, debuggen en onderhouden, en zo'n constructie is totaal onverwacht voor iedere (nieuwe)collega die ook iets moet beheren of troubleshooten.
Ik zeg nog steeds: Niet Doen . Je setup is verkeerd, dat repareren is heel veel makkelijker.
Setup is niet correct ja, maar wijzigen gaat helaas niet.
Bedankt voor je reactie overigens!
02/09/17 22:24
Oh, dit gaat zeker niet vanzelf mergen inderdaad. Zonetransfer zou hier alleen het transport mechanisme zijn waar je gebruik van zou kunnen maken wanneer scp, rsync e.d. politiek/organisatorisch niet te regelen zijn - zonetransfer is dan de kleinste gemene deler van een data dump met trigger/notificatie mechanisme.
Het mergen moet je zelf scripten (en je moet dus op de één of andere manier beide zones apart ontvangen).
Ik noem het omdat je blijkbaar in de situatie zit dat je nogal weinig structureel kunt oplossen en mogelijk dus op geen andere manier bij de bron data kunt komen.
Ik vraag me overigens af hoe de hostnamen uniek blijven wanneer er zo weinig te veranderen valt en de systemen zo gescheiden zijn - om die uniciteit te garanderen heb je dan wel een centrale naam-authoriteit nodig , technisch of organisatorisch.
Als je zou kunnen zorgen dat de updates op beide zones ook op een derde zone gezamelijk gemaakt worden is je probleem ook opgelost .
Likes: 
Quote