On 1/20/20 6:28 AM, Brian J. Murrell wrote:
I'm really not sure about what the name of this feature I am going to describe would be. I would probably call it an "overlay view". But I am sure there are better names.
I get why you say "overlay view", but I think I'd try to avoid the "overlay" term for various reasons.
Imagine I have a BIND 9 server for the following network topology: Network 1 192.168.1.0/24 ------------------------ -------------------------|.254 | | Router | Network 2 | | 192.168.2.0/24 | | -------------------------|.254 | | | Network 3 | | 192.168.3.0/24 | | -------------------------|.254 | ------------------------There are a few dozen hosts/services on Network 3 which hosts from Network 1 and Network 2 need to resolve names of. All pretty straightforward.But the hosts on Network 1 and Network 2 need to resolve the same name (let's call it "gateway") to the address of their interface on Router. So that is, hosts on Network 1 want a query of "gateway." to resolve to 192.168.1.254 and hosts on Network 2 want a query of "gateway." to resolve to 192.168.2.254.
Okay.
So this is currently all achievable through "views" in BIND 9, but requires that the zone data for each view be 98% duplicate (Network 3 resources) and continually copy-n-paste updated whenever names on Network 3 are added.
Yep.
What I am looking for is a way to save the duplicate copying of Network 3 resources to the views for Network 1 and Network 2. This is where the term "overlay" comes in. What I'd like to do is reference a single copy of data from Network 3 in Network 1 and 2's views but "overlay" some view-specific resources on top of that, namely the "gateway." name, with it's per-view specific value.Thoughts?
A couple of things come to mind.1) Do you /need/ the gateway name to resolve exclusively to the single IP of the connected network? Or could you possibly leverage BIND's ability to sort / order responses based on client network? I.e. return the IP in the client's network /first/.
2) Split things into two levels of zones. The first being the common example.net and the second being gateway.example.net. Have the parent delegate gateway. Then have the parent in all three views (possibly via "in-view" that Tony mentioned) and each network's specific gateway.example.net in each respective view. You would simply put the gatteway's IP in the apex of the gateway.example.net zone.
The behavior of #2 would be quite similar to what Bob suggested, but would avoid CNAMEs and just answer with authority directly.
-- 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
