In message <916eeeb9-3709-492b-8e19-5c832b11a...@fugue.com>, Ted Lemon writes:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews <ma...@isc.org> wrote:
> > The delegatation is INSECURE and SIGNED not UNSIGNED. The wording
> > here is *important*.
>
> Can you explain what the distinction is, and what the problem is that you
> see in point five? The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant. It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct." So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?
The delegation has *signed* NEC/NSEC3 records that prove that there
is no DS record at the delegation *and* that the delegation *exists*
unless OPTOUT is also set in the covering NSEC3 record. The presence
of the NS bits without a SOA and DS bits in the validated NSEC/NSEC3
record proved that the child zone is insecurely delegated. Note
this does not work if the delegation is unsigned.
All delegations from a signed zone are signed. These is no such
thing as a unsigned delegation. There are only secure (with signed
DS) and insecure (without DSi but with signed NSEC/NSEC3).
This is different to a unsigned delegation in a unsigned zone where
there is no proof of anything.
RFC 4033
Insecure: The validating resolver has a trust anchor, a chain of
trust, and, at some delegation point, signed proof of the
non-existence of a DS record. This indicates that subsequent
branches in the tree are provably insecure. A validating resolver
may have a local policy to mark parts of the domain space as
insecure.
RFC 4035
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
Then add to that "insecure delegation" is the existing term for this
type of delegation.
RFC 6063
As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
namespaces, the zones listed above will need to be delegated as
insecure delegations, or be within insecure zones. This will allow
DNSSEC validation to succeed for queries in these spaces despite not
being answered from the delegated servers.
RFC 7719:
Insecure delegation: a name containing a delegation (NS RRSet), but
lacking a DS RRSet, signifying a delegation to an unsigned child
zone.
Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.)
Opt-out tackles the high costs of securing a delegation to an
insecure zone. When using Opt-Out, names that are an insecure
delegation (and empty non-terminals that are only derived from
insecure delegations) don't require an NSEC3 record or its
corresponding RRSIG records. Opt-Out NSEC3 records are not able
to prove or deny the existence of the insecure delegations.
(Adapted from [RFC7129], Section 5.1)
As for point 5 the delegation for "home.arpa." will exist once IANA
adds it to the ARPA zone. The content of the delegation won't match
but it will exist. Note any server that performs such tests is
already broken as STD 13 requires that the child zone be setup
before the delegation is made. I know there are DNS hosters that
require the delegation exists and list the server but they are
actually wrong to do this. DNS delegations are make before break.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
