> [...].  To that end it seems quite prudent to have the DNS software
> do the checking early and often too, especially on certain record
> types, just in case that other software might fall flat on its face
> with the likes of a unicode exploit or what have you.

Perhaps.  On the other hand, doing this means that your DNS software
will then prevent you from doing things like investigating Empire
Towers spam thoroughly (they tend to use octets in the 0x00-0x1f range
in DNS labels).

> It's one thing to be liberal in what you accept and quite another to
> pass on poisoned data.

But you cannot tell what constitutes "poisoned" data to arbitrary other
pieces of software.  Perhaps something will fall over if it ever gets a
domain name as short as three characters but nevertheless containing a
dot (currently no such are valid because all TLDs are >=2 characters).
Does this mean it's sane to have your DNS server refuse to accept such
names?  (Such a bug is not as farfetched as it sounds.  I once had to
find a bug that struck on May 10th because it was the first time the
month's full name was no longer than its three-letter abbreviation and
the day number in a two-character field didn't have a leading space.)

And making the DNS software reject some data from others because it
might be poison to some other piece of software also makes it
impossible to use that data in ways that _aren't_ poisoned by it.  (To
pick a simple example, consider

	$ORIGIN 30.20.10.in-addr.arpa
	40	IN CNAME	32/28.30.20.10.in-addr.arpa

If you refuse that because the slash might be "poison" to SMTP (or to
something that constructs filenames based on DNS names), you will be
unable to resolve perfectly reasonable reverse DNS.

> In my world (i.e. in the places where I manage the DNS) it's quite
> clear that until agreement is reached on how to safely
> internationalize domain name labels everything which is not "let-dig
> [ldh-str]" could be poison to some client, or at least unusable by
> some client.

Certainly.  So could some things which *are* "let-dig [ldh-str]".  The
variety of actual bugs is almost endless; the variety of *potential*
("could be") bugs *is* endless.

> I know I have DNS clients that are vulnerable to the unicode
> exploits, for example, and there's nothing I can to do fix them so
> filtering is my only cure.

Surely the right fix is to just not run software that broken?  I have
trouble seeing how it's a favor to anyone to have the DNS server paper
over bugs in random client code.

Those of you who've been paying enough attention may notice that I
appear to have reversed my previous position on whether check-names is
a good option.  This is because the context is different.  I think
having check-names semantics available for zone files is good (though
using it is, of course, up to the DNS admin).  I think having such
tests applying to data not loaded from locally maintained files (or
more precisely, to data over which the local admin has no control)
borders on insanity.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B