> On Mar 23, 2017, at 1:50 PM, Ray Bellis <r...@bellis.me.uk> wrote: > > > > 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".
No snark intended, but if "the protocol" were really just DNS, we wouldn't be having this discussion. Rather, it is the DNS wire protocol using a local resolution context rather than the root zone. In any event, yes, the locally server homenet zone can function with DNSSEC. As I see the situation, a problem arises if there is a requirement for DNSSEC at some point in the future, and ".homenet" is found to be unusable as the special-use domain name. It would be unfortunate to deploy devices with ".homenet" now and find that needs to be changed in the future. > > 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. On the other hand, not publishing -redact now leaves ".home" in an indeterminate state in an Internet Standard, for example relative to the TLD assignment process in ICANN. > >> 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_. Again, I'll argue that "for now" is a potentially problematic way of looking at the issue, considering there may be several years of deployment between the selection of .homenet as an SUDN and determination of whether or not the necessary entry in the root zone can be added. - Ralph > > Ray > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
