On 1/21/19 1:39 AM, ObNox wrote:
Hi,
Hi,
I'm trying to find a viable solution to my use case. Here is the context : - Site 1 : ISC DHCP + ISC Bind and dynamic updates for example.net Here, example.net is authoritative with views for different query sources.There are plans to add a new site (Site 2) and probably a third (Site 3) which must be functioning independently so they'll both feature ISC DHCP + ISC Bind for their needs.They must use example.net domain (ie: host1.example.net, etc, etc) and can not use subdomains (stupid licensing issues on business software)Each site will only deal with local information in their DNS like only the local workstations and printers.All sites will have a VPN connection to the main site (Site 1) because there are a number of centralized services that can not be distributed (ie: the main business software) so a host in Site 2 will want to connect to "app.example.net" residing at Site 1.
Before going into your requirements / desires below, I feel the need to say: I feel like this can be done with a single common zone. Site 1 is authoritative and handles dynamic updates. Site(s) 2 (and 3) slave the zone -and- forward dynamic updates to Site 1.
What I would like to have is some kind of selective forwarding like this : - Each site have its own "example.net" zone for the DHCP dyn DNS
Why do you want to have multiple (three) distinct copies of the same zone?Rather, why don't you want a single common zone that is replicated and can relatively easily be converted from secondary to master.
Note: I'm assuming a zone expiry of a week to a month. I think that would accommodate most outages.
- If some host queries xxx.example.net via its local DNS server, try to resolve it locally. If not found, forward the query to "Site 1" DNS server which probably have the right answer.
I feel like my "Duplicate authoritative DNS zones .... on purpose" article might help you.
Link - Duplicate authoritative DNS zones .... on purpose- https://dotfiles.tnetconsulting.net/blog/2013/0610/Duplicate-authoritative-DNS-zones-on-purpose.html
You can have site local authoritative information in what I referred to as the DR instance. Then if the local authoritative information (DR instance) doesn't have what you want, forward to Site 1.
What I'm trying to achieve : 1/ All sites work independently of each other.
Please elaborate how much this statement precludes the sites from sharing a DNS zone.
2/ Each DNS server have it's own records which are unique among all sites of course
Site unique records do not preclude other site records being in the same zone.
3/ If the main site (Site 1) is down, only the centralized services are unavailable to the other sites
This is where a healthy expiry timer on a slave server comes into play. You can set the timer high enough to allow service / connectivity restoration -or- connecting into the server and reconfiguring it from a secondary zone to be a primary zone instead.
3/ Each time I add a new record in Site 1 DNS server, I don't need to replicate this record to all other sites to make it known.
I assume that you are wanting to avoid manual replication, as in needing to enter the same record in multiple other sites.
Is such a DNS configuration possible ?
I think something close can probably be done.I personally would try to use the common zone that is replicated from Site 1 to the other sites combined with update forwarding from the remote sites back to Site 1.
If that's unsatisfactory for some reason, I'd look into sets of the configuration described in my "Duplicate authoritative DNS zones .... on purpose" article.
There might also be some other options, but I think they are even further into the weeds and likely more problematic to support.
I feel like this might be a viable use case for a multi-master configuration. But I'm not sure how well BIND supports that, be it integrated or via DLZ to some sort of replicated back end.
Thank you for any advice.
You're welcome. Good luck. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users