[DNSOP] front-end naming document: Synchronization Server
Michael Richardson <mcr+ietf@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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAA8120133; Mon, 13 May 2019 09:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xHtQCTf354Y; Mon, 13 May 2019 09:35:00 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F75120072; Mon, 13 May 2019 09:34:59 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2607:fea8:bdc0:1518::5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 3B86F1F455; Mon, 13 May 2019 16:34:57 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 957491D47; Mon, 13 May 2019 12:34:56 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
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"
Date: Mon, 13 May 2019 12:34:56 -0400
Message-ID: <7728.1557765296@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AYNq_i6EIiGU9zgSwB4ZYGUZiGE>
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:04 -0000
Last week Daniel and I resurrected https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ 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: https://github.com/ietf-homenet-wg/ietf-homenet-hna (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? Abstract 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 Infrastructure. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [DNSOP] front-end naming document: Synchronizatio… Michael Richardson