On 2012-09-27 at 19:30 +0100, Tony Finch wrote: > Phil Pennock <[email protected]> wrote: > > The most notable change would be that the ANY response with the MX > > would not include in-bailiwick A records for the hosts pointed to by > > the MX records in the ADDITIONAL section, because some clients assume > > that only the last section received could have been truncated, so an > > ADDITIONAL section can't be included. > > Note that a mail server can't rely on MX additional section processing,
Right; the difference is one of performance, with an additional query, not one of outcome. > Also, in-bailiwick is the wrong term since it includes sub-zones which > might be hosted elsewhere. Additional section processing doesn't require a > server to retrieve data it doesn't already have. >From the perspective of a client trying to decide whether to trust or not, in-bailiwick is the only view they have; they won't probe to distinguish if the ADDITIONAL section records are in a sub-zone. I could have written "any in-bailiwick answers which the server has available", to include AA and glue entries (which can still be included in the zone-file, although it obviously becomes a maintenance nightmare to do that for anything more than NS glue records). > Clients are allowed to assume that records are not dropped from the middle > of truncated responses, because that is forbidden by section 6.2 of RFC > 1035. And yet some do, which is why Bind is stricter than the RFC requires it to be and will only truncate at the end. Real world meets RFC and the result is pragmatic software. http://bridge.grumpy-troll.org/2011/02/dns-dont-implement-edns0-to-bypass.html Vernon Schryver wrote: > Try some experiments to see if what kind of amplification you can get > without ANY. I see about 20X from `dig +dnssec asadfasdf.com` A fair point, for which an approach only occurred to me after sending my mail, so rather than reply in email to myself, I commented on my G+ post (ah, netiquette): It's possible that this could be used to defer DNSSEC responses to non-ANY queries too, during DoS; the RRSIG belongs in the ANSWER section, but a TC response which skips the RRSIG and causes a TCP retry would: (1) return smaller results, turning off a large chunk of the amplification (2) with non-existent RR queries causing NSEC3 responses, defer the crypto work for NSEC3 until there's a TCP connection, which rate-limits the queries and reduces the CPU burden on the authoritative server All of this assumes that a modern server can be adequately tuned for TCP query volumes; for a dedicated DNS auth server, some very aggressive TCP state timeouts can be used (and can anyway, if the OS permits timeout tuning on a per-port/socket basis). Yes, any response _can_ be large and be used, but for DDoS amplification to spoofed source to be easy and useful, there needs to be something _consistently_ large which can be sent back in a UDP response. The main candidates today are ANY and DNSSEC. If we have a way to mitigate the impact of those and can turn it on by default, we shrink the general amplification ratio of the Internet's nameservers. It's likely that in future another RR type will result in similar amplificiation. Perhaps future RFCs for DNS should be required to tackle UDP amplification attacks in their Security Considerations, forcing new RR type proposers to make sure that the data they expect to insert into everyones' caches is as small as possible, rather than whatever's most convenient for their protocol. As long as UDP is used and enough ISPs aren't using ingress filtering, attacks will be possible; if we refuse to reduce the typical impact of those attacks because the solution isn't perfect, we're left with quixotic tilting at windmills, complaining about ISPs that don't filter. It would be helpful to find ways to work within a reality of ISPs not being willing to spend the money and engineering effort to be good network neighbours, instead finding ways to make sure DNS isn't part of the problem. -Phil _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
