full-disclosure - Verisign abusing .COM/.NET monopoly, BIND releases new

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1064086872.13723.6.camel@tantor.nuclearelephant.com>
From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski)
Subject: Verisign abusing .COM/.NET monopoly, BIND
	releases new

You know, I'm wondering.. if everyone in the world all wrote a little
perl script to do a million HTTP GETs of some domain that doesn't exist,
they wouldn't really be guilty of any network flooding, since they
_should_ be getting domain not found errors and the problem being
restricted locally to that script...so it seems as though it would be
Verisign's own fault for specifically redirecting these queries to their
own server - which I doubt could handle a few million per second.

The same would apply I believe for a domain that someone registered but
didn't have configured properly; it'd be an attempt to flood one's own
servers, but Verisign would redirect all that flooding to themselves.

The naturally logical way Verisign would want to stop all that flooding
would be turning the sitefinder service off, which would cause
everyone's little script to just sit there and be unable to resolve DNS,
remaining dormant.

Just thinking out loud :\

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030920/73d3889d/attachment.html