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

Reply via email to