Hacker News Reader

Comment by kevinday | Hacker News Reader

https://bugzilla.mozilla.org/show_bug.cgi?id=1910322

for more background. The short story is that when doing CNAME based validation, they were supposed to put an underscore at the start of the random string for you to add to your DNS records. They still generated sufficiently random strings but didn't include a _ before it which is in violation of the RFC. The rationale is that some sites might do something like give you control of yourusername.example.com and they don't want to make it possible for random users to register the random string and be able to manipulate it. If you don't allow users to generate anything that causes a hostname to appear with a leading underscore, they can't pass the domain validation.

View on HN

Also, while a DNS name can have an underscore a host name, even in DNS, cannot have this character. So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid.

So even if you are completely oblivious to this work, and don't care about security at all, your "Give everybody a hostname" code should already avoid underscore characters as desired because otherwise stuff breaks.

Several current systems use DNS names (but not hostnames) which feature underscores but it's pretty unlikely that you've got (for example) a service where users can pick their own TCP/IP service name and port and issued appropriate records for it in DNS. If you have done this weird thing you probably want to use the existing mechanism (in DNS of course, the CAA record) to tell most CAs that they should not issue for your names even if they think they've received permission. You can then cut a suitable deal with a for-profit CA to do whatever crazy extra checks you want (e.g. Meta's CA has to contact actual people in the appropriate security team at Meta, so that "mistakes" which give somebody a certificate for facebook.com never happen without some pretty drastic real world errors).

So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid.

Not long ago I actually did come across a site that had an underscore in its domain name, and it worked both for me and apparently Google, because it indexed and showed a (relevant) page from that site. I only remembered it was on a *.tripod.com subdomain, and can't find that exact site now since I don't remember what I was searching for (it was a highly obscure and technical topic), but there do appear to be others there with underscores, e.g.:

http://computer_collector.tripod.com/

http://hattori_striker.tripod.com/

http://forgotten_dark_angel.tripod.com/

There are.

There shouldn't be, but there are.

Google also indexed my site http://_.4a.si as seen here http://google.com/search?q=site:_.4a.si

A live proof that CNAME records starting with _ exist.

In 2019 the CAs agreed not to issue certs to underscored subdomains making this less useful.

As evidenced by all your links being http.

(as an aside, it looks really weird seeing a bare http link in the wild - crazy that was the old norm!)

My browser is configured to auto-upgrade such links and I get a full screen interstitial when the upgrade fails (as of course it did for these)

This is now at a place where I'd recommend such configuration more broadly, it's not suitable for everybody, but many could benefit from just knowing all links are secured.

A wildcard would still work for these fwiw

Wildcard certs match subdomains with underscores, as pointed out by a sibling comment. Example: https://_.4a.si./

Reply on news.ycombinator.com