Shortcut the lookup algorithm *other* than via 'forward' ?

Barry Margolin barmar at alum.mit.edu
Tue Mar 2 01:15:09 UTC 2010


In article <mailman.682.1267490202.21153.bind-users at lists.isc.org>,
 "L. Gabriel Somlo" <gsomlo at gmail.com> wrote:

> Kevin,
> 
> > For redundancy, you might want to consider slaving ".local" and 
> > "example.com" on the remote servers. Note that you don't need to 
> 
> Thanks for the reply ! I am slaving and/or stubbing some of our zones
> in some instances, and redundancy is not what I was concerned about.
> 
> I am simply looking for a way to avoid repeating what is already
> expressed in the data. E.g. primary-auth-server.example.com is master
> for the zone 'example.local', but not for 'marketing.example.local'.
> In the master zone file for 'example.local', I have
> 
> marketing.example.local NS marketing-auth-svr.example.com
> 
> I'd rather not *also* have to maintain a 'marketing.example.local'
> zone in primary-auth-server's named.conf, be that of type forward,
> slave, or stub.
> 
> When the cache asks primary-auth-server about
> 'www.marketing.example.local', I want to be able to return the
> marketing.example.local NS record and let the cache do its thing.
> 
> As it is now, the cache either starts at the root (and fails, since
> it's looking for something.local), or forwards to primary-auth-server
> (which then must be able to answer the full query, regardless of
> mechanism -- another forward, slave, or stub), or I have to configure
> the cache with specific forwards for each subdomain of example.local
> that is delegated from primary-auth-server, etc.
> 
> Each scenario requires putting in the same information multiple times:
> once as delegation NS records, and then again as explicit
> slave/stub/forward zones in the config file. It is this latter round of
> duplicated information that I'm trying to avoid having to deal with.
> 
> > The "hints" file is a non-starter -- for years now it's been limited to 
> > only containing root-zone-related information.
> 
> Allright, but that was my second question :)
> 
> > > Alternatively, I'd also appreciate any insights into why what I'm
> > > asking for might be a very bad idea and shouldn't be done (or even
> > > supported at all in BIND) ! :)
> 
> And the mechanism itself is of no importance here. I tried adding data
> to the root hints file (which did not work). I also tried a separate
> 'type hint' zone only for 'example.local', which bind told me
> explicitly it's ignoring since it's not '.' :)
> 
> For all I care, it could be a variation of the 'type forward', let's
> call it 'type lean_forward', where the 'lean_forwarders' might just
> return an NS record and not a full result, and the requesting server
> would have the responsibility to continue following up with the NS
> record it received, as though it had started at the root.
> Using 'type hint' just seemed like the most obvious place to start...

If you create a "type forward" zone with an empty forwarders list, that 
will override the global forwarders, and it will follow the NS records 
that it got from the delegation records.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***



More information about the bind-users mailing list