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

["Dominik Filipp" <dominik.filipp@xxxxxxxx>]

Well, extra slashes needed for expressing IDN domain addresses, if
applied, could spoil the easy recognition of the URL domain name part I
mention. On the other hand, it seems that backslash prefixed codes are
sufficient enough for expressing non-ascii characters in ascii
environment instead, so this still could work.

Sure, a pathological naming system could easily confuse a DNS system as
to what such a system is semantically expected to be. There may perhaps
be omitting a restriction explicitly imposed on DNS input string formats
in various systems but a fair 'trade-off' tacitly expects respecting the
basic DNS rules as we know them, e.g. domain name should contain only
ascii letters/numbers and dash, etc.
The IDN's external or internal representation must therefore take all
this into account. For example, in IE on Windows, IDN non-ascii
characters expand to dash-based sequences of characters conforming to
the domain name format restriction, becoming unreadable though. But
this, I guess, will change as soon as the IDN system becomes more
popular.

Dominik
 

-----Original Message-----
From: Karl Auerbach [mailto:karl@xxxxxxxxxxxx] 
Sent: Monday, February 11, 2008 10:43 AM
To: Dominik Filipp
Cc: Christopher Anderson; ga@xxxxxxxxxxxxxx
Subject: Re: Fwd: [ga] Public Comments Requested on DNS Stability: The
Effect of New gTLDs on ,the Internet Domain Name System

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--