From Dave Farber's IP list...
Galvin said that the continued opposition stems from "an ideological
belief by a narrow section of the technological community who don't
believe you should innovate the core infrastructure of the Internet."
Again, the close knit community responds:
_ INNOVATE THIS! _
>_| |_|
> > /^^^\ | |
_| |_ (| "o" |) _| |_
_| | | | _ (_---_) _ | | | |_
> > > > >' | _| |_ | `| | | | |
> > / \ | |
\ / / /(. .)\ \ \ /
\ / / / | . | \ \ \ /
\ \/ / ||Y|| \ \/ /
\__/ || || \__/
() ()
>> >>
ooO Ooo
and this helps fix thed "biased technologists" image, how?
Again, the close knit community responds:
[ ... ]
If they give us 90 days headstart, by the time its supposed to start
it'd be blocked everywhere and Microsoft and Netscape would have released
a fix to redirect users to the page of their choice. If 90 days is not
enough to release such updates to software, lawyers can make sure its
delayed in court long enough so that everyone is ready to block it.
But I don't think we need to spend OUR resources to create application
workaround for the problem that does not need to exist in the first place!
From Dave Farber's IP list...
> VeriSign Reconsiders Search Service
This is an interesting suggestion that I saw on another list. It may
or may not be feasible, but it is certainly interesting, I must say.
srs
This is an interesting suggestion that I saw on another list. It may
or may not be feasible, but it is certainly interesting, I must say.
why? that is, why kill sitefinder? there's been plenty of invective
on both sides, and a lot of unprofessional behaviour toward verisign
employees at a recent nanog meeting, which tends to bolster verisign's
claim that only the outlying whackos are actually opposed to sitefinder.
this is nanog@. if you think sitefinder poses an operational problem
then please describe it (dispassionately). if you think there is an
operational thing that ought to be done in response to sitefinder, then
please describe that (dispassionately). the response you included...
> There's an easy way to kill sitefinder stone cold dead.
> ...
> It would be trivial to create a bot to start walking through every
> possible 20 letter domain name - and if ICANN held them to the rules,
> Verisign would be rather poorer in short order.
...does not describe an operational problem, and gives a financial remedy.
Paul Vixie wrote:
why? that is, why kill sitefinder? there's been plenty of invective
on both sides, and a lot of unprofessional behaviour toward verisign
As I said, the measure may or may not be feasible - in fact, given that the domains are not registered, it most certainly is not feasible.
this is nanog@. if you think sitefinder poses an operational problem
then please describe it (dispassionately). if you think there is an
operational thing that ought to be done in response to sitefinder, then
please describe that (dispassionately). the response you included...
You are of course right. The problem posed by sitefinder in its previous form has been discussed already, and our bind / djbdns resolvers have been patched appropriately to ignore the aberrant behavior introduced by verisign.
There ends the operational impact of verisign's decision, till such time as they revive sitefinder, and till such time as resolver patches in existence are modified if necessary to cope with the new edition of sitefinder.
regards
-srs
Has Verisign published a in-depth technical discussion of what they
are thinking of deploying, including details such as what happens to
MX entries, what they intend to do with mail misrouted to them, and so on?
(Yes, that's an operational issue - if they are harvesting and selling a
list of known-good From: addresses on misrouted mail, this will eventually
end up adding to spam - and that's operational)
<>
You are of course right. The problem posed by sitefinder in its previous
form has been discussed already, and our bind / djbdns resolvers have
been patched appropriately to ignore the aberrant behavior introduced by
verisign.
There ends the operational impact of verisign's decision, till such time
as they revive sitefinder, and till such time as resolver patches in
existence are modified if necessary to cope with the new edition of
sitefinder.
But that's a HUGE operational impact. Now we're all expected to go around and run patched versions of our resolvers or nameservers to get around a company using shady tactics to just increase it's bottom line! Lets say it takes on average about 10 minutes per machine to do the necessary changes, I'll have to spend several hours installing patched software for something that is harmful. They remove the ONLY method for testing if a domain exists or not, and certainly the only 'lightweight' method.
Not to mention there is no guarantee the patch will continue to work. Well already know of a few ways in which it can break, and anything we do to get around those surely introduces maintenance or other headaches. Who's going to pay me to maintain these parts of systems that until now just worked? Who's going to pay any of us? Not VeriSign. But they'll be making quite likely millions off of the hijacked hits.
So I ask again, who's going to pay for my time to that? Last time they turned this thing on globally I also spent at least two hours on the phone trying to explain it to various users. And what about the systems or platforms that *CAN'T* be patched? What about systems that have long depended on the way things are supposed to work?
: this is nanog@. if you think sitefinder poses an operational problem
: then please describe it (dispassionately). if you think there is an
: operational thing that ought to be done in response to sitefinder, then
: please describe that (dispassionately). the response you included...
I brought this issue up (dispassionately) offline at the last NANOG
conference.
As most everyone knows, the Windows resolver has its share of
problems under the hood. Well, we ran into a rather interesting glitch
when Verisign did away with the NXDOMAIN. In our internal enterprise, we
have DNS search suffixes defined on client workstations. If a user enters
a plain hostname it will impute the suffixes automatically to find a
matching winner within the various internal subdomains. Never had a
problem with it prior to this.
However, Microsoft's imputing implementation has an undocumented flaw (at
least from the command line that we could determine). If you enter more
than 5 search suffixes, the MS resolver, at least in NT and 2000,
demonstrates irrational behavior. In this scenario, the resolver will
actually append all of the search suffixes, instead of just one at a time,
and make one big request with all the domains separated by commas. In our
case we had 6 search suffix entries for internal subdomains and the root
domain. When a request was made for a plain hostname, the client would
send a request that looked like:
plainhostname.a.domain.com,b.domain.com,c.domain.com,d.domain.com.e.domain.com,domain.com
When our internal DNS server received the request it parsed the root
domain as com,domain.com. Our DNS servers, of course, would end up
forwarding the request out to the root servers and then receive back the
lovely Sitefinder IP address, instead of NXDOMAIN.
We actually lost quite a bit of time in remote troubleshooting during an
application test out of Amsterdam the day Sitefinder came online because
of this issue. We were making internal DNS changes for a test and using
dynamic DNS. We were having a user run nslookups from the command line and
they kept getting back the bogus Sitefinder address, which we couldn't
figure out where it was coming from. (It can pay to stay current on this
list) Oddly, the browser still resolved the name correctly in the end and
was able to function, even though command line still showed this very
strange behavior.
When NXDOMAIN returned, the issue disappeared and we haven't tested it
again.
Suresh,
You clearly aren't having enough fun playing Whack-A-Mole with spammers, now you get to play Whack-A-Mole with Verisign too!
jc
[I'm sure that Paul Vixie knows the difference but others may not and
the Washington Post paper, mentioned at the beginning of the thread,
was quite confused.]
a message of 22 lines which said:
why? that is, why kill sitefinder?
Nobody suggested to kill SiteFinder. Despite Verisign's lies,
SiteFinder is alive and well (well, Verisign suppressed the A record
for sitefinder.versigin.com but it is their decision, they could
recreate the A record at anytime) and never stopped. Anyone is free to
create a Sitefinder-like service if they want.
Many people opposed WILDCARDS in ".com", not SiteFinder. The bad
action was not to launch SiteFinder, it was to add wildcards.
there's been plenty of invective on both sides, and a lot of
unprofessional behaviour toward verisign employees at a recent nanog
meeting,
Wake up: the Internet is no longer a commune of happy geeks working
together for a common goal. It is now a social infrastructure and
there are fights for its control. There is no longer any reason to be
nice with everybody, specially with people trying to divert the common
resource for their own profit.
(Yes, that's an operational issue - if they are harvesting and selling a
list of known-good From: addresses on misrouted mail, this will eventually
end up adding to spam - and that's operational)
Site Finder on its own added to spam; spam volumes increased as the number
of "sender domain does not resolve" bounces dropped away. Also customers'
sending addresses no longer underwent this simple sanity check as all domain
misspellings resolved.
Although a solution to that part may be a second wildcard:
*.com. IN MX 127.0.0.1
Mailers changed to drop mail for hosts MX'd to 127.0.0.1
This would also fix even more spam -- as people are swamped by spam bounces
they sometimes change their own MX to 127.0.0.1. So adding a 127.0.0.1
check to the nonexistent domain check would actually be useful on it's own
and mean then wildcard A record wouldn't have the negative impact on email.
But it would take some time for people to roll out new mailers/configs with
the new rule if it was to be a solution.
David.
I can confirm this same type of issue with several clients of mine that run
microsoft networking stuff, suddenly were unable to locate devices on the
network (like printers and NT file servers) as soon as the Verisign sitefinder
stuff came online. I'll have to let my clients know who to bill when they do
this again 
Actually, I wrote about alot of the issues in my paper at:
http://www.sosdg.org/papers/VSGNWCD.html
Its not really geared to technical people, but might be useful if talking to
end users about the problems associated with sitefinder. Should probably
update it with some of the newer issues I've been finding.
Unfortunately, when you talk about SiteFinder, what ends up happening is that
you can't avoid the financial end of it. There is no technical reason why
SiteFinder needs to exist. It is purely a financial reason why SiteFinder
exists. If they weren't concerned about money, Verisign would be offering all
of the other registars an oppertunity to get involved too, and they wouldn't
be selling ads on the site and paid search listings.
AOL, MSN, and god knows how many other ISPs implement this internally on their
networks without affecting the rest of the world.
Of course, I already know that Verisign is going to start saying that you can
opt-out of it this time around and how it wont break everything again. We all
know that their claims are, well, full of crap. But, its going to end up
being how fast Verisign can spin it in their favor. I mean, look at SCO, and
compare it to what Verisign is doing.
They both don't seem to care how the rest of the world views them, and don't
seem to have a problem turning the rest of the world against themselves. Of
course, neither realizes that because of their actions, they will face
opposition for the rest of their existance. People don't just forget stuff
like this. Especially not when it happens multiple times.
Anyways, enough of my moaning about the problem for now. If anyone has any
real life examples and stories they'd like to share with me so I can add to my
paper on the SiteFinder issue, let me know offlist, and I'll add it.
Date sent: Tue, 10 Feb 2004 09:51:38 +0100
It's apparent that some of today's network operation problems simply do not have an "operational" solution - but these problems are still network operational in nature even if the solution is not operational in nature.
Take spam, for example. We are mere weeks from the 10 year anniversary of Canter and Siegel's green card spam of April 1994. The network operations community has been trying to develop and implement an "operational fix" for this problem ever since; instead the problem exponentially grows worse. It has become clear that the only possible technical solution to spam will be one that replaces our present Simple Mail Transport Protocol with something else - something certainly less simple - even if it's just an end-to-end authentication protocol laid over the present SMTP.
Just as Canter and Siegel's green card spam was a novel way to (ab)use SMTP for Canter and Siegel's profit, ten years later Verisign develops Sitefinder [1] - a novel way to (ab)use DNS requests for Verisign's profit. Both are abuses because they break the existing protocol - making it less functional for those who use it the way it was designed to be used. Both require that network operators patch their systems to try to keep the abuse from negatively impacting their networks. Just as spammers keep on finding ways around the anti-spam patches, expect to see Verisign find and implement new ways around anti-Sitefinder "patches". Whack-A-Mole over DNS, here we come.
Those who do not know their history are doomed to repeat it.
I believe that there is no good "operational" way to solve either problem.
It is my opinion that we will not solve the spam problem until we do one of two things: Change the protocol so that spam is simply no longer possible, or change the financial cost of spam via legal remedies (fines and jail terms) worldwide, along with courage and resolve to enforce those remedies (worldwide). It is also my opinion that we will not solve the Sitefinder problem without resorting to a similar financial sword, as Verisign has shown no signs of caring what the operational community says about the wisdom of their breaking this key fundamental infrastructure protocol for their selfish corporate financial gain. Changing DNS worldwide so that Sitefinder is impossible would be impossibly and horribly painful - we haven't managed to change email to a secure protocol despite 10 years of abuse so what chance do we have of changing DNS?
The biggest problem with the proposed "financial" solution is that it assumes that ICANN has the courage and resolve to enforce their contract with Verisign. If ICANN was interested in firmly enforcing their contract with Verisign, they could simply yank the root database management contract from Verisign, citing the several well documented instances of Verisign failing to properly manage this public resource as a public trust and instead using it as their "owned" property. In reality, ICANN is useless and powerless because key people do not have the courage or resolve to take strong action when strong action is clearly called for.
If this isn't a call to arms to everyone in the operational community to take back control over ICANN, I don't know what is.
jc
[1] Where I use "Sitefinder", I am referring to Verisign's entire project of adding wildcard records to .com and then pointing all the NXDOMAIN domain records to the Sitefinder service.
I still maintain that what sitefinder is trying to do is not really
wrong but it's the wrong way to go about it. This is functionality
that is strictly for web users. Why should every other protocol that
relies on domain name service be subject to this garbage?
If they want to partner with someone to include functionality in their
browser such that if gethostbyname() returns NX Domain and
subsequently redirect to that site, this is fine by me. But I don't
want everything else (ssh, ftp, smtp, pop, imap, etc, etc, etc) to
have to compensate for the wildcard record. Making everyone else
adjust just so that Verisign can earn another penny per share is just
wrong.
I still maintain that what sitefinder is trying to do is not really
wrong but it's the wrong way to go about it. This is functionality
that is strictly for web users. Why should every other protocol that
relies on domain name service be subject to this garbage?
Precisely! Only web users "benefit" from this "service." And you know what? None of my users did. Caused LOTS of confusion. Does anyone know of a way to get Gartner Group, Nielsen, or some other fairly non-biased large group to do an actual poll/study on this in the next couple of months?
If they want to partner with someone to include functionality in their
browser such that if gethostbyname() returns NX Domain and
subsequently redirect to that site, this is fine by me. But I don't
want everything else (ssh, ftp, smtp, pop, imap, etc, etc, etc) to
have to compensate for the wildcard record. Making everyone else
adjust just so that Verisign can earn another penny per share is just
wrong.
We've all been saying this all along....Question is how to make it heard? Who has contacts in the media? Who would be willing to submit to interviews? Etc.
It's totally ridiculous, but this is a political issue being allowed to effect the technical system, and as is almost always the case, it's a miserable failure.
I still maintain that what sitefinder is trying to do is not really
wrong but it's the wrong way to go about it. This is functionality
that is strictly for web users. Why should every other protocol that
relies on domain name service be subject to this garbage?Precisely! Only web users "benefit" from this "service." And you know what? None of my users did. Caused LOTS of confusion. Does anyone know of a way to get Gartner Group, Nielsen, or some other fairly non-biased large group to do an actual poll/study on this in the next couple of months?
Easy to do if you have $20K+ to pay them.
If they want to partner with someone to include functionality in their
browser such that if gethostbyname() returns NX Domain and
subsequently redirect to that site, this is fine by me. But I don't
want everything else (ssh, ftp, smtp, pop, imap, etc, etc, etc) to
have to compensate for the wildcard record. Making everyone else
adjust just so that Verisign can earn another penny per share is just
wrong.We've all been saying this all along....Question is how to make it heard? Who has contacts in the media? Who would be willing to submit to interviews? Etc.
It's totally ridiculous, but this is a political issue being allowed to effect the technical system, and as is almost always the case, it's a miserable failure.
--
Michael Loftis
Regards
Marshall Eubanks
T.M. Eubanks
e-mail : marshall.eubanks@telesuite.com
http://www.telesuite.com
I still maintain that what sitefinder is trying to do is not really
wrong but it's the wrong way to go about it. This is functionality
that is strictly for web users. Why should every other protocol that
relies on domain name service be subject to this garbage?Precisely! Only web users "benefit" from this "service." And you know what? None of my users did. Caused LOTS of confusion. Does anyone know of a way to get Gartner Group, Nielsen, or some other fairly non-biased large group to do an actual poll/study on this in the next couple of months?
Easy to do if you have $20K+ to pay them.
If they want to partner with someone to include functionality in their
browser such that if gethostbyname() returns NX Domain and
subsequently redirect to that site, this is fine by me. But I don't
want everything else (ssh, ftp, smtp, pop, imap, etc, etc, etc) to
have to compensate for the wildcard record. Making everyone else
adjust just so that Verisign can earn another penny per share is just
wrong.We've all been saying this all along....Question is how to make it heard? Who has contacts in the media? Who would be willing to submit to interviews? Etc.
It's totally ridiculous, but this is a political issue being allowed to effect the technical system, and as is almost always the case, it's a miserable failure.
--
Michael Loftis
Regards
Marshall Eubanks
T.M. Eubanks
e-mail : marshall.eubanks@telesuite.com
http://www.telesuite.com