EarthLink Establishes Their Own "Site Finder"

Guppy06 writes "Last week, instead of a regular DNS error, EarthLink's DNS servers started to return a redirect to earthlink-help.net, a site that bears a close resemblance to VeriSign's much-maligned Site Finder, to their subscribers. According to their official blog at Earthling, "By presenting users with contextual help based upon the non-existent domain the user entered, we believe we are improving the EarthLink user experience with a system that will not interfere with other network processes." Most of the responses in said blog posting aren't positive."

Comments

Re:icann should ban this

[Qzukk]

Nah, in this case it doesn't break the internet, it only breaks Earthlink's net, and only then software that expects it to work "correctly" which is probably only used by 5% of their customers. If you're going to do this, you might as well do it at the ISP level, since then people can switch to the other ISP (assuming that both cable and dsl don't start doing this), and the ISPs don't have it forced on them by some higher level.

Re:The "Unix Way" vs "Everyone Else"

[TheRaven64]

Here's an example:

I am configuring my email client. I typo when I enter the mail server's domain name. When my client tries to connect to the server, it receives an NXDOMAIN error, and tells me 'the host you are looking for does not exist.'

Now, I try the same thing on EarthLink. This time, the error I get from my client is that the mail server does not respond to connections on the IMAP port. Now what do I do? I call up the server administrator (assuming it's not my server) and tell him to fix it. He tells me it works fine for him. It takes me twice as long to find the problem.

this doesn't just affect HTTP

[keithmoore]

The biggest problem with this is not the ads (though they are annoying). This DNS hack doesn't just affect HTTP, it affects every application that does DNS queries. The claim that the system is configured to only handle NXDOMAIN HTTP traffic is a bald lie. There is no way for the DNS server to determine whether a query is being done for HTTP or for some other protocol.

When an application queries DNS for A records (IPv4 addresses) for a particular domain, one of three things should happen:
1. if there are A records for that domain, they should be returned
2. if there are no A records for that domain but there are other records, "no information" should be returned
3. if there are no records of any type for that domain, "no such domain" (NXDOMAIN) should be returned

What Earthlink's servers appear to be doing is the following:

1. if there are real A records for that domain, they are returned
2. if there are no A records for that domain, return A records for several hosts that don't belong to that domain.
if the application tries to talk HTTP to port 80 on any of those hosts and supplies the Host: query request
(standard in HTTP 1.1) the HTTP server will do a search for the domain that appears in the Host: request
and return HTML that suggests other domains that appear to be similar to the one given in the Host: request.
however if the application tries to talk to other ports on that machine it will get "connection refused" or
it will time out.

(the behavior is actually a bit more complicated than that. the behavior seems to be dependent on the IP address from
which the queries were made - so if you make the query to their servers from a host that isn't on Earthlink DSL
you will apparently get normal results. the behavior also seems to be dependent on the domain being queried.)

There are several things wrong with this behavior:

1. It's not reporting the error correctly. Applications that do DNS queries quite reasonably expect NXDOMAIN
to be returned if the domain does not exist, and "no information" to be returned if there are no records of
the type they're looking for - not a list of apparently valid IP addresses pointing to hosts that have nothing
to do with that domain. Many applications behave differently depending on the error condition. "connection
refused" and "connection timed out" are often treated as temporary errors - the application assumes that the
remote server is rebooting or isn't reachable and tries again later. "no such domain" is more often treated
as a permanent error, or one that requires immediate user attention. So this Earthlink change can cause
applications other than web browsers to behave improperly, or to give misleading error messages.

For example: if an email server is trying to send mail to someone at a particular domain, it will first do
a query for MX records to determine if there are any mail servers assigned to that domain. If the MX query returns
no answers, it may then issue a separate query for A records. If this happens the Earthlink DNS server will return
bogus A records and the email server will try to send the mail to Earthlink's servers rather than bouncing the mail
like it should. When Earthlink's servers refuse the connection, the email server will treat the condition as a
temporary error and retry at intervals for several days. As a result, mail for nonexistent domains (say, bounced
spam) can clog up the email server's queues and slow things down.

2. It is hiding other records associated with that domain. Say an application will

Re:this doesn't just affect HTTP

[keithmoore]

SRV records only affect protocols that are defined to use SRV records. most protocols are not defined to use them, and most application codes therefore don't do SRV queries.

even if an application did an SRV query, though, a nonexistent domain wouldn't list any SRV records, and Earthlink's server would return "no such domain" in response to a SRV query. then the application would presumably fall back to querying for A records, and Earthlink's server would return the bogus A records.

(I checked just now, and Earthlink's servers don't appear to return bogus answers in response to queries for _http._tcp.xxx.yyy - they respond with NXDOMAIN even if they give answers for xxx.yyy)

Re:Voting with one's dollars is not always effecti

[Cygfrydd]

A strong recommendation for someone who works in advanced broadband svcs @ BH Tampa Bay: insist on speaking to a Level IV rep to make account changes. Regional customer service is notorious for wrecking accounts when making changes involving internet service. We Level IV's are the ones who are called on to fix said accounts. In CS's defense, we have to deal with an unneccessarily complex billing system that isn't as straightforward as it should be.

Fight fire with fire

[Anonymous Coward]

If they want to play that game then maybe you should just use:

http://www.opendns.com/

They have easy to use instructions for changing your computer to point to their servers.

If you don't like their service, you can always revert back to what your are annoyed with now...

I have been using them for more than a month with no problems.

We got bit by this Friday

[tweek]

Attempting to test VPN-related DNS lookups with a business partner.

I IMMEDIATELY called earthlink business T1 support and the guy on the phone had no idea what I was talking about.

Why would a company roll out something like this WITHOUT telling its support people and without letting customers know in advance? Why do they not have an opt out option?

I'm in the process of going over the contract for our T1 to see if it's early enough to break (the service was purchased before I came on board but only by a month or so).

I'll get a Speakeasy T1 and be done with it. Why is it so damn hard to find a provider who gives you IP with no bullshit?

Re:What's the problem?

[Anonymous Coward]

Too many people confuse HTTP 404 Page Not Found with DNS NXDOMAIN Domain does not exist. Think about it. If you went to a site, and that sites web server gave you a 404, OBVIOUSLY DNS RESOLVED AND YOU CONNECTED TO THE WEB SERVER. The PAGE you wanted didn't exist, but OBVIOUSLY the DOMAIN exists, and resolved successfully. THATS a 404. I read some of the blog postings and saw another one where a user confused a 404 with NXDOMAIN.

Broken DNS Servers vs. Broken Web Caching

[billstewart]

Most of the PR from Earthlink is extremely fuzzy about what it's actually doing. The pages it points to at Barefruit say that they're doing web-proxy manipulation, not DNS manipulation, and that if their web-proxy caching server detects a DNS miss, it'll go to the substitution advertising page. That means that if you try email, or ssh, or telnet, or ping or traceroute, or some other non-http protocol to a mistyped domain, you should still see the correct DNS message, though it's not clear whether they're doing it with https (that'd be very evil) or http on ports other than 80 (e.g. www.example.com:8080, which would be a relatively bad idea). They do say that they're not messing with email, but it's not clear that they're really doing it through the web proxy or whether they're doing something else instead.

Re:Broken DNS Servers vs. Broken Web Caching

[XanC]

There's nothing fuzzy about what's actually happening. I can ping any random string of garbage and get a response. That's no Web-proxy problem; it's a fundamental breakage of DNS.

Re:The "Unix Way" vs "Everyone Else"

[Bitsy Boffin]

The point is, it's the BROWSER that should be presenting the user with options of what to do when a domain is unresolvable, some browsers might just display an error, others a search, others might try and fix it, others might ask the user what they want to do... Earthlink has usurped that.

As others have pointed out, it's not just the web that's the problem, silently resolving invalid domains to some other IP has much wider ramifications, from spam elimination, to email security.