Hi all, After the discussion a few days ago about the stunt Verisign has pulled recently, and most people expressing outrage over it, I wonder how many network operators/ISP's etc are actually willing to go as far as running the patches that are surfacing for the various nameserver software that will return NXDOMAIN when a root server tries to return an A record directly instead of a referal ? (Effectively reverting the behaviour to what it was before for your customers, and fixing issues with mailservers trying to look up non-existant domains in the aid of spam detection etc etc) I guess some people that might consider doing so could be waiting for "official" patches to come out first (like the one recently released as an rc for BIND 9) rather than hacks before implementing it, but what is the general feeling about this kind of action ? Anyone want to 'fess up to doing it already ? :) (on a medium to large scale) Regards, Simon Byrnand iGRIN Internet
heh, this could always be an option :-P ip route 64.94.110.11
255.255.255.255 null0
Edward
----- Original Message -----
From: "Simon Byrnand"
Hi all,
After the discussion a few days ago about the stunt Verisign has pulled recently, and most people expressing outrage over it, I wonder how many network operators/ISP's etc are actually willing to go as far as running the patches that are surfacing for the various nameserver software that will return NXDOMAIN when a root server tries to return an A record directly instead of a referal ? (Effectively reverting the behaviour to what it was before for your customers, and fixing issues with mailservers trying to look up non-existant domains in the aid of spam detection etc etc)
I guess some people that might consider doing so could be waiting for "official" patches to come out first (like the one recently released as an rc for BIND 9) rather than hacks before implementing it, but what is the general feeling about this kind of action ? Anyone want to 'fess up to doing it already ? :) (on a medium to large scale)
Regards, Simon Byrnand iGRIN Internet
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
"Edward Yardley"
heh, this could always be an option :-P ip route 64.94.110.11 255.255.255.255 null0
*Please* don't do that. That doesn't get rid of the bogus A record; it just turns an attempt to connect to Verisign into a looong wait while the connection times out. Install the BIND patches and be happy. (And would whichever of Linuxnet and/or Ihug who are doing this, please stop.) -- don
"Edward Yardley"
wrote: heh, this could always be an option :-P ip route 64.94.110.11 255.255.255.255 null0
*Please* don't do that.
That doesn't get rid of the bogus A record; it just turns an attempt to connect to Verisign into a looong wait while the connection times out.
Exactly.... and think of all the mis-addressed mail stuck in the outgoing mail queue that won't even report a temporary failure for hours, let alone bounce in a timely fashion... Hopefully not too many have resorted to the knee-jerk reaction of blackholing the ip address, although I have to wonder from the various mailing lists I read.... :/ Regards, Simon
I guess some people that might consider doing so could be waiting for "official" patches to come out first (like the one recently released as an rc for BIND 9) rather than hacks before implementing it, but what is the general feeling about this kind of action ? Anyone want to 'fess up to doing it already ? :) (on a medium to large scale)
I swapped over ICONZ's servers to 9.2.3rc4 and put in the requisite delegation-only entries today. Would have done so earlier but the rc2 was giving false positives and the hack for 8.4.1 was slow to return NXDOMAIN for some reason (which I admittedly didn't look into). It was perhaps a mistake to make such an autocratic decision, but considering the technical implications of not doing so I felt it justified. Completely unacceptable behaviour on Verisign's part as far as I am concerned. Besides, the servers needed an upgrade anyway. :) -- David Clarke Tech ICONZ Ltd
On Tue, 23 Sep 2003, David Clarke wrote:
I swapped over ICONZ's servers to 9.2.3rc4 and put in the requisite delegation-only entries today. Would have done so earlier but the rc2 was giving false positives and the hack for 8.4.1 was slow to return NXDOMAIN for some reason (which I admittedly didn't look into).
Oh, you removed those patches? Okay, ICONZ _DID_ patch against it the same day, but if the patches were dodgy, perhaps we should have waited. My own personal DNS servers are unpatched, as I've been testing exactly how much these poisoned entries break stuff, and what stuff that might be. JSR -- John S Russell | Big Geek | Doing geek stuff.
FYI, monkeys.com DNSBL is gone and not coming back. This is the result of a massive DDoS attack on their network. I know it may have been asked before, but are there any local .nz DNSBL's hanging around? Cheers, P
On Tue, Sep 23, 2003 at 07:35:31PM -0700, Pipes wrote:
FYI,
monkeys.com DNSBL is gone and not coming back. This is the result of a massive DDoS attack on their network.
I know it may have been asked before, but are there any local .nz DNSBL's hanging around?
Cheers,
Yep, I disabled proxies.relays.monkeys.com this morning. Now I have got my first CacheFlowServer@ proxied UBE in a long time. I find it perplexing that there are organizations out there which can afford CacheFlow prices yet can't afford administrators with a clue. Hopefully there is some software out there somewhere that can be used as the basis of a new proxy blacklist without reinventing the wheel. It looks like the existing public access blacklists are systematically being blasted one by one. Regards, RH. -- Friends don't let friends do Windows(tm).
On Wed, Sep 24, 2003 at 15:23 +1200, richard(a)kcbbs.gen.nz wrote:
Hopefully there is some software out there somewhere that can be used as the basis of a new proxy blacklist without reinventing the wheel. It looks like the existing public access blacklists are systematically being blasted one by one.
Would a distributed service be the best way to avoid the DDoS peril? Does any such software exist?
Regards, RH.
Hamish. -- Space isn't remote at all. It's only an hour's drive away if your car could go straight upwards. --Fred Hoyle
Wonder if something simular to the F-root server setup would work. With
local mirrors in each country with the same ip.
Barry
----- Original Message -----
From: "Hamish MacEwan"
On Wed, Sep 24, 2003 at 15:23 +1200, richard(a)kcbbs.gen.nz wrote:
Hopefully there is some software out there somewhere that can be used as the basis of a new proxy blacklist without reinventing the wheel. It looks like the existing public access blacklists are systematically being blasted one by one.
Would a distributed service be the best way to avoid the DDoS peril? Does any such software exist?
Regards, RH.
Hamish.
-- Space isn't remote at all. It's only an hour's drive away if your car could go straight upwards. --Fred Hoyle _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On Wed, Sep 24, 2003 at 10:03:26PM +1200, Hamish MacEwan wrote:
On Wed, Sep 24, 2003 at 15:23 +1200, richard(a)kcbbs.gen.nz wrote:
Hopefully there is some software out there somewhere that can be used as the basis of a new proxy blacklist without reinventing the wheel. It looks like the existing public access blacklists are systematically being blasted one by one.
Would a distributed service be the best way to avoid the DDoS peril? Does any such software exist?
Don't forget that the database is in DNS, and the DNS is distributed by design. You can have several nameservers. However the tester machine, website and primary nameserver are perhaps a single point (each). Regardless, a few zombies on wideband connections or university residences can throw a lot of traffic even if you can distribute. If I was doing it, I'd want to use a separate /24 so that it could be dropped while under attack without affecting anything else, and it would be kept fairly quiet so it wouldn't get much attention. Regards, RH.
FYI,
monkeys.com DNSBL is gone and not coming back. This is the result of a massive DDoS attack on their network.
And since its a .com domain, presumably if/when the domain becomes unregistered or undelegated, good 'ol verisign will start returning their webserver ip address for all lookups, magically making the DNSBL "spring to life" again but blacklisting everyone :) (as happened with ORBS recently with SpamAssassin) For those that havn't patched their DNS servers yet, anyway... Regards, Simon
Simon Byrnand
I guess some people that might consider doing so could be waiting for "official" patches to come out first (like the one recently released as an rc for BIND 9) rather than hacks before implementing it, but what is the general feeling about this kind of action ? Anyone want to 'fess up to doing it already ? :) (on a medium to large scale)
I'm thinking about it seriously because of various practical issues, e.g. Richard M. Smith's post to bugtraq "How Verisign's SiteFinder service breaks Outlook Express". It would also be nice to be able to use domain name lookups for spam scoring purposes again. cheers, Jamie -- James Riden / j.riden(a)massey.ac.nz / Systems Programmer - Security Information Technology Services, Massey University, NZ. GPG public key available at: http://www.massey.ac.nz/~jriden/
On Tue, 23 Sep 2003, Simon Byrnand wrote:
After the discussion a few days ago about the stunt Verisign has pulled recently, and most people expressing outrage over it, I wonder how many network operators/ISP's etc are actually willing to go as far as running the patches that are surfacing for the various nameserver software that will return NXDOMAIN when a root server tries to return an A record directly instead of a referal ? (Effectively reverting the behaviour to what it was before for your customers, and fixing issues with mailservers trying to look up non-existant domains in the aid of spam detection etc etc)
ICONZ patched against Verisigns mass-poisoning of the DNS the day it began. JSR -- John S Russell | Big Geek | Doing geek stuff.
participants (11)
-
Barry Murphy
-
David Clarke
-
Don Stokes
-
Edward Yardley
-
Hamish MacEwan
-
J S Russell
-
James Riden
-
Juha Saarinen
-
Pipes
-
richard@kcbbs.gen.nz
-
Simon Byrnand