dig @server foobar +trace +recurse

[Anne Bennett]

Tony Finch <dot at dotat.at> recommends:

>> As for the problem itself, I'll probably fix it by setting up
>> a forwarding zone for my parent zone on my resolvers, to make
>> sure that I always get the internal view for their data.
> 
> Note that the target server of a forward zone should offer recursive
> service.  You will have problems if the target is authoritative-only, and
> serves the zone you are forwarding but not some child zone.

It does offer recursion, but your suggestion is most helpful nevertheless:

> Better to use
> static-stub in that case; that makes BIND do normal iterative resolution
> except it overrides the NS records for just that zone, not its children.

Good point; I want queries for its children (my zones!) to be answered
by my resolvers (which are authoritative for my zones).

> (We make our recursive servers authoritative for our zones to avoid
> problematic dependency cycles - the kind of horror you find out about
> when trying to recover from a power outage.)

Indeed.  Here we're "blessed" with having had a long-duration
(days!) planned power outage lately for major electrical work,
so my careful redundancy planning has been well tested.  :-)
The local resolvers are totally standalone - no dependencies
on directory services, NFS, or anything but the presence of
the local network and power.

Now back to the static-stub zones... reading the ARM, I see that
I cannot use "server-names" because the internal-view servers
for my parent zone are in the zone itself, thus I must use
"server-addresses".  But I'm told that if I specify:

  zone example.com {
    type static-stub;
    allow-query { APPROPRIATE_ACL_HERE };
    server-addresses { 192.0.2.1; 192.0.2.2; };
  };

then the following RR's are internally configured:

  example.com. NS example.com.
  example.com. A 192.0.2.1
  example.com. A 192.0.2.2

But my parent (call it "example.com") *has* an A record;
they use it for their web server, I believe.  Will the above
internally configured A RR not interfere with getting the
correct data for "host -t a example.com"?  Or does the sentence
"These records are internally used to resolve names under the
static-stub zone" imply that they are used *only* for this
purpose, and never leaked out?

I guess I can test that in any case; just being paranoid!

Thanks for your suggestion; static-stub is indeed a better solution.


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
anne at encs.concordia.ca                                    +1 514 848-2424 x2285