STARK, BARBARA H <mailto:[email protected]>
1 Sep 2015 12:23
and that is also not covered in DNS-SD AFAICS.
<individual hat firmly in place>
As a potential end user of homenet (i.e., within my personal home
network), I very much do *not* want any of my IoT devices, printers,
or scanners to be publicly discoverable via DNS. If and when I want
anything discoverable via public DNS, I want to be very explicit about
what that is. So any "automating zone delegation" solution needs to
have as a requirement that it must not automatically cause anything to
be externally discoverable that the end user does not explicitly identify.
The tremendous lack of security being built into printers, scanners,
IoT devices, and other devices on the home network suggest that
automatically exposing them to external discovery would likely have
Very Bad Consequences for the majority of end users (who will be
completely unaware that such automatic exposure was occurring).
Barbara
I hear you.
But I think the discussion on automatic delegation of a DNS name space
is separate from which content Homenet publishes in which zone.
I'm thinking of a delegation mechanism similar to how RFC3633 delegates
address prefixes, that would allow a DNS service provider to delegate
one or more subsets of their name space to a Homenet to use as it's
parent name space.
The transport for this delegation mechanism might be DHCPv6, for the
case where a DNS operator (the ISP) wants to delegate a reverse zone for
PTR records for reverse resolution, but it might also be an API over
HTTP for where there's a DNS provider who has no business relationship
with the upstream ISP(s). Or both....
The name space delegation would support the use case where the DNS
service provider supplies information for the Homenet on how to update
the RR hosted on the DNS provider's DNS servers, as well as the use case
where the Homenet itself provides the DNS servers, and the DNS service
provider has to enter NS records and glue records in their own DNS servers.
Once those name space delegations are in place, it would be a separate
discussion on how content is generated and updated e.g. printers using
ULA addresses should not be pushed to a zone visible on the public Internet.
If we don't have a set of unique parents for the Homenet name space
(either delegated or self-generated), we'll also run into security
issues, as .home or .local themselves are not unique for devices that
roam between multiple (disjoint) Homenets. In exactly the same way that
ULA addresses also have to be (reasonably) unique across the set of
Homenets.
So myprintservice.<obscure_nonce>.home. would be fine for me for the ULA
space. The <obscure_nonce> portion of the name space would obviously not
generally be displayed to end users.
And for GUA space it could be myservice.<obfuscated_cust_id>.myisp.com
or myservice.<obfuscated_cust_id>.mydnsservice.org
--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
