Re: DNSSEC in real life

[Viktor Dukhovni <[e-mail]>]

On Wed, Apr 21, 2021 at 05:10:16PM -0700, [e-mail] wrote:

> It's simple enough to configure it for basic domains, but I have a split-horizon
> setup, and that complicated things quite a bit.

Sure.  It is often simpler to avoid views and just operate separate
zones, even if some IP addresses appear in both zones.  But views
do have their uses.  What versio of BIND are using?  Significant
further improvements in DNSSEC support have been made in 9.16.

> However, in the process I managed to make a cut-and-paste error and
> ended up with one valid and one invalid DS record for one of my
> infrequently-used domains. Which was noticed by exactly nothing,
> including the DNSSEC testing tool I happened to use to validate my
> setup.

Then you need better monitoring scripts, because DS records should
always match an extant DNSKEY, proper operational procedure is to first
retire the DS record, and only later the corresponding key.  With fully
automated signing, and as registries begin to roll out CDS/CDNSKEY
support, this sort of mistake will become less common.  But it is easy
to check for.

> Some time later I got a problem report from IANA. It seems that IANA has DNSSEC
> checking enabled on mail server, I assume because they have enabled DANE
> (although this was never 100% clear), and I happened to have used this domain
> for an internal list forwarding address.

I wouldn't expect a DANE mail server to notice a partial DS RRset
mismatch, validating resolvers continue to work so long as the
other DS record is sound.

> And I still have work to do because Bind has added a number of options
> that I need to set, but before that can happen I need to upgrade BIND,
> and before that can happen I need to upgrade some other stuff.

When you're done upgrading, you'll find BIND 9.16 quite easy to
work with.  Take a look at the new signing policy features.

> All this is for a total of 9 domains - a toy setup by any measure.

It is often easier to things at scale than for just a handful of
domains.  The effort to learn the tools is more efficiently amortised.
This is why we're seeing a rush to move IT to the cloud and make it
someone else's problem.

> I know a little (but not a lot) about the DNS infrastructure at
> Oracle, and the cost and complexity of migrating it to DNSSEC would be
> staggering.

I'm rather sceptical about "staggering", sure there'd be a bunch of man
weeks spent in meetings, and some devops folks may have to put together
some Nagios monitoring scripts, and spend a bit of time to enable
automated zone signing.  It is a non-trivial, but not a staggering cost.

Yes, the business case to expend the modest, but non-trivial resources
is often not that great at present, and complications arise if one is
also depending on just short of standards-compliant DNS load-balancers,
that don't even do regular EDNS at all well.

The main adoption barrier is IMHO really poor support for key rollover
at the registrars.  There's a bunch of recent activity to make that
better, and some new registrars are much better at this than the long
established ones, who aren't investing in keeping current, the cost
savings may make sense in the short to medium term, but long-term I
expect they're not a good strategy.

-- 
    Viktor.