-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Thompson wrote:
>Michael Sierchio <[EMAIL PROTECTED]> writes: > >>Robert Story wrote: >> >>>VG> In the scenario you describe, I cannot see any actual amplification... >>> >>>The amplification isn't in the number of hosts responding, but in packet size. >>>A very small DNS request packet results in a huge response packet. >> >>Are you talking about rogue authoritative servers? Otherwise, responses >>will be limited to 512 bytes, possibly with the truncation bit set. > > >Unless it supports EDNS, in which case it may be persuaded to send >larger replies. BIND does currently have "you cannot be serious" >cutoff at 4096 bytes. > >The reason that it is more awkward to use the method against >authoritative-only nameservers is that you have to find a large >RRset in the wild (or one that will come with large authority and/or >additional sections in the reply) and then use the authoritative >nameservers for that RRset, not any old open recursive nameserver >(or many of them). You cannot craft your own RRset for the purpose. > That is not a problem. As usually MCI at your service. They have switched from RFC 3258 DNS design to having a very long list of name servers each of which is separate. That is at least 345 bytes of extra/authority section instead of the usual 70-100. All you need is to find a domain hosted with them. If you are happy with a 5x amplification you can simply use MCI.com They are not the only ones. It is a general trend in large ISPs/Telcos to exterminate with extreme prejudice any DNS design that requires some networking competence. Once again - transitions from RFC3258 to long lists are only one example. Plenty of others. >But you can still get amplification, certainly. > The real solution to this problem is people finally starting to enforce antispoofing on access networks. It is the same story as with smurf and broadcast amplification 7 years ago. It is time to put up a name and shame list out there. - -- A. R. Ivanov E-mail: [EMAIL PROTECTED] WWW: http://www.sigsegv.cx/ pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <[EMAIL PROTECTED]> Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEI5uu/NpXLt3l5xURApliAJ9LzA/Cnan74hSvRhOEKH6B0BI1zwCfe3x2 uDzVwvQTQQ5ugwYdtRdKhbM= =AKsS -----END PGP SIGNATURE-----