Re: [homenet] securing zone transfer

[Michael Richardson <[e-mail]>]

Juliusz Chroboczek <[e-mail]> wrote:
    >> The front end naming architecture uses a primary and a secondary dns server to
    >> synchronize a zone.

    > People will recall that the need for a hidden primary hasn't been
    > established yet.  Please see my unanswered e-mail of 21 November 2018.

    > https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

We strongly believe that the HNA needs to know the list of names in order to
be able to answer for those names when there is unstable (or no) Internet connectivity.

Otherwise, applications and people have to know two different names for the
service. (A public one for when away, and the .local one)

In our current draft we have:

2.1.  Alternative solutions

   An alternative to having a single zone is what is currently common
   with IPv4, where a host uses a RESTful HTTP service to register a
   single name into a common public zone.  This is often called "Dynamic
   DNS", and there are a number of commercial providers, including
   dyn.com, ghandi.com.  These solutions were typically used by a host
   behind the CPE to make it's CPE IPv4 address visible, usually in
   order to enable incoming connections.

   For a small number (one to three) of hosts, use of such a system
   provides an alternative to the architecture described in this
   document.  The alternative does suffer from some limitations:

   o  the CPE/HNA router is unaware of the process, and can not answer
      for the same names when there are disruptions in connectivity.
      This makes the home user using different names when there are
      disruptions.

   o  the CPE/HNA router can not control the process.  Any host can do
      this regardless of whether or not the home network administrator
      wants the name published or not.  There is therefore no possible
      audit trail.

   o  the credentials for the dynamic DNS server need to be securely
      transferred to the hosts that wish to use it.  This is not a
      problem for a technical user to do with one or two hosts, but it
      does not scale to multiple hosts and becomes a problem for non-
      technical users.

   o  "all the good names are taken" - current services put everyone's
      names into a some set of zones, and there are often conflicts.
      Distinguishing similar names by delegation of zones was among the
      primary design goals of the DNS system.

   There is no technical reason why a RESTful cloud service could not
   provide solutions to many of these problems, but this document
   describes a DNS based solution.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-