Hacker News Reader

Comment by fcanela | Hacker News Reader

Server not found error when connecting. Tried removing the "-" but didn't work neither.

According to RFC 1034[1] hyphens can only be interior to a label; it appears many tools simply follow these recommendations strictly.

The exact wording is: "They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen."

[1]: http://www.ietf.org/rfc/rfc1034.txt

The wording “must start with” doesn’t sound like a “recommendation”, and I would think that these tools are right to interpret the standard strictly, and that Github is wrong to allow such domain names.

Whatever happened to "be lenient in what you accept, conservative in what you send"?

Github ignores that rule when they emit such domain names. One might make the point that Firefox and others who in turn reject such domain names are not being lenient in what they accept, but since domain names on the edge of acceptability often are a security issue, I think that a strict interpretation of the standard is the safe choice to make here.

It's a terrible idea that just causes all sorts of intro l interop problems. Web development, for instance, is a mess because of all the various attempts to interpret stuff in some way, versus just failing.

In glibc's libresolv, this is caused by res_hnok in resolv/res_name.c returning 0:

    /*
     * Verify that a domain name uses an acceptable character set.
     */

    /*
     * Note the conspicuous absence of ctype macros in these definitions.  On
     * non-ASCII hosts, we can't depend on string literals or ctype macros to
     * tell us anything about network-format data.  The rest of the BIND system
     * is not careful about this, but for some reason, we're doing it right here.
     */
    #define PERIOD 0x2e
    #define	hyphenchar(c) ((c) == 0x2d)
    #define	underscorechar(c) ((c) == 0x5f)
    #define bslashchar(c) ((c) == 0x5c)
    #define periodchar(c) ((c) == PERIOD)
    #define asterchar(c) ((c) == 0x2a)
    #define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
		       || ((c) >= 0x61 && (c) <= 0x7a))
    #define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)

    #define borderchar(c) (alphachar(c) || digitchar(c))
    #define middlechar(c) (borderchar(c) || hyphenchar(c) || underscorechar(c))
    #define	domainchar(c) ((c) > 0x20 && (c) < 0x7f)

    int
    res_hnok(const char *dn) {
	    int pch = PERIOD, ch = *dn++;

	    while (ch != '\0') {
		    int nch = *dn++;

		    if (periodchar(ch)) {
			    (void)NULL;
		    } else if (periodchar(pch)) {
			    if (!borderchar(ch))
				    return (0);
		    } else if (periodchar(nch) || nch == '\0') {
			    if (!borderchar(ch))
				    return (0);
		    } else {
			    if (!middlechar(ch))
				    return (0);
		    }
		    pch = ch, ch = nch;
	    }
	    return (1);
    }

And the hack fix:

    /*
    hnokpre.c: LD_PRELOAD shim to bypass valid hostname checking in glibc
    gcc -fPIC -shared hnokpre.c -o libhnokpre.so
    LD_PRELOAD=./libhnokpre.so curl http://mattias-.github.io/
    */

    int res_hnok(const char* dn)
    {
        return 1;
    }

    int __res_hnok(const char* dn)
    {
        return 1;
    }

I'm kinda wondering what's the reason for that that check to begin with. Just being pedantic for pedentrys sake?

     * Note the conspicuous absence of ctype macros in these definitions.  On
     * non-ASCII hosts, we can't depend on string literals or ctype macros to
     * tell us anything about network-format data.  The rest of the BIND system
     * is not careful about this, but for some reason, we're doing it right here.

Well that is only a problem if the charset is converted to something else. Are there still systems out there without a C compiler that can be told to use ASCII?

Author here: This is slightly embarrassing.

I just added a custom domain/CNAME to my github pages so it should be reachable at http://blog.ppelgren.se

Could happen to anyone. Nice job solving it fast.

Apparently the hyphen isn't there by mistake. Here's the blog source repo: https://github.com/Mattias-/Mattias-.github.io

Are you perhaps using a browser or a DNS stack that rejects this type of domain name?

The question should probably be: which OS are you using?

It's quite interesting... dig seems to resolve the domain just fine, but neither chrome, curl nor firefox seem to be able to open the page. (tested on Fedora/CentOS/Android)

Same here. My dnsmasq server responds with the domain name when I try it with 'host', but curl and firefox fail on Debian and Ubuntu with only that 1 DNS server in resolv.conf. Curl says "curl: (6) Could not resolve host: mattias-.github.io".

However, curl and firefox seem to be RFC-compliant. RFC952 states: "The last character must not be a minus sign or period."

Android, Google chrome, also have the resolver problem.

Firefox on Debian here, also get a "Problem loading page"

Firefox on Arch, same stuff.

Edit: Google Chrome works.

I had the same problem, but you can read the page from the Markdown-parsed source. https://github.com/Mattias-/Mattias-.github.io/blob/master/_...

Ubuntu 14.04 / Chrome + Firefox... same behaviour :( DNS resolves, curl + both browsers fail.

randunel@18:~$ curl Mattias-.github.io

curl: (6) Could not resolve host: Mattias-.github.io

randunel@18:~$ dig +short Mattias-.github.io

github.map.fastly.net.

185.31.18.133

Interesting... I'm on Ubuntu 14.04 too, and Firefox fails for me, but Chrome succeeds.

I got it with curl -I 185.31.18.133 --header "Host: mattias-.github.io"

I am also unable to visit the page. I'm on Android 4.2, using Firefox and Chrome.

Reply on news.ycombinator.com