kcd at chrysler.com
Tue Sep 29 14:48:11 UTC 2009
Paul Wouters wrote:
> On Tue, 29 Sep 2009, Chris Thompson wrote:
>> What I would like to see is for more reverse zones to go away, by use
>> of the scheme I describe in
> I don't see how moving the reverse into a special forward zone decreases
> management of it. I assume you'd still need to update the records when
> neccessary. The only thing you're reducing might be the use of one DNSSEC
> key for your "reverse mapped" zones in the forward tree.
I didn't read the document as being DNSSEC-focused.
Having the PTR records in the same zone as the corresponding A records
means less zone replication cycles because the forward/reverse records
being changed in any given transaction are in the same zone. On the
in-addr.arpa side, if the number of zones are reduced and/or the
remaining zones have their REFRESH settings relaxed (because they are
pretty much static), one could save on serial-query traffic as well.
For an environment such as ours (4 assigned B-classes, all of the RFC
1918 ranges, remnants of a partial A-class being sundowned from a
previous business arrangement), maintenance and optimization of the
reverse namespace is a serious challenge, even in the absence of DNSSEC
More information about the bind-users