Selective forwarding?

[Grant Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190121/2983372e/attachment-0001.bin>