On 23/03/2017 10:34, Suzanne Woolf wrote:
> I’m trying to make sure I understand what the special use reservation > accomplishes in the absence of the insecure delegation. > > If I read your comment correctly, I can infer two things about the > protocol, whether the insecure delegation is delayed or refused, at > least in the short term: > > 1. The protocol is sufficiently functional for deployment without > working capability for DNSSEC validation. Correct, in so much as "the protocol" is actually "DNS". The HNCP protocol is only used to configure the domain name used for local resolution, but Homenet's zeroconf nature requires that there be a default value, and as such Homenet / HNCP is not fully deployable without an agreed default. The presence of ".home" as that default in RFC 7788 was a mistake, and the current pair of drafts is our attempt to rectify that. Hence w.r.t Matt Pounsett's argument that the -redact document go first and then the assignment of ".homenet" be done later, the Homenet WG has argued *very* strongly that this is not acceptable because it leaves HNCP in an indeterminate state. > 2. Having a single-label name is more important for the functioning > of the protocol than having DNSSEC validation work. > > Is this a fair assessment of the WG’s view? Not quite - DNSSEC should work correctly on any Homenet resolver which has the appropriate trust anchor configured. The insecure delegation is required to allow validating stub resolvers in hosts to access .homenet names without the signed proof of non-existence that's currently in the root from getting in the way. Since those validating stubs are currently exceedingly rare, we can live without that insecure delegation _for now_. Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
