Kill Verisign Routes :: A Dynamic BGP solution
I wanted to discuss the merits of the following: I have written a proof of concept solution to nuke a route to sitefinder. Code to those who care or to the list if anyone cares. Perl is your friend :) Basic concept: Use Net::BGP to set up a peering session with my route server. Query DNS for *.com and *.net on x interval. Then take the answers (if they are valid A records) and inject them into the route server (which in our case is used solely to feed a blackhole network to sink traffic from APNIC space, etc). If an address no longer appears in the DNS (i.e. the idiots switched hosts), withdraw the route. If they set up multiple hosts, it will catch each one of them. You can set the polling interval as you please. Thoughts? Eric ========================================================================== Eric Germann CCTec ekgermann@cctec.com Van Wert OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 603 825 5893 "The fact that there are actually ways of knowing and characterizing the extent of one’s ignorance, while still remaining ignorant, may ultimately be more interesting and useful to people than Yarkovsky" -- Jon Giorgini of NASA’s Jet Propulsion Laboratory
I wanted to discuss the merits of the following:
I have written a proof of concept solution to nuke a route to sitefinder. Code to those who care or to the list if anyone cares. Perl is your friend :)
Basic concept: Use Net::BGP to set up a peering session with my route server. Query DNS for *.com and *.net on x interval. Then take the answers (if they are valid A records) and inject them into the route server (which in our case is used solely to feed a blackhole network to sink traffic from APNIC space, etc).
If an address no longer appears in the DNS (i.e. the idiots switched hosts), withdraw the route. If they set up multiple hosts, it will catch each one of them. You can set the polling interval as you please.
Thoughts?
I think the whole idea of getting into an escalating technical war with Verisign is extremely bad. Your suggestion only makes sense if you expect Verisign to make changes to evade technical solutions. Each such change by Verisign will cause more breakage. Verisign will either provide a way to definitively, quickly, and easily tell that a domain is not registered or Verisign will badly break COM and NET. DS
-----Original Message----- From: David Schwartz [mailto:davids@webmaster.com] Sent: Thursday, September 18, 2003 6:38 PM To: ekgermann@cctec.com; nanog@nanog.org Subject: RE: Kill Verisign Routes :: A Dynamic BGP solution Sensitivity: Confidential
<snip>
I think the whole idea of getting into an escalating technical war with Verisign is extremely bad. Your suggestion only makes sense if you expect Verisign to make changes to evade technical solutions. Each such change by Verisign will cause more breakage. Verisign will either provide a way to definitively, quickly, and easily tell that a domain is not registered or Verisign will badly break COM and NET.
DS
Who said they're logical in their decision making process. While they experiment with .com/.net, countermeasures are called for. And they have badly broken .com/.net. This is just an evolution of the blackhole solution, doing it dynamically. Keeps us from having to find out they changed it/moved it/etc. And, if *.com goes away, so does the route :).
I think the whole idea of getting into an escalating technical war with Verisign is extremely bad. Your suggestion only makes sense if you expect Verisign to make changes to evade technical solutions. Each such change by Verisign will cause more breakage. Verisign will either provide a way to definitively, quickly, and easily tell that a domain is not registered or Verisign will badly break COM and NET.
Who said they're logical in their decision making process. While they experiment with .com/.net, countermeasures are called for. And they have badly broken .com/.net.
It's precisely because they may not be logical that I don't think it's wise to get into an escalation battle with them. Mutually assured destruction works well when your adversary is logical and very badly when they're not.
This is just an evolution of the blackhole solution, doing it dynamically.
And if Verisign escalates, do you escalate again? Now you've indirectly caused a second wave of breakage. And then what? You escalate again for a third wave of breakage?
Keeps us from having to find out they changed it/moved it/etc. And, if *.com goes away, so does the route :).
It would be a major escalation for Verisign to use technological means to dupe people into again getting to SiteFinder despite their clear, explicit configuration to the contrary. If you really think such an escalation is inevitable, then the escalation will be sufficient to defeat whatever mechanism is deployed at that time. So deploying more complex mechanisms before that point is pointless. If you're hoping to push Verisign into an escalation to use that escalation for a lawsuit or PR angle, a number of small escalations is better than one big one. People are already employing means to avoid sitefinder, so if they think it's worth escalating to get around that, they already have to. In any event, Verisign's policy descisions will likely be driven primarily by actions taken by Microsoft, AOL, and perhaps ICANN and the DOC. The plain and simple truth is that if you want to use .COM and .NET, you have to trust Verisign. Sad, but true. DS
On Thu, 18 Sep 2003, Eric Germann wrote:
I wanted to discuss the merits of the following:
I have written a proof of concept solution to nuke a route to sitefinder. Code to those who care or to the list if anyone cares. Perl is your friend :)
Basic concept: Use Net::BGP to set up a peering session with my route server. Query DNS for *.com and *.net on x interval. Then take the answers (if they are valid A records) and inject them into the route server (which in our case is used solely to feed a blackhole network to sink traffic from APNIC space, etc).
If an address no longer appears in the DNS (i.e. the idiots switched hosts), withdraw the route. If they set up multiple hosts, it will catch each one of them. You can set the polling interval as you please.
Thoughts?
So totallymadeupdomain.com now resolves but is unreachable. That will prevent you from bouncing emails to non-existent domains immediately.. Steve
Thus spake Stephen J. Wilcox (steve@telecomplete.co.uk) [18/09/03 18:54]:
So totallymadeupdomain.com now resolves but is unreachable. That will prevent you from bouncing emails to non-existent domains immediately..
FWIW, the latest versions of postfix have code in them to block connects from explicitly listed hosts: New check_{helo,sender,recipient}_{ns,mx}_access maptype:mapname restriction that applies the specified access table to the NS or MX hosts of the host/domain given in HELO, EHLO, MAIL FROM or RCPT TO commands. This can be used to block mail from so-called spammer havens, or from sender addresses that resolve to Verisign's wild-card mail responder, currently at IP address 64.94.110.11. - Damian
Which is fine with me/my client base. Since what they are doing is essentially a MITM attack, the client base I serve and I would rather have the mail sit in OUR spools for a couple of days, vs. bouncing immediately with the potential of the mail addresses being harvested. Also, from the perspective of our "sensitive clients", they would like mistyped URL's with parameters to be errored out on the browser side, vs being dumped to a Verisign server with the parameters (potentially usernames/passwords, etc) possibly ending up in their logs. Also, whats to keep Verisign from changing the behavior of their mail spool? Right now, its questionable how it rejects. It would make a neat project to make a server that accepted the whole message, and THEN bounced it after it was all spooled/logged. Verisign do something like that? Nahhh, not our beloved Verisign .... Eric
-----Original Message----- From: Stephen J. Wilcox [mailto:steve@telecomplete.co.uk] Sent: Thursday, September 18, 2003 6:51 PM To: Eric Germann Cc: nanog@nanog.org Subject: Re: Kill Verisign Routes :: A Dynamic BGP solution
<snip>
So totallymadeupdomain.com now resolves but is unreachable. That will prevent you from bouncing emails to non-existent domains immediately..
Steve
participants (4)
-
Damian Gerow -
David Schwartz -
Eric Germann -
Stephen J. Wilcox