BIND - sorting of reverse domain.

Danny Mayer mayer at gis.net
Sat Jul 13 00:53:32 UTC 2002


At 04:03 PM 7/10/02, D. Stussy wrote:

>On 9 Jul 2002, Danny Mayer wrote:
> >At 03:57 AM 7/9/02, D. Stussy wrote:
> >>  Furthermore, the RFC requires an order
> >>for the MEMORY IMAGE, but again, that isn't relevent to the FILE image I
> >>queried
> >>about.
> >
> >RFC's don't care about memory image.  Making such a statement shows that
> >you didn't bother to actually read them.  Memory Image is an implementation
> >detail rightly left to the implementors.
>
>So, algorithic implications made by certain requirements of the RFC's have no
>bearing whatsoever?  I'll agree that it doesn't come straight out and say that
>one must use structure "x", ....

The RFC's make no algorithmic implications.  That's not the role of the RFC's.

> >
> >Noone really cares. The file is written the way it is due to the way the
> >tree is
> >traversed. The file when read back in is read record by record and each 
> one is
> >added to the tree in the appropriate place. What's the real issue?
>
>The fact that if we write it using a different transversal (by a mere
>rearrangment of the existing statements), we can avoid certain performance
>penalties (i.e. having to resort/rebalance the zone) in certain circumstances.
>Since everyone has said that the current traversal order is arbitrary, 
>then one
>order is as good as another.

The traversal order is NOT abitrary as Mark has pointed out several times.
It's the way it is due to DNSSEC requirements, to ensure efficient and
speedy retrieval or records required for DNSSEC.  One order is NOT as
good as another. That's a false assumption on your part.

>   I have given you an alternative order that has an
>efficiency side-effect; a reason to use it over the others.  Is there a good
>reason NOT to use it?

Yes, the traversal order you propose will have a detrimental effect to 
retrieving
the records for DNSSEC.  There are no known benefits to doing what you
propose.

Danny



More information about the bind-users mailing list