Subject: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 Jul 2018 23:21:29 +0200

Dear all,

Since the 1990s, people have been putting their dynamically allocated IPv4
addresses into global DNS by using a family of gratuitiously incompatible
trivial protocols.  The technique doesn't have an official name (let alone
a specification), and is usually referred to as DDNS, DynDNS or Dynamic DNS.

The basic idea is as follows:

  - the client is configured with its DynDNS provider;
  - whenever its public IP changes, the client makes an HTTP request to
    register the name directly with the provider.

Usually, but not always, there's some form of garbage collection -- if the
client fails to refresh its name within some timeframe, the entry is
deleted.  Security can be achieved either by using HTTPS with a plaintext
password, or by using clear HTTP and a cryptographic challenge mechanism.

This kind of protocol has a number of desirable features:

  - the client side can be implemented in roughly 4 lines of Python;
  - it's end-to-end, so no privacy issues (if using HTTPS);
  - it's end-to-end, so it doesn't depend on any local infrastructure;
  - it's end-to-end, so it can be used in a foreign network (e.g. you can
    use it to advertise the address of the game server you run on your
    laptop during IETF meetings).

DynDNS has been widely deployed for 20 years or so, and would appear to
solve the problem of name outsourcing quite nicely.  What technical
problem is draft-ietf-homenet-front-end-naming-delegation solving that is
not adequately solved by a DynDNS-style solution?

This is a question that I've been asking since July 2014:

  https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA

and I still haven't received an answer I could understand.

-- Juliusz

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Jul 2018 11:07:41 +1000

All of this can be done in the DNS without resorting to any other protocol.

_dns-update._udp SRV is registered with IANA for finding where to send
UPDATE request to if the SOA MNAME or the NS’s are not reasonable.
UPDATEs can be secured with TSIG (shared secret) or SIG(0) (public key
cryptography).  The later has the advantage that there isn’t a scaling
issue as the KEY record is stored in the zone.

If you want to experiment with this named has an update policy rule that
allows just such secured updates.

	update-policy {
		grant example.com name * KEY;
		grant * self . [type list];
	};

where example.com is a TSIG or KEY record used by the administrator
to install the KEY record for the node initially.

Garbage collection (GC) had never been defined by a DNS protocol but a simple
one would be to request a TYPE that can live a long side CNAME (like KEY
does) which has the type code to be removed and GC time.  Server policy
could be to add this or the client could include the record in the UPDATE
request. Doing GC with a record like this would be trivial for a DNS server.

DNSSEC servers already do wall clock time based regeneration of RRSIGs using
the type covered and expiry fields of the RRSIG records.  GC would use a
similar mechanism.

> On 19 Jul 2018, at 7:21 am, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 03:35:25 +0200

> All of this can be done in the DNS without resorting to any other protocol.

Excellent.

So what technical reasons are there to prefer the complexity of
draft...front-end-naming-delegation over a trivial update protocol,
whether encapsulated in HTTPS or DNS?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 21:46:11 -0400

The trivial update protocol isn't a standard protocol, and doesn't do what
we need it to do.   In order for services to be discoverable on the
homenet, they have to publish their contact info on the homenet.   The
protocol that everyone uses for this is DNSSD.   This is how you find your
printer when you want to print to it.   Nobody uses the ad-hoc DynDNS
protocol for this.

What the DynDNS protocol does is to allow you to track the IP address of
your home gateway using a single A record in someone else's zone (e.g.,
dyndns.org).   It doesn't let you populate your own zone, and you can't do
service discovery on the resultant DNS entry, because service discovery is
a bit more complicated than that.

It's certainly true that we could use an HTTPS-based protocol for setting
up delegations for the forward mapping zone.   This makes a great deal of
sense, since the forward mapping zone shouldn't have to be tied to the
ISP.   The reverse mapping zone has to be delegated by the ISP, so we might
as well do it in a prefix delegation transaction.

So if you are advocating this second thing, that makes sense, and we should
definitely talk about whether it makes sense to do it this way.   If you
are talking about the first thing, then maintaining a zone in the homenet
is definitely a requirement.  Also, think of the privacy implications if
all of the services on the homenet had to be discovered from a shared zone
like dyndns.org.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 11:42:18 +0200

> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.

I am not speaking about discovery within the Homenet.  I am speaking about
exporting names into the global DNS, which is what Daniel's draft is about.

> It's certainly true that we could use an HTTPS-based protocol for setting up
> delegations for the forward mapping zone. This makes a great deal of sense,

Good.

> The reverse mapping zone has to be delegated by the ISP, so we might as
> well do it in a prefix delegation transaction.

I'm not following your reasoning here -- why does the zone being tied to
the ISP imply that we must use a more complex protocol?

> definitely talk about whether it makes sense to do it this way.

Let's.

> Also, think of the privacy implications if all of the services on the
> homenet had to be discovered from a shared zone like dyndns.org.

Quite the opposite.  In the trivial update protocol, the update is
end-to-end, encrypted, and only the host and the DNS provider see the
data.  Every Homenet, every host, heck, even every application can use
a different DNS provider, and each DNS provider only sees the data that
was explicitly sent to it.

In Daniel's protocol, the data goes from host to hidden primary to DNS
provider.  The hidden primary is probably controlled by the ISP, which is
convenient if you happen to be a privacy-violating ISP.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 08:48:33 -0400

> exporting names into the global DNS, which is what Daniel's draft is about.

Yes, but the problem is that you are treating this as if these are two
separate problems, but they are not.   If we need devices to know how to do
one thing, that's enough.   We shouldn't demand that they know how to do
two things that accomplish the same thing.   So if we need service
registration, we shouldn't also have a second method of publishing names,
because that's additional work for the device manufacturer.

> the ISP imply that we must use a more complex protocol?

Again, we are already doing DHCP PD to get the prefix from the ISP.   The
transaction is already happening.   Sending our ZSK to the root along with
the IP address of our public or hidden primary for the reverse zone isn't a
lot of additional work.   Doing this transaction over HTTP means another
service that the ISP has to operate, and another service that the HNR has
to connect to.   So it's not a simplication—it's a complexification, even
though the protocol itself is simple.

> was explicitly sent to it.

You've published a record in a public zone.   It doesn't matter that the
protocol you used to publish it is  privacy-protecting, because the
publication of the name immediately negated that.

> convenient if you happen to be a privacy-violating ISP.

The hidden primary would be on an HNR, so unless the HNR is controlled by
the ISP, the hidden primary isn't either.   In principle, at least, the
hidden primary should only be exposing names to the ISP that are intended
to be exposed.

The reason I was hassling  Daniel about implementations at the mic is that
I actually share your concern that what he's got written down right now is
more complicated than it needs to be, and this is partly because it was
originally motivated by his work at an ISP.   Now that he isn't doing that,
we have an opportunity to do a rethink about what is good and bad about the
proposal, and I think we should take advantage of this opportunity.

That said, DNS delegation and IXFR are well-understood technologies that
are well-suited to the purpose we have here, so I think we should be
careful when trying to simplify this to make sure that what is being
proposed actually has that effect!

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Jul 2018 14:28:19 +0100

(with no hats...)

> was explicitly sent to it.

I'm also a bit puzzled by how the subset of records to be
globally published relates to the set of records that are
to be internally visible. I guess this is not something
that we'd fully standardise, but there are privacy issues
here if too much gets published globally, so there may be
some protocol (change/tweak) required to make it possible
for implementers to distinguish which information ought be
globally visible, and which not.

Cheers,
S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 15:30:07 +0200

> separate problems, but they are not.

These are two completely different problems, with different default
behaviours and different failure modes.

The default behaviour for the local zone is that devices should be
discoverable.  The default behaviour for the public DNS is that a device
should not be published unless it takes explicit action.

It makes a lot of sense to have two different protocols, rather than
essentially leaking a local zone into the ISP's DNS servers.

> Doing this transaction over HTTP means another service that the ISP has
> to operate,

Not the ISP, a third-party DNS provider.  That's the whole point.

> and another service that the HNR has to connect to.

Not the HNR, the end host.  That's the whole point.

And it's literally four lines of shell:

    while true; do
        wget --post-data 'name=gameserver.myhome.net&password=topsecret' \
             https://dyndns.example.com
        sleep $((24 * 3600))
    done

>     data.

> publication of the name immediately negated that.

With delegation through an ISP-controlled hidden master, the ISP gets
a database of all the names published by all of its users.

With an encrypted connection to a DNS provider, the ISP needs to troll all
of the DNS providers in order to build such a database.

> I actually share your concern that what he's got written down right now
> is more complicated than it needs to be, and this is partly because it
> was originally motivated by his work at an ISP.

Uh-huh.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 09:31:15 -0400

One way to automate this would be using mud.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Jul 2018 23:58:03 +1000

> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek <[email-masked]> wrote:
> 

vs

while true; do
	(
		# delete all the existing AAAA records
		update delete host.example.com IN AAAA
		# add in all the GUA AAAA records
		ifconfig -a inet6 |
			sed -n -e '/%/d' -e '/ ::1 /d' -e '/ fd[0-9a-f][[0-9a-f]:/d’ \
	       		-e 's/inet6/update add host.example.com 3600 IN AAAA/‘ \
	       		-e 's/ prefixlen.*//p’
		# tell nsupdate to send the update request.  Nsupdate will work out zone and
		# DNS servers to send the update request too.
		echo send
	) | nsupdate -y Khost.example.net.+001+56524
	sleep $((24 * 3600))
done

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Jul 2018 23:59:55 +1000

> On 19 Jul 2018, at 11:58 pm, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

And I forgot to mention that this supports multiple AAAA records.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 16:28:59 +0200

> (omitted for brevity)

You're doing end-to-end dynamic update over DNS, which is fine with me.
The exact transport we end up using doesn't matter that much.

You're not doing the proxying through a hidden master mandated by Daniel's
draft, which is what I find complex and fragile.

-- Juliusz

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2018 18:01:28 +0300

>              https://dyndns.example.com

How does that get both IPv4 and IPv6 addresses published? Perhaps bit
more parameters are needed?

The reason people use those dyndns services is because they only use
IPv4, and they have NATs, and they want to publish the outer address
of the NAT. I would hope we are getting proper non-natted IPv6
networks with globally routable address at home too, so you do not
need to use such hacks.

On the other hand same thing using nsupdate (using TSIG and dynamic
dns) is one command line + input file for nsupdate:
----------------------------------------------------------------------
nsupdate -k $KEYFILE << EOF
server ns.example.com.
zone myhome.net.
update add gameserver.myhome.net. 3600 A $IP4
update add gameserver.myhhome.net. 3600 AAAA $IP6
send
EOF
----------------------------------------------------------------------
No need to sleep and do operations periodically, you only need to run
this when the IP-addresses change...
-- 
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 17:06:16 +0200

> dns) is one command line + input file for nsupdate:

Cool.

Whichever end-to-end (host to DNS provider with no intermediate proxying)
encrypted and authentified protocol you pick, I'm with you.

-- Juliusz

---

From: Jacques Latour <[email-masked]>
Date: Thu, 19 Jul 2018 20:23:22 +0000

The provisioning process for front end naming delegation we’re thinking of includes the provisioning of the domain name itself at the registry, and the setup on the home gateway itself and registration with an external secondary anycast for global name resolution. The gateway would have an internal and external view, where the external view would sync with the outsourced DNS service, could be using standard IXFR/AXFR methods.  We would sign both internal/external views with DNSSEC and publish a CDS that the registry can take to bootstrap the delegation. We need to add a Dyn like process to sync external dynamic addresses to the external zone file.

We’re not planning to use home.arpa because it will not have a secure chain of trust and if we have a domain name for external reachability (example.ca) then might as well use it internally.

As a side note, I don’t think we should even think of building a solution to make home.arpa a secure delegation, it’s a good domain name for internal use and avoid name collisions, not good for DNSSEC.

From: homenet <[email-masked]> On Behalf Of Ted Lemon
Sent: Thursday, July 19, 2018 9:31 AM
To: Stephen Farrell <[email-masked]>
Cc: Homenet <[email-masked]>; Daniel Migault <[email-masked]>; Juliusz Chroboczek <[email-masked]>
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

(with no hats...)

On 19/07/18 10:42, Juliusz Chroboczek wrote:

>> homenet had to be discovered from a shared zone like dyndns.org<http://dyndns.org>.

Cheers,
S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Jul 2018 22:38:01 +0200

> 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?)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 09:01:19 -0400

Apparently my comment was clear as mud.   I meant this:
https://tools.ietf.org/html/draft-ietf-opsawg-mud-25

Having a public/private zone pair where the public zone is an image of the
private zone that is constructed following rules, the default rule being
"don't copy," seems very straightforward to me.   It's not clear to me in
what sense it's brittle.   Requiring each device to be configurable with a
way to update a name server Out There, and managing the set of devices that
are publishing their names, seems not merely brittle but also difficult to
operate.   To me, the difference between what you are proposing, Juliusz,
and what Daniel is proposing, is where the control point is.   For you, the
control point is the device.   For Daniel, the control point is the
resolver.   Each of these has different properties in terms of
manageability.   Depending on how each is used, your model may be easier or
harder.

What I have set up in my home assumes the mud model, although that's not
actually implemented yet, and even the topology is a work in progress
because I haven't gone back and fixed everything yet.   The model is that
all of my IoT devices are on their own network, which is firewalled from
the rest of my network and has no external connectivity by default.   If a
device needs external access, it gets access to what mud says it needs
access to (e.g., it can download its firmware updates, but not log in to
facebook).   If it wants to be externally reachable, its mud description
would say so, and would say what would be allowed to reach in and touch it.

This model would work with non-IoT devices as well—if they don't have mud
descriptions, then by default they can reach out to touch anything, but
nothing is allowed to reach in to touch them, and their names are not
published.

What's good about this model is that things can happen completely
automatically.   The end user is not asked to understand security models,
and need take no action other than enrolling devices on the network, which
I think is unavoidable.   The only problem with this is that there's no way
to automatically corral IoT devices to the IoT network.

That said, what I've described here is out of scope for the current
discussion, other than with respect to naming.

---

From: Elson Oliveira <[email-masked]>
Date: Mon, 23 Jul 2018 15:03:05 +0000

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 <[email-masked]> On Behalf Of Juliusz Chroboczek
Sent: Thursday, July 19, 2018 4:38 PM
To: Ted Lemon <[email-masked]>
Cc: Homenet <[email-masked]>
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.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 23 Jul 2018 20:38:00 +0200

> 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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 23 Jul 2018 20:50:50 +0200

Juliusz Chroboczek <[email-masked]> writes:

> 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.

Why? What is wrong with the owner of the network selecting which devices
/ services he/she wants globally reachable without each device/service
having to implement (and be configured for) an external naming provider?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 23 Jul 2018 20:58:18 +0200

> https://tools.ietf.org/html/draft-ietf-opsawg-mud-25

Quote, "YANG-based JSON that describes a Thing", unquote.  61 pages.
Revision 25, and still a draft.  I wish you a lot of fun implementing that.

> Having a public/private zone pair where the public zone is an image of
> the private zone that is constructed following rules, the default rule
> being "don't copy," seems very straightforward to me. It's not clear to
> me in what sense it's brittle.

It's brittle because you have state in the network.  (You know, end-to-end
argument and so on.)

More concretely:

  - what happens when the current hidden master loses an election?  Is the
    state magically transferred?
  - what happens when the current hidden master crashes/is unplugged/is retired?

... let alone the issue of electing the hidden master in the first place,
which I believe Daniel hasn't addressed at all.

> To me, the difference between what you are proposing, Juliusz, and what
> Daniel is proposing, is where the control point is. For you, the control
> point is the device.

That's right.

> For Daniel, the control point is the resolver.

Which resolver?  (I could be wrong, but I don't think that the Homenet
architecture has a central resolver.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 23 Jul 2018 21:09:01 +0200

> / services he/she wants globally reachable

I don't think this is about global reachability (which is hopefully managed
by PCP), it's about exporting names into the global DNS.  We ought to
distinguish the two -- you can be remotely reachable without publishing
your name in the DNS.

> without each device/service having to implement (and be configured for)
> an external naming provider?

Roughly 100% of Homenet devices don't need a name in the global DNS --
neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything else
that normal people run in their home relies on the DNS for locating remote
peers.

In the rare case where a device needs to be in the global DNS (and the
only case I can see is that of a web server), I'd much rather configure
that on the device itself than on the buggy web interface of my
ISP-provided CPE (or, even worse, "in the cloud").

-- Juliusz

---

From: Gert Doering <[email-masked]>
Date: Mon, 23 Jul 2018 21:12:10 +0200

Hi,

> having to implement (and be configured for) an external naming provider?

This is homenet.  There is nobody here who manages the network.

Which seems to be the main difference in views here - "I have a middlebox
where I can do configuration" vs. "the network is not managed, if I want
something to happen, I do it on the host".

Looking at my parents' setup, things like "teamviewer" work because they
do not need configuration on their router.  It has its own namespace,
registers the host, and it can be found  (due to IPv4 NAT, it needs to
also use a rendezvous server, but that might hopefully go away one day).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 23 Jul 2018 21:28:24 +0200

Juliusz Chroboczek <[email-masked]> writes:

> I don't think this is about global reachability (which is hopefully
> managed by PCP), it's about exporting names into the global DNS. We
> ought to distinguish the two -- you can be remotely reachable without
> publishing your name in the DNS.

Fair enough.

> neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything
> else that normal people run in their home relies on the DNS for
> locating remote peers.

Well, those all work because they use a "giant MITM in the cloud"
rendezvous point. If publishing things into global DNS worked reliably
and automatically, and we had IPv6 everywhere, such designs would not be
needed...

> only case I can see is that of a web server), I'd much rather
> configure that on the device itself than on the buggy web interface of
> my ISP-provided CPE (or, even worse, "in the cloud").

Right, I can certainly see where you're coming from with this :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 23 Jul 2018 22:08:58 +0200

> If publishing things into global DNS worked reliably and automatically,
> and we had IPv6 everywhere, such designs would not be needed...

That's arguable, but we can probably agree that Daniel's draft does not
provide a useful service for these applications.  For example, if I'm
using Skype, I want to be globally findable even if I'm at an IETF meeting
in Bangkok -- whereas Daniel's draft only allows me to publish my address
if I'm in my Homenet.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 16:30:40 -0400

On Mon, Jul 23, 2018 at 4:08 PM, Juliusz Chroboczek <[email-masked]> wrote:

>  whereas Daniel's draft only allows me to publish my address
> if I'm in my Homenet.
>

One of the reasons I was hassling Daniel at the mic about updating his
draft based on implementation experience is that I think it's hard to read
the document and get a clear sense of what is being described.

That said, what is being described is a building block, not a system.   The
hidden primary is a building block.   You mention in another message that a
stateful primary is brittle, because there is no permanent authority on a
homenet.   You are actually agreeing with Daniel: the reason to have the
state somewhere other than the homenet is that it can be managed by someone
who maintains it; then if the homenet loses its memory, it can simply
refresh it from the cloud.

How to update your DNS when you aren't on the homenet is a separate issue.
 One way to do it would be to always be connected to the homenet over a
VPN; another would be for the homenet to have a global name and just do it
the usual way; this global name could be set up in much the same way that
you are proposing to set up individual hostnames: not a delegation from a
TLD, but a delegation from a service provider.

That said, the use case for what you are describing is a bit beyond the
pale for a typical end user.   They just want to be able to reach their
printer or their home automation system.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 24 Jul 2018 00:10:11 +0200

> if the homenet loses its memory, it can simply refresh it from the cloud.

What?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 18:36:22 -0400

> What?

You're concerned with the homenet losing state when the master is unplugged.   By having the master in the cloud, this problem is eliminated.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Jul 2018 17:27:41 -0700

On 07/23/2018 03:36 PM, Ted Lemon wrote:
> On Jul 23, 2018, at 6:10 PM, Juliusz Chroboczek <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> What?
>
> You're concerned with the homenet losing state when the master is 
> unplugged.   By having the master in the cloud, this problem is 
> eliminated.

I can't speak for Juliusz, but my first question was "what if i don't 
want it in the cloud"? For one thing, what if it's a cloudless day?

Mike

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 24 Jul 2018 00:45:13 +0000

> I can't speak for Juliusz, but my first question was "what if i don't want it in the cloud"? For one thing, what if it's a cloudless day?

I was starting to accept the idea that selecting a subset of my devices to exist in global DNS. But absolutely, positively, not all. Any design I could buy into will *not* push all my DNS into the cloud.
Barbara

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Jul 2018 18:02:18 -0700

> I was starting to accept the idea that selecting a subset of my devices to exist in global DNS. But absolutely, positively, not all. Any design I could buy into will *not* push all my DNS into the…

As usual i'm probably behind, but I kind of thought this was more about 
provisioning/configs. The way I've thought
about this is that where I decide is the ultimate repository for truth 
for my configs is really a deeply personal
decision. The easy case is when i delegate it to "the cloud" since it 
then becomes somebody else's $DAYJOB to
figure out how to back it up, etc. But if I want to keep things local -- 
for whatever reason, including tin foil hats --
i'd really like my homenet to have the property that i can take one 
router and throw it in the trash, and plug in
another, and with minimal fuss it takes over for the old one.

For naming, that implies that i want to distribute the naming database 
such that there isn't a single point of failure.
While this isn't exactly new territory, it is in the context of my home 
networking. Better would be to use already
standardized mechanisms so that everybody's sanity is preserved, if only 
a little bit.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 22:43:20 -0400

The DNS server in the cloud doesn't have to answer queries.   Indeed, it
probably shouldn't.   It's really just a backing store.   The
public/private primary with selective publication is just a functional
block—you can put it where it makes the most sense.   Juliusz is saying
that he wants a nearly stateless homenet; for him, putting the
public/primary functional block in the cloud makes sense because it keeps
his homenet stateless.   I would not want that configuration because it
exposes the internals of my network to the cloud provider (unless it's also
encrypted, but then you have a keying problem).

On Mon, Jul 23, 2018 at 9:02 PM, Michael Thomas <[email-masked]> wrote:

>>>> unplugged.   By having the master in the cloud, this problem is eliminated.
>>>>
>> I was starting to accept the idea that selecting a subset of my devices
>> to exist in global DNS. But absolutely, positively, not all. Any design I
>> could buy into will *not* push all my DNS into the cloud.
>>
>
> about this is that where I decide is the ultimate repository for truth for
> my configs is really a deeply personal
> decision. The easy case is when i delegate it to "the cloud" since it then
> becomes somebody else's $DAYJOB to
> i'd really like my homenet to have the property that i can take one router
> and throw it in the trash, and plug in
> standardized mechanisms so that everybody's sanity is preserved, if only a
> little bit.
>
> Mike
>
>

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Jul 2018 00:31:25 -0400

Instead of calling it a "DNS Server" perhaps call it the "declarative data
store"?  it could be a git repo,

tim

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2018 00:58:13 -0400

Sure, it *could*, but it's probably easier to implement it as a
split-horizon DNS server that only talks to the homenet.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 24 Jul 2018 10:34:15 +0200

> Juliusz is saying that he wants a nearly stateless homenet;

No, I'm not.

> for him, putting the public/primary functional block in the cloud makes
> sense

No, it doesn't.

Ted, please don't put words into my mouth.  It's unpleasant, and it's
disrespectful.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2018 09:38:56 -0400

You said that having state in the homenet makes it brittle.   That implies
that you think a stateless homenet will be less brittle, no?