Re: forwarding rfc1918 queries, stub zones

On 2004-02-02, Kevin Darcy <kcd@daimlerchrysler.com> wrote:
> Will Yardley wrote:

[ Thanks for the long response. My head is still spinning, but doing my
best to digest all of that. ]

>> Maybe a FAQ, but what's the simplest way (if you have a split
>> caching-only / authoritative setup) to forward queries for rfc1918
>> reverse lookups to the authoritative machine? Can I just setup a stub
>> zone for 10.in-addr.arpa. and forward all those queries to the
>> authoritative nameservers (even if the zones we're running are actually
>> more specific)?
>>
>> Also, what should the "master" of a stub zone be set to - the server
>> it's forwarding queries to?

> Set up a 10.in-addr.arpa on a master. For redundancy, have one or more
> other nameservers be published slaves for the zone.

The problem (and I realize that this is somewhat specific to our
situation, perhaps), is that our DNS zones are all generated
automagically (by our system), and it generates separate zone files for
each /24 we're using in rfc1918 space.

For example, say I have 34.3.10.in-addr.arpa. and 35.3.10.in-addr.arpa.
setup on our master authoritative nameserver and 2 slaves. However, I
don't want to have to make any special changes I were to add
36.3.10.in-addr.arpa. or even 10.3.10.in-addr.arpa... other than adding
those zones themeslves. Could I just create 10.in-addr.arpa. and do a
wildcard delegation -- something like this:

$ORIGIN 10.in-addr.arpa.
* IN NS ns1.example.com.
IN NS ns2.example.com.
IN NS ns3.example.com.

Or (as below), would forwarding the whole 10.in-addr.arpa. zone to
ns{1-3}.example.com Just Work without setting up 10.in-addr.arpa. at all
on those machines (provided zones for any 10 block IPs we're actually
using are setup individually, and are all setup on the same 3 machines)?

> b) define all of the descendant zones as slave zones (which can be a
> maintenance nightmare, you might not be able to do zone transfers of
> all of those zones, or it would use up too much bandwidth)

Right - in this case, it would probably be a management headache since
the zones on the authoritative servers (master and slave) are all
managed by machine, and (currently), the caching-only machines are
managed by hand - thus I'm trying to keep the config on these as simple
as possible, and the number of slave zones to a minimum.

> or c) define 10.in-addr.arpa itself as a "type forward" zone, pointing
> to alternate forwarders which can resolve all names in that part of
> the namespace (just be sure these alternate forwarders either honor
> recursion or are authoritative for all of the descendant zones as in
> (b) above).

This is my preferred solution (see above) - except that I'd forward to
the 3 authoritative nameservers which already serve the various 10 net
zones.

--
No copies, please.
To reply privately, simply reply; don't remove anything.