Re: NOTIFY from masters when slave provides several views
Let me clarify - for a zone in more than one of the views, that zone's
data doesn't vary by zone. The internal view has some zones not found
in the customer or external views.
This sounds like a job for the allow-query option in the zone statements.
I should have mentioned that I tried that, but got:
option 'allow-query' is not allowed in 'forward' zone 'xxx.yyy.com'
In fact, that's what forced me into views in the first place.
Also, the external view doesn't provide recursion, while the customer
and internal ones do.
And this is a job for allow-query and allow-query-cache.
What's the deal with allow-query? I did some lookups from a host on an
outside net (not in either the internal or customer views) and the server
answered queries for the zones it hosted regardless of whether it was set
to allow-query { internal; customer; }; or allow-query { any; };.
Terry Kennedy http://www.tmk.com
te...@tmk.com New York, NY USA
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY from masters when slave provides several views
In article gqq1nm$2tc...@sf1.isc.org, terry+bindus...@tmk.com wrote:
Let me clarify - for a zone in more than one of the views, that zone's
data doesn't vary by zone. The internal view has some zones not found
in the customer or external views.
This sounds like a job for the allow-query option in the zone statements.
I should have mentioned that I tried that, but got:
option 'allow-query' is not allowed in 'forward' zone 'xxx.yyy.com'
In fact, that's what forced me into views in the first place.
Since forwarding is part of recursion, this will be handled by the
allow-recursion global option.
Also, the external view doesn't provide recursion, while the customer
and internal ones do.
And this is a job for allow-query and allow-query-cache.
Sorry, I meant allow-recursion there.
What's the deal with allow-query? I did some lookups from a host on an
outside net (not in either the internal or customer views) and the server
answered queries for the zones it hosted regardless of whether it was set
to allow-query { internal; customer; }; or allow-query { any; };.
Do you still have views configured? I think the view options override
the global options.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY from masters when slave provides several views
On Fri, 2009-03-27 at 23:48 -0400, Terry Kennedy wrote:
If you can describe how to handle the recursion issue without using
views or multiple DNS servers, I'd be very interested.
Perhaps
allow-recursion { address_match_list };
would meet your needs. See section 6 of the ARM.
/Niall
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY from masters when slave provides several views
On Thu, 2009-03-26 at 19:46 -0400, terry+bindus...@tmk.com wrote: Importantly, neither the masters nor ns1/2/3 have different zone data in different views - the answers are always the same. If you don't have different zone data per view, I don't understand what purpose the views serve, that could not be met using other configuration options. From what you describe, they seem to be getting in the way. /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY from masters when slave provides several views
niall.orei...@ucd.ie wrote: On Thu, 2009-03-26 at 19:46 -0400, terry+bindus...@tmk.com wrote: Importantly, neither the masters nor ns1/2/3 have different zone data in different views - the answers are always the same. If you don't have different zone data per view, I don't understand what purpose the views serve, that could not be met using other configuration options. From what you describe, they seem to be getting in the way. Let me clarify - for a zone in more than one of the views, that zone's data doesn't vary by zone. The internal view has some zones not found in the customer or external views. Also, the external view doesn't provide recursion, while the customer and internal ones do. If you can describe how to handle the recursion issue without using views or multiple DNS servers, I'd be very interested. Terry Kennedy http://www.tmk.com te...@tmk.com New York, NY USA ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY from masters when slave provides several views
Hi Terry,
Each view has to be independently notified if an update takes place.
/Jonathan
On Thu, Mar 26, 2009 at 4:46 PM, terry+bindus...@tmk.com wrote:
This question is related to the prior Internal and External view on same
slave server? - RESOLVED thread, but seems to be a different situation in
which the previous answer doesn't apply.
I have 3 nameservers, which we'll call ns1, ns2, and ns3. These servers
are primarily slave servers for stealth master servers (that last part
shouldn't really matter).
ns1, ns2, and ns3 operate with three views each - internal, customer, and
external. Internal is for the ISP's infrastructure systems, customer is for
customers (and allows recursion), and external is for the rest of the net
(no recursion, just authoritative answers for the zones it serves).
The master servers can be in address ranges covered by any of those views
as well - the ISP's own zones come from a server in the internal view, most
customer zones come from servers in the customer view, with a few coming
from servers in the external view.
Importantly, neither the masters nor ns1/2/3 have different zone data in
different views - the answers are always the same.
As an example, if ns1 gets a NOTIFY for a slave zone from a master in an
address covered by the customer view, it will do an xfer of the zone, but
only for ns1's customer view. The internal and external views won't trans-
fer until the expiry/refresh time for the zone fires.
Also important is that there are a *lot* of zones, and they all live in
an external include file (which, itself, is a collection of smaller include
files), which are all auto-generated from an external database. So it would
be very difficult to change that. Also, most of the masters are on customer
systems with a variety of nameserver versions, and asking them to add addit-
ional IP addresses (or indeed, make any changes at all) would also be very
difficult.
What I'd like is some way to tell BIND that if it gets a NOTIFY for a
zone, it should transfer that zone for all views, not just the matching
view.
The BIND versions in use are 9.6.0-P1 and 9.6.1b1.
Here's a censored example of the relevant parts of the named.conf file:
// The internal view allows everything
view internal in {
match-clients { internal; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
// Root hints
//
zone . {
type hint;
file named.root;
};
// snip... (internal-only zones removed from example)
// Customer zones
//
include includes.conf;
};
// The customer view allows everything too, but has a different nane for
// statistics gathering purposes, and might have restrictions added later
view customer in {
match-clients { customer; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
// Root hints
//
zone . {
type hint;
file named.root;
};
// Customer zones
//
include includes.conf;
};
// The external view allows queries of zones we serve, but not recursion
view external in {
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
// Root hints
//
zone . {
type hint;
file named.root;
};
// Customer zones
//
include includes.conf;
};
Terry Kennedy http://www.tmk.com
te...@tmk.com New York, NY USA
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
