Sync Resolver data between remote sites?
I may not be asking the right question. I want to synchronize Resolve data so that machines VPN'd into one netgate(VPN01-russia) and resolve machines connected to netgate(VPN02-china) through an IPSEC tunnel connecting VPN 01 and 02?
Is this possible at all? or is this a scenario requiring services external to the netgates?
Are these sites the same domain? Are you registering dhcp and you want to resolve those?
Unbound is not meant as an authoritative. if you want that run bind so you can run soa and slaves off your master, etc.
If you are using different domains then just setup domain overrides in your different unbounds pointing to the other site to resolve whatever domain is used there.
They are not on the same DNS domain. But the DNS domains are internal only and we control both ends. Resolver is being used at both ends but obviously only locally resolving clients/wks connected locally. I like the dynamic behavior of Resolver with out needing a full DNS service running.
But I can implement anything I like. What I'd like to do is make it an all Netgate solution avoiding any server/service management overhead. But, again, we can do what we want.
Thank you for responding!
<> ipsec tunnel <>
|Netgate 2 (stuff2.morestuff2.com)|
|LAN2 -- dhcpd|
|Openvpn2 clients |
well just setup dns override in your different instances pointing to the NS that has the domain in it..
You can end up with circular references that way if a domain doesn't exist at either location. You should have each location on a separate subdomain, not everything in one large single domain. Then forward queries for the other subdomain(s) to the other firewalls.
Since you can't have Forwarder and Resolver running at the same time I assume you mean add Resolver IP for N1 to be handed out to N2's clients and N2 Resolver's IP to be add and handed out to N1's clients?
No you do not have to hand out hte other NS to the different locations clients - its a simple freaking override... What is not clicking here?
This is basic 101 dns, it is how it works when you look up anything.. But since these are not public domains you have to tell the NS at site 1 where to go find the NS for domainxyz.. is all which is over at site 2.
I blame the raging sinus headache I've had for three days now
no biggy his morestuff and morestuff2 not real good examples of different domain. I normally use domain and otherdomian to represent different domains in an example ;)
If you have some private domain that nsX has records for be authoritative or not.. Unbound is not really meant to be authoritative for any domain. And you are asking nsY for records that that nsX would respond too - then you just need to tell nsY to go ask nsX for those - ie a domain override..
Clients that are in nsY location should only have nsY listed as dns.. Client that are at the nsX site should only have nsX listed for dns..
jim's circular example would be if both nsX and nsY had records for samedomain.tld..
To be honest a better solution when you control both would prob be to run bind. Since now you have true authoritative NS, and one site could be SOA for domain.tld, and other site could be SOA for otherdomain.tld - and each NS could be slave for each others domains, and have records for both domains via zone transfers.. Or both sites could be NS for samedomain.tld, I am a fan of unbound for sure - but if your wanting to actually run domains with lots of clients and or multiple domains that you want to be authoritative for then bind is the gold standard.
Thanks Johnpoz! Jimp! I came to the conclusion earlier that this should be done via a couple of bind servers. I was looking for an easy way out but usually that makes for a brittle environment. What I didn't know is our team that manages the hosts in "domain" and "otherdomain" forgot to mention they have bind servers.
I dislike Dynamic DNS for security reasons but since this is internal what could possibly go wrong? ;^)..
If you have pfsense you have bind with a gui - its 20 seconds to install the bind package. No need for "servers" etc..