"overlay" views

[Grant Taylor]

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

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