On 12/15/2016 3:11 PM, Ted Lemon wrote:
On Dec 15, 2016, at 2:23 PM, Steve Crocker<st...@shinkuro.com> wrote:
I don’t understand what is meant by an “unsecured delegation.” I also don’t
understand what sort of delegation you want, irrespective of whether DNSSEC is
involved.
There would be a delegation for .homenet in the secure root, which would point
at the AS112 servers, and would have no DS records.
For clarity, the difference between unsecured and secured (or as
4033/34 call it unsigned and signed) is the presence of the DS record in
the parent.
The problem with providing an unsecured delegation for .homenet is that
items subsidiary to .homenet become spoofable in the wider internet and
that's not necessarily a good thing. It might make life easier for the
homenet folks to use the unsecured .homenet local zone, but it might
have adverse consequences for the non-homenet folken.
RFC6840, section 5.10 talks about how to handle nested trust anchors (in
this case consider the global "." trust anchors and one or more local
".homenet" trust anchors). If ICANN does a secure delegation to a DS
record, any
non-homenet-compliant--but-dnssec-validating-with-root-trust-anchors end
point or resolver will not see the .homenet zone. In other words, you
force a fail-secure for those systems that don't implement the Homnet
structure. In the Homenet-compliant case, you generate a local trust
anchor, install it in the various machines and configure your resolution
to use the "Accept Any Success" policy.
So the question: fail-secure-bogus or fail-unsecured (spoofable) with
respect to resolving .homenet on non-Homenet systems? I'd vote for
fail-secure and a secured/signed delegation.
I also think "secured but bogus DS records" is probably going to be a
more acceptable use pattern for the long term for special use names - if
for no other reason that to give us some control over the swamps.
Mike
ps - I see that at least the framework for .homenet local trust anchors
was done:
https://datatracker.ietf.org/doc/draft-mglt-homenet-dnssec-validator-dhc-options/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
