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.
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.