While a single zone is perfectly fine from a standards point of view, "some" clients might be served addresses they don't like 10.x.x.0 and 10.x.x.255.
Just a reminder that this could be a reason if something appears weird. On 27/09/10 23:07, Chris Buxton wrote: > On Sep 27, 2010, at 1:03 PM, Christopher Cain wrote: > >> Hi all. >> >> I am setting up a new appliance-based DNS solution that will contain a fair >> number of separately managed Windows DNS slave servers (in addition to the >> DNS appliances that will handle the . >> >> Currently there are just over 8000 host records that resolve to IP's in the >> 10.x.x.x space. I am wrestling with whether or not I should create a single >> 10.in-addr.arpa zone or if I should create 256 /16 zones (i.e. - >> 0.10.in-addr.arpa to 255.10.in-addr.arpa). >> >> The reason I want to encompass the entire 10 space is so new arpa zones will >> not have to be defined on all servers (specifically on the Windows slaves) >> if a new part of the 10 space is used at some point. >> >> Any recommendations or comments would be greatly appreciated. > There's nothing wrong with a single 10.in-addr.arpa zone. If you need to > break it up amongst different master servers, a 10.in-addr.arpa zone can > still be used to delegate child zones to their respective servers. > > You might break it up if, for example, the DDNS traffic from DHCP clients > across the enterprise would be too much for one master server to accommodate. > The BIND name server writes to its journal file synchronously, for every > update, and this can be quite a bottleneck. (The same is true for slave > servers, which keep a journal file for zone transfers in order to service > IXFR requests sent to them.) > > Regards, > Chris Buxton > BlueCat Networks > > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!"
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
