> By using DynDns are you proposing to remove the requirement of having > a naming resolution mechanism internally in the homenet ?
No. Naming *internal* to the Homenet needs another mechanism, perhaps what Ted is designing (and implementing), perhaps something else. Exporting names from the Homenet into the global namespace, on the other hand, should be done by the hosts, with no involvement of any third party (neither the ISP nor the Homenet itself). This is where I argue for some form of end-to-end, secured, dynamic DNS update. > But considering that we need an internal dns to serve internal requests > (regardless of an ISP connection) and that we also need an outsourced > one for external resolution, isn't it simpler to make them synchronize > in a primary / secondary fashion ? Wouldn't it be an extra work to > manage (update/add/delete) multiple records through dyndns ? I claim it isn't. Synchronising with the external DNS provider is no more work than synchronising with the hidden master, and it avoids the hairy issue of electing the hidden master. > From my understanding dyndns would solve just a small part of the whole > problem being tackled here which is: providing internal/external name > resolution and manage the synchronization of an entire zone, rather than > updating a single record continuously. It solves the issue of exporting names into the public namespace. This has nothing to do with name resolution internal to the Homenet. -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
