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