That won't work for virtual hosted web sites, which is most web sites, because the unrecognized host name in the Host header which will hit the default host on the target web server instead of the correct virtual host, unless that web server is configured to recognize the foo.ipq.co host name.

I don't think it implies ownership, but it could certainly mislead users who are not familiar with the purpose of DNS. It's always been trivial to point one of your own domain names at someone else's IP address (or create a CNAME), but this hasn't been the source of any major abuse that I'm aware of, probably because you don't have any control over the remote resource.

Other than the servers checking host per other people's comments, this is basically just how dns works... anybody with a domain can point any subdomain or domain they own to any IP they want. I can't see any practical way around this at the dns level.

On top of it I was able to create an account on hackernews.ipq.co version of hackers news called blahhah.

Maybe y-combinator doesn't care but I think I would!

Why should anyone care? You would do more damage by pointing to a fake site like countless phishing sites already in existence.

It's up to the web site owner to check HTTP Host.

You could equally have registered hakernews.com and CNAME'd it

I agree, web site owners should be checking the host. Most of them don't.

And yes I could easily create a CNAME record to do the same thing but you have to have a reasonable amount of knowledge to do so. Unlike this tool.

I disagree. Most HTTP configs I've seen use virtual hosts, which means that the correct Host header is the only way to get the server to send the request to the right site.

(When dealing with SSL, then things are different, because you can't authenticate the connection until you get the cert, you can't send data until the connection is authenticated, and the server can't give you the right cert until it gets the Host. Fundamental conflict, leading to one-IP-per-domain-name, or a pricey wildcard certificate. So in that case, the server doesn't care much about Host anymore, but you are still protected because the domain name that the browser sees has to match the one in the cert, or the browser gives you the OH NOES dialog. But I digress.)

It's not even necessary to check the HOST header. Simply use name-based virtual hosts and forbid access to the default virtual host. This denies access to simple drive-by bots that crawl IP ranges and others that request a HOST that isn't configured as a virtual host.

FYI: Name based virtual hosting uses the Host Header to route.

http://en.wikipedia.org/wiki/Virtual_hosting#Name-based

Remember, TCP/IP doesn't specify Hostname, messages are only routed by IP.

HTTP 1.1 specifies the Host Header specifically to enable features like name based virtual hosting.