[c-nsp] rate limit dns

[Mack McBride]

Now you are using the straw man argument.
Phishing has little to do with DNS per se.
If a known address is doing phishing a provider can certainly falsify that DNS to protect their customers.
BUT, forcing customers to use your DNS results in the possibility of all of your customers suffering in a DDoS
situation where your DNS servers are targeted.

DDoS attacks on DNS servers are particularly devastating for both resolvers and authoritative.
You can't simply block the traffic to those boxes as that takes sites off line,
effectively completing the attack. Simply rate limiting can achieve the same result.

As an ISP, how many of my customers are going to stick around if their service is down for 3 days or even a week?
I mean for Comcast that might work because many customers don't have any other choice.
I currently live in an area where I can only get Comcast, no DSL available.
DSL is another arena as you still have a choice of providers available as the phone companies are still required
to provide other providers access to their customers.

I would advise against limiting DNS choices.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbride at viawest.com | www.viawest.com | LinkedIn | Twitter | YouTube



-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dobbins, Roland
Sent: Sunday, December 29, 2013 5:32 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] rate limit dns


On Dec 29, 2013, at 7:21 PM, Gert Doering <gert at greenie.muc.de> wrote:

> And that is where we differ.  You find it OK to limit the protocol du 
> jour to "what users do not need", I do not agree to it.  Even if I agree with you that "most users would not notice".

I'm not proposing blocking DNS.  I'm proposing a default policy for consumer broadband users which assumes that they'll use the DNS recursors provided by the broadband network operator, unless the use chooses to opt-out.

> in reasonable countries, ISPs are protected from charges for traffic 
> they transport *unless* they start messing with it - if you start filtering traffic for "protocol X", but leave through the evil packets for "protocol Z", you're *way* more likely to be made liable for it.

Again, this isn't the same thing.  Nobody's talking about blocking the DNS.

Here's the risk that I see for network operators, moving forward, if they don't implement sensible, low-impact default (with the ability to opt-out, which would include indemnification) policies of this nature to protect their user bases:

1.	Consumer user X ends up getting phished/compromised, attacker empties his bank account, maxes his credit cards, applies for new credit cards in the user's name but delivered to another mailing address under the control of the attacker or his minions, etc.

2.	User X ends up suing the bank(s) and credit card issuer(s) in question, alleging that those entities didn't take reasonable security precautions, and are now liable for all the actual and punitive damages claimed by user X as he struggles to get his money back, clear his credit history, etc.

3.	Liability insurance companies for the bank(s) and credit card issuer(s) in question turn around and sue the network operator for damages based upon negligence, alleging that reasonable and practical security policies which could've potentially prevented this fraud from being possible weren't implemented.  They might sue software vendors - OS vendors, foundations providing open-source Web browsers, and so forth, as well.

4.	Politicians/regulators get wind of this, and pile on.

A little bit of prudence now could obviate a whole lot of financial hurt and heavy-handed legislation/regulation, later.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton