Subject: [homenet] Discussion on draft-ietf-homenet-simple-naming-03

From: RayH <[email-masked]>
Date: Fri, 26 Jul 2019 15:42:13 +0300

Hi, I've re-read this draft and have some questions and comments.

The draft seems to assume a typical primary secondary DNS set up configured using HNCP.

I checked but couldn't see explicit details of the election process for determining which node would become master for the base zone e.g. home.arpa.

I did see the round robin query specification to gather the maximum amount of information, and how dnssd clients find and update the master.

Is the master for the base zone elected in the same way as the zones per link?

I also have some questions about transitory status and synchronisation.

The assumption seems to be that state can be preserved in a distributed system where nodes leave and join the network.

My concern is not about recovering a network partitioned for hours or days, because there's not much we can do about that, but more avoiding short term race conditions of seconds or minutes.

Example 1: HNCP uses trickle. During boot up, and power cycling, many nodes may arrive and depart at unpredictable times. The state of each node also takes time to propagate across the homenet on a hop by hop basis.

How does a node know HNCP has reached network-wide convergence before starting serving as the master?

Wait for local trickle timers to reach a certain threshold? Wait for a fixed period? We don't care?

Otherwise it's likely we'll end up temporarily at least with two active masters and/or hot secondaries.

Example 2: new high priority node arrives in the network out of the shrink wrap or after a hard reset and thus has a blank zone.

Does the blank zone become authorative: wiping all existing state?

[standard DNS replication assumes copying from master to slave, not stitching together information from alternative sources]

"Nodes without recent state information should reduce their announced priority so they aren't chosen as master over nodes with existing state information"?

"On learning new servers for the base domain via HNCP, a node SHOULD query that server to try to glean additional state information. Non-conflicting information MAY be added to local state"?

Or do we punt and give the hint that "state retention in Homenet is imperfect, and all nodes SHOULD regularly resolve and re-publish, update, or delete their own rr's as necessary"?

Regards,

RayH