Dear RIPE: Please don't encourage phishing
marka at isc.org
Wed Feb 15 13:32:19 UTC 2012
In message <86mx8kqpy7.fsf at seastrom.com>, "Robert E. Seastrom" writes:
> Valdis.Kletnieks at vt.edu writes:
> > On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
> >> Challenge taken.
> >> RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1,
> >> "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY
> >> specify, in addition, how to use other charsets [something DNS does
> >> not do, so it must be UTF-8]"
> > (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :)
> > That requires overlooking the minor detail that the DNS RFC predates that by quite
> > some time, and there's no combination of RFCs 2119 and 2277 that mandates
> > retrofitting grandfathered protocols by fiat.
> > It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and
> > as such isn't itself binding, merely A Good Idea.
> > Nice try though. ;)
> Valdis, re-read the original assertion and challenge.
> Your attempt at RFC lawyering appears to be "Experimental" <grin>
The Internationalised DNS uses IDNA suite of RFC's to encode UTF
into A-labels. Before deciding to go the IDNA route, treating DNS
labels as UTF-8 was discussed, evaluated and rejected.
DNS labels are length tagged binary blobs with case folding of the
7 bit ascii values 'a'-'z' when performing lookups. If a server
is fully compliant (and I don't think any is) answers should be
returned in a case preserving manner, including owner names. The
intent of RFC 1035 was to be able to use the DNS to store and
retrieve binary data using binary keys.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG