Re: securing bind in todays hostile environment

[N. Max Pierson]

Ah, allow me to apologize then. Since I did not see any mention as to why you 
possibly didn’t think ansible would serve us well for this job I had wrongly 
assumed you to had maybe demo’d or just got handed the task of automating in 
your organization and didn’t have time to research or test it before go live, 
causing a bad experience from it possibly. 

The idea for ansible in this case would be to simply manage the zones for us on 
record changes which allowed me to come up with a front end so our customers 
would have self service for the ones that do not pay us to manage their zone 
for them. Trying not to have to re-invent the wheel and write some sort of API 
that did some sort of regex nightmare in shell against the zones, etc for 
simple changes. I can much more easily write a form that generates YML I need 
with the data. The next step is to actually interface with ansible at the API 
level to remove the having to generate YML and run cli commands all together, 
but I’m only one person and coding isn’t even more area of expertise, so in 
time lol.

Yes I have been a part of that same boat a few times myself elsewhere but 
fortunately where I am now, they seem to understand if I make them more money, 
it has to work both ways. They agreed so the arrangement is working quite well 
and I appreciate the remark. 

regards,
m

> On Jan 19, 2020, at 2:01 PM, John W. Blue  wrote:
> 
> Since it sounds like you have not had much experience with, I urge you to 
> check it out should you have anything in your environment that could benefit 
> from automation. Simply telling someone to chunk it and not have any 
> experience with it is a little misguided IMO.
>  
> We pay multiple different teams to play in the ansible, docker, kubernetes et 
> al sandbox so, yeah, I admittedly do *need* to have much experience.  My 
> comments are not an indictment against ansible itself because I observe it 
> being used to create basic servers on a regular basis.  It does a fantastic 
> job.  Rather I was questioning the use of ansible to specifically deploy DNS 
> servers.
> 
> Since you updated your comments to mention that you all are selling DNS 
> services, the choice of ansible now makes more sense.
> 
> I've worked in the MSP space in the past and my general observation is that 
> it is a sweat shop with no loyalty in a race to the bottom of how low of a 
> salary they can get away with paying.  I genuinely hope your experience will 
> be different.
> 
> John
> 
> Sent from Nine 
> 
> 
> ___
> 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

___
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

Re: securing bind in todays hostile environment

[N. Max Pierson]

My terminology seems to be the issue here, so let me try and rephrase/elaborate 
: )

> I'm sure that you can get Ansible to add / remove / modify the list of zones 
> on the slave servers.  But is that the best solution when BIND has something 
> built in for doing the same thing?

I was not aware there was anything built in that would let you 
add/remove/change the zone itself from the master. Is this feature basically 
some sort of named.conf synchronization utility? The current setup needs to be 
touched should a new zone need to be added or removed today.

> At least I would evaluate if it's reasonably possible to do. Is the added 
> complexity of NAT /required/ -> /needed/ -> /desired/?

It’s certainly not required and not really wanted personally but having the 
master with a public IP (doing a no nat for that host in the FW policy) on the 
inside would be a snowflake as everything else has RFC1918 on it behind the 
firewall (IPv4 that is). Not that that’s a deal breaker, I just would have to 
get sign-off from others. The reason I had for having it in the DMZ is so that 
one would have to penetrate the FW to get to the master for any changes to be 
made. And this FW would next-gen with for high level of scrutiny which IPtables 
can’t give. 

> I'm failing to understand why the /reverse/ zones have more security than 
> /other/ zones.

So all of the slaves would be answering for public/external domains. No 
internal will exist on them nor the master. Very simple setup without any views 
currently, so the slaves are copies of the master. Forward and reverse would be 
treated the same, sorry if I mis-spoke.

> I would still expect the scope of access to be the same for forward and 
> reverse zones.

See previous. I think what I meant to say was that the recursive servers be 
locked down via ACL at 2 different layers. Not the authoritative, again my 
apologies.

Thanks for the quick and dirty on RPZ. I knew what it was and how it works 
somewhat but was not aware the scope of the vars and functions that act upon 
them to be so flexible. The functions allow me to return/manipulate the 
response at what seems like a pretty granular level. I need to read up on 
exactly what each response does in totality but I get a good guess from their 
name/description. 

Again I appreciate the detail in your response. It makes me feel a little 
better about managing our own instances versus handing it off to some other 
cloud provider. 

Regards,
m

> On Jan 19, 2020, at 11:23 AM, Grant Taylor via bind-users 
>  wrote:
> 
> On 1/19/20 3:25 AM, N. Max Pierson wrote:
>> Hi Grant,
> 
> Hi,
> 
>> I should have been a little more descriptive in the scenario by giving the 
>> purpose of these name servers. They are basically being deployed as a 
>> managed DNS service that we offer. We are a MSP for the most part and the 
>> DNS infrastructure was not being very well maintained when I got here. 
>> Knowing that and the fact we sell this as a service, it needs more attention 
>> that it has gotten in the past plus someone with more knowledge than the 
>> ones that originally set them up. Having that said, I have my work cut out 
>> for me.
> 
> Fair enough.
> 
> With that in mind, I'm speculating that the list of zones (in scope) will be 
> somewhat dynamic.  As such, I *STRONGLY* encourage you to take a look at 
> catalog zones.
> 
> I'm sure that you can get Ansible to add / remove / modify the list of zones 
> on the slave servers.  But is that the best solution when BIND has something 
> built in for doing the same thing?
> 
>> We do not use dynamic entries and as far as the hidden/shadow master, I do 
>> not have an issue with the master being on the public segment and part of 
>> the NS records. I was thinking of simply poking a hole in the firewall to a 
>> static NAT for the master (restricted by the slave IPs) so that it could be 
>> contacted from the outside. I would have the master in the DMZ. Since this 
>> isn’t being used for any internal name services, I guess it may not make 
>> much sense to have it in the DMZ.
> 
> If the master is functionally identical to the slaves, save for the master vs 
> slave configuration, then it probably can live with the slaves.  However, if 
> the master has any other data / configuration / internal DB access / etc, I 
> would recommend that it be separated.
> 
> I like to think of slave servers in the DMZ as a line of defense for the 
> master.  Sometimes it's appropriate, sometimes it isn't.
> 
> I don't know your network topology.  But I'd be tempted to see if I could use 
> standard routing in lieu of NAT between the slaves and the master.  At least 
> I would evaluate if it's reasonably possible to do. Is the added complexity 
> of NAT /required/ -> /needed/ -> /desired/?  The same questions should be 
> asked about routing, and chose the appropriate answer.
> 
>> Paranoia I guess lol.
> 
> Hum.
> 
> I'm failing to understand why the /reverse/ zones have more security 

RE: Slow recursive query performance on Windows x64

[Steve Farr via bind-users]

... And please don't misunderstand; I'm not asking you to debug my network. 
There are actually two parts here, one is what the clients are/n't doing with 
the  responses they receive, and that's sort of beside the point and came 
up incidentally, They aren't really experiencing any issues or problems just 
from the fact that they get  responses; it was mostly just wishful thinking 
in the sense of "why give them responses they don't need and can't ever use?" 
No machines on this network have IPv6 default routes in their routing tables. 
I'm not trying to argue with you or make a stink about it. Hopefully I didn't 
come across that way.

But setting that aside, on the BIND server itself, IPv6 is not bound on any NIC 
(only the built-in Windows ISATAP adapter which is unsupported to disable), and 
the IPv6 routing table does not contain any routes at all except for ::1/128 
and ff00::/8  -  so that's why it was puzzling to me that it BIND would still 
try to use IPv6 for outbound queries, especially when started with the -4 flag. 
The response you get back from trying to ping any (ipv6) host in an unreachable 
network in this situation (on a Windows kernel) is not an ICMP Unreachable, but 
rather a "Transmit Failed: General Failure" which doesn't show up anywhere in a 
packet trace, even on the loopback adapter. If BIND is looking for the ICMP 
message specifically to decide whether IPv6 is go or no-go, perhaps it's not 
perceiving that General Failure means "don't keep trying this, it will never 
work" so it's still waiting for the timeout. I'm not saying you have to chase 
this down, just pointing out that this seems (to me) to be unexpected behavior 
on a standard-configuration Windows host system in an IPv4-only network.

-Steve


-Original Message-
From: Ondrej Sur� 
Sent: Monday, January 20, 2020 9:37 AM
To: Steve Farr 
Cc: bind-users@lists.isc.org
Subject: Re: Slow recursive query performance on Windows x64

The problem is that apparently[*] the machines in your network have default 
IPv6 routes, but you don t have IPv6 connectivity. Fix that and you don t have 
to apply any bandaids. I think we should just remove filter- in the next 
release cycle of BIND 9, having the feature doesn t do any good for the health 
of the Internet.

* - Normally, the ICMP unreachables are generated by local kernel, and based on 
the evidences you provided (timeouts) it doesn t, so something is misconfigured 
either in your network or on that particular machine. Debugging your network is 
beyond the scope of this mailing list.

Ondrej
--
Ondrej SurISC

> On 20 Jan 2020, at 15:19, Steve Farr via bind-users 
>  wrote:
> 
> ?Yeah, it's hard to disagree on the "should" part but we all definitely have 
> to administer networks in an imperfect world... To my mind, when there's zero 
> ipv6 connectivity beyond the LAN, it would be handy to not ask the firewall 
> to create 3x more TCP connections that it can never complete, and/or have it 
> send unreachables for all of them, especially on a larger network, so I would 
> suggest that even if it is "wrong," filter--on-v4 is probably still 
> "helpful" in some situations, particularly where v6 is not available. The 
> network that I originally posted about is small, but I administer a number of 
> larger ones and this has been very eye-opening, so I do thank you all for 
> your contributions to the conversation. 
> 
> It looks like I'd have to compile the filter plugin separately on Windows 
> since it's not already integrated, and I don't see a dll or exe for it in the 
> bin folder... That's all right though; I'm just glad to have the query times 
> be so much quicker now! 
> 
> In case it's useful for anyone to know, I did just now try running named with 
> the -4 option, taking out the server ::/0 { bogus yes; }; and it still has 
> the same delay problem, so it appears that even with -4 it's still trying to 
> do something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes; 
> }; is still the fix... at least on Windows, anyway. Many thanks again to all 
> of you for the insightful responses. 
> 
> -Steve
> 
> -Original Message-
> From: bind-users  On Behalf Of Mark 
> Andrews
> Sent: Monday, January 20, 2020 1:45 AM
> To: Lee
> Cc: Ondrej Sury
> Subject: Re: Slow recursive query performance on Windows x64
> 
> Devices should return ICMP unreachables when networks are not reachable.  
> This allows applications to move onto the next address.  Not returning 
> unreachables results in timeouts being the mechanism to move to the next 
> address.
> 
> Additionally applications can make parallel connection attempts.  This works 
> particularly well for TCP and is what Happy Eyeballs does with a slight delay 
> (sub second) between each different address. Once a TCP connection succeeds 
> the other connection attempts are aborted.  Too many developers have coped 
> out on providing fast multi-homing support.  It usually only takes 

Re: Slow recursive query performance on Windows x64

[Ondřej Surý]

The problem is that apparently[*] the machines in your network have default 
IPv6 routes, but you don’t have IPv6 connectivity. Fix that and you don’t have 
to apply any bandaids. I think we should just remove filter- in the next 
release cycle of BIND 9, having the feature doesn’t do any good for the health 
of the Internet.

* - Normally, the ICMP unreachables are generated by local kernel, and based on 
the evidences you provided (timeouts) it doesn’t, so something is misconfigured 
either in your network or on that particular machine. Debugging your network is 
beyond the scope of this mailing list.

Ondřej 
--
Ondřej Surý — ISC

> On 20 Jan 2020, at 15:19, Steve Farr via bind-users 
>  wrote:
> 
> Yeah, it's hard to disagree on the "should" part but we all definitely have 
> to administer networks in an imperfect world... To my mind, when there's zero 
> ipv6 connectivity beyond the LAN, it would be handy to not ask the firewall 
> to create 3x more TCP connections that it can never complete, and/or have it 
> send unreachables for all of them, especially on a larger network, so I would 
> suggest that even if it is "wrong," filter--on-v4 is probably still 
> "helpful" in some situations, particularly where v6 is not available. The 
> network that I originally posted about is small, but I administer a number of 
> larger ones and this has been very eye-opening, so I do thank you all for 
> your contributions to the conversation. 
> 
> It looks like I'd have to compile the filter plugin separately on Windows 
> since it's not already integrated, and I don't see a dll or exe for it in the 
> bin folder... That's all right though; I'm just glad to have the query times 
> be so much quicker now! 
> 
> In case it's useful for anyone to know, I did just now try running named with 
> the -4 option, taking out the server ::/0 { bogus yes; }; and it still has 
> the same delay problem, so it appears that even with -4 it's still trying to 
> do something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes; 
> }; is still the fix... at least on Windows, anyway. Many thanks again to all 
> of you for the insightful responses. 
> 
> -Steve
> 
> -Original Message-
> From: bind-users  On Behalf Of Mark Andrews
> Sent: Monday, January 20, 2020 1:45 AM
> To: Lee 
> Cc: Ondrej Sury 
> Subject: Re: Slow recursive query performance on Windows x64
> 
> Devices should return ICMP unreachables when networks are not reachable.  
> This allows applications to move onto the next address.  Not returning 
> unreachables results in timeouts being the mechanism to move to the next 
> address.
> 
> Additionally applications can make parallel connection attempts.  This works 
> particularly well for TCP and is what Happy Eyeballs does with a slight delay 
> (sub second) between each different address. Once a TCP connection succeeds 
> the other connection attempts are aborted.  Too many developers have coped 
> out on providing fast multi-homing support.  It usually only takes small 
> while to convert a application from serial connection attempts to parallel 
> connection attempts to the addresses returned from getaddrinfo().  What s 
> more work is adding MIF (multiple interface) support which allows you to try 
> different source addresses as well.
> 
> Mark
> 
>> On 20 Jan 2020, at 17:16, Lee  wrote:
>> 
>>> On 1/20/20, Ondrej Sur   wrote:
>>> 
>>> Please note that filter--on-v4 was always wrong.
>> 
>> how so?
>> 
>>> You should fix your network instead. It s a bandaid, not a fix.
>> 
>> My ISP doesn't offer ipv6, so I'm not sure how to fix my network..
>> unless you mean disable ipv6 on everything?  (which I'm not sure is 
>> even possible)
>> 
>> Lee
>> ___
>> 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
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> 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
> 
> 
> ___
> 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

___
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

Re: "overlay" views

[Bob Harold]

On Mon, Jan 20, 2020 at 8: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.
>
> 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.
>
> 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.
>
> 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?
>
> b.
>
>
What I have set up, is for the few names that need to be different, use
CNAME to a zone that is different in each view:

This zone is same in all views:
zone example.com
host1.example.com  IN  A  10.0.0.4
host2.example.com  IN  A  10.1.1.7
router.example.com  CNAME router.splitview.example.com

Then in one view:
zone splitview.example.com
router.splitview.example.com  IN A 10.0.0.1

And the other view:
zone splitview.example.com
router.splitview.example.com  IN  A 10.1.1.1

Any downsides that I have not thought about?

-- 
Bob Harold
___
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

RE: Slow recursive query performance on Windows x64

[Steve Farr via bind-users]

Yeah, it's hard to disagree on the "should" part but we all definitely have to 
administer networks in an imperfect world... To my mind, when there's zero ipv6 
connectivity beyond the LAN, it would be handy to not ask the firewall to 
create 3x more TCP connections that it can never complete, and/or have it send 
unreachables for all of them, especially on a larger network, so I would 
suggest that even if it is "wrong," filter--on-v4 is probably still 
"helpful" in some situations, particularly where v6 is not available. The 
network that I originally posted about is small, but I administer a number of 
larger ones and this has been very eye-opening, so I do thank you all for your 
contributions to the conversation. 

It looks like I'd have to compile the filter plugin separately on Windows since 
it's not already integrated, and I don't see a dll or exe for it in the bin 
folder... That's all right though; I'm just glad to have the query times be so 
much quicker now! 

In case it's useful for anyone to know, I did just now try running named with 
the -4 option, taking out the server ::/0 { bogus yes; }; and it still has the 
same delay problem, so it appears that even with -4 it's still trying to do 
something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes; }; is 
still the fix... at least on Windows, anyway. Many thanks again to all of you 
for the insightful responses. 

-Steve

-Original Message-
From: bind-users  On Behalf Of Mark Andrews
Sent: Monday, January 20, 2020 1:45 AM
To: Lee 
Cc: Ondrej Sury 
Subject: Re: Slow recursive query performance on Windows x64

Devices should return ICMP unreachables when networks are not reachable.  This 
allows applications to move onto the next address.  Not returning unreachables 
results in timeouts being the mechanism to move to the next address.

Additionally applications can make parallel connection attempts.  This works 
particularly well for TCP and is what Happy Eyeballs does with a slight delay 
(sub second) between each different address. Once a TCP connection succeeds the 
other connection attempts are aborted.  Too many developers have coped out on 
providing fast multi-homing support.  It usually only takes small while to 
convert a application from serial connection attempts to parallel connection 
attempts to the addresses returned from getaddrinfo().  What s more work is 
adding MIF (multiple interface) support which allows you to try different 
source addresses as well.

Mark

> On 20 Jan 2020, at 17:16, Lee  wrote:
> 
> On 1/20/20, Ondrej Sur   wrote:
>> 
>> Please note that filter--on-v4 was always wrong.
> 
> how so?
> 
>> You should fix your network instead. It s a bandaid, not a fix.
> 
> My ISP doesn't offer ipv6, so I'm not sure how to fix my network..
> unless you mean disable ipv6 on everything?  (which I'm not sure is 
> even possible)
> 
> Lee
> ___
> 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

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
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


___
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

Re: "overlay" views

[Tony Finch]

Brian J. Murrell  wrote:
>
> 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.

This is a strange requirement. It sounds to me like you have dug yourself
into a hole made of unwise decisions and you'd be better off revisiting
them rather than solving the immediate problem.

> 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.

Use "in-view" zones for the shared data, and view-specific zones for the
data that differs.

On our authoritative servers we have a "main" view which has all the zones
configured in the usual way, and an "external" view which refers to the
public zones using "in-view main". Our internal zone private.cam.ac.uk is
configured in the external view with a static empty zone file to return
NXDOMAIN to errant queries, because using an ACL to return REFUSED causes
problems with query retries and CAA lookup failures, amongst other things.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Mull of Kintyre to Ardnamurchan Point: Westerly or southwesterly, 6 or 7 until
later north and west of Islay, otherwise 4 or 5. Moderate or rough,
occasionally very rough from Islay northwards. Occasional rain or drizzle.
Moderate or good, occasionally poor.
___
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

"overlay" views

[Brian J. Murrell]

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.

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.

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.

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?

b.



signature.asc
Description: This is a digitally signed message part
___
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