Subject: [DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Mar 2017 19:23:46 -0500

I have looked at the need for unsigned delegations required to satisfy stub
validators, and am interested in feedback to an idea I have: signal to the
stub, deliberate non-use of DNSSEC.

The presumption is that a stub's use of a recursive resolver involves some
degree of "trust", at least if it uses the resolver by choice, and does not
set the CD bit.

What seems to be "missing" (as in, maybe it is a corner case that wasn't
noticed before), is the ability for a security-aware resolver to "signal"
to a stub, that it is deliberately not returning DNSSEC records, even
though the stub set the DO bit (DO=1).

The obvious signaling mechanism, at least to me, would be setting DO=0 in
the response.

The particular circumstances under which a resolver might do so, are
probably irrelevant (call it "local policy"), but one example in particular
would be homenet.

If a query for <something>.<homenet-domain> from a validating stub were
received, and local policy was "no DNSSEC for you" if the query is at or
below <homenet-domain>, this signaling would help the stub realize that the
situation for that resolver is, "I'm not deaf, I'm ignoring you". Set DO=0
and return unsigned answers.

Or is it far too late to be suggesting changes for sub-resolver DNSSEC
signaling?

Thoughts?
Brian

---

From: Evan Hunt <[email-masked]>
Date: Fri, 31 Mar 2017 02:57:02 +0000

> though the stub set the DO bit (DO=1).

Why would the stub trust such a signal? Seems like an easy mechanism
for a downgrade attack.

> Or is it far too late to be suggesting changes for sub-resolver DNSSEC

Signaling from the resolver to the stub doesn't seem like a promising
approach to me.

If for some reason you can't put an insecure delegation in the global
DNS, then it would work to configure both the stub and the resolver with
(*sigh*) a permanent NTA for .hab.arpa or whatever.

(I was so very firm in my advocacy that NTAs should always be temporary
when RFC 7646 was being written. Please let's just have insecure
delegations?)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.