Laurent Frigault wrote:
gethostbyaddr (and may be other functions) will return NULL under at
least FreeBSD/NetBSD for ANY PTR having the "_" character.
As it should. I wish it would also return a null for hostnames
containing sequential non-alphanumerics (--, ---, __, ___, ...).
Don't like RFC3490 and its xn-- hostnames? 
It is possible to reject multiple dots, both in theory and in practice (in
fact it's a useful for spotting certain kinds of spamware that generates
bogus HELO domains).
You can't reject double hyphens because they are permitted by the syntax
and used by IDN, for example.
Tony.
If null were returned for all "host names" containing "--" then IDN names wouldn't "work." (See RFC 3490, section 5.)
Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with "-", TLD names shorter than 2 or longer than 4 characters,
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.
There is real value in KIS, and not just from the perspective of a
security-minded coder...
Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with "-", TLD names shorter than 2 or longer than 4 characters,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.
I understand your other concerns, there, but TLD length?
To preserve assumptions in old apps?
Cheers,
-- jra
...
Don't like RFC3490 and its xn-- hostnames?
xn--... aren't host names, they are domain names. The host name corresponding to that would be something my simple minded mail application can't accept as input.
Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with "-", TLD names shorter than 2 or longer than 4 characters,
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.There is real value in KIS, and not just from the perspective of a
security-minded coder...
KIS is great, if it gets the job done. Systems that are too simple are useless too.
Supporting "IDN" is a necessary job. That's been made clear to the Internet community. If it "complicates" things, well, then that's what has to be done. If the Internet is to be global, it can't restrict the world to just a few convenient languages.
It's true that the xn-- convention isn't the best way to encode IDN's, but it has proven to be the optimal one in design (at least). It would have been nice to use a new domain name label type, but we've about run out of them. It would have been nice to use domain classes and use this to create a new domain name syntax, but that can't be done either. Encoding IDNs this way ("xn--") is optimal according to the considered opinion of the IETF, at least those working on RFC 3490 (published in 2003), when you consider impacts on other protocols and applications.
Edward Lewis wrote:
It's true that the xn-- convention isn't the best way to encode
IDN's, but it has proven to be the optimal one in design (at least).
It's the necessary minimum for compatibilty purposes, but not anywhere
near the optimal design.
Moreover, those have nothing to do with each other.
"Optimal" is so subjective.
