gethostbyname() cant resolve names starting/ending with "-"

RFC3696 s2 does not say that all-numeric labels are not permitted, only that all-numeric TLD's are not. Even if it did, the counterfactual that some invalid names are accepted would be irrelevant

gethostbyname is operating entirely correctly.

RFC1035 section 2.3.1 says that labels start with letters only. So gethostbyname should not accept 123.deviantart.com, but it do.

Lynn writes ("[Bug 144431] Re: gethostbyname() cant resolve names starting/ending with "-""):
> RFC1035 section 2.3.1 says that labels start with letters only. So
> gethostbyname should not accept 123.deviantart.com, but it do.

This rule was relaxed a little while later. You may be aware of a
certain very prominent networking company with a digit at the start of
its name.

Ian.

This bug report is valid. The RFC does not prohibit labels that don't start with a letter; it merely recommends against them. The definition of "label" mentioned above is part of a guideline introduced with this text:

"The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET)."

Points in favor of supporting domain names that don't necessarily follow those guidelines:

1. There are actual domains out on the Internet running web sites with such domain names (several blogs at blogspot.com spring to mind)
2. Such domains resolve on other OSes (not just Windows, but also OS X).
3. Direct DNS queries (dig, host, nslookup) on Linux work fine with such names.
4. Even gethostbyname() on Linux works for such names when they're in the local /etc/hosts file. Possibly in NIS maps as well.

Point 4 is especially telling; I don't see any reason for gethostbyname() to introduce a restriction between two interfaces when that both operate correctly without the restriction. Especially not a restriction that prevents access to actual web sites. Telling users that "The owner of that site shouldn't have named it that" is not helpful.

Oh, the submitter mentioned RFC 3696. This is from that RFC:

"Any characters, or combination of bits (as octets), are permitted in DNS names."

It then goes on to make several recommendations for restrictions - but these are, again, recommendations only.

upstream says won't fix.

I think Mark J. Reed gives quite enough reasons to fix this bug. Either in upstream or Ubuntu.
There is no technical reason not to fix it, and I do not understand why I can't visit -kol.deviantart.com from Ubuntu while my neighbour with Mac can?

It's ridiculous not to fix this bug

The file in question is:

resolv/res_comp.c

The function: res_hnok should act like res_dnok. I am going to write a patch and build a package with the changes as soon as I can get around to it - By next Sunday would be a good bet.

Marking Confirmed, Low - I am also seeing this on Jaunty.

Note to upstream reporter: You may want to give them a nudge on this one, as there haven't been any replies recently.

In case you're unaware, it's not just names beginning with, say, a hyphen, but also with parts ending with a hyphen.
I can't access my Deviantart account (my username ends with a hyphen) on Ubuntu 10.04 because of this.
It seems to me that fixing this sort of bug contributes towards fixing bug#1: I am currently using Windows 7 and trying out Ubuntu, but if I can't do stuff like accessing my Deviantart account I'm just going to go back to that and adieu.

Almost four years have passed since this bug reported and still not fixed. Shame.

Both the Glibc upstream (http://sourceware.org/bugzilla/show_bug.cgi?id=4671) and Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575209) seem to not want to fix this.

The patch in the Debian bugreport will allow hyphens; my patch is a little bit more liberal and allows underscores as well (it also cleans up the logic to make res_hnok more like res_dnok).

Tested on my system, and it seems to be working.

Hi, can we please push for this bug to be fixed.

If Ubuntu wants to hit it's expected user target then silly bugs like this need to be fixed or people will be like this, "Lol, you can't even go on my blog http://my-awesome-blog-.tumblr.com because you're computers poo" (probably with more profanity and this does happen).

It's a ridiculously simple patch to apply, even if just Ubuntu adds it

The attachment "2011-09-02-ubuntu-bug-144431.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Is this bug still not fixed? I'm getting this issue on 12.04.

This bug is just as much not a bug now as it was when it was filed. If anyone other than deviantart is advertising hostnames that start or end in hyphens, I'd be curious to know. If this is pretty much just a deviantart problem, has anyone considered talking to them about not doing that? The fact that someone does it doesn't make it valid. You can put literally ANY STRING YOU WANT in DNS, but that doesn't make it a valid host name. Period.

Tumblr also has hostnames that end in hyphens.

Regardless, if there is a publicly available web address at a given hostname, albeit with an invalid hostname, this "not a bug" prevents almost any program-level function from accessing said publicly available web addresses. For example, curl, PHP, web browsers are all affected because they utilize gethostbyname() somewhere in their process chain. Do these programs need to stop using gethostbyname() and start adopting a new method of resolving hostnames in order to access said web addresses?

Your argument seems to be that if there's a "publicly available web address", we should support resolving that, no matter what, right? I could set up a publicly available website at "[wow-square-brackets].sili.ca" today. Would that mean every OS that doesn't resolve square-bracket-hostnames is now buggy? Or should someone tell me to stop being silly and not do that?

You're welcome to take this argument back upstream to the bug there. If they are convinced, fine. But I won't carry a distro patch for this, and I would prefer that people who care deeply about this tell tumblr and deviantart that they're breaking spec, rather than telling me that I should care about their spec abuse.

When someone blatantly violates rfc822 or 2822 and postfix/exim/sendmail reject those emails, do you file that as a bug too?

No, I don't think gethostbyname should accommodate for any crazy hostname, and I understand your argument. However, the hyphen is a special character. It *is* allowed in hostnames, just not technically as a border character. Many people have made the argument that hostnames aren't technically supposed to start with a digit, and yet gethostbyname will still resolve those addresses. Why not allow border hyphen characters for the same reason of it being practical in terms of reaching actual available web addresses?

Except that "hostnames with a digit" argument is incorrect, as this was explicitly allowed (with a MUST on support, no less) in RFC 1123, section 2.1. Quoting ancient RFCs when they've been superseded doesn't actually help one's case here.

To be fair, I'm not an expert on RFCs, just a developer with an unfixable problem. So I suppose you're saying the RFC needs to be amended for this to go through.

It doesn't seem sensible to not support this if BIND supports it.

It doesn't seem sensible to not support this if There Are Sites On The Internet I Can't Access Due To My Choice Of OS!
Please forget the precise wording of restrictions in technical specs and remember that this is an actual user facing issue.

David, that circles us back to my argument that you're saying we should support resolving any hostname anybody exposes on the Internet, period. There are any number of reasons that just doesn't work, and pretty much toss out the whole point of having standards.

@kees: BIND supports resolving damned near anything, because DNS != hostnames.

I must have missed an e-mail with your previous post sorry. Anyway, what are some of these reasons that there are any number of?

I think the practical solution to deciding which domains to drop and which to support is unfortunately that we should support at minimum any that Windows does. It is (for now at least) the de facto client implementation: If Windows didn't allow accessing sites with the leading or trailing hyphens, then tumblr etc. would not expose them.

As long as we are bickering about RFCs, I would like to propose that this situation is best covered by the first half of RFC 1958 part 3.9:

3.9 Be strict when sending and tolerant when receiving.
   Implementations must follow specifications precisely when sending to
   the network, and tolerate faulty input from the network.

(it goes on to say "When in doubt, discard faulty input silently", but I disagree with that for this instance obviously, I guess it comes down to if "faulty" means would cause problems vs merely out of spec.)