Subject: [DNSOP] Is there a concise and comprehensive definition of a "zone file"?

From: Edward Lewis <[email-masked]>
Date: Fri, 20 Feb 2015 15:17:58 +0000

I’m hoping to be able to use terms like “canonical zone file” (to define a
file that has lines like FQDN/TTL/CLASS/TYPE/RDATA) - as opposed to other
‘equivalent’ versions of a zone file.  I’d also like to see a delineation
of all of the “dollar-directives” (like $TTL, $ORIGIN, $INCLUDE and
$GENERATE) defined in a document.

Not to mention escape rules.

This just flashed back at me.  Two RFCs had examples of SIP DNS entries.
One presented the line with escapes according to (what I’ll call) BIND’s
parsing rules and the other presented the line with how a person would
normally write it.  This was called to my attention when a SIP implementer
was confused over the differences because the escape rules were not that
obvious to a non-BIND-experienced person.

(And I’d like to distinguish between preferred encodings - is \075 or ‘K’
preferred?)

Does such a thing exist (in one document)?

Where I am going with this is - when one wants to automate looking at zone
files today, there are many varied formats to consider.  (Kind of like
WhoIs.)  With the inclusion of S-labels in some zone files I have seen,
what was once simple parsing means loading in IDNA2008 libraries.

And given the flashback I just related, it would be good to recommend how
DNS records are shown in RFCs - for the sake of consistency between
documents.

IMHO, it would be good to (ahem) ‘clarify’ what is meant by a zone file.
And how to write or document a DNS record.

I’m been thinking that this is needed - or maybe I’ve overlooked a
document that’s already in use.  So I’m asking if anyone knows of a
document?

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Feb 2015 15:43:07 +0000

> $GENERATE) defined in a document.

RFC 1035 defines the standard master file format including $ORIGIN and
$INCLUDE. RFC 2308 adds $TTL. $GENERATE is a BIND extension.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy: Westerly or northwesterly 5 to 7, occasionally gale 8 in northeast
later. Rough or very rough. Rain or showers. Moderate or good, occasionally
poor.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 16:55:13 +0100

What about RFC 1035 (aka STD 13) section 5 "MASTER FILES"?

Thanks

[email-masked]

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...

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 20 Feb 2015 22:42:09 +0530

> $INCLUDE. RFC 2308 adds $TTL. $GENERATE is a BIND extension.

For the syntax of $GENERATE, see the BIND 9 ARM btw.

		Mukund

---

From: Edward Lewis <[email-masked]>
Date: Fri, 20 Feb 2015 17:13:02 +0000

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-masked]> wrote:

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

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 20 Feb 2015 12:49:20 -0500

> document that’s already in use.  So I’m asking if anyone knows of a

There's an interesting specification in the ICANN new GTLD agreements:

http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm

(Search for "master file format".)

It's not concise or comprehensive; it's mostly a list of features of the
master file format to not use.  It looks like a wish list from those
who've had to write custom parsers for the different "ZFA" file formats
that the gTLD operators generate.

Leaving aside the minor stuff like whether to use upper case or lower
case, etc., if there were a "canonical" way to write a zone file, I'd
recommend placing all RRs constituting an RRset together, without
interleaving RRs from different RRsets, so that one doesn't need to scan
the entire zone file before extracting RRsets.  I can't think of an
example from an RFC where RRs aren't shown like this, so at least there
are aesthetic reasons to place them like this.  (It seems like a case of
unnecessary flexibility in the original spec.)

-- 
Robert Edmonds

---

From: Bob Harold <[email-masked]>
Date: Fri, 20 Feb 2015 13:19:09 -0500

On Fri, Feb 20, 2015 at 12:49 PM, Robert Edmonds <[email-masked]> wrote:

> ...
I can see a case where in a hand-edited zone file that one might want to
group by the type of record - putting all the MX records together, possibly
in an $INCLUDE file controlled by the mail team, where the "A" records are
controlled by the server team.  So the RR sets would not be together in the
file.
(Having moved to a database system, I don't remember exactly how the zone
files were arranged when we hand-edited them, but I remember we often
grouped records by type.)

-- 
Bob Harold

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 20 Feb 2015 13:25:01 -0500

> grouped records by type.)

RRsets are type-specific, though, so you can still place an MX RRset and
address RRsets for the same owner name contiguously in separate sections
of the zone file.  (I'm not saying that all RRs should be placed
contiguously by owner name.)

-- 
Robert Edmonds

---

From: Bob Harold <[email-masked]>
Date: Fri, 20 Feb 2015 13:43:21 -0500

My apologies.  It seems that most of the time when I respond, I learn that
I did not understand properly (meaning I was wrong).

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
[email-masked]
734-647-6524 desk

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2015 19:31:50 -0000

>There's an interesting specification in the ICANN new GTLD agreements: ... 

>that the gTLD operators generate.

That was mostly me and, yes, I tried to get them to specify a subset
of master file format that matched what we were already seeing from
large gTLDs so we could parse it easily.  It took a few rounds to
explain to other people that the general 1035+all-other-DNS-RFCs
master file format was both impossible to specify and way more than
any TLD zone would need.

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Fri, 20 Feb 2015 19:45:58 +0000

>master file format was both impossible to specify and way more than

If just to wrap up - I’m aware of the ICANN specification.  I guess I just
want to translate it into an RFC and also put it up for IETF vetting.
(Yes, I work for ICANN but my motivation is not to do something that would
impact the new gTLDs agreements, my motivation is just to have a document
for future reference.)

Defining a canonical form in no way is meant to imply that any other form
is wrong.  The objective is to put a name on a canonical form, and provide
a reference, so that anyone who wants to see zone files meeting a strict
format can say so succinctly.  (Plus, the document can discuss other
issues, provide updated references, etc.)

So, when I get around to it...

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 22:08:30 +0100

>  definition.  (I have seen some zone files put IDNA U-Labels in the owner

=> at least one of the IDNA DNS RFCs is pretty clear about the zone files
(aka master files) are in ASCII.

Regards

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Feb 2015 13:24:20 -0800

> (aka master files) are in ASCII.

The IDNA RFC in question simply relied on the assumption that RFC 1035, in turn, assumed ASCII. Note that RFC 1035 never explicitly required ASCII for the format: it simply didn't say how to interpret non-ASCII octets, but did say how to escape characters.

--Paul Hoffman

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 22:35:40 +0100

>  issues, provide updated references, etc.)

=> in masterdump.{h,c} BIND 9 defines a lot of style flags and some
predefined style for master file dump. IMHO the one you want is
simlare to the "simple" one which comes with this comment:

/*%
 * A master style that prints name, ttl, class, type, and value on
 * every line.  Similar to explicitttl above, but more verbose.
 * Intended for generating master files which can be easily parsed
 * by perl scripts and similar applications.
 */

Regards

PS: it is simple too in its code (no attempt to skip any optional stuff,
so "simple" as in KISS :-).

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 22 Feb 2015 08:22:22 +0100

> The IDNA RFC in question simply relied on the assumption that RFC 1035, in turn, assumed ASCII. Note that RFC 1035 never explicitly required ASCII for the format: it simply didn't say how to interp…

Given, 

- that RFC20 is standard now,  ;-)

- that we've got IDNA, 

the not-yet-proposed scheme by Ed might propose that, 

- while the wire-format is 8-bit, 

- the protocol /as such/ does not say ASCII, 

...we still very much would like STD80 charset in the canonical file.

Non-ASCII characters then probably should be encoded using IDNA. (comments
can of course be anything that does not interfere with reading of the
file, like NULL. The rationale for this is that IMNSHO a very desirable
property of the canonical file format is that it is loadable into the
absolute maxiumum of DNS zonefile parsers.  One can argue that this can
be the over-arching rationale for such a specification. A procurement
specifiation for a piece of DNS software could then state "The software
MUST be capable of reading and parsing a zonefile compliant with
draft-dnsop-lewis-zonefile-format-07".

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
does your DRESSING ROOM have enough ASPARAGUS?

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Feb 2015 07:22:47 -0800

On Feb 21, 2015, at 11:22 PM, Måns Nilsson <[email-masked]> wrote:
> Non-ASCII characters then probably should be encoded using IDNA.

Not at all. Assuming that you meant "Punycode" for "IDNA", that encoding is used for full labels, not characters. The result of this is that, if the master file format is ASCII, names would be encoded Punycode. It is important to *not* require IDNA2003 or IDNA2008, which have different prohibitions on different characters. A second result is that anything other than domain names that might have non-ASCII characters needs to be encoded in Base64.

> (comments
> file, like NULL.

Proposal: comments not be allowed in the canonical format. This will allow more likely interoperability.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 22 Feb 2015 11:07:10 -0500

> ...we still very much would like STD80 charset in the canonical file.

Anything in STD80?  That's kinda strange.  The STD13 "rule" is
effectively the Preferred Syntax, which is LDH.  Alternatively, labels
are octets.  Note that there are most definitely systems that put
UTF-8 in zones, and this is entirely fine and legitimate; it just
doesn't work that well on the Internet maximally construed.

> Non-ASCII characters then probably should be encoded using IDNA.

Perhaps here you mean, "labels should be IDNA-conformant"?  If so,
underscore labels are out, and that seems like it'd suck.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 22 Feb 2015 11:09:23 -0500

> Proposal: comments not be allowed in the canonical format. This will allow more likely interoperability.

Ick.  Also, the comment character is specified in RFC 1035.  If you're
not doing that specification correctly, I suggest, you're not
implementing DNS.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Feb 2015 08:31:08 -0800

> underscore labels are out, and that seems like it'd suck.

As I said earlier, I think that "labels in domain names should be encoded in Punycode" would be sufficient, and would eliminate your problem with _labels, I believe.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Feb 2015 08:32:11 -0800

> not doing that specification correctly, I suggest, you're not

Fair point. I was responding to Måns calling the format "canonicalized", which is not what Ed called for. If we just want a standardized form, we can leave comments in.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 22 Feb 2015 11:49:51 -0500

> As I said earlier, I think that "labels in domain names should be encoded in Punycode" would be sufficient, and would eliminate your problem with _labels, I believe.

What exactly makes you decide that underscore labels aren't domain
names?  Indeed, one style of them uses two in a row, and there is
nothing whatever to say that there wouldn't be a zone cut there -- in
which case such labels are definitely domain names (I'll leave aside
whether the ones without a zone cut are too).  This is an operational
convention, not something that flows from the name "domain", and I
don't think we should define anything such that it depends on the
nature of domains.

a

-- 
Andrew Sullivan
[email-masked]

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 22 Feb 2015 18:12:27 +0100

> > doesn't work that well on the Internet maximally construed.

And since that is the case, and since there most likely are zone file
parsers that barf on anything !ASCII I still believe it is wise to
limit the standard file format. As I understand it, one of the goals
with defining the file format is that a file conforming to the format
should pass most parsers today. That might seem like a backwards way of
defining things, and it is, but we are trying to clarify something that
is pretty old by any information technology time scale here..
 
> As I said earlier, I think that "labels in domain names should be encoded in Punycode" would be sufficient, and would eliminate your problem with _labels, I believe.

That was at least what I meant. Thanks for helping me express myself ;-) 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
As President I have to go vacuum my coin collection!

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 22 Feb 2015 18:12:51 +0100

> not doing that specification correctly, I suggest, you're not

++;

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I haven't been married in over six years, but we had sexual counseling
every day from Oral Roberts!!

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Feb 2015 11:58:19 -0800

On Feb 22, 2015, at 8:49 AM, Andrew Sullivan <[email-masked]> wrote:
> names?

A mistake in me remembering which label the "xn--" prefix was applied. :-( (That's really a :-(:-( given that I am the co-author on that document...)

So, n'r mind what I proposed above. A better rule would be "express labels in the wire format, except where the wire format is not printable ASCII, in which case use \Dxxx escaping". That is, IDNA would have nothing to do with this.

As for Måns original question: converting wire-format IDNA to some encoding of Unicode characters is unstable because some registries use IDNA2003 rules, others use IDNA2008 rules, and some labels in the former can't be represented in the latter. Yes, IDNA2008 obsoleted IDNA2003; that is irrelevant to the a good chunk of the operator community.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Sun, 22 Feb 2015 12:02:11 -0800

On Feb 22, 2015, at 9:12 AM, Måns Nilsson <[email-masked]> wrote:
>>> effectively the Preferred Syntax, which is LDH.

I thought this was applicable to "hostnames", not "domain names".

>>> Alternatively, labels are octets.

Well, 0 to 63 octets.

>>> Note that there are most definitely systems that put
>>> UTF-8 in zones, and this is entirely fine and legitimate;

Yes, to wit:

http://www.thedomains.com/2015/02/20/coca-cola-puts-smiley-face-emojis-into-web-address-using-ws-domains/

>>> it just doesn't work that well on the Internet maximally construed.

Somewhat as an aside, I suspect the desire to ensure this is what is leading to ossification.  Not a criticism, just an observation.

> limit the standard file format.

As far as I can tell, there are zone file parsers that barf on pretty much anything (including 20+ year old RR type names).

> As I understand it, one of the goals
> should pass most parsers today.

While I appreciate the pragmatism, I'm not sure I see the value of this approach given (from past experience, but have little current data) few zone file parsers actually do the right thing in all cases. I'd imagine the goal here is aspirational: what does the DNS technical community think the concise and comprehensive zone file format _should_ be, regardless of the abominations found in the myriad implementations.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Mon, 23 Feb 2015 07:53:30 +1100

master files are ASCII files.  Non printable ASCII is encoded as
\DDD in TXT fields and domain names with the additional constraint
that space is encoded as \032 in domain names.  Binary in other
fields is encoded as base64, base32hex, hex and other rdata specific
encodings.  The DNS presentation format for all records only emits
ASCII.

If you have a file that contains u-labels it is not as master file.
It can be converted to a master file by processing the labels and
turning them into a-labels.

Master files are supposed to be able to be processed by nameservers
that are not IDNA aware.

If you use master files extensions such as $TTL, $DATE and $GENERATE
then you need to ensure that the nameserver can process them.  A
cannonical version of the master file contains none of these
extensions.

Additionally you need to be aware of what types the nameservers
supports otherwise you should encode all non RFC 1034 records as
unknown types.  Unfortunately RFC 103[45] failed to specicify how
to encode unknown types in master files which makes it impossible
to have a master files that contains new types be readable by all
nameservers in existence.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Feb 2015 08:52:05 +0100

> On 22 feb 2015, at 20:58, Paul Hoffman <[email-masked]> wrote:
> 

It is correct that the policy for what Unicode Characters are allowed have changed over time (even for IDNA2008 it changes when the Unicode version changes).

But the _encoding_ of the characters is the same.

So maybe some of the "maybe disagreements" are not disagreements after all?

   paf

---

From: Edward Lewis <[email-masked]>
Date: Tue, 24 Feb 2015 15:08:56 +0000

On 2/23/15, 2:52, "Patrik Fältström" <[email-masked]> wrote:

>> As for Måns original question: converting wire-format IDNA to some
>>encoding of Unicode characters is unstable because some registries use
>>IDNA2003 rules, others use IDNA2008 rules, and some labels in the former
>>can't be represented in the latter. Yes, IDNA2008 obsoleted IDNA2003;
>>that is irrelevant to the a good chunk of the operator community.
>
>It is correct that the policy for what Unicode Characters are allowed
>have changed over time (even for IDNA2008 it changes when the Unicode
>version changes).
>

Okay, before getting too silly on this, IDNA is a convention for
representing identifiers in non-ascii/latin scripts into DNS labels, for
the purpose of restricting what can be registered to prevent confusion.
(Okay, okay, for providing a unique and reversible way to transliterate
between the printed and on-wire forms.)  But there’s nothing stopping me
in the DNS protocol from putting arbitrary binary garbage in a label even
if it wouldn’t be very useful to a human if I did.

I.e., the domain internet groper tool (version 9.10), distributed by the
Internet Software Consortium, can report this in an AXFR reply:

\000\001\002\003.example. 600	IN	TXT	"binary label”

I put that into a zone file using \DDD format, loaded it into a name
server and it served it up.  Not IDNA, but very DNS.

(Side note - don’t let top-level domain operational considerations blind
us to how the underlying protocol works.  E.g., IDNA is a convention, not
a protocol change, in how one reads labels outside of the DNS arena, such
as business cards.  I say this because a lot of the operational input to
the DNS document set is from TLD operators - who have a lot of real good
experience and see a lot of the packets - but is not entirely
representative of the way the DNS eco-system is run.)

Zone files are a way to represent what is meant to be in-memory for a zone
in a “file.”  While it makes sense to, one doesn’t have to convert labels
the same way for zone files as is done under IDNA.  In the example above,
I used the STD 13 convention of \DDD.  One could put in UTF-8 or UTF-16 or
whatever suits them in files.

As I said, this is silly talk and perhaps I’ve been bit too loose with
language.  If someone feels the need to fix what I’ve said, go ahead,
please.

What I have in mind (to solve) was seeing some zone master files with
UTF-8 entries.  There’s nothing inherently wrong with that except that my
parser assumed letter-digit-hyphen only.  The producer of the zone files
had been asked to submit them in LDH but made a mistake, probably because
it was early in the reporting and the request wasn’t clear enough.

My goal is just to clearly define and put a name in the desired format in
a definitive reference document.

BTW, thanks to the participants in the thread.  I am aware of “all of
this” (as someone who’s written the code before) but the refreshers on
references is very helpful.  Consider this a desire to bring up the
written word to the state of the code, which is what the IETF documents
are about.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Feb 2015 10:42:50 -0500

> the purpose of restricting what can be registered to prevent confusion.

I think that misstates things a little.  I'd say it is a protocol for
representing Unicode in labels conforming to LDH, and for
internationalizing the LDH convention.

> in the DNS protocol from putting arbitrary binary garbage

Or arbitrary UTF-8 strings.  There are systems that use them,
including some from the small vendors called "Apple" and "Microsoft".
(I don't think we're saying anything different; just trying to point
out this isn't theoretical.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Feb 2015 16:03:03 +0000

I admit that this thread rolled off my screen before I noticed it.  I’m
going to pick on a few things said here that extend backwards in the
thread a bit.

On 2/22/15, 15:53, "Mark Andrews" <[email-masked]> wrote:

>master files are ASCII files.

Maybe they are supposed to be.  But what got my goat recently was trying
to parse a zone file that had UTF-8 in it.  There are zone master files
that are not purely ASCII in the wild.

Not saying that it is right.  Saying that they deserve to be recognized.
I mean, there’s every reason that the file can be put to use.  I had
considered extending the parser I had to do so, then decided for my use
case the effort wasn’t worth it.

>If you have a file that contains u-labels it is not as master file.

Walks like a duck, talks like a duck, smells like a duck…but yes,
according to some dusty old documents - written before u-labels were
imagined [by the community producing the documents] - they aren’t.

>turning them into a-labels.

Bingo!

>Master files are supposed to be able to be processed by nameservers

There’s no reason that we can’t add an adjective to "master file.”  Then
folks writing RFPs, contracts, work orders can specify what is best.  If I
choose to run antiquated software I’ll ask for antiquated master files. If
I choose software that reflect the native language of my staff, I might
want master files that have a different formatting.

Orthogonal to my desire to document this is the desire to see how far we
can get away from assuming everyone has ASCII knowledge.  NOCs shouldn’t
have to list a particular (human) language as a requirement.

>cannonical version of the master file contains none of these

I know of name servers that do not read master files at all, so no, you
can’t “ensure."

>nameservers in existence.

I’m well aware of this.  RFC 1034/1035 didn’t specify how you’d include
write an RRTYPE they didn’t invent, not even the ones in "New DNS RR
Definitions” RFC 1183 (October 1990, Experimental - ok, outside of RP non
are in use and RP may or may not be).  It’s a shame RFC 1034/1035 didn’t
cover this (but there were many omissions, so it’s not surprising) but we
deal with that.  The printed form of unknown record types is no different
that the printed form of, say AAAA (in some use [wink], not in RFC
1034/1035).

The point is to define a way to print data into a file.  And not even “a”
way, but have a lowest common denominator and then more useful
“adjectives.”  It doesn’t matter if parsers today “break” or “fail” to
consume a particular format - if that happens, operators can perform “tech
refresh” if they need.

PS - I want to emphasize that LDH is not a requirement for a domain name.
(I think that point was made already.)  A label can have only LDH, it can
have punydode, it can have arbitrary binary code.  Printing a label (as it
is seen in a file) isn’t the same as converting a name for registration.

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2015 19:16:19 -0000

>that are not purely ASCII in the wild.

Indeed.  I have no idea what they mean.  Since the DNS is a mostly
8-bit clean protocol, give or take ASCII case folding, if I run into
UTF-8 where I'm expecting a name, I can't tell whether the plan was to
store those bytes literally as the names for some private application,
or to treat them as u-labels and to put the corresponding a-labels
into the names.  It is my impression that there are places in Asia
where they did 8-bit hacks before we came up with IDNA and some of
those hacks aren't dead yet.

Whoever created the zone files presumably knew which one they wanted,
but if one of them shows up from, e.g., some random entity that's
asked me to do name service, I can't tell what they mean without
asking them.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Feb 2015 08:46:07 +1100

> that are not purely ASCII in the wild.

There are files that people want to be master files with UTF8 in them
but they are not master files.

> imagined [by the community producing the documents] - they aren’t.

And also that IDNA explicity does not require changes to nameservers.

> choose to run antiquated software I’ll ask for antiquated master file
> s. If I choose software that reflect the native language of my staff, I might

I repeat.  They are not master files.  They a 'u-files' or whatever
name we decide to give them.  That said non-ascii doesn't mean that
the file contains UTF-8.  Lots of "master files" contain ISP-LATIN-FOO
or Windows-XXXXX.  Making any assumption about the character set
is plain fraught with danger.  IDN goes native -> utf8 (u-labels)
-> a-labels.

> I know of name servers that do not read master files at all, so no, you

Master files are a zone transfer method.  You only need a tool to
convert them to whatever you are using internally to meet RFC 1034
requirements.

i.e.  here is a master files for zone example.net.  Please load it
into your nameserver.

There is no requirement for a nameserver to read then directly though
many do.

If you "extend" the format you need to know apriori that the receiver
can handle it.  We started out with a request for a "canonical
master file format".  That is ascii and only ascii.  Yes lowest common
denominator.

> Definitions” RFC 1183 (October 1990, Experimental - ok, outside of RP
> non are in use and RP may or may not be).  It’s a shame RFC 1034/1035
> didn’t cover this (but there were many omissions, so it’s not surprising)
> but we deal with that.  The printed form of unknown record types is no
> different that the printed form of, say AAAA (in some use [wink], not in RFC
> 1034/1035).
>