DNSSEC basic information

[Evan Hunt]

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 -- each at isc.org
Internet Systems Consortium, Inc.