[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] IDNA interoperability failures, once again

[This message contains responses to D. J. Bernstein and Eric A. Hall
regarding related issues.]

"D. J. Bernstein" <djb@cr.yp.to> wrote:

> > the man page does not specify the output format of dig
>
> Actually, the dig manual page clearly states that dig prints answers
> from name servers.  There is only one printed DNS record format in
> BIND, namely BIND's zone-file format, which is documented in detail
> and meant to be machine-parsed.

I don't see any mention of RFC 1035 or "master file" or "zone file" in
the dig man page, but let's go ahead and suppose that the output format
of dig is indeed the RFC 1035 master file format.

In that case, IDNA section 3 requirement 1 *prohibits* dig from
outputing the non-ASCII form of domain names.  So there's no problem,
mail does not bounce, the sky does not fall.

"Eric A. Hall" <ehall@ehsco.com> wrote:

> As we can see, a Message-ID header field that includes decoded output
> from an ACE-encoded IDN is not a valid Message-ID.

Exactly right.  Therefore RFC-822 compliant mail programs will not put
non-ASCII domain names in a Message-ID field.  An RFC-822 compliant
program faced with the task of putting a non-ASCII domain name into a
Message-ID field will call ToASCII if it's IDNA-aware, otherwise it will
have no option left but to return an error to whatever handed it the
non-ASCII domain name.  It was the calling program's error for passing
a non-ASCII domain name to a non-IDNA-aware program, or it was a human
error for piping data into a program that doesn't understand the data
format.

As in the dig example, any program with a well-defined pre-existing
output format that includes domain names is prohibited by IDNA from
outputting the non-ASCII form (unless it redefines the output format).
But if the program does not define its output format, then making
assumptions about the output format (like assuming that it won't change
in the next version) is an inherently risky business, and people who
write scripts that pipe such output into other programs are deliberately
choosing to take that risk.  (I'm not saying they shouldn't write
such scripts, just that they should accept responsibility for the
consequences of their unfounded assumptions.)

AMC