Re: Fwd: [ga] Public Comments Requested on DNS Stability: The Effectof New gTLDs on ,the Internet Domain Name System

["Jeffrey A. Williams" <jwkckid1@xxxxxxxxxxxxx>]

Karl and all,

  Good points, well articulated and agreed here!  But this information
is not unknown or undocumented.  Which points me back to where
we all were some 5 years ago to the extent of technical considerations
of this level of granularity.

  Yet bigger and more basic security and stability concerns remain
seemingly unchecked, corrected, and in some significant instances
allowed and even encouraged to continue and/or remain.  One is
DNSSEC, or lack there of, misconfigured DNS such as IETF.ORG's,
the use of "UltraDNS", ect., ect., which I have tried to bring to the
attention of all for review, and correction.

Regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@xxxxxxxxxxxxx
My Phone: 214-244-4827

Karl Auerbach wrote:

> OK, you got me on the trailing /.  However, last time I noticed (I think
> it was a couple of months ago) the absence of a trailing slash caused
> some browser/webserver combinations (firefox/apache) to go through a
> redirect sequence.
>
> For real "fun" with domain names one can create names that are legit per
> the basic DNS standard but which trip over the character set limitations
> (a-z, A-Z, 0-9, and non-leading hyphen) that may or may not apply
> depending on what the name is being used for and what software is being
> used.
>
> And they can be hidden from the user by mapping 'em via CNAME records.
>
> For example, consider the name "maps-to-nonascii.cavebear.com" - give it
> a try - it goes via a CNAME record to another name,
> "non-ascii-chars\015\012\.\000end.cavebear.com" that has an A record
> attached.
>
> Those internal non-ascii characters tend to drive certain
> implementations of gethostbyname() into the weeds (like, for instance,
> the version on Linux.)
>
> (One can also cause confusion by embedding dot characters into a DNS
> label itself - the DNS protocol itself does not carry those dots we use
> in the human [and zone file] representations, so it is possible to have
> dot characters inside labels.  However, a lot of utility library code
> doesn't carry the labels around as length based strings and uses dots as
> separators.  That kind of ambiguity, especially when handled differently
> by security code and application code, can be a source of security gaps.)
>
> I've always wondered what might happen to certain kinds of machines if
> there were a DNS label that went to a CNAME that was "del /F /Q C:\*.*"
>
> What I'm getting at is this - there are lots of ways of generating names
> that will cause trouble.
>
> Rules that focus on simplistic problems - such as banning .php or .pdf
> as top level domains - are inadequate and protect only against a tiny
> portion of the latent possibilities.
>
> Rather than banning such TLDs it might be better for ICANN to publish a
> zone full of really pathological names - like my non-ascii and
> label-with-dots examples - and set it up like the W3C html tester and
> say to the world "If your resolver code can't gracefully hanle this then
> it's broken."
>
> It's better to fix the roof than try to prevent the rain - and it is
> equally better to convince programmers to write better DNS code than it
> is to try to find and ban all possible troublesome DNS character strings.
>
>                 --karl--
>
>                 --karl--