[DNSOP] front-end naming document: Synchronization Server

Michael Richardson <mcr@sandelman.ca> Mon, 13 May 2019 16:35 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7E120228; Mon, 13 May 2019 09:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FzLRdqOX6Bpl; Mon, 13 May 2019 09:35:23 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83EB12013D; Mon, 13 May 2019 09:35:22 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2607:fea8:bdc0:1518::5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 640B21F455; Mon, 13 May 2019 16:35:21 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id DF44A1D47; Mon, 13 May 2019 12:35:21 -0400 (EDT)
To: dnsop@ietf.org, homenet@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
From: Michael Richardson <mcr@sandelman.ca>
Date: Mon, 13 May 2019 12:35:21 -0400
Message-ID: <7839.1557765321@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-yx0gLhe2DSTnRTvcMjXC_XDnXY>
Subject: [DNSOP] front-end naming document: Synchronization Server
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 16:35:30 -0000

Last week Daniel and I resurrected

The -08 version was posted, it should have minimal changes for the expired
-07 version, except that this version is done in Markdown/github, etc.
Issues tracked are at:
(please ignore similar named repo which was duplicated)

The -09 version will include significant changes, and we posted -08 to be
sure that all changes were intentional.  I include the abstract below for the
benefit of people who are BCC'ed.

The essential architecture is a stealth primary running in the homenet
(likely in one of the CPEs), using a zone-transfer to "cloud" hosted primary
server (A), and likely from there to a typical set of authortiative servers.
These might be anycast'ed or not, depending upon who is running the service.

The question I have for this email is whether or not there is a common
name for the primary server (A), which collects the zones from the stealth
primary server.  That server is often not publically listed.  In the document,
it was called the "Synchronization Server", but I don't think that is a good
name.  In my previous experience doing this kind of thing the server A
was called the Distribution Server.

While I like that term better, I don't know how common it is for other DNS
providers.  So what term do you know of?

Has the architecture of having a stealth primary feeding a distribution
server, which then transfers to some set of public facing servers been
formally described in an IETF document?  If not, in some OARC document?


   Designation of services and devices of a home network is not user
   friendly, and mechanisms should enable a user to designate services
   and devices inside a home network using names.

   In order to enable internal communications while the home network
   experiments Internet connectivity shortage, the naming service should
   be hosted on a device inside the home network.  On the other hand,
   home networks devices have not been designed to handle heavy loads.
   As a result, hosting the naming service on such home network device,
   visible on the Internet exposes this device to resource exhaustion
   and other attacks, which could make the home network unreachable, and
   most probably would also affect the internal communications of the
   home network.

   As result, home networks may prefer not serving the naming service
   for the Internet, but instead prefer outsourcing it to a third party.
   This document describes a mechanisms that enables the Home Network
   Authority (HNA) to outsource the naming service to the Outsourcing

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-