NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Comcast files "recommended practices" draft RFC with IETF for DNS Redirection
I can't speak for the ISPs motivations, but you're right that they are
probably driven by profits (though I'd argue they are going to be
getting short-term profits and the expense of long-term unhappy
customers) but I will point out that there are lots of legitimate
reasons people want to do DNS error redirection. 12 million + people
have opted to use the services of my company, OpenDNS, to make their
internet safer and more reliable. That's why I was willing to lend a
few thoughts to the IETF document.
-David
[ Note that David (Reed's) message didn't discuss the profit issue,
so your response is actually to my comment. However, I agree,
there are legit reasons why individuals or organizations may
choose to use alternate DNS services such as yours. And I have
no problems at all with anyone choosing whichever DNS resolver
that they might wish. However, I know of no case where a major ISP
has introduced a DNS diversion service on an *opt-in* basis.
Every one I've seen has been opt-out (usually by means of users
changing their DNS settings manually) and -- judging from people
who contact me on this topic -- often very badly (if at all)
explained to ISP customers. Seriously, does anyone know of a
major ISP that introduced DNS diversion completely opt-in?
-- Lauren Weinstein
NNSquad Moderator ]
On Jul 9, 2009, at 2:06 PM, David P. Reed wrote:
>
>
> http://tools.ietf.org/html/draft-livingood-dns-redirect-00
>
> I note that this draft RFC proposes practices that routinely return
> *valid* responses to erroneous DNS lookups, and encourage an opt-out
> policy rather than an opt-in policy.
>
> The sole justification is that the default way that a browser such as
> Firefox or IE would present an error message is inadequate for users,
> thus an ISP should take matters into its own hands to fix that
> cosmetic
> problem, rather than asking the browser vendors to do a better job!
>
> And the side effects identified do not include the impact on http
> requests not generated by typing into web browsers, but instead used
> as
> part of "web 2.0" service apis and other uses of port 80 that do not
> arise from end users typing into the url bar of their browser.
>
> One might ask why the sole justification given for this misuse of DNS
> to patch an application weakness is the only one?
>
> And even more so, why this is such an urgent problem that ISPs must
> fix
> it via a flawed and risky solution, rather than the makers of browsers
> fixing it in the most logical place?
>
> The potential to disrupt non web-browser features is noted in the
> "draft
> RFC", but instead of a balanced analysis of benefits and costs to
> other
> uses, the draft is silent. In fact, the draft refers to this as
> "enhanced" functionality.
>
> I expect the wiser heads at the IETF to prevail.... This is a
> solution
> to a non-existent "problem", with bad side effects.
>
> While this is not exactly the same as directing a misdialed phone call
> to call a Caribbean phone company number with the consequent and
> unavoidable billing charge to the user, it seems very close to that
> sort
> of thing - a surprise to all application developers, and a
> modification
> to the expected semantics of directory lookup.
>
> [ I agree with David. If IETF goes along with this proposal, there
> is something very rotten in Denmark. What's really amusing about
> the referenced document though is that for all its verbiage in
> which it tries to establish a "need" for such DNS redirect
> services -- mostly focused on highly questionable assumptions
> about malware protection and legal mandates -- it fails to
> mention the primary reason that ISPs implement DNS redirects.
>
> This is of course use of such DNS diversion services to create
> profit centers, by shunting users to ISP-affiliated search
> engines and affililated ad delivery services, attemping to
> monetize users' interactions with the broader Internet by
> capturing low-level transactional communications to which the ISP
> has privileged access.
>
> -- Lauren Weinstein
> NNSquad Moderator ]
>