ICANN Requests Public Comment on Initial Report on Fast-Flux Hosting

Published: 2009-01-29. Last Updated: 2009-01-29 16:36:45 UTC
by Patrick Nolan (Version: 1)
4 comment(s)

This issue deserves widespread comment, the report is published here;

Initial Report of the GNSO Fast Flux Hosting Working Group
 

Already have an opinion? Go here - Public Comment: Initial Report on Fast Flux Hosting

You or your organization's lack of comment will ensure that what is adopted will turn out something like the SMTP Protocol. YMMV

Keywords:
4 comment(s)

Comments

Please comment. SMTP is painful.

Bill Essig

Jan 29th 2009
1 decade ago

Real-time blacklists of domain names, within an ISP or shared LAN's resolver or proxy, or used by a browser or security product, would be just as effective against a fast-flux domain as any other.

Steven Chamberlain

Jan 29th 2009
1 decade ago

One problem I can see immediately is DNSSec. When you're rolling over keys, you want a low TTL on your RRs to allow rollover propagation to complete as soon as possible, so you'll find many DNSSec production zones using TTLs as low as 600. Most of my zones use this as SOP and there's nothing inherently evil about using low TTLs. It also has a side-effect of minimising the damage of cache-poisoning for non-DNSSec aware resolvers. Granted, low TTLs are just one attribute pointed out in the PDF, but there are legitimate reasons for people to use them on their RRs. Hopefully, this "reliable detection [and] acceptable rate of false positives" (in this case, none, I should hope) will take this into account.

Matt

Jan 30th 2009
1 decade ago

Sounds like the first discussion about Fast Flux to decide if there were legitimate uses was contentious.

This is a case of blaming the network layer for inappropriate choices made for the session or application layers.

Basic requirements for authentication and encryption are not being appropriately graded to the criticality of the application.

Banks and investment companies routinely communicate to customers via email. Account management is implemented via web browser with asymmetrical authentication that relies on human judgment! The result is that fraud by FF hosting pays.

The solution to this problem is to secure the applications with technology that is appropriate to the level of value and risk. The network is only the pipe.

Michael H

Jan 30th 2009
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives