No (recognised) hostname given

You must supply a hostname which is known to this webserver.

   hostname == sitename == the bit between http:// and the next /

Why is this happening, instead of letting me see a default site?

To defend against a very nasty type of targetted attack. Suppose that there exists someone trying to probe their way into our system? Even if not particularly likely for some of us, it's good practice to assume that there might be someone and to get into the habit of defending against it.

Key points for this are:

• It's easy to get web-hosting allowing use of any domains which you register. This applies to everyone, including attackers.
• DNS hosting is available with point-and-click interfaces. Any attacker worth worrying about is going to take the minimal amount of time to at least learn about hostname to IP address mappings.
• JavaScript is common. So are Frames. So are XSS bugs in browsers.

The attacker uses frames. The top frame is loaded from www.evil.example.net. One of the child frames is loaded from victim.evil.example.net. For some browsers, the parent frame will be able to use JavaScript to control the child frame, because both are in the same domain, right? Well, so what? The attacker controls DNS for evil.example.net, so they can make “victim” point at any IP address they want. Including one of our IP addresses, even if an address is in RFC 1918 space.

Net result: if the server responds with content when given unknown hostnames then an attacker can do anything to any web-pages with JavaScript; all they need is web-hosting and DNS control, and for someone to be nudged into visiting their site with a frames-capable brower which has JavaScript enabled (which is every major browser and most of the minor ones too).

In theory, these days browsers have learnt to protect against this with careful application of same-origin policies. In practice, there is no end in sight to the stream of browser security holes, for every web-browser implementing a scripting engine, which allow these browser-side cross-site scripting (XSS) bugs. So fairly often and without prior warning, the “some” browsers mentioned before suddenly become “many” or even “most”.

Because the entire attack can be neutralised on the webservers which hold the content to be protected, without having to worry about the patch status of every client browser or the presence of bugs not publicly disclosed, and because the fix is normally easy and lightweight, all webservers should ideally be careful to only respond to hostnames which they explicitly know about. This ideal might not always be practicable, but for typical webservers it is.

Latest example: Same-origin protection doesn't help when the same hostname is being requested. If the hostname is served with short TTL and uses resources on the same hostname, a malicious DNS server can serve RFC 1918 address-space results for the second query. This is a “DNS rebinding” attack. You can try to protect against it by:

• have your recursive resolvers refuse to let external zones resolve to RFC 1918 address-space; this will probably become more common.
• having the browser latch onto an IP address; this reduces the quality of service provided by legitimate sites which load-balance, if they try to direct you away from an overloaded component.
• Refuse to serve content for an unknown Host: header. As this page explains.

Why don't you provide a link here to the real site?

Which real site?

• Did we give you a new hostname and not configure it correctly?
  In that case, we messed up and we're in some trouble, but which hostname is “correct” for you? Programming to figure that out reliably is difficult and an area of much research (the field of AI, artificial intelligence). Providing a link to the wrong site can easily be worse than providing no link at all.
• Do you know a hostname other than www and did you try it?
  The Internet != The Web
  Again, figuring out which website to show you, for some arbitrary hostname, is non-trivial.
• Do you know the IP address but not the site name?
  How come?
  Hopefully we would never mess up badly enough that you wouldn't know what hostname to use when retrieving content from this webserver but would know the address of the server. We can't conceive of such a case. If this is a limit of our imagination and we do mess up that badly, then perhaps we deserve to lose you as a visitor.
  But really, the only class of situations where people do know the IP address and not the site is because they're going through entire blocks of IP address space, finding webservers and then looking to see what's on the webserver. If you're not an administrator of the server, then this is an attack and in many cases is illegal in many jurisdictions. (See all those cop-out words?)

Why don't you try a search engine to find the content that you were after? And no, there are no links to search engines on this page, to keep bad hostnames or raw IP addresses from appearing in Referer: logs and discovering that some search engines are using these sites as input for their web-crawl systems. That might lead to legitimate traffic to this page, but we like to be able to review the webserver logs and determine if we've misconfigured something or if someone's doing something they shouldn't. In the former case, we have an extra type of feedback to correct problems, which is always good. In the latter case we can decide whether or not to report suspicious activity. We're not always nice people.