Re: Stub zone vs forward zone
> On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote: > > As a general rule, use "type forward" zones only if you have some > > connectivity issue you need to work around, e.g. trying to resolve > > Internet names from behind a restrictive firewall. On 18.03.11 10:15, Marc Haber wrote: > So, a "type forward" zone is the right thing to do for the reverse DNS > zones of RFC1918 networks that are reachable via a VPN link. I wouldn't say so. You need forward zone, if you: - don't know which servers provide the zone, so you need to query recursive servers - want to fall back to standard resolution if forward servers are unreachable. Otherwise stub or static-stub zones will do what you want. > However, my setup using a "type forward" zone doesn't work, and bind does > not even try querying the forwarders listed in the type forward zone > statement when I try to obtain a PTR record for an IP on these nets. do you have recursion enabled? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. We are but packets in the Internet of life (userfriendly.org) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On 18.03.2011 10:17, Marc Haber wrote:
> Which it doesn't in the "forward" setup, it just immediately returns NXDOMAIN.
Do you include zones.rfc1918 in your configuration? What SOA RR does the
NXDOMAIN return?
| zone "0.10.in-addr.arpa" {
| type forward;
| forwarders { 10.0.0.2; };
| };
|
| include "/etc/bind/zones.rfc1918";
The dummy zone overrides the forward declaration:
| $ dig -x 10.0.0.3
| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59555
|
| ;; AUTHORITY SECTION:
| 10.in-addr.arpa. 86400 IN SOA localhost. root.localhost. 1
604800
86400 2419200 86400
Hauke.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, Mar 14, 2011 at 01:36:10PM +0100, Jan-Piet Mens wrote:
> A stub zone tells BIND to load SOA and NS records from its masters {}.
> (forwarders {} is, I belive, both useless and incorrect here.) From that
> point onwards, your BIND will use the data in the stub to recursively
> find answers to queries for that zone.
>
> The forwarder on the other hand, instructs BIND to forward all queries
> for the zone to the addresses in the forwarders {} list; the target
> server must be prepared and willing to perform recursive lookups on your
> behalf.
In this case, the servers mentioned in the configuration I posted are
both authoritative for the zones that they're query for _and_ willing
to recurse for my bind if it asked them a recursive query. Which it
doesn't in the "forward" setup, it just immediately returns NXDOMAIN.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
Hi,
On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote:
> Stub zones: only available as a single level beyond one's "authoritative
> core", i.e. the stub server must be able to talk directly to one or more
> authoritative servers for the zone.
> Forward zones: can be daisy-chained an arbitrary number of levels from
> the authoritative core (but this is not recommended due to
> manageability, performance and reliability concerns).
>
> Stub zones: will use whatever is in the NS records of the zone (or
> descendants of the zone, if not otherwise defined) to resolve queries
> which are below a zone cut.
> Forward zones: will always use the configured forwarders, which must
> support recursion, even for names which are known to be deeper in the
> delegation hierarchy and whose delegated/authoritative nameservers might
> respond more quickly than the forwarders, if asked.
Thanks for the clarification, I appreciate that.
> As a general rule, use "type forward" zones only if you have some
> connectivity issue you need to work around, e.g. trying to resolve
> Internet names from behind a restrictive firewall.
So, a "type forward" zone is the right thing to do for the reverse DNS
zones of RFC1918 networks that are reachable via a VPN link. However,
my setup using a "type forward" zone doesn't work, and bind does not
even try querying the forwarders listed in the type forward zone
statement when I try to obtain a PTR record for an IP on these nets.
> Use slave zones if you want a full copy of the zone available at all
> times (unless it expires of course), thus maximizing fault-tolerance
> and client-to-resolver performance, but subject to the replication
> overhead, storage space and willingness of the zone owner to allow
> zone transfers. And use stub zones if you want a more lightweight
> alternative to slaving, at the expense of some fault-tolerance and
> client-to-resolver performance.
In my case, my slave could only intermittendly reach the master
servers for the zones, so I'd need to reload these zones quite
frequently to "catch" a time when the VPN tunnel is built. Does a stub
zone use the same mechanism, or will it immediately query for the
stub's NS records when a query comes in and the NS records are no
longer cached?
> To answer your specific question, the non-intuitive[1] "forwarders { };"
> is needed to inhibit forwarding which has presumably been defined at a
> higher level (semantically) in your config, either at the
> 1.10.in-addr.arpa level, or somewhere above that, explicitly, or
> so-called "global forwarding" defined in the "options" clause.
Global forwarders. So they would take precedence over the locally
available delegations for the stub zone?
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
Stub zones: only available as a single level beyond one's "authoritative
core", i.e. the stub server must be able to talk directly to one or more
authoritative servers for the zone.
Forward zones: can be daisy-chained an arbitrary number of levels from
the authoritative core (but this is not recommended due to
manageability, performance and reliability concerns).
Stub zones: will use whatever is in the NS records of the zone (or
descendants of the zone, if not otherwise defined) to resolve queries
which are below a zone cut.
Forward zones: will always use the configured forwarders, which must
support recursion, even for names which are known to be deeper in the
delegation hierarchy and whose delegated/authoritative nameservers might
respond more quickly than the forwarders, if asked.
As a general rule, use "type forward" zones only if you have some
connectivity issue you need to work around, e.g. trying to resolve
Internet names from behind a restrictive firewall. Use slave zones if
you want a full copy of the zone available at all times (unless it
expires of course), thus maximizing fault-tolerance and
client-to-resolver performance, but subject to the replication overhead,
storage space and willingness of the zone owner to allow zone transfers.
And use stub zones if you want a more lightweight alternative to
slaving, at the expense of some fault-tolerance and client-to-resolver
performance.
To answer your specific question, the non-intuitive[1] "forwarders { };"
is needed to inhibit forwarding which has presumably been defined at a
higher level (semantically) in your config, either at the
1.10.in-addr.arpa level, or somewhere above that, explicitly, or
so-called "global forwarding" defined in the "options" clause. By
default, named does not forward, so if those were the only 2 zone
definitions in named.conf, and there was nothing about forwarding in
your "options" clause, then you wouldn't need "forwarders { };" in any
of your zone definitions. You only see that directive in "hybrid"
configs, where forwarding is used at one level of the namespace
hierarchy, and then overridden with regular iterative forwarding at a
lower level.
- Kevin
[1] Personally, I would have preferred a syntax like "forward none" or
something of that nature, but I guess it's water under the bridge at
this point...
On 3/14/2011 6:43 AM, Marc Haber wrote:
Hi,
I am running a local instance of bind on my notebook to spare myself
some rather annoying reconfiguration orgies that are bound to happen
when changing networks.
On my biggest customer's network, I am trying to be able to access
their reverse DNS, which is (don't ask) not loaded on the servers that
my notebook is assigned via DHCP as forwarders.
I have thus configured these zones locally, experimenting with
differnt configuration types:
zone "2.1.10.in-addr.arpa" {
type stub;
masters { 10.1.2.11; 10.1.2.45; };
file "stub/2.1.10.in-addr.arpa";
forwarders { };
};
zone "101.1.10.in-addr.arpa" {
type forward;
forwarders { 10.1.101.6; };
forward only;
};
The stub zone works; the forward zone doesn't. When I ask my local
bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
without bind even trying to talk to the actual name server.
I can ping 10.1.101.6 just fine.
I must admit that I haven't yet full understood the difference between
a stub zone and a forward zone, any why i need the forwarders { } on
the stub zone.
Any hints will be appreciated.
Greetings
Marc
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, 14 Mar 2011, Jan-Piet Mens wrote:
>
> A stub zone tells BIND to load SOA and NS records from its masters {}.
> (forwarders {} is, I belive, both useless and incorrect here.) From that
> point onwards, your BIND will use the data in the stub to recursively
> find answers to queries for that zone.
>
> The forwarder on the other hand, instructs BIND to forward all queries
> for the zone to the addresses in the forwarders {} list; the target
> server must be prepared and willing to perform recursive lookups on your
> behalf.
If I understand correctly, the difference is visible if there are
delegated sub-zones. For a stub zone BIND will follow the NS records to
the delegated zone's authoritative servers; for a forward zone all
sub-domains will use the specified recursive servers in the "forwarders"
clause.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
South Fisher, German Bight: Variable, becoming easterly 3 or 4, increasing 5
or 6. Slight or moderate. Fog banks. Moderate, occasionally very poor.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
In message <20110314104330.ga29...@torres.zugschlus.de>, Marc Haber writes:
> Hi,
>
> I am running a local instance of bind on my notebook to spare myself
> some rather annoying reconfiguration orgies that are bound to happen
> when changing networks.
>
> On my biggest customer's network, I am trying to be able to access
> their reverse DNS, which is (don't ask) not loaded on the servers that
> my notebook is assigned via DHCP as forwarders.
>
> I have thus configured these zones locally, experimenting with
> differnt configuration types:
>
> zone "2.1.10.in-addr.arpa" {
> type stub;
> masters { 10.1.2.11; 10.1.2.45; };
> file "stub/2.1.10.in-addr.arpa";
> forwarders { };
> };
>
> zone "101.1.10.in-addr.arpa" {
> type forward;
> forwarders { 10.1.101.6; };
> forward only;
> };
>
> The stub zone works; the forward zone doesn't. When I ask my local
> bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
> without bind even trying to talk to the actual name server.
>
> I can ping 10.1.101.6 just fine.
>
> I must admit that I haven't yet full understood the difference between
> a stub zone and a forward zone, any why i need the forwarders { } on
> the stub zone.
The empty forwarders clause turns off the enclosing/global forwarders.
> Any hints will be appreciated.
>
> Greetings
> Marc
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
> Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
> ___
> 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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
Marc,
A stub zone tells BIND to load SOA and NS records from its masters {}.
(forwarders {} is, I belive, both useless and incorrect here.) From that
point onwards, your BIND will use the data in the stub to recursively
find answers to queries for that zone.
The forwarder on the other hand, instructs BIND to forward all queries
for the zone to the addresses in the forwarders {} list; the target
server must be prepared and willing to perform recursive lookups on your
behalf.
-JP
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
