syntax/format of zone on slave $ORIGIN/paragraph - sorted?

[Chris Buxton]

The order of records in the zone is always going to be determined by a lexicographical sort by label, the same sort order as would be used by NSEC records if you were using them.

The $ORIGIN statements are just somebody's idea of a good time. But again, really inconsequential unless you are actually reading your slave zone files, and why would you need that? (Also applies to dynamic master zone files.)

You could always just use named-compilezone to convert your zone to a more script-readable format before you actually open it up; that removes all $ORIGIN statements altogether and writes out each domain name in full. Once you're in that habit, you could (as Alan Clegg said) use the raw file format for your zone files, which named-compilezone can read just as easily - just add '-f raw' to the command line.

Chris Buxton
BlueCat Networks

On Feb 10, 2011, at 10:11 AM, Walter Smith wrote:

> Yes!
> 
> So - I want to combine and sort unique $ORIGINs without seeing same $ORIGIN again and again.
> 
> Like in your example, I would prefer to see just _ONE_ time this sorted paragraph:
> <<$ORIGIN admin.cam.ac.uk. >> and not having multiple entries...
> 
> 
> 
> $ORIGIN cam.ac.uk. 
> admin                   MX      7 mx 
> $ORIGIN admin.cam.ac.uk.    <<<---------------- FIRST OCCURENCE
> aat                     A       131.111.150.33 
> alumni                  A       131.111.150.60 
> blog                    CNAME   webservices 
> $ORIGIN blog.admin.cam.ac.uk. 
> preview                 CNAME   cms.admin.cam.ac.uk. 
> $ORIGIN admin.cam.ac.uk.   <<< ---------------- SECOND OCCURENCE
> bolero                  CNAME   ufsplay 
> bpaservices             A       131.111.150.69 
> www.business            CNAME   www 
> camino                  A       131.111.150.91 
> 
> 
> 
> --- On Thu, 2/10/11, Chris Thompson <cet1 at cam.ac.uk> wrote:
> 
> From: Chris Thompson <cet1 at cam.ac.uk>
> Subject: Re: syntax/format of zone on slave $ORIGIN/paragraph - sorted?
> To: "Barry Margolin" <barmar at alum.mit.edu>
> Cc: "Bind-Users List" <bind-users at isc.org>
> Date: Thursday, February 10, 2011, 9:48 AM
> 
> On Feb 10 2011, Barry Margolin wrote:
> 
> >When writing the zone file on a slave, BIND uses $ORIGIN so that all 
> >records just have a single label.  So instead of writing:
> >
> >foo.bar IN A 1.2.3.4
> >
> >it will write:
> >
> >$ORIGIN bar
> >
> >foo IN A 1.2.3.4
> >
> >If you have a zone with lots of levels of subdomain, the file will have 
> >lots of $ORIGIN statements as a result.
> 
> Except that the rules seem to be a bit more complicated than that. (I am
> using "named-checkzone -D -s relative" but I am pretty sure the same code
> is involved.) Here's an extract:
> 
> $ORIGIN cam.ac.uk.
> admin                   MX      7 mx
> $ORIGIN admin.cam.ac.uk.
> aat                     A       131.111.150.33
> alumni                  A       131.111.150.60
> blog                    CNAME   webservices
> $ORIGIN blog.admin.cam.ac.uk.
> preview                 CNAME   cms.admin.cam.ac.uk.
> $ORIGIN admin.cam.ac.uk.
> bolero                  CNAME   ufsplay
> bpaservices             A       131.111.150.69
> www.business            CNAME   www
> camino                  A       131.111.150.91
> 
> So why did it dive into a subdomain for preview.blog.admin.cam.ac.uk,
> but not for www.business.admin.cam.ac.uk? These lines
> 
> $ORIGIN blog.admin.cam.ac.uk.
> preview                 CNAME   cms.admin.cam.ac.uk.
> $ORIGIN admin.cam.ac.uk.
> 
> could have been replaced by
> 
> preview.blog            CNAME   cms
> 
> just as in the latter case.
> 
> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110210/c326e42c/attachment.html>