On May 16, 2014, at 8:13 AM, Colm MacCárthaigh <c...@allcosts.net> wrote: > I've never been able to make prioritisation really work at microsecond scale. > I can imagine a dedicated process for signing and having prioritized queues > to it, but that would need so much packet copying that it would likely > degrade throughput seriously. Alternatively the DNS handling process may > defer the signing and keep its own queue locally, but that introduces > scheduling overhead. Every time I've tried it, I've found that taking out > prioritisation and smart scheduling made the overall average faster.
Good point, although it really only takes 2 queues: If in cache->return it. If "high", queue 1 if "low", queue 2. You need at least one queue anyway, because you want to do the cache check first, and you need to keep doing cache checks while your crypto is ongoing to avoid the trivial DOS. >> Thus your wristwatch loaders can only act to load the non-priority category, >> which would be NSEC3. If you actually care about zone enumeration, you MUST >> generate NSEC3 records on the fly, because lets face it, NSEC3 in the static >> case doesn't stop trivial enumeration of the zone. > > Another approach to this is to pre-sign a fixed number of NSEC3 records per > zone, regardless of the zone's real size or contents :) You need the order of records to be HUGE, because you walk the NSEC3 zone, and you then use a dictionary attack: NSEC3 in a static case, even with a huge number of bogus NSEC3 records you can only hide names if names are not a-priori predictable from a reasonable attacker. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
