Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: multiple internal views not working (requested conf files

1 view
Skip to first unread message

Krash, Paul

unread,
Nov 2, 2009, 4:38:45 PM11/2/09
to bind-...@lists.isc.org
Kevin Darcy asked:

>Confused. Looks like the clients are matching the
>correct view, but "fckd.net" is not defined in either view,
> so what exactly was the point of having views? fckd.net names are
>going to get resolved the same regardless.

I attempted to obfuscate our internal domain name, Mr. Reed caught it.
fckd.net is the imaginary name of the segment I am serving.

Sorry for the confusion, too many balls in the air today
(some are on the floor :-)

what I understand that this:
________________________________________________________________
view dot5 {
match-clients {
10.x.5.0/24;
};
zone "5.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.19.5.default.rev";
};
zone "fckd.net" {
type master;
file "/etc/bind/fckd.net.default.dot5";
notify yes;
also-notify {
10.x.1.32;
};
};
};
_________________________________________________________

will serve one zone to .5 network only.

While this:

----------------------------------------------------------------

view internal {

match-clients {
!10.x.5.0/24;
10.x.x.0/16
};
zone "fckd.net" {
type master;
file "/etc/bind/fckd.net.default";
notify yes;
also-notify {
10.x.1.32;
};
};
---------------------------------------------------------------

will serve a different zone file to the rest of the 10.x.x.0/16 network.

I think I am close to resolving this, back to integration of Samba+NFS+
NIS+LDAP+DHCP+DNS+Kerberos w/Active Directory 2008, without third party
plugins and helpers.....(*long* term project)....[sigh]

PKrash

This e-mail and any documents accompanying it may contain legally privileged and/or confidential information belonging to Exegy, Inc. Such information may be protected from disclosure by law. The information is intended for use by only the addressee. If you are not the intended recipient, you are hereby notified that any disclosure or use of the information is strictly prohibited. If you have received this e-mail in error, please immediately contact the sender by e-mail or phone regarding instructions for return or destruction and do not use or disclose the content to others.

Kevin Darcy

unread,
Nov 2, 2009, 4:50:39 PM11/2/09
to bind-...@lists.isc.org
Krash, Paul wrote:
> Kevin Darcy asked:
>
>
>> Confused. Looks like the clients are matching the
>> correct view, but "fckd.net" is not defined in either view,
>> so what exactly was the point of having views? fckd.net names are
>> going to get resolved the same regardless.
>>
>
> I attempted to obfuscate our internal domain name, Mr. Reed caught it.
> fckd.net is the imaginary name of the segment I am serving.
>
Ah, OK. But now that the real domain name has been "outed", is there any
point in trying to obfuscate it?
Views are matched in order, so "!10.x.5.0/24;" is redundant -- anything
in that range would have been matched by the previous view.

Also, if 10.x/16 matches your entire community of clients you could just
use "any" for the second view.


> I think I am close to resolving this, back to integration of Samba+NFS+
> NIS+LDAP+DHCP+DNS+Kerberos w/Active Directory 2008, without third party
> plugins and helpers.....(*long* term project)....[sigh]
>

Make sure to publish a quick 3-step setup guide once you're done with
that :-)

- Kevin

Alan Clegg

unread,
Nov 2, 2009, 4:58:14 PM11/2/09
to bind-...@lists.isc.org
Kevin Darcy wrote:

> Views are matched in order, so "!10.x.5.0/24;" is redundant -- anything
> in that range would have been matched by the previous view.

But, but by explicitly putting it there, the ordering of the views is
no-longer important. "Better safe than sorry".

AlanC

Kevin Darcy

unread,
Nov 2, 2009, 6:11:21 PM11/2/09
to bind-...@lists.isc.org
If I were inclined to rearrange views on a whim, then maybe I'd think
more highly of the value of "view portability".

But the typical view-based config I've ever dealt with had one or more
views matching specific ranges and/or TSIG keys, followed by an
"any"-matching view at the end. Such a structure is inherently
sequential and does not lend itself to rearrangement.

I'm also wary of declaring the same range in multiple match lists (once
asserted, then negated everywhere else), since that means if the numeric
value of the range changes, you have multiple places to update, and you
could miss one.

- Kevin

0 new messages