There’s a term for this – typosquatting. It might not be illegal, but it is unethical.

If someone tries to visit my site but misspells the URL, I want them to see “Page Not Found” and let them try again. But instead they’ll see Verizon’s page, and some visitors won’t understand what has happened or realize that they typed the name wrong.

This raises trademark issues as well, because Verizon will be able to make money from misspelled trademarked names.

I use 4.2.2.2 a forwarder now and then it certain situations, and I have never had a page return a verizon search page.

I had a friend tell me about this problem when he misspelled my website URL but I didn’t understand how that could happen.

I never heard of the term “typosquatting” before today. I learned something new today. And Rob, I think the betting would be too one sided.

I just tried it. Typed in some bogus URL on my Verizon FIOS service. Verizon took my attempt and fed it to yahoo search for me automatically. I think they are just trying to help the grandmas who don’t know what they are doing.

The only ads that appear are the ads that normally appear if you type the url in a search engine.

I think you completely missed the point of what they are doing, and it’s yahoo feeding ads, not verizon.

that “web” and Internet” are synonymous.

One of the many problems with this ill-conceived idea is that
it presumes that DNS is used solely to support HTTP. It’s not,
of course, and the impact on other protocols can be substantial.

For example, it is a best practice to refuse mail which purports
to be from any host or any domain that does not resolve, or from
any IP address which does not resolve to a host.

To illustrate: I get an incoming SMTP connection from 1.2.3.4.
I lookup rDNS for 1.2.3.4; if that lookup fails, I 550 the connection
and hang up — the host has failed to meet minimum requirements for SMTP clients. If that lookup succeeds, I
query forward DNS for the hostname I just got back, and
550 the connection if it doesn’t resolve. If that test succeeds, and I
allow the SMTP conversation to continue, then eventually
the other side will specify a sender, say fred@flintstone.example.com. I then look up example.com;
if that lookup fails, I 550 the connection and hang up — it’s
foolish to accept mail from domains that don’t exist. If that
lookup succeeds, I pull the MX records for example.com and
see if they’re valid — if they point to bogon space, I 550 the
connection and hang up, because the message can’t be replied
to, therefore there is no point in accepting it. I might also check
for flintstone.example.com — is there an MX record for it? Is it covered by a wildcard MX? Is there an A record (so that I can
fall back to that in the absence of an MX record)?

The gist is that these are all basic sanity checks designed
to refuse mail that’s either (a) obviously bogus or (b) coming
from an incorrectly-configured host, since long experience (long painful bitter experience) has shown that the only way to get the attention of operators of such hosts is to make the problems obvious to them. These basic sanity checks have as a
desirable byproduct considerable effectiveness against unwanted SMTP traffic. (Which is why some MTAs, e.g. sendmail, include
them as easily-configurable options.)

Now consider what happens to them if someone starts
forging DNS replies a la Verizon. Consider further what happens if those forgeries start happening with no warning. And consider still further that this is just one small example with just one of many application protocols that rely on DNS returning what it’s supposed to, not what is convenient.

The bottom line is that this is a really, really bad idea
executed by a company that’s clearly trying to monetize DNS
without regard for the degradation of service it’s imposing
on its own customers.