Re: [DNSOP] Question regarding RFC 8499

Robert Edmonds <edmonds@mycre.ws> Thu, 23 July 2020 18:23 UTC

Return-Path: <edmonds@mycre.ws>
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 82D3C3A0C66 for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 11:23:08 -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 I7b4wOJ9jM3M for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 11:23:07 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B503A0C64 for <dnsop@ietf.org>; Thu, 23 Jul 2020 11:23:07 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 7C5E212CB10A; Thu, 23 Jul 2020 14:23:06 -0400 (EDT)
Date: Thu, 23 Jul 2020 14:23:06 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop WG <dnsop@ietf.org>
Message-ID: <20200723182306.GA375927@mycre.ws>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <20200723172449.GA371024@mycre.ws> <1C6ACEA9-CCC5-41F5-AEAD-432B48370D12@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1C6ACEA9-CCC5-41F5-AEAD-432B48370D12@hopcount.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kjKNPlgBSXtrqE9W06_n4vRMSDk>
Subject: Re: [DNSOP] Question regarding RFC 8499
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: Thu, 23 Jul 2020 18:23:09 -0000

Joe Abley wrote:
> STD 13 assumes a model where there is a single authoritative nameserver which acts as a source of truth for zone data ("primary"), from which other nameservers retrieve data and also make it available ("secondary"). As such they describe the whole of a simple directed graph of zone transfers.
> 
> In my experience, in common usage today, master and slave describe functions along a single edge of such a graph. A single piece of software might act as a master server on one edge, and a slave on another. As such those terms can be used to describe more complicated graphs than the particular topology imagined in STD 13.

It's not the case that you can only build simple directed graph XFR
topologies using the STD 13 model. RFC 1034 describes an "intermediate
secondary" which seems to be exactly what you described, a server that
performs both XFR-in and XFR-out.

    Each secondary server is required to perform the following operations
    against the master, but may also optionally perform these operations
    against other secondary servers.  This strategy can improve the transfer
    process when the primary is unavailable due to host downtime or network
    problems, or when a secondary server has better network access to an
    "intermediate" secondary than to the primary.

-- 
Robert Edmonds