BIND - sorting of reverse domain.

[Andris Kalnozols]

Since this thread has gotten rather large (22 replies at last count),
I'll insert a few quotes before making my point.

Original post:

> D. Stussy <kd6lvw at bde-arc.ampr.org> wrote:
> It appears that BIND (I have version 9.2.1) sorts all its domain
> entries in the files it stores alphabetically ("machine sort order").
> That's fine for the forward domain file where domain/hostnames are
> usually alphabetic.  However, for the reverse domain file, it makes
> more sense to sort it in NUMERICAL value order, thus keeping adjacent
> IP addresses nearer to each other.  (Of course, I don't care what
> named does internally with the zone as a memory image ....)

Selected replies:

> Mark Andrews <mark_andrews at isc.org> replied:
> The order is DNSSEC order.  To support returning signed NXDOMAIN
> responses the namserver needs to know the node that appears
> immediately before the name in the query.  To do this it sorts the
> zone when it loads it into DNSSEC order.  When named writes out the
> zone it just walks the zone which results in records being emitted
> in DNSSEC order.

> > Mark Andrews <mark_andrews at isc.org> replied:
> > BIND 9 sorts in DNSSEC order because it *needs* the zone to be
> > sorted this way to able to find the correct NXT record to be
> > returned with a NXDOMAIN response.
>
> D. Stussy <kd6lvw at bde-arc.ampr.org> wrote:
> Perhaps in the current implementation, but such need not be the case.

> D. Stussy <kd6lvw at bde-arc.ampr.org> wrote:
> If true, then it must actively sort the zone file in order for
> it to be written out in alphabetical order (which is occuring
> with this version).  It is obviously bothering to take the time
> to do this, so while we're at it, why not write out the reverse
> domain files in numerical order where possible?  [We're back to
> my original question!]

> D. Stussy <kd6lvw at bde-arc.ampr.org> wrote:
> ...How the RR records are ordered for a zone name is of no
> consequence whatsoever when determining whether or not the
> name EXISTS or not.  I couldn't care less about that - it is
> not relevent to the original question.
>
> My question was not one of how it IS coded - but one of how
> it MAY be coded.  How the current source code is actually
> written isn't of consequence because if the preference I asked
> about were to be accepted, the source program would have to be
> changed anyway.
>
> You all are too worried about the actual implementation while
> I'm talking about conceptual design - a separate step.

After reading your comments, I get the distinct impression that
when DNSSEC is mentioned, you are not making the connection to
RFC-2535, the specification that implements it.  Here's what it
requires as a sort order:

  8.2 Canonical DNS Name Order

    For purposes of DNS security, the canonical ordering of owner names
    is to sort individual labels as unsigned left justified octet strings
    where the absence of a octet sorts before a zero value octet and
    upper case letters are treated as lower case letters.  Names in a
    zone are sorted by sorting on the highest level label and then,
    within those names with the same highest level label by the next
    lower label, etc. down to leaf node labels.  Within a zone, the zone
    name itself always exists and all other names are the zone name with
    some prefix of lower level labels.  Thus the zone name itself always
    sorts first.

    Example:
          foo.example
          a.foo.example
          yljkjljk.a.foo.example
          Z.a.foo.example
          zABC.a.FOO.EXAMPLE
          z.foo.example
          *.z.foo.example
          \200.z.foo.example

Since BIND 9 strives for strict compliance with IETF standards,
changing the internal sort order when a zone is loaded is not
an option if DNSSEC is to be implemented efficiently.

To implement what you are asking means that the code for writing
out a zone to disk must first traverse the red-black tree to see
if the relative domain names consist solely of digits and, if so,
traverse the tree once again and resort the data numerically before
writing the disk file.  With all the essential work that name servers
(and BIND maintainers) have to do, do you still think that your idea
would be a good use of resources?

Andris