[dns-operations] Small datapoint on current DoS mitigation

Dobbins, Roland rdobbins at arbor.net
Fri Apr 4 09:13:00 UTC 2014


On Apr 3, 2014, at 3:38 PM, bert hubert <bert.hubert at netherlabs.nl> wrote:

> We hear from many operators that this has successfully mitigated the impact of this DoS both on them and on the target.

This is an interesting feature, but there are a couple of other considerations:

1.	This attack traffic is in many cases being bounced through broadband CPE which are misconfigured as open DNS forwarders.  They can potentially be abused for DNS reflection/amplification attacks, so it's important that they be remediated.  

2.	If the situation is as described above, there's another way to temporarily resolve this particular problem (pardon the pun, heh).  Simply implement an ACL on the coreward interfaces of the broadband customer aggregation routers, something like this (obviously, it should be integrated in a situationally-appropriate manner with any existing iACL and tACL stanzas; and the IP address ranges in these ACL stanzas should reflect the actual IP address ranges in use on the consumer broadband access networks in question):

-----

access-list 101 remark Apply these stanzas inbound on coreward customer aggregation gateway interfaces.
access-list 101 remark Deny inbound traffic to UDP/53 on broadband customer networks.
access-list 101 deny udp any 172.19.25.0 0.0.0.255 eq 53
access-list 101 remark Allow all other IP traffic to customer nodes - VERY important!
access-list 101 permit ip any 172.19.25.0 0.0.0.255

-----

The above example ACL stanzas are in Cisco ACL syntax.  They can be implemented on Juniper and other devices by utilizing the relevant ACL syntax.

This *must* be tested, then piloted, before general deployment, and must be scrubbed in terms of AUPs, etc.  It *must* also be socialized to customers and to internal support staff prior to general deployment.  

If customers are running older resolver code which sources queries from UDP/53, then this ACL will cause problems for them; utilizing flow telemetry to determine the likelihood of these corner-cases arising is very important, along with plans to proactively handle them without breaking the Internet for these customers.

This is *not* a permanent solution, and should *not* be left in place forever.  The *real* solution is to clean up the broken, misconfigured CPE devices, and that must be done, anyways.

Operators should poke holes in the above ACL to allow their dedicated management systems to send packets to UDP/53 in order to facilitate scanning for broken devices; they should also poke holes in it to allow such scanning from <http://www.openresolverproject.org/> and the self-test on <http://www.thinkbroadband.com/tools/dnscheck.html>.  The folks behind these projects should be contacted directly in order to obtain the relevant IP address ranges (the respective contact email addresses can be found on the Web pages listed above).

ACLs of this nature are highly undesirable.  They are a form of arteriosclerosis which has been affecting the Internet since ACLs were invented, and the problem gets worse over time, because folks put them into place and then forget that they're there.  But judicious *temporary* use of such an ACL, combined with a commitment to fix the underlying proximate issue (in this case, misconfigured CPE devices) and then remove the ACL, can be tactically useful in order to provide relief and maintain availability in the interim.

This is a *temporary* measure intended to provide immediate relief whilst the *real* solution - i.e., remediating the broken CPE - is pursued.  And it *must* be tested, piloted, and validated prior to any general deployment.  And it *must* be removed as soon as the broken CPE are remediated.

Obligatory BCP38/BCP84/SAC-004/S.A.V.E. exhortation should be considered as read.

;>

To clarify, I am *not* an enthusiastic proponent of these types of measures.  Indiscriminate, de facto-permanent filtering of the problem-of-the-day has caused untold damage to the Internet ecosystem.  This temporary emergency measure is being posited as just that - a *temporary emergency measure* - and it should *not* be deployed and then left in place for the duration (i.e., forever).

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

	  Luck is the residue of opportunity and design.

		       -- John Milton




More information about the dns-operations mailing list