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.ga27...@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@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: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users