www.consumeraffairs.com/news04/2007/11/verizon_search.html
November 3, 2007
Subscribers to Verizon's high-powered fiber-optic Internet service
(FiOS) are reporting that when they mistype a Web site address, they
get redirected to Verizon's own search engine page -- even if they
don't have Verizon's search page set as their default.
I know this is just anecdotal, but I have Verizon FIOS in Northern Virginia and I have not seen sitefinder pop up. I just verified with a few sites to make sure.
allan
Verizon != VeriSign, despite what people think.
A single provider doing this is not equivalent to the root servers doing it. You can change providers, you can't change "." in DNS.
Plus lots of providers do this, in the US and abroad.
Lastly, it's trivial to get around, unless your provider is transparently intercepting / redirecting port 53.
Patrick W. Gilmore wrote:
Verizon != VeriSign, despite what people think.
A single provider doing this is not equivalent to the root servers doing it. You can change providers, you can't change "." in DNS.
Charter has been doing this for quite some time. If you have security/network/diagnostic tools where you need a DNS failure to get a valid result, you're out of luck, they resolve everything, and you only know something happened if you were doing http to start with. Mistype a telnet, ssh, ftp, mail, etc hostname and you're in for some considerable confusion until you figure out what's going on...
Jeff
I don't think we're going to put the genie back in the bottle, despite
the best efforts of some IETFers.
I just wish the IETF would acknowledge this and go ahead and define a
DNS bit for artificial DNS answers for all these "address correction" and "domain parking" and "domain tasting" people to use for their keen
"Web 2.0" ideas.
And for all the other non-Web protocols which get confused, can treat that artificially generated crap/answers like NXDOMAIN. Yes, I know
it sounds like the evil bit; but if these folks are so convinced people
really want this crap/address correction...
They're not convinced their customers want it; they simply say that
publicly. They're convinced that (a) they're going to make money from
it from equally sleazy advertisers/marketdroids, and (b) their
customers will be either too clueless or too sheeplike to do anything.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Sean Donelan wrote:
I just wish the IETF would acknowledge this and go ahead and define a
DNS bit for artificial DNS answers for all these "address correction"
and "domain parking" and "domain tasting" people to use for their keen
"Web 2.0" ideas.
Yes, it sounds like the evil bit. Why would anyone bother to set it?
Eliot
Two reasons
1) By standardizing the process, it removes the excuse for using
various hacks and duct tape.
2) Because the villian in Bond movies don't view themselves as evil. Google is happy to pre-check the box to install their Toolbar, OpenDNS is proud they redirect phishing sites with DNS lookups, Earthlink says it
improves the customer experience, and so on.
If they don't set the bit using the standardized process, then they lose their fig leaf.
* Sean Donelan:
I just wish the IETF would acknowledge this and go ahead and define a
DNS bit for artificial DNS answers for all these "address correction"
and "domain parking" and "domain tasting" people to use for their keen
"Web 2.0" ideas.And for all the other non-Web protocols which get confused, can treat
that artificially generated crap/answers like NXDOMAIN.
It's not that simple, you need three states: original, rewritten NODATA,
and rewritten NXDOMAIN. Perhaps a general "original RCODE" is
necessary; I haven't checked this.
Sean,
Yes, it sounds like the evil bit. Why would anyone bother to set it?
Two reasons
1) By standardizing the process, it removes the excuse for using
various hacks and duct tape.2) Because the villian in Bond movies don't view themselves as evil.
Google is happy to pre-check the box to install their Toolbar, OpenDNS
is proud they redirect phishing sites with DNS lookups, Earthlink says it
improves the customer experience, and so on.
Forgive my skepticism, but what I would envision happening is resolver
stacks adding a switch that would be on by default, and would translate
the response back to NXDOMAIN. At that point we would be right back
where we started, only after a lengthy debate, an RFC, a bunch of code,
numerous bugs, and a bunch of "I told you sos".
Or put another way: what is a client resolver supposed to do in the face
of this bit?
Eliot
This is true, but Verisign wasn't doing it on root servers, IIRC, but
on the .com and .net TLD servers. Not that that's any better.
The last time I heard a discussion of this topic, though, I heard
someone make the point that there's a big difference between
authority servers and recursing resolvers, which is the same sort of
point as above. That is, if you do this in the authority servers for
_any_ domain (., .com, .info, or .my.example.org for that matter),
it's automatically evil, because of the meaning of "authority". One
could argue that it is less evil to do this at recursive servers,
because people could choose not to use that service by installing
their own full resolvers or whatever. I don't know that I accept the
argument, but let's be clear at least in the difference between doing
this on authority servers and recursing resolvers.
A
Andrew Sullivan (andrew) writes:
The last time I heard a discussion of this topic, though, I heard
someone make the point that there's a big difference between
authority servers and recursing resolvers, which is the same sort of
point as above. That is, if you do this in the authority servers for
_any_ domain (., .com, .info, or .my.example.org for that matter),
it's automatically evil, because of the meaning of "authority". One
could argue that it is less evil to do this at recursive servers,
because people could choose not to use that service by installing
their own full resolvers or whatever. I don't know that I accept the
argument, but let's be clear at least in the difference between doing
this on authority servers and recursing resolvers.
Fully agreed. In some ways, if your ISP is stupid enough to want
to do this, and they don't ever want to return NXDOMAIN to their
customer's resolvers, and their ToS specify that they do it, well,
they're welcome.
But the moment you start to mess around with the authority that is
being delegated to you, then it's Evil.
I think ICANN should probably come out and specify that doing
wildcard matchin on TLD delegations is Not A Good thing.
Phil
a message of 29 lines which said:
One could argue that it is less evil to do this at recursive
servers, because people could choose not to use that service by
installing their own full resolvers or whatever.
It depends.
There are three possible ways for an access provider to do it, in
order of ascending nastiness:
1) Provide, by default, DNS recursors which do the mangling but also
provide another set of recursors which do the right thing (and the
user can choose, for instance via a dedicated Web interface for his
account).
2) Provide DNS recursors which do the mangling. Power users can still
install BIND on their laptop and talk directly to the root name
servers, then wasting resources. (Variant: they can add an ORNS in
their resolving configuration file.)
3) Provide DNS recursors which do the mangling *and* block users,
either by filtering out port 53 or by giving them a RFC 1918 address
with no NAT for this port.
I've seen 1) and 2) in the wild and I am certain I will see 3) one day
or the other.
A single provider doing this is not equivalent to the root servers
doing it. You can change providers, you can't change "." in DNS.This is true, but Verisign wasn't doing it on root servers, IIRC, but
on the .com and .net TLD servers. Not that that's any better.
Touché. Guess I wasn't awake when I wrote that. But .com/.net is still bad (as you say).
The last time I heard a discussion of this topic, though, I heard
someone make the point that there's a big difference between
authority servers and recursing resolvers, which is the same sort of
point as above. That is, if you do this in the authority servers for
_any_ domain (., .com, .info, or .my.example.org for that matter),
it's automatically evil, because of the meaning of "authority". One
could argue that it is less evil to do this at recursive servers,
because people could choose not to use that service by installing
their own full resolvers or whatever. I don't know that I accept the
argument, but let's be clear at least in the difference between doing
this on authority servers and recursing resolvers.
I would argue against such a blanket statement. Doing this in an authority for a TLD is bad, because most people don't have a choice of TLD. (Or at least think they don't.)
But if I want to put in a wildcard for *.ianai.net, then there is nothing evil about that. In fact, I've been doing so for years (just 'cause I'm lazy), and no one has even noticed. It is my domain, I should be allowed to do whatever I want with it as long as I pay my $10/year and don't use it to abuse someone else.
Hijacking user requests on caching name servers is very, very bad, because 1) the user probably doesn't know they are being hijacked, and 2) even if the user did, most wouldn't know how to get around it. So you're back to the TLD authority problem, there is no choice in the matter.
Yes, let's let the IETF go off for 7 years to debate and try to put
into an RFC something else that won't actually be used. Sorry Sean,
you've lost me on this one. 
John
When Verisign hijacked the wildcard DNS space for .com/.net, they
encoded the Evil Bit in the response by putting Sitefinder's IP
address as the IP address. In theory you could interpret that as
damage and route around it, or at least build ACLs to block any
traffic to that IP address except for TCP/80 and TCP/UDP/53. But if
random ISPs are going to do that at random locations in their IP
address space, and possibly serve their advertising from servers that
also have useful information, it's really difficult to block.
Does anybody know _which_ protocols Verizon's web-hijacker servers are
supporting? Do they at least reject ports 443, 22, 23, etc.?
In contrast, Microsoft's IE browser responds to DNS no-domain
responses by pointing to a search engine, and I think the last time I
used IE it let you pick your own search engine or turn it off if you
didn't like MS's default. That's reasonable behaviour for an
application, though it's a bit obsequious for my taste.
authority for a TLD is bad, because most people don't have a choice of
TLD. (Or at least think they don't.)
I don't think that's the reason; I think the reason is that someone
who needs to rely on Name Error can't do it, if the authority server
is set up in such a way as to hand out falsehoods.
But if I want to put in a wildcard for *.ianai.net, then there is
nothing evil about that. In fact, I've been doing so for years (just
'cause I'm lazy), and no one has even noticed. It is my domain, I
should be allowed to do whatever I want with it as long as I pay my
$10/year and don't use it to abuse someone else.
I'm not sure I agree.
I think that it's probably true that, if you have a wildcard that
actually resolves so that everyone can use the services they thought
they were trying to talk to, there's no basis for complaint (to the
extent one thinks wildcards are a good idea). But if you're doing
wildcarding so that people get all manner of strange results if they
happen not to be arriving on port 80, then I think it's evil in any
case.
I _also_ think it's evil to serve wildcards on authority servers for
largeish (100s, anyway) zones, in almost every case. If the domain
gets big enough that you have that many hosts, then others' ability
to diagnose surprises depends partly on their ability to get
meaningful answers about what things are and are not out there on the
net. For very small domains, perhaps there is some argument that the
user community is so small that the benefit outweighs the costs. But
in truth, if I had my 'druthers, I'd go back in time and eliminate
the wildcard feature from the outset, at least for the public
Internet. (I can see an argument in split-view contexts, note.)
And no, it isn't "your domain". This is one of the pervasive myths
of the namespace -- one that has been expanding as privatisation of
the DNS has become the norm. The truth is that namespaces are
rented, and are subject to all manner of terms and conditions. If
you don't believe me, read your contract with your registrar.
There are current conditions about labels' relations to other labels,
for example, in all gTLDs (these are the UDRP policies). There are
rules about what you may and may not register in .aero or .pro, and
what you must and must not do with the resulting domain once you've
been approved. Many country codes have rules about residency, and if
you move you will find you lose your domain as well.
Policy -- or, I suppose, politics -- is what constrains TLDs from
enforcing more stringent additional rules. I can't make up my mind
whether a "no wildcard, ever" policy would in fact be a good one to
have. But it is surely open, and something that could be imposed on
gTLD regisrtations with sufficient support inside ICANN. (There are
some rather tricky regulations in this area, though.)
Hijacking user requests on caching name servers is very, very bad,
because 1) the user probably doesn't know they are being hijacked, and
2) even if the user did, most wouldn't know how to get around it. So
you're back to the TLD authority problem, there is no choice in the
matter.
This is the response I expected, but I have to say that I'm
frustrated by the answer, even during the alternate hours when I
agree with it. What we're really saying in this case (and I mean
"we", because I say similar things often enough) is that consumer
choice is an uninteresting lever, because most consumers are mindless
sinks who'll take whatever's given to them. If that's the case, why
is everyone furious when various kinds of heavy regulations are
proposed? We can't have libertarian paradise and guaranteed correct
behaviour simultaneously. Libertarians claimed historically that
this dilemma could be solved by market mechanisms. If the market
mechanism won't actually work, though, what alterantive correction do
you have to propose beyond "some government sets the rules, and
enforces them"? Isn't that regulation?
A
Hi,
Based on the procedures they document to opt-out, doesn't look like Sitefinder-like authoritative wildcarding. Looks more like caching server NXDOMAIN rewriting. If so, easy to get around: just run your own caching server. Also means you can't defeat this using DNSSEC (if it was actually deployed).
Regards,
-drc
I think ICANN should probably come out and specify that doing
wildcard matchin on TLD delegations is Not A Good thing.
You mean like http://www.icann.org/committees/security/sac015.htm ?
Regards,
-drc