Thanks for your patience, Daniel. I feel I'm understanding a little more
now. My main misunderstanding was the following:
- you're not populating DNS with mDNS data, you're populating it with the
DHCP hostname data; I now understand that mDNS is mostly orthogonal.
What I still don't understand is how your protocol can work when the
hidden master is not the CPE.
> In the architecture document we mention that the CPE is the most likely
> to host the DNS zone for the home network.
I'd really like to encourage you to revise the drafts so that it makes it
clear that the hidden master is not necessarily the CPE. I'd be
particularly keen to understand how the hidden master can sign the zone
when it is not the CPE, given that you expect signing keys to be obtained
over DHCP.
> I do not think our architecture is bound to the CPE [...] If you could
> point specific sections, that would help to clarify the next versions.
This document describes a homenet naming architecture where the CPEs
manage the DNS zone associates to its home network,
[...]
the DNS(SEC) Homenet Zone built by the CPE is outsourced to Public
Authoritative Servers.
[...]
The zone signing and secure delegation can be performed either by the
CPE or by the Public Authoritative Servers.
[...]
outsourcing the authoritative naming service from the CPE
...and so forth, and so on. I'm sure you can see where my confusion stems
from ;-)
> Similarly, I do not recall using the term proxy in one or the other
> draft, and I do not see what could be considered as a proxy.
I fear I wasn't very clear:
1. the homenet nodes populate the master zone at the hidden master (which
is not at all the CPE, as we've established above) using DHCP;
2. the hidden master (which is not at all the CPE) performs a zone
transfer to its secondaries (which are not at all the ones hardwired by
the ISP into the CPE) using normal DNS(SEC) procedures.
So in effect the hostname data is flowing (1) from the node to the hidden
master which (2) forwards it to the authoritative secondaries. In effect,
it's being proxied from the node to the secondaries by the hidden master.
> In the architecture we propose, things may be as follows: the NAS only
> needs a hostname: myserver for example. You plug the NAS in your home
> network, it announces its name via DHCP. The DHCP transmit the
> information to the entity that manages the DNS zone, which then
> outsource the zone to the registrar. You NAS does not need to be
> configured to update the zone at the registrar.
Ah. I think that's the crucial point -- it's easier to provide
credentials to a single node rather than to every node that needs to
register in the global DNS. That makes sense.
So how does the hidden master get the credentials? You say:
The DHCP Server makes the Public Key available to the DNS servers, so
the CPE can secure its DNS transactions. Note that the Public Key
alone is not sufficient to perform the authentication [...] How the
binding is performed is out of scope of the document. It can be
a centralized database or various bindings may be sent to the
different servers.
That speaks about the ISP's DHCP server, right? But now that we've
established that the hidden master is not the CPE -- it's not necessarily
on the same link as the DHCP server. Are you assuming a DHCP proxy at the
CPE?
I also don't understand what you mean by "various bindings" in the last
sentence quoted above. I'd appreciate a clarification. Perhaps you can
tell us how the private keys are distributed in your implementation?
>>> Suppose your ISP has a connectivity issue, even a node in your home
>>> network will not be able to contact your web server as the DNS(SEC)
>>> resolution is not possible.
>> But my nodes are still running mDNS/zeroconf, right?
> By the way, I am not deprecating the use of mDNS at all it is simply
> orthogonal.
What I meant by that is that you're still running mDNS, so losing
connectivity to the master won't prevent you from resolving using mDNS.
However, I now see that you're not deriving the DNS zone from mDNS, so the
name you're interested in might very well not be advertised over mDNS.
Thanks for your patience,
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
