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

[Mark Andrews]

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