Intended usage of dnssec-must-be-secure?

[Thomas Sturm]

Dear all,

According to the documentation of the option 'dnssec-must-be-secure',
which reads like

"Specify hierarchies which must be or may not be secure (signed
and validated). If yes, then named will only accept answers if
they are secure. If no, then normal DNSSEC validation applies
allowing for insecure answers to be accepted. The specified domain
must be under a trusted-keys or managed-keys statement, or dnssec-
lookaside must be active."

I understand that I should be able to resolve dnssec-failed.org
successfully with a config like:

managed-keys {
. initial-key 257 3 8 [current root key];
};

options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-must-be-secure dnssec-failed.org no;
};

I have a managed-keys statement and dnssec-validation is set to "yes",
and not "auto" (which might be a problem as I read elsewhere). However,
this doesn't work.

02-Feb-2016 17:29:47.036 broken trust chain resolving
'dnssec-failed.org/A/IN': 69.252.250.103#53

Am I doing something wrong, or is this not the actual intended usage of
this option?

Of course, my use case is not resolving broken DNSSEC zones, but
resolving forwarded local zones (non-existing TLD), however, above
example should make the question more obvious.

Thanks for any input.

Cheers,
Thomas

[Mark Andrews]

In message <34d77fc23ee95386...@nerdli.ch>, Thomas Sturm writes:
> Dear all,
>
> According to the documentation of the option 'dnssec-must-be-secure',
> which reads like
>
> "Specify hierarchies which must be or may not be secure (signed
> and validated). If yes, then named will only accept answers if
> they are secure. If no, then normal DNSSEC validation applies
> allowing for insecure answers to be accepted. The specified domain
> must be under a trusted-keys or managed-keys statement, or dnssec-
> lookaside must be active."
>
> I understand that I should be able to resolve dnssec-failed.org
> successfully with a config like:
>
> managed-keys {
> . initial-key 257 3 8 [current root key];
> };
>
> options {
> dnssec-enable yes;
> dnssec-validation yes;
> dnssec-must-be-secure dnssec-failed.org no;
> };

No. Insecure != invalid. Insecure zones don't have a DNSSEC chain
of trust to a configured trust anchor.

> I have a managed-keys statement and dnssec-validation is set to "yes",
> and not "auto" (which might be a problem as I read elsewhere). However,
> this doesn't work.
>
> 02-Feb-2016 17:29:47.036 broken trust chain resolving
> 'dnssec-failed.org/A/IN': 69.252.250.103#53
>
> Am I doing something wrong, or is this not the actual intended usage of
> this option?

The intended use is to catch policy errors where a zone is made
insecure but should not have been.

> Of course, my use case is not resolving broken DNSSEC zones, but
> resolving forwarded local zones (non-existing TLD), however, above
> example should make the question more obvious.
>
> Thanks for any input.
>
> Cheers,
> Thomas

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Evan Hunt]

On Wed, Feb 03, 2016 at 08:37:27AM +0100, Thomas Sturm wrote:
> Am I doing something wrong, or is this not the actual intended usage of
> this option?

That's not the intended usage.

dnssec-must-be-secure means what it says: the answers in this domain
*must be secure*. Everything has to be signed and validate correctly.
If it gets an unsigned answer, it is presumed to be a forgery.

> Of course, my use case is not resolving broken DNSSEC zones, but
> resolving forwarded local zones (non-existing TLD), however, above
> example should make the question more obvious.

I would suggest slaving the local zone instead of forwarding it.

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

[Thomas Sturm]

On 03.02.2016 09:36, Mark Andrews wrote:
> No. Insecure != invalid. Insecure zones don't have a DNSSEC chain
> of trust to a configured trust anchor.

OK, understood. However, in the case of an unsigned private domain that
is forwarded, it would be insecure and not invalid, right? What's the
reason this does not work either, then?

[Evan Hunt]

On Wed, Feb 03, 2016 at 10:02:39AM +0100, Thomas Sturm wrote:
> OK, understood. However, in the case of an unsigned private domain that
> is forwarded, it would be insecure and not invalid, right? What's the
> reason this does not work either, then?

It is invalid. There's a TLD claiming to be a child of the root zone
which the root zone denies having.

A couple of ways to make this work:

1) Sign your internal TLD and give all your local resolvers a copy of its
key. The key for the TLD will be used as a trust anchor; there will be no
need to validate the full chain of trust up to the root zone.

2) Have all your local resolvers slave the local TLD. When a server gives
out an authoritative answer to a query, it doesn't bother to validate it,
because when you're the authority you already *know* whether you're giving
the correct answer.