In article <mailman.682.1267490202.21153.bind-us...@lists.isc.org>, "L. Gabriel Somlo" <gso...@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, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
