Hacker News Reader

Comment by Animats | Hacker News Reader

How many of those are even routed to anywhere?

Browsers don't like to route directly to TLDs. In theory, Amazon could have a web site at

    amazon

but browsers interpret that as a search request, not a request for a rooted domain name. Even

    amazon.

which means to treat that as a fully qualified domain name doesn't work in browsers any more.

(That's what the trailing "." means. Relative domain names were a thing. If you're on a machine within "bigu.edu", and you want "ourteam.bigu.edu", you can supposedly just use "ourteam" as a domain. This rarely works right, because few clients have domain names any more. Is it even still implemented in most DNS lookup clients?)

View on HN

ICANN expressly forbid google, and other companies from operating these gTLDs as "dotless" domains back when they approved them. Annoyingly, URLs like "maps.google" aren't set up to go where you'd expect.

It’s crazy that maps.google doesn’t exist, but sheets.new and docs.new both work.

Those .new TLDs have specific requirements as in you are required to use it for creating a new "YOUR_DOMAIN" resource.

Maps is a little weird because while originally they were bundling maps and search and a bunch of products together they have had to back off on that strategy due to the recent antitrust concerns and bundling so now they are purposefully separating the products and the domains further.

I think they've been (slowly) migrating things over--passwords.google and blog.google and a few others exist nowadays

it's very by design on that example. maps.google.com also stopped working a long time ago.

No?

    $ curl -v maps.google.com
    [...]
    < HTTP/1.1 302 Found
    < Location: http://maps.google.com/maps
    [...]

keep going...

It still works, but it redirects to google.com/maps

I’ve found that it works pretty well, at least in my home environment. The first time going to a new host, it has to include https, but subsequent visits auto-complete to the host rather than a web search.

For example, I can type “opnsense” and hit enter, which loads https://opnsense, whose FQDN is opnsense.home.my.domain. This works on all machines on my network; most are configured to use home.my.domain as the primary search domain (through DHCP), but my DNS server also properly responds to queries for just the host portion. And, I’ve configured opnsense to hijack all (standard) DNS traffic on my network, so even if a device is specifically ignoring the DHCP-provided search domain and DNS server, it should be able to query all local hosts.

FWIW "http://amazon." still does what you want it to in Chrome and Firefox.

Huh. HTTP works, but HTTPS does not.

HTTPS for dotless domains (a bit of a misnomer but it can help in finding good reading material about it) should also work fine on the same browsers. That said, most dotless domains don't run it because they've historically not been given certs due to security concerns. As an example: https://uz./ likely just had the *.cctld.uz cert applied to the whole virtual server block and uz was just one of the names assigned to that block.

Bonus fact: https://. works on Firefox (triggers an A/AAAA DNS query for root) but not Chrome.

This may be an antifeature if someone's environment has a host on the LAN named amazon.

Note the trailing ., it's an FQDN. Your system/application shouldn't use search domains if provided a fqdn.

hence under a properly set up DNS and application: system with search domain for `.internal` and a host named `amazon` will be hit the internal host for `https://amazon` and `https://amazon.internal` but not `https://amazon.`

I’ve used search domains in corporate networks, yes it’s still a thing and fully supported. I’d always tell somebody to type [name][forward-slash] in their browser, like ‘jira/‘ to get to our internal Jira server, which would always convince the browser to actually do a DNS lookup and not a search. Worked well.

I liked alway having a rule in the web server to redirect to the fully qualified hostname on requests to the internal ones, so links could be shared and would always work even if the search domain wasn’t set up (could happen on the VPN for example).

There’s an entire library, libpsl, dedicated to checking the public suffix list, and that needs to be updated whenever some marketing department has a brain fart because ICANN needed more cash for its CEO’s cocaine budget.

Doesn't Google use "go" internally? Is it special cased like localhost?

I believe http://go isn’t special cased, but instead (ab)uses DNS search domains - the server is actually something like go.corp.google.com, and all Google PCs are configured to use corp.google.com as a search domain

That's normal DNS behavior. If your machine is foo15241.corp.google.com, and you ask DNS for "go", you are supposed to get "go.corp.google.com".

Unofficial TLDs work fine without being special cased (well, so long as the browser is being pointed at the appropriate DNS server which knows about these entries), it's when the TLD itself is used as a URL you have to enter "http://tld." instead of just typing "tld." but any sub like "example.tld." still works automatically.

Reply on news.ycombinator.com