in-addr.arpa zone design
kcd at daimlerchrysler.com
Fri Jan 10 18:32:08 UTC 2003
Graham Turner wrote:
> have posted along these lines couple of months ago but was wondering
> to recall, given an IP schema which uses addresses from the 172.30 /12
> internal range and a 24 bit mask it seems there are two options for design
> of the
> in-addr.arpa zone;
> 1. zone cuts at the 16 bit boundary yielding management of 16 zones
> 2. further zone cuts at the 24 bit boundaries
> the delegation of zones alnog the 24 bit bounaries is NOT an issue given a
> centralised DNS administration.
> was wondering if anyone had a view on the performance aspect of the former
> design in the context of dynamic update.
> the observed behaviour of a w2k clients is that 2 SOA queries are generated
> to locate a SOA record for an update zone against a single query if the
> latter design is implemented. it does not seem to derive from the subnet
> mask a most "likely" zone to update.
> aside - is this behaviour common to other DNS client implementations or just
> MS ??
> it seems to me that there would be a further performance hit if all the
> records are stored in a zone on the 16 bit boundary as compared to a larger
> number of files
> i guess this one would come down to performance of the server but
> nonetheless would be glad for views on what in a lot of cases comes down to
> "good working practice".
I don't see why 2 SOA queries would ever be necessary for a single update. Even
if the name to be updated doesn't exist, then the SOA of the closest enclosing
zone should be returned in the Authority Section of the response to the first
More information about the bind-users