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

[L. Gabriel Somlo]

Mark,

Thanks much for clearing this up ! I get it now -- the lookup
algorighm is opportunistic, and starts below the root if the right NS
records are already in cache. Having stub zones insures that is always
the case -- very cool !

Also thanks to everyone else who responded !
--Gabriel

On Tue, Mar 02, 2010 at 12:36:49PM +1100, Mark Andrews wrote:
> 
> In message <20100302003617.GA27346 at foober.net.cmu.edu>, "L. Gabriel Somlo" writ
> es:
> > 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.
> 
> You don't have to.  You just have a stub zone for each internal namespace.
>  
> > 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.
> 
> Please go re-read what was said in the previous email.  Stub zones do
> what you want if you set them up correctly.
> 
> 	zone "local" {
> 		type stub;
> 		masters { .... };
> 		forwarders { /* empty */ };
> 		file "local.stub";
> 	};
> 
> This is be in all the servers that need to see the "local" namespace and
> are not masters or slaves for "local".
> 
> The master of local should be configured to turn off forwarding for the "local"
> namespace if you are using global forwarders.
> 
> 	zone "local" {
> 		type master;
> 		file "local.db";
> 		forwarders { /* empty */ };
> 		....
> 	};
> 
> The slaves of local should be configured to turn off forwarding for the "local"
> namespace if you are using global forwarders.
> 
> 	zone "local" {
> 		type slave;
> 		masters { .... };
> 		file "local.db";
> 		forwarders { /* empty */ };
> 		....
> 	};
> 
> > 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
> > _______________________________________________
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org