On Thu, 28 Mar 2013 17:04:25 -0400 Michael Mol <mike...@gmail.com> wrote:
> > > >> listened to the dangers and even now simply redesigned DNSSEC. > > > > Or they could fudge it by making every request requiring padding > > larger than the response. Bandwidth would increase astronomically > > but amp attacks would have to find other avenues. > > > > Infeasible; the requester cannot know the size of the response in > advance. If a packet comes in, and the response is larger than the > request, is it really an amp packet, did the client not know, or is > the server misconfigured and not limiting the response data as much > as it could? I'm certainly not saying it's a good idea, hence the 'fudge' and 'making every request' which would mean non updateable clients or non updated routers (90%) needing special treatment. I'm sure there are probably other hurdles to it but it is certainly possible to make a request much larger than any potential response similar to the anti-spam system that makes creating a message take a lot of cpu and then only accepting messages from those that do (hsomething I think, only works too if all take part but would eliminate spam almost completely). However thinking about it, considering the want for dns to provide larger things like encryption keys, huge requests may be the best long term solution for a DNSSEC which seemingly refuses out of pride to add something like DNSCURVE to prevent spoofing. Similar to firewalls only sending a single syn ack (less than or equalise)
