Re: Hey, SiteFinder is back, again...

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

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

The other half of this is that it probably isn't
*appropriate* to encourage
abuse of the DNS in this manner, and if you actually add a
framework to do
this sort of thing, it amounts to tacit (or explicit)
approval, which will
lead to even more sites doing it.

Consider where it could lead.  Pick something that's already
sketchy, such
as hotel networks.  Creating the perfect excuse for them to
map every domain
name to 10.0.0.1, force it through a web proxy, and then
have their tech
support people tell you that "if you're having
problems, make sure you set
the browser-uses-evilbit-dns".  And that RFC mandate to
not do things like
this?  Ignored.  It's already annoying to try to determine
what a hotel
means if they say they have "Internet access."

Reinventing the DNS protocol in order to intercept odd stuff
on the Web 
seems to me to be overkill and bad policy.  Could someone
kindly explain
to me why the proxy configuration support in browsers could
not be used 
for this, to limit the scope of damage to the web browsing
side of things? 
I realize that the current implementations may not be quite
ideal for 
this, but wouldn't it be much less of a technical challenge
to develop a
PAC or PAC-like framework to do this in an idealized
fashion, and then 
actually do so?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me
one chance [and] then I
won't contact you again." - Direct Marketing Ass'n
position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way
too many apples.