So, based on a few replies, I’ll explain.  First off, it looks like the
answer to my question is “no” - no comprehensive and concise definition
exists.

RFC 1034/1035 started the definition of master files and just about
everything one would want to know about the files are contained in public
documentation.  Just never in one place.  I’ve written parsers (in the
90’s) for these things and recall the tricks you need to convert from a
file format into what you’d use in, say, a DNSSEC signer.  I’ve expanded
$GENERATE’s and done all the others.

Nowadays I look at zone files as a source of information.  There are
various flavors of zone files, all fitting some interpretation of the
known definition.  It would be easier if the parsing of the files were
more common.

What I’d like to be able to ask for is ‘a canonical DNS master file’ when
I have the opportunity to ask for a zone file.  To me, in brief, a
canonical form would have a FQDN first, then the ttl, class, type and
rdata all in one line.  Yadda, yadda, yadda.

Nothing new.  Nothing changed.  And nothing that would mean any change to
“the protocol.”  In industry, I have seen specifications calling for a
format that matches what I think of when I say a canonical DNS master
file.  I’m just curious if the IETF has ever written it up.  (And yes, I’m
tempted to try if it doesn’t exist.[0])

Okay, well, maybe something new.  Like - should the master files be in
ASCII or accommodate, say UTF-8?  Just a teaser of what would be part of a
definition.  (I have seen some zone files put IDNA U-Labels in the owner
field.)

PS - And then there’s the escape rules.

[0] - If you think this isn’t worth doing, no need to holler now.  I’m not
promising I’ll ever get around to this, but if I do, you can holler then.

On 2/20/15, 10:55, "Francis Dupont" <[email protected]> wrote:

>What about RFC 1035 (aka STD 13) section 5 "MASTER FILES"?
>
>Thanks
>
>[email protected]
>
>PS: the concept was introduced in RFC 1034, RFC 2308 added $TTL,
>RFC 2540 (dead?) added $DATE, $GENERATE is a BIND extension
>(Mark shall confirm but it is what the BIND 9 ARM says).
>And I agree there is not "consolidated" document...
>
>_______________________________________________
>DNSOP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsop

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to