On Mon, Sep 23, 2019 at 08:16:43PM +0000, Jukka Pakkanen wrote: > I am finally diging in to DNSSEC, updating out BIND 9.14.5 servers to > support it, both resolving & signing, secure zone transfers etc. > > I just have read the DNSSEC Mastery by Michael W. Lucas from year 2013, > and my question basically is, is this information from 6 years back still > valid, or hopelessly outdated? I do suppose in six years things have > already changed a lot. And while started testing some things, noticed > they are not working as expected, as presented in the book. Like when > upgraded our servers to DNSSEC resolving, the only zone I can find the ad > flag set is paypal.com, example isc.org does not show it.
isc.org and all of its subdomains *except* for "www" should have the AD flag set. We switched recently to having our website hosted at a cloud provider, which is why the "www" domain doesn't have it. Some other domains that I use when I want to check quickly whether my local resolver is validating are nasa.gov (really anything at all .gov), ietf.org, icann.net. > Also, with current status of DNSSEC, is it still recommend/required to > have separate authoritative & recursive servers, DNSSEC-wise? Technically it was never required. It's still widely considered to be a best practice, though. But that's not really because of DNSSEC. > DLV functionality seems to be dropped from the current BIND too? Yes. The ISC DLV service was shut down a few years ago. The DLV key and the "dnssec-lookaside auto" feature were removed from BIND 9.14, but it could still be switched on manually if you wanted to use some other DLV zone that you set up yourself. Lookaside validation has been fully removed from the current development branch, which will become 9.16. > And so on... would like to know how outdated this book is, what has > changed since 2013, and also, any hints for a good DNSSEC tutorials with > todays BIND versions. Well, the big environmental change is that root key has been rolled. You longer need to specify "dnssec-validation auto" to activate the root key; it's on by default in BIND now. There's a new tool for generating DNSSEC keys, "dnssec-keymgr". It will create all the keys for your zone according to policy that can be set up in a "policy.conf" file, and maintains them for you if you run it in a cron job. (Something similar is likely to become an internal feature of named in a future release.) There's a way now for a signed domain to send an in-band signal to its parent that the DS RRset needs updating. A new tool "dnssec-cds" is available to help with this. AFAIK this mechanism hasn't been adopted by any TLDs yet, but may be of interest anyway. There's an rndc command "nta" to temporarily disable DNSSEC below a specified domain, to allow a domain to be resolved insecurely when it's been misconfigured. In newer releases there's also a configuration option, "validate-except", which permanently disables validation below specified domains. This can be used, for example, if you have an internal network using a fake TLD and you want to prevent it from showing up as bogus. Six years is a long time, I've probably forgotten a few. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
