Re: Hurricane Maria: Summary of communication status - and lack of

[Phil Rosenthal]

Has anyone heard anything about Liberty Cablevision / AS14638?

Our Netflow stats show a traffic drop to zero at the moment of landfall of 
Maria, late on 9/19, and a continued flat line at zero until now. Almost 11 
days without a single packet exchanged. This is (as far as I am aware), the #2 
largest ISP in Puerto Rico.

By comparison, Claro’s traffic certainly has dropped by a large degree, but it 
always stayed at least slightly above zero, and is roughly at 10% of normal 
traffic levels today.

-Phil

Re: American Airlines down

[Phil Rosenthal]

http://www.flyertalk.com/forum/american-airlines-aadvantage/1820617-aa-com-technical-outage-8feb17.html
 


> On Feb 8, 2017, at 10:11 PM, Michael Voity  wrote:
> 
> Hello
> 
> Stuck at DCA after NANOG because America airlines system are down.  
> 
> Anyone know anything?
> 
> Mike
> 
> Sent from my iPhone

Re: EVERYTHING about Booters (and CloudFlare)

[Phil Rosenthal]

Are you of the opinion that the victim of a DDoS attack who is not a 
multi-billion-dollar corporation would actually receive help from the FBI as a 
result of a DDoS attack?
In the past, I have been told that the dollar-threshold for the FBI to even 
consider looking at a case was at least $2M in damages. This was 10 years ago, 
and I can't imagine the threshold has gone down.

-Phil

> On Jul 28, 2016, at 12:51 PM, Naslund, Steve <snasl...@medline.com> wrote:
> 
> It is not beyond the realm of law enforcement to run down the entire chain of 
> events all the way back to the “whodunit” and “howdunit”.  It is pretty 
> amazing what they can figure out when they put their minds to it and don’t 
> underestimate what they can learn by getting someone in the hot seat under 
> the bare light bulb.  They also have lots of informants.
> 
> Victim complaints don’t matter a bit to these guys, it will take the guys in 
> the windbreakers kicking in the doors one of these days.
> 
> Steven Naslund
> Chicago IL
> 
>> On Thu, Jul 28, 2016 at 12:20 PM, Phil Rosenthal 
>> <p...@isprime.com<mailto:p...@isprime.com>> wrote:
>> Keep in mind also, the victims of these DDoS attacks do not know which 
>> "booter" service was paid to attack them. The packets do not have "Stress 
>> test provided by vBooter" in them. The attack packets do not ?>come from the 
>> booter's or Cloudflare's IP addresses, they come from secondary victims -- 
>> compromised servers, PC's infected with malware, and abused DNS/NTP [and a 
>> few other protocols] reflectors.
>> 
>> It is impossible for a victim to submit a complaint to Cloudflare stating "I 
>> was attacked by someone paying vBooter", because they do not know which of 
>> the numerous "booter" services was responsible.
>> 
>> -Phil

Re: EVERYTHING about Booters (and CloudFlare)

[Phil Rosenthal]

Keep in mind also, the victims of these DDoS attacks do not know which "booter" 
service was paid to attack them. The packets do not have "Stress test provided 
by vBooter" in them. The attack packets do not come from the booter's or 
Cloudflare's IP addresses, they come from secondary victims -- compromised 
servers, PC's infected with malware, and abused DNS/NTP [and a few other 
protocols] reflectors.

It is impossible for a victim to submit a complaint to Cloudflare stating "I 
was attacked by someone paying vBooter", because they do not know which of the 
numerous "booter" services was responsible.

-Phil
> On Jul 28, 2016, at 12:12 PM, Naslund, Steve  wrote:
> 
> Miles is right.  Their thinly veiled "stress tester" thing is not going to be 
> much of a defense.  They must not have very good legal counsel.  Here is the 
> issue.  Stress testing is perfectly legal as long as I am:
> 
>   a) Stress testing my own stuff
>   b) Stress testing your stuff WITH YOUR CONSENT
> 
> Selling a product or service that is unsafe can lead to serious civil 
> consequences.  For example, I sell you roach killer and don't warn you that 
> it will also kill every other living thing in your home, I am going to get 
> sued and lose badly.
> 
> Let's say I am running a demolition company that offers to knock down any 
> house for a price.  Don't you think I have a responsibility to verify that 
> you own the house you just asked me to knock down?   (by the way, this has 
> happened in the real world -wrong address on paperwork- and the demolition 
> company was held liable) Obviously I have that responsibility and obviously 
> the same rules would apply to any service that can potentially damage 
> someone's property.
> 
> Steven Naslund
> Chicago IL
> 
>> Let's see:
>> 
>> Vbooter (on their home page) claims:
>> "#1 FREE WEBBASED SERVER STRESSER"
>> "Using vBooter you can take down home internet connections, websites and 
>> game servers such us Minecraft, XBOX Live, PSN and many more."
>> "You don't have to pay anything in order to use this stresser! In addition 
>> there are NO limits if you are a free user."
> 
>> So they're advertising a free service that explicitly offers DDoS 
>> capabilities.
> 
>> Now - with the caveat that I'm not a lawyer, and I'm talking from a US 
>> perspective only - as a sometimes hosting provider who pays attention to our 
>> legal liabilities, and >who's had one of our boxes compromised and used to 
>> vector a DDoS against a gaming site
> 
>> 1.  DDoS is clearly illegal under multiple statutes - most notably the 
>> Computer Fraud and Abuse Act - see 
>> https://www.justice.gov/sites/default/files/criminal->ccips/legacy/2015/01/14/ccmanual.pdf
>> - for a Justice Dept. memo on "Prosecuting Computer Crimes."  When coupled 
>> with threats, requests for payoffs, etc. - it expands into lots of other 
>> crimes (e.g., >extortion).  And that's before one starts attacking 
>> Government-owned computer systems.
>> 
>> 2. One might infer that, while "stress testing" is a legitimate and useful 
>> service - under specific circumstances, vBooter's tools might also fall 
>> under laws regarding >being an accomplice to a criminal act, aiding & 
>> abetting, "burglar's tools," etc., and more generally "creating a public 
>> nuisance."
>> 
>> 3. There are also various (mostly state) laws against the sale of burglar's 
>> tools (e.g., sale of a lockpick to someone who's not a professional 
>> locksmith).  I expect some >of those laws might apply.
>> 
>> 4. All of those certainly could be applied to vBooter.org.  Whether 
>> Cloudflare is liable for anything would seem to depend on whether Cloudflare 
>> is complicit in the use >of vBooter's use for criminal purposes, or 
>> promoting it's use therefore.  Hosting would certainly fall into that 
>> category - and while, I have no direct knowledge that >Cloudflare hosts 
>> vBooter, they do provide nameservice, and their web server's IP address is 
>> in a network block registered to Cloudflare - that would seem to establish 
>> >complicity.  Now if Cloudflare were to actively suggest that folks use 
>> vBooter to test systems, as a way to boost sales for Cloudflare - that would 
>> certainly be an >interesting test case for RICO (akin to McAfee encouraging 
>> folks to write and release viruses).
>> 
>> As to whether "Nothing is going to happen" - I expect something WILL happen, 
>> when somebody big, with a good legal department, gets hit by a really 
>> damaging DDoS attack, >and starts looking for some deep pockets to sue.  Or, 
>> if somebody attacks the wrong Government computer and the FBI, or DoD, or 
>> DHS get ticked off.
>> 
>> It will make for very good theater - at least for anyone not directly in the 
>> cross-hairs.
>> 
>> Miles Fidelman
> 

Re: cloudflare hosting a ddos service?

[Phil Rosenthal]

Plus, it’s good for business!

-Phil

> On Jul 26, 2016, at 10:14 PM, jim deleskie  wrote:
> 
> sigh...
> 
> On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore 
> wrote:
> 
>> CloudFlare will claim they are not hosting the problem. They are just
>> hosting the web page that lets you pay for or points at or otherwise
>> directs you to the problem.
>> 
>> The actual source of packets is some other IP address. Therefore, they can
>> keep hosting the web page. It is not sending the actual
>> [spam|DDoS|hack|etc.], right? So stop asking them to do something about it!
>> 
>> Whether you think that is the proper way to provide service on the
>> Internet is left as an exercise to the reader.
>> 
>> --
>> TTFN,
>> patrick
>> 
>>> On Jul 26, 2016, at 9:49 PM, Mike  wrote:
>>> 
>>> Hi,
>>> 
>>>   So vbooter.org's dns and web is hosted by cloudflare?
>>> 
>>> "Using vBooter you can take down home internet connections, websites and
>> game servers such us Minecraft, XBOX Live, PSN and many more."
>>> 
>>>   dig -t ns vbooter.org
>>> 
>>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;vbooter.org.INNS
>>> 
>>> ;; ANSWER SECTION:
>>> vbooter.org.21599INNSrick.ns.cloudflare.com.
>>> vbooter.org.21599INNSamy.ns.cloudflare.com.
>>> 
>>> dig -t a www.vbooter.org
>>> 
>>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;www.vbooter.org.INA
>>> 
>>> ;; ANSWER SECTION:
>>> www.vbooter.org.299INCNAMEvbooter.org.
>>> vbooter.org.299INA104.28.13.7
>>> vbooter.org.299INA104.28.12.7
>>> 
>>> 
>>>   Can anyone from cloudflare answer me why this fits with your business
>> model?
>>> 
>>> Mike-
>> 
>> 

Re: MTU

[Phil Rosenthal]

> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka <grzeg...@janoszka.pl> wrote:
> What I noticed a few years ago was that BGP convergence time was faster with 
> higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
> 
> Anyone else observed something similar?

I have read about others experiencing this, and did some testing a few months 
back -- my experience was that for low latency links, there was a measurable 
but not huge difference. For high latency links, with Juniper anyway, there was 
a very negligible difference, because the TCP Window size is hard-coded at 
something small (16384?), so that ends up being the limit more than the tcp 
slow-start issues that MTU helps with.

With that said, we run MTU at >9000 on all of our transit links, and all of our 
internal links, with no problems. Make sure to do testing to send pings with 
do-not-fragment at the maximum size configured, and without do-not-fragment 
just slightly larger than the maximum size configured, to make sure that there 
are no mismatches on configuration due to vendor differences.

Best Regards,
-Phil Rosenthal

Re: NANOG67 - Tipping point of community and sponsor bashing?

[Phil Rosenthal]

Hello all,

I wasn't able to attend NANOG this time around, but watched Dave Temkin's 
presentation on youtube.

My comments are:
1) Over the past 5 years:
My cost for switch/router ports have gone down a lot.
My cost for transit has gone down a lot.
My cost for exchange ports have gone down, but not quite as fast as my transit 
and switch/router ports, and this does lead to some value questions. Dave is 
right to ask them.

However: exchange port fees are not my biggest enemy today. My cross connect 
fees have not gone down *at all*. On a proportion basis, cross connect fees 
have gone from "not mattering" to being an important part of any deployment 
cost calculation. Why aren't we raising hell about cross connect fees?

2) Exotic features -- Pvlan, L2VPN, L3VPN have absolutely no purpose on an 
exchange. If it could be done 'free' with commodity hardware, then fine -- but 
if it translates to requiring Big Expensive Routers instead of a cheaper but 
fast switch, this should translate to higher pricing for the customers 
requiring these exotic features -- not the customers who just want a big L2 
vlan.

3) Remote peering -- This is mostly a question about distance for value.  There 
is a clear benefit in providing multi-datacenter exchanges within a metro, and 
both FL-IX and SIX are doing this with a very good value proposition. Having 
the ability to join DECIX Frankfurt from NYC and vice versa -- again, this is a 
bizarre service to be offered, and regular users should not be expected to pay 
for this. If there is a market for these services at an unsubsidized price, 
then fine -- but regular members should not be subsidizing this service.

4) sFlow -- I'm not sure why this is even really a topic. Commodity hardware 
does have sFlow capability, and FLIX demonstrates this well. With that said, 
for us, it is of extremely limited value. We might check these graphs to 
validate measurements of our internal netflow/sflow graphing systems, but 
generally, I look at the graphs generated by my exchange vendors less than once 
per year per exchange. I am honestly not even sure if SIX offers this service, 
as I never had a reason to check.

5) Marketting vs Outreach: These things are honestly basically the same thing, 
mostly separated by the question of "is it good marketing or not". I like 
having more members at the exchanges I am a member of. If it translates to an 
additional 3% per year to have an additional 5% of traffic to new members, I am 
fine with this.  If it translates to an extra 50% of cost for 5% of additional 
traffic, I am not fine with it.

Finally -- there is nothing wrong with asking questions. If you are an exchange 
company and you can defend your prices for what you offer, then there is no 
problem.  If you are an exchange and are mostly just hoping nobody asks the 
questions because you won't have any good answers -- well, I think this is 
exactly why Dave asked the question.

Best Regards,
-Phil Rosenthal
> On Jun 16, 2016, at 1:58 PM, Adam Rothschild <a...@latency.net> wrote:
> 
> I think a fresh conversation is needed around what makes up a
> "minimally viable" feature set for an IXP:
> 
> The days of an IXP "needing" to engineer and support a multi-tenant
> sFlow portal, because the only other option is shelling out the big
> bucks for Arbor, have long passed -- overlooking the plethora of open
> sourced tools, folk like Kentik have broken into that market with
> rationally priced commercial alternatives.  Likewise, one might argue
> that offering layer-2 and layer-3 (!) VPNs is at best non-essential,
> and a distraction that fuels purchasing very expensive hardware, and
> at worse competitive with customers.
> 
> On the other hand, building out a metro topology to cover all relevant
> carrier hotels, with reasonable path diversity, is absolutely table
> stakes.  And outreach is a great function, *when* it nets unique new
> participants.  To cite a recent example, the various R networks and
> smaller broadband and mobile providers showing up here in the US, due
> to excellent efforts by the NYIIX and DE-CIX teams.
> 
> At the end of the day, IXP peering must be significantly cheaper than
> transit alternatives, many of which are priced based on utilization
> (as opposed to port capacity).  We can dance around this point all we
> want, but absent a change in trajectory, I worry some IXPs will
> ultimately price themselves out of the market, and all the gold-plated
> features in the world won't satiate those making purchasing decisions.
> 
> $0.02,
> -a
> 
> On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker 

Re: Traffic engineering and peering for CDNs

[Phil Rosenthal]

Hello,

> On Jun 6, 2016, at 7:36 AM, Graham Johnston <johnst...@westmancom.com> wrote:
> 
> Lately I have been putting in some effort to maximize our IX connections by 
> trying to work with the top 5-ish list of ASNs that still send us traffic via 
> a paid transit connection despite the fact that we are both present on the 
> same IX(s). In one case I missed the fact that one ASN wasn't using the IXs 
> route-servers, that's on me for not spotting that one.
> 
> Even with proper IX peering in place though it seems like some CDNs are 
> better at using the IX connections than others.  ASN 15169 for instance does 
> an excellent job sending more than 99.99% of traffic via the IX connection; 
> thank you. While others only seem to manage to send 60 - 80% of traffic via 
> the IX.  What I am not understanding about the respective CDN's network 
> wherein they don't send traffic to me through a consistent path? Is the 
> content coming from widely different places and rather than transport it 
> across their own network from a remote site they would rather hot-potato it 
> out a local transit connection?  Are their transit costs so low that they 
> don't care about using an IX connection over transit unlike a small operator 
> like me? Is this just a non-obvious issue wherein they maybe just can't 
> originate enough of the traffic near the IX and therefore don't make use of 
> the IX connection, again a hot-potato phenomenon?

Most CDN’s do not have a backbone.  Transit costs are not free, but as most 
traffic is served by local nodes from cache, the costs of transport between 
locations in many cases is higher than just sending via transit. In some cases, 
the CDN may not have good mapping and may not be certain which node is best to 
serve your customers. In other cases, not all content exists on all nodes, and 
they may redirect to serve from the nodes which have the content. Finally, 
there may be an outage or capacity limits from the closest location, and 
another location may be serving to make up the shortfall.

> 
> Secondly can someone explain to me why some CDNs want a gigabit or two of 
> traffic to be exchanged between our respective networks before they would 
> peer with me via a public IX? I totally get those kinds of thresholds before 
> engaging in a private interconnect but I don't understand the reluctance with 
> regard to a public IX, that they are already established at. Is it again just 
> a simple case of bandwidth economics that operate at a different scale than I 
> can comprehend?
> 

This sounds like a surprisingly high threshold, but to some extent it boils 
down like this — setting up sessions requires some time. In the ideal world, 
the peer is intelligent and has everything set up properly, but even in this 
case, it still requires some time for making sure things go up properly. Some 
(but not all) CDN’s have it automated to reduce this time. Some potential 
peering networks are poorly run, and will leak routes, not announce all of 
their routes, will not configure the sessions properly, etc — this adds up to 
significantly more time. Before the CDN starts setting up peering with another 
network, it is not necessarily obvious if the potential peer is run by 
competent people or not. Many CDN’s are members of the route servers.  If you 
are exchanging a small amount of traffic, and both you and the CDN are on the 
Route Server for the IX, there maybe no reason to set up direct sessions which 
will require both more coordination time for configuration, and more router cpu 
time/ram on an ongoing basis. From the perspective of the CDN, most likely, 
1Gbps or less is a perfectly reasonable amount of traffic to exchange to peers 
who are learned only via the route server, and not directly.
 
> I'm hoping the community can shed some light on this for me as I'm trying to 
> avoid grilling the operators that are working with me as I don't expect those 
> front line individuals to necessarily have a full view of the factors at play.
> 
> Thanks,
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829
> johnst...@westmancom.com<mailto:johnst...@westmancom.com>
> P think green; don't print this email.
> 

Best Regards,
-Phil Rosenthal
ISPrime

Re: Chile Status?

[Phil Rosenthal]

Hello,

Our internal monitoring tools show that there was a momentary drop in traffic 
(~30 minutes) coinciding with the earthquake, but traffic quickly returned to 
normal, and is at normal levels today.
We are serving Chile from Miami.

Best Regards,
-Phil

> On Sep 17, 2015, at 9:47 AM, Marshall Eubanks  
> wrote:
> 
> Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any
> information about the status of the Internet in Chile, and in particular
> about the status of the undersea fiber links that go down off the West
> coast of South America to Chile?
> 
> Given that this was an offshore Earthquake, and its magnitude, I would
> expect those fiber links to be at risk to undersea landslides.
> 
> Regards
> Marshall Eubanks

Re: Youtube / IPv6 / Netherlands

[Phil Rosenthal]

 On Jun 25, 2015, at 9:32 AM, Christopher Morrow morrowc.li...@gmail.com 
 wrote:
 
 geolocation is hard :(

If you would like to see how Google has your geolocation set, check:
curl http://redirector.c.youtube.com/report_mapping

You might want to force it both IPv4 and IPv6 to see if there is any difference.

Best Regards,
-Phil

Re: Netflix To Cogent To World

[Phil Rosenthal]

With this war of blog posts — perhaps Netflix should ask this question:

Who can we buy transit from who has sufficient peering capacity to reach 
Comcast’s and Verizon’s customers?

-P

On Jul 23, 2014, at 1:00 PM, Adam Rothschild a...@latency.net wrote:

 I think the confusion by Jay and others is that there is a plethora of 
 commercial options available for sending traffic to Comcast or Verizon, at 
 scale and absent congestion.  I contend that there is not.
 
 I, too, have found Netflix highly responsive and professional, as a peering 
 partner...
 
 $0.02,
 -a
 
 On Jul 23, 2014, at 11:31 AM, Bob Evans b...@fiberinternetcenter.com wrote:
 
 Most likely Netflix writes policies to filter known cogent conflict
 peers...Chances are they use cogent to reach the cogent customer base and
 other peers.  I know from experience that peering directly with Netflix
 works very wellthey don't depend heavily on transit delivery if direct
 peering is possible.
 
 Thank You
 Bob Evans
 CTO
 
 
 
 
 If I were Netflix, why would I buy all my transit from Cogent[1], given
 Cogent's propensity for getting into peering fights with people
 *already*,
 even before *I* start sending them 1000:1 asymmetric outbound traffic?
 
 Perhaps Netflix expect this to be an ongoing problem with moree ISPs
 asking them to pay to deliver (following Bretts lead ;-), so with their
 previous transits experience why would they continue to buy from pussies?
 
 So why would Cogent offer Netflix a helluva deal?
 
 Previous events have shown Cognet only use live rounds, so why would they
 not take the opportunity to get a bigger gun?
 
 Mutually assured domination. Perhaps one will buy the other sometime.
 
 brandon
 
 
 
 

Re: Netflix To Cogent To World

[Phil Rosenthal]

On Jul 23, 2014, at 1:18 PM, Adam Rothschild a...@latency.net wrote:

 Comcast’s position is that they could buy transit from some obscure networks 
 who don’t really have a viable transit offering, such as DT and China 
 Telecom, and implement some convoluted load balancing mechanism to scale up 
 traffic.
 
 (I believe this was in one of Jason Livingood’s posts to broadbandreports, 
 unfortunately I don’t have a citation handy.)

If this is Comcast’s position, it is patently absurd. In 2005, I had several 
options available to buy transit from with reasonably good connectivity to 90% 
of the Internet’s eyeballs (eg: Level3, Global Crossings, NTT). While DT and 
China Telecom may have a huge presence in certain parts of the world — 
suggesting using them for general delivery in the USA.

As far as I am concerned, Netflix is sticking their neck out for the good of 
the internet here — and the don’t really have to.  Netflix has money.  Netflix 
has many pops. They can “just pay”. They can buy from whomever they have to. 
They can change their codecs however they need. 

The “little guy” doesn’t have those options, and Netflix’s battle is really for 
their benefit.

-Phil

NANOG Attendees: Flight cancellations on Wednesday

[Phil Rosenthal]

Just a heads up to those attending NANOG in Atlanta.

Delta has already cancelled 500 flights for wednesday, and will likely be 
canceling more.

http://www.delta.com/content/www/en_US/traveling-with-us/alerts-and-advisories/Southeast-Winter-Weather.html

You may want to check your reservations on your respective airlines, and 
reschedule flights and extend your hotel stay here, before everything is sold 
out.

In my particular case, the flights for thursday to my home town were already 
almost entirely sold out.

Regards,
-Phil

Re: Updated ARIN allocation information

[Phil Rosenthal]

On Jan 29, 2014, at 10:22 PM, Christopher Morrow morrowc.li...@gmail.com 
wrote:

 maybe these weren't meant to be used outside the local ASN? :)
 I do wonder though what the purpose of this block is? If it's to be
 used inside the local ASN (as seems to be indicated based upon minimum
 allocation sizes) then why not use the IETF marked 100.64/10 space
 instead? Global-uniqueness? ok, sure...

Seems like the obvious use case is for 6to4 NAT gateways, which would mean that 
global reachability would be expected.

-Phil

Re: isprime DOS in progress

[Phil Rosenthal]

Just a friendly notice, the attack against 66.230.128.15/66.230.160.1  
seems to have stopped for now.


-Phil
On Jan 22, 2009, at 6:01 AM, Bjørn Mork wrote:


Graeme Fowler gra...@graemef.net writes:


I've been seeing a lot of noise from the latter two addresses after
switching on query logging (and finishing an application of Team  
Cymru's

excellent template) so I decided to DROP traffic from the addresses
(with source port != 53) at the hosts in question.

Well, blow me down if they didn't completely stop talking to me. Four
dropped packets each, and they've gone away.

Something smells not quite right here - if the traffic is  
spoofed, and

my Refused responses have been flying right back to the *real* IP
addresses, how are the spoofing hosts to know that I'm dropping the
traffic?


Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping
traffic from other sources too?  Looks like some of the other source
addresses are controlled by the DOSers. Possibly used to detect  
filters?


These clients may look similar to the DOS attack, but there are subtle
differences:

Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656:  
view external: query (cache) './NS/IN' denied
Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656:  
view external: query (cache) './NS/IN' denied
Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656:  
view external: query (cache) './NS/IN' denied
Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662:  
view external: query (cache) './NS/IN' denied
Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662:  
view external: query (cache) './NS/IN' denied
Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662:  
view external: query (cache) './NS/IN' denied
Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664:  
view external: query (cache) './NS/IN' denied
Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664:  
view external: query (cache) './NS/IN' denied
Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664:  
view external: query (cache) './NS/IN' denied
Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667:  
view external: query (cache) './NS/IN' denied
Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667:  
view external: query (cache) './NS/IN' denied
Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667:  
view external: query (cache) './NS/IN' denied
Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670:  
view external: query (cache) './NS/IN' denied
Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670:  
view external: query (cache) './NS/IN' denied
Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670:  
view external: query (cache) './NS/IN' denied
Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673:  
view external: query (cache) './NS/IN' denied
Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673:  
view external: query (cache) './NS/IN' denied
Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673:  
view external: query (cache) './NS/IN' denied
Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678:  
view external: query (cache) './NS/IN' denied
Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678:  
view external: query (cache) './NS/IN' denied
Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678:  
view external: query (cache) './NS/IN' denied
Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679:  
view external: query (cache) './NS/IN' denied
Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679:  
view external: query (cache) './NS/IN' denied
Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679:  
view external: query (cache) './NS/IN' denied


Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716:  
view external: query (cache) './NS/IN' denied
Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716:  
view external: query (cache) './NS/IN' denied
Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716:  
view external: query (cache) './NS/IN' denied
Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752:  
view external: query (cache) './NS/IN' denied
Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752:  
view external: query (cache) './NS/IN' denied
Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752:  
view external: query (cache) './NS/IN' denied
Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785:  
view external: query (cache) './NS/IN' denied
Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785:  
view external: query (cache) './NS/IN' denied
Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785:  
view external: query (cache) './NS/IN' denied
Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808:  
view external: query (cache) './NS/IN'