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