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

[L. Gabriel Somlo]

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 it's a bad idea, could anyone please explain *why* ? 
(I wouldn't mind spending a few days/weeks/whatever on trying to cook
up a patch, but I'd hate to waste time if there's a good reason the
bind folks hate the idea behind it :) )

Thanks,
--Gabriel