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
http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones
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
complications.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
