Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: COM/NET informational message

  • From: E.B. Dreger
  • Date: Fri Jan 03 14:20:21 2003

EL> Date: Fri, 3 Jan 2003 13:44:53 -0500
EL> From: Edward Lewis


EL> The DNS protocol is not 8-bit safe, much less any
EL> implementations of it.  This is because ASCII upper case
EL> characters are down cased in comparisons.  I.e., the

My point is there's no need to force chars <= 0x7f if DNS servers
are properly implemented.  If they're not properly implemented,
why not, and whose fault is that?  Catering to bad or broken
implementations instead of following standards is not a good way
to ensure interoperability.

DNS labels are encoded by a one-octet length representation
followed by that number of octets, with no restrictions on the
content of the octets.  Show me where an RFC says something to
the extent of "labels and <any type of> RR MUST NOT contain
characters >= 0x7f" that rescinds 1035.

Yes, comparisons are case-insensitive.  So what?  strcasecmp()
works on ASCII strings.  Now it must work on <new encoding x>.
Why not let <new encoding x> be UTF-8, something programmers
should support already?  Maybe MS-style Unicode encoding?  Why
add yet another encoding?!

I fear I may be straying OT, for this is layers 6/7...


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

> Network Working Group                                     P. Mockapetris
> Request for Comments: 1035                                           ISI
>                                                            November 1987
>
> 2.3.3. Character Case
>
> For all parts of the DNS that are part of the official protocol, all
> comparisons between character strings (e.g., labels, domain names, etc.)
> are done in a case-insensitive manner.  At present, this rule is in
> force throughout the domain system without exception.  However, future
> additions beyond current usage may need to use the full binary octet
> capabilities in names, so attempts to store domain names in 7-bit ASCII
> or use of special bytes to terminate labels, etc., should be avoided.
>
> When data enters the domain system, its original case should be
> preserved whenever possible.  In certain circumstances this cannot be
> done.  For example, if two RRs are stored in a database, one at x.y and
> one at X.Y, they are actually stored at the same place in the database,
> and hence only one casing would be preserved.  The basic rule is that
> case can be discarded only when data is used to define structure in a
> database, and two names are identical when compared in a case
> insensitive manner.
>
>
> 3.3. Standard RRs
>
> The following RR definitions are expected to occur, at least
> potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
> will be used in all classes, and have the same format in all classes.
> Because their RDATA format is known, all domain names in the RDATA
> section of these RRs may be compressed.
>
> <domain-name> is a domain name represented as a series of labels, and
> terminated by a label with zero length.  <character-string> is a single
> length octet followed by that number of characters.  <character-string>
> is treated as binary information, and can be up to 256 characters in
> length (including the length octet).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@brics.com>, or you are likely to
be blocked.





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.