On 22/01/2019 02:20, Grant Taylor via bind-users wrote:
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.
I'm not fully against this idea but I'm not comfortable with Site2/3
depending on Site1 for the updates.
If for some reason Site1 is unreachable and a host tries to update the
DHCP lease, the DNS update would fail and the said host wouldn't be
reachable by other direct neighbor hosts (same site) by DNS name just
because a remote service is not available. Yes, I could lower the DHCP
leases time to try again sooner but it looks inelegant to me.
This reminds me of an infamous issue few years ago where a WiFi router
brand cut the internet access to all hosts because their cloud service
was down. The idiotic router firmware believed that internet was "down".
Also like stupid Windows hosts displaying warning icons when they can't
access www.msftncsi.com, etc. etc. I hate these kind of dependencies and
I do whatever I can to avoid them.
- 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.
There would be no need to promote secondaries to primaries because Site1
is really the big one holding most of the information. Site2/3 are
"satellites" really where only minimal service is provided.
Note: I'm assuming a zone expiry of a week to a month. I think that
would accommodate most outages.
I thought of that too :-) A week would be far enough in my case.
- 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
That's a nice idea, however I feel like it's starting to be a bit
complicated for my use case. 2 DNS servers per site, maintaining RPZ
zones, etc seems a bit overkill for my setup.
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.
If I understand correctly, each site would have 2 DNS servers, one
"normal" and one forwarder. Would this kind of setup support dynDNS
without trouble?
1/ All sites work independently of each other.
Please elaborate how much this statement precludes the sites from
sharing a DNS zone.
What I meant is that each site would work on its own for normal traffic.
Hosts and assets (printers, etc.) would boot up, DHCP, register DNS and
access internet the usual way. That's what I mean by "independent".
Only the DNS requests for "unknown records within the local example.com"
would be forwarded to the "master" (Site1)
Site1 would hold all the DNS records for its own hosts/assets (ie:
host1, printer1, etc.). Site2/3 would do the same on their own (ie:
host21,printer21, host31, printer31, etc.) but "app.example.com" and all
the others would be forwarded to Site1.
All of this to avoid duplicating the DNS records on each site (currently
3 of them but could grow). At least, that's the current idea but I'm
open to other solutions if they fit the bill :-)
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.
I wouldn't need to promote secondary servers to be primary as all of
this is purely internal to the company. Site2/3 people would to their
work normally, just being unable to reach the centralized app only
available at Site1.
I assume that you are wanting to avoid manual replication, as in needing
to enter the same record in multiple other sites.
You assume correctly :)
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.
I think I'm now geared towards this solutions which seems to be the
simpler one to implement.
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.
I like out-of-the-comfort-zone ideas but in my current case, this seems
to be a bit overkill.
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.
I think I'm a bit biased here because I thought about a multi-master DNS
service like I already have with OpenLDAP! The multi-master setup of
OpenLDAP works so magically well that I really wished it was possible
for my DNS use case :-) I can update any LDAP server in the chain and it
magically propagates everywhere in an instant.
That's because I didn't find anything in the docs about the multi-master
setup that I came up with the idea of a "selective forwarding" thing :)
You're welcome. Good luck.
Thank you for your feedback.
--
ObNox
_______________________________________________
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
