On 2012-09-29 2:28 AM, Mark Andrews wrote: >>>> Are you referring to this? >>>> http://tools.ietf.org/html/draft-eastlake-dnsext-cookies >>> Yes. It's a reasonable way to identify non-spoofed traffic which >>> means you can apply filtering techiques to the rest of the traffic >>> which will be a mix of spoofed and non-spoofed. >> i don't agree. there's no way to tell the difference between a client >> who hasn't upgraded, vs. a client who has downgraded or is behind a NAT >> box, vs. a spoofer. therefore we will not be able to drop non-cookied >> queries even while under attacks which spoof the same netblock as we get >> a non-cookied query from. > It's about identifying non spoofed returning clients. It does a good job of > identifying that set of clients. Those clients arn't using the server a > reflector. Those clients don't need to be penalised.
unless we can distinguish between packets from clients who don't implement EDNS from packets which are spoofed this is a small comfort to us or them. this is especially problematic for a large set of clients behind a NAT. > It also does a good job of protecting clients from off path spoofed replies. i don't think i'd be willing to drop non-EDNS requests just on the basis that some EDNS+cookies requests are coming from that address. so, no. > For the server queries that present no cookie or a bad cookie go > into the potentially rate limited pile. i'm ready to accept that rate limiting (as specified by DNS RRL) hurts non-spoofing clients who ask "similar enough" questions during the attack. but so far this has not been demonstrated or even described. a real recursive-service initiator may be forced to retry by UDP or even by TCP. but a real recursive-service initiator will usually have a cache. so the number of "similar enough" questions they'll ask will be so small that the total pain of this delay is not worth the investment of server-side state to solve for it. > For clients the benefits come in less need to use multiple ports > and knowing they are not going to be rate limited other than on > initial queries when talking to servers that support cookies. > > This is about pulling out good traffic from the undifferentiated > traffic we have today. given that RFC 2671 was finalized more than a decade ago, we now know the deployment curve of something like this. for that investment i want more payback next time. thus, RFC 6013. >> see RFC 6013, as earlier summarized in ;login: >> (http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf), >> for another approach to fixing not just DNS but HTTP state management. paul -- "It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin." --rick jones _______________________________________________ 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
