Selective forwarding?

[ObNox]

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