At the browser level, is it a keyword or a domain? Try "ai". "ai" is a real domain, and there's a web site at "http://ai", touting the advantages of starting an offshore company in Anguilla. Most browsers interpret "ai" as a search term by default. If you enter "ai.", though, you've specified a rooted domain name (a feature few people know about) and should get the "ai" web site. Firefox understands this, but Android doesn't. Try various browsers.
At the glibc level, there's an exploitable bug, which I reported in 2012.[1] It's still open. The bug was first seen in 2011 and reported on serverfault.[2] The problem is that glibc DNS lookup has a feature which is supposed to allow abbreviating domain names. The idea was that if you're on "something.harvard.edu" and you look up "law", it tries "law.harvard.edu". The exploit is that if you're on "foo.com", and you look up "baz.com, glibc tries "baz.com.com". There's a domain "com.com", and it has a wildcard DNS server, so it will resolve "baz.com.com". What's there? A scam. "You are selected by G00GLE to be among the first few persons to win an iPhone 7...".
This behavior is a problem for all single word domains. Whether it is active depends on the hostname of your local host. It's mostly a server problem, but some ISPs issue clients hostnames such as "12345678.comcast.net", which means that "google" gets tried as "google.comcast.net". Fortunately, "google.comcast.net" doesn't resolve in DNS. Neither does "com.comcast.net" ISPs need to be careful about this.
(It's a big problem if you're writing a web crawler, which is why I know about it.)
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13935 [2] http://serverfault.com/questions/341383/possible-nxdomain-hi...
This can also be set via DHCP.
I stumbled on this earlier this week: https://twitter.com/mholt6/status/838504217731948544 and found it amusing but confusing in two ways:
1) The prompt is pointing to the "Secure" icon; I thought it was asking me if I wanted to downgrade my protocol to HTTP.
2) The domain "google" made me and several others wonder if there was a hosts file entry for "google", which turns out there isn't.
No, of course, the real problem is much more complicated; a strange twist of omnibar meets DNS meets HSTS. This is definitely an edge case, but might be a glimpse into the complicated future of gTLDs and the emergence of ever-more web standards...
Or alternatively "the web is hard if you sacrifice any kind of structure to make a quick buck".
On the risk of sounding get-off-my-lawn-ish, but TLDs used to be assigned using some relatively simple, service-agnostic rules: A hierarchical system for ccTLDs, plus a small set of universal gTLDs plus some historic quirks. Nowadays assignment seems to be solely by who pays most.
You don't. At least not to me. The new gTLDs are clearly a money grab on the part of ICANN.
The ICANN has really gone into dark territory with this decision to open things up. It's fitting that their wiki logo is some unruly weed taking over the world: https://icannwiki.org
Now, let's make every program more user friendly by obscuring the meaning of our input fields and creating very complex rules for how they'll act... Oh, wait, our programmers aren't able to understand our rules anymore? Nah, we are an AI company, we can live with that.
(Search box, shortcut ctrl-K does that.)
Chrom(e|ium) will suggest to navigate to http://google if you're opening google.com
One of these days I'll just disable it altogether.
From a technical perspective, there's no difference between `www.example.com`, `example.com` and `com` having an A record.
From a best-practices standpoint, A records on TLDs aren't liked (just see this submission here when looking for a reason) and thus exist only very rarely.
Technically the root zone has to have NS records. So even records without a label at all should work. of course you can not resolve them without a static zone configuration.
If OP thought it was misleading, then he was right to adjust it?
