Hi Juliusz, I'm just catching up in the mailing list here and I'd like to clarify if my understanding is correct.
By using DynDns are you proposing to remove the requirement of having a naming resolution mechanism internally in the homenet ? DynDns does work nicely to update a single record whenever it changes. 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 ? >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. Cheers Elson -----Original Message----- From: homenet <homenet-boun...@ietf.org> On Behalf Of Juliusz Chroboczek Sent: Thursday, July 19, 2018 4:38 PM To: Ted Lemon <mel...@fugue.com> Cc: Homenet <homenet@ietf.org> Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS > One way to automate this would be using mud. A bright light shines from the heavens, bathing you in its warm glow. An enormous, white temple stands to the north, taking most of your view. In order to enter the Temple of Homenet Naming, you must travel up the large staircase that stands in front of you. Exits: North, West, East, South. (Perhaps you had something else in mind when you said MUD?) _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet