Re: [DNSOP] Terminology: "primary master"

Tony Finch <dot@dotat.at> Mon, 27 November 2017 17:15 UTC

Return-Path: <dot@dotat.at>
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 B259C128B4E for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 09:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 vpeftiX1pGOH for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 09:15:30 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B1512895E for <dnsop@ietf.org>; Mon, 27 Nov 2017 09:15:30 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47446) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJN01-000VvK-0n (Exim 4.89) (return-path <dot@dotat.at>); Mon, 27 Nov 2017 17:15:28 +0000
Date: Mon, 27 Nov 2017 17:15:17 +0000
From: Tony Finch <dot@dotat.at>
To: Joe Abley <jabley@hopcount.ca>
cc: "dnsop@ietf.org" <dnsop@ietf.org>, Havard Eidnes <he@uninett.no>
In-Reply-To: <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca>
Message-ID: <alpine.DEB.2.11.1711271640260.4416@grey.csi.cam.ac.uk>
References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <alpine.DEB.2.11.1711231740240.4416@grey.csi.cam.ac.uk> <5562271920774233970@unknownmsgid> <alpine.DEB.2.11.1711271315380.32058@grey.csi.cam.ac.uk> <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uhpDqqbkhrFcFK6p1oP8Q-_8c4A>
Subject: Re: [DNSOP] Terminology: "primary master"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Nov 2017 17:15:38 -0000

Joe Abley <jabley@hopcount.ca> wrote:

> > A primary master is wrt a zone not a server - a zone's primary master is
> > a server that's authoritative for a zone and which does not get the zone
> > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or
> > a non-standard mechanism such as directly from a database).
>
> That's an alluringly clear definition, but I'm not sure it matches
> common understanding of the term, which I think has more to do with
> "single source of truth" than with the specifics of what transport is
> used to provision zone data in a server.

Hmm, I think I sort-of agree, but with caveats...

I prefer to make a clear distinction between the standard DNS as specified
in the RFCs versus any funky non-standard stuff that people might do with
the DNS.

The standard DNS protocols are closely fitted to a particular distributed
architecture, in which a zone has a single source of truth that we call
the primary master. You can, of course, implement a similar architecture
using non-standard protocols, but if you do you should take care to make
it clear how you are diverging from the standard - and be careful about
how you use standard DNS terminology when talking about your non-standard
system.

> For example,
>
>     W <------- A -------> X
>
> Suppose A is a source of truth for a particular zone, and that W and X
> obtain zone data from A. Are you saying that if the mechanism
> represented by the arrows is [AI]XFR then A is a primary master and W
> and X are not, whereas if that mechanism is something else (perhaps it's
> rsync, with W, A and X all configured to be masters from local zone
> files) then W, A and X are all primary masters?

In this case I would say A is a primary master and W and X are secondaries
that use rsync instead of standard zone transfers.

The part of the standard architecture that you have replaced is the zone
transfer mechanism, so the primary master is architecturally unaffected,
so it's OK to use the same name.

(But you can't call rsync "ixfr" even though it is incrementally
transferring zones, because that would be unreasonably confusing.)

> If A is not a nameserver but instead is a database, and the arrows
> represent database replication, then W and X are primary masters but A
> is not?

In this case I would be very proud of my high-availability multi-master
system.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7,
occasionally gale 8 except in Shannon. Rough or very rough, occasionally
moderate. Squally showers. Good.