John Allen wrote:

As you point out a PTR lookup probably does everything that an attack would do any way. If that is the case is it pointless to have nsec3 set at all.

This is not entirely true, as you may have multiple names that resolve to one address, with only a single PTR record. If you put the names of upcoming products and such in your domain names, you may find that NSEC3 offers some protection (at least if you change the salt often enough to prevent brute-force attacks). But if you don’t care about zone walking, there are many advantages to using NSEC, not just simpler signing and smaller responses. In particular, some recursive resolvers already use cached NSEC responses to synthesize NXDOMAIN responses (https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 – currently only Unbound and Google Public DNS). This can provide some mitigation of random-prefix DoS attacks on your authoritative name servers. The RFC does describe the possibility of using cached NSEC3 responses but this is more complicated, and because of NSEC hashing, the effectiveness is reduced (the recursive resolver has to cache many more NSEC3 responses to get the coverage it can get from much smaller sets of NSEC responses. It is absolutely true that there is no point ever using NSEC3 for reverse (in-addr or ip6) .ARPA zones, since you can use NXDOMAIN responses on partial results do an efficient search of only the populated parts of the zone time proportional to number of domains in the reverse zone rather than the number of addresses in the delegated name space (in other words, even IPv6 is no protection). See https://tools.ietf.org/html/rfc7707#section-5.1.4 https://tools.ietf.org/html/rfc7707#section-5.1.4. A reasonable split-the-difference approach can be to use NSEC for your domain’s top-level zone (example.com) where the domain names are likely to be “www” “mail” “smtp” and so forth, and only use NSEC3 for delegated subdomains where confidentiality may be more important (dev.example.com). @alex

On Mar 6, 2017, at 4:39 AM, Andreas Schulze wrote:

Hello Viktor,

Your suggestion differ from RFC 5155. https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing"

Could you explain your choice more verbose?

If you do manual full-zone re-signing, feel free. Most zones are re-signed incrementally and automatically, but the entire NSEC3 chain must use a single salt (or two chains need to be built during the transition). In any case, the main benefit of NSEC3 is "opt-out" to allow sparse signing in TLDs, hiding the zone content is only an emotional impulse, there's little rational use for it in the vast majority of cases. Others may of course disagree, ... Be sensible, but focus on operational reliability above all other considerations. -- Viktor.