On Sep 27, 2010, at 3:55 PM, Sten Carlsen wrote: > 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.
Don't confuse "zone" and "DHCP range". Having a 10/8 reverse zone does not mean you must have an address range that covers these addresses that might confuse users. You wouldn't want a DHCP range (or a network) that large anyway. The broadcast traffic would be a killer. Regards, Chris Buxton BlueCat Networks > 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
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
