ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-ff-pdp-may08] Section 5.10 Text

  • To: Fast Flux Workgroup <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: [gnso-ff-pdp-may08] Section 5.10 Text
  • From: Rod Rasmussen <rod.rasmussen@xxxxxxxxxxxxxxxxxxxx>
  • Date: Thu, 13 Nov 2008 14:03:34 -0800

Hi folks,

Sending this around to everyone as I don't think we made the cut on getting it in Marika's latest draft.

This text is meant for section 5.10 that asks, "What are some of the best practices available with regard to protection from fast flux?" All that was done here was to add and explain references to two different documents that cover some possible best practices that could be brought to bear: the APWG Registrars Best Practices and the SSAC paper on Fast Flux hosting. Some of the pertinent points were brought out to show their relevance, but the point here is to get references to relevant documents included here.

We should probably discuss any changes/additions/etc. to this along with our other work for tomorrow's call.

Thanks!

Rod

=====================

One source of best practices for protection from fast flux can be found in the phishing world. The Anti-Phishing Working Group has recently released a best practices document for domain registrars in dealing with domain names registered by phishers ("Anti-Phishing Best Practices Recommendations for Registrars" http://www.apwg.org/reports/APWG_RegistrarBestPractices.pdf) . Several of the practices outlined in that document apply directly or indirectly to dealing with fast flux domain names. While the audience for this particular document is the domain registrar community so some particular recommendations may not translate to other entities within the domain registration space, the same general principles can apply to domain registries, domain resellers, and other providers of domain registration or support services.

The following is a paraphrased sampling of some of the applicable practices mentioned in this document: - Track the IP address, date, time, frequency and action of all account changes such as updating DNS or WHOIS information

- Limit the ability of registrants to repeatedly change their name servers via a programmatic interface to reduce or eliminate automated name server hopping.

- Proactively use available data to identify and/or shut-down malicious domains: There are numerous data sources that can provide information that may help in identifying malicious activity. Lists such as theSORBS Dynamic User and Host List can provide networks associated to dial-up, DSL, and cable networks that are more likely to be abused. The Composite Block List (XBL) may indicate fraud. Optimally a registrar would check against this information at DNS set- up or modification time, however periodic scanning should see good results.

- Use a "Registrar Lock" on registrations that are deemed to be suspicious enough to warrant further investigation.

Another source for suggested practices to mitigate the use of domain names in the "double flux" variant of fast flux attacks is SAC 025, Fast Flux Hosting and DNS (http://www.icann.org/committees/security/sac025.pdf ).

SAC 035 identifies mitigations methods certain registrars practice today in cases where the registrar provides DNS for the customer's domains:

- Authenticate contacts before permitting changes to name server configurations. - Implement measures to prevent automated (scripted) changes to name server configurations. - Set a minimum allowed TTL (e.g., 30 minutes) that is long enough to thwart the double flux element of fast flux hosting. [The WG notes that this method could interfere with customers (registrants) who use low TTLs for legitimate uses, without harm to others. In such cases, the DNS provider might provide exception case processing or white listing.] - Implement or expand abuse monitoring systems to report excessive DNS configuration changes. - Publish and enforce a Universal Terms of Service agreement that prohibits the use of a registered domain and hosting services (DNS, web, mail) to abet illegal or objectionable activities (as enumerated in the agreement).

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy