Is 10.in-addr.arpa not recommended?
chris.p.buxton at gmail.com
Mon Sep 27 23:09:44 UTC 2010
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.
> 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.)
>> Chris Buxton
>> BlueCat Networks
>> bind-users mailing list
>> bind-users at lists.isc.org
> Best regards
> Sten Carlsen
> No improvements come from shouting:
> "MALE BOVINE MANURE!!!"
> bind-users mailing list
> bind-users at lists.isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users