Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt

Havard Eidnes <he@uninett.no> Fri, 19 February 2021 17:46 UTC

Return-Path: <he@uninett.no>
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 3190D3A142D for <dnsop@ietfa.amsl.com>; Fri, 19 Feb 2021 09:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uninett.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 eyjxg8o9yFZA for <dnsop@ietfa.amsl.com>; Fri, 19 Feb 2021 09:46:52 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3603A1983 for <dnsop@ietf.org>; Fri, 19 Feb 2021 09:45:04 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 287FF43F3E5; Fri, 19 Feb 2021 18:45:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1613756701; bh=Y5V1OErZ9iC6VMBd60Ximftq9u0l7NWL/W+GM/iyR0A=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=GSJqNCvEgSkAv5bzoBIOtkTQGzfyvlH0oLEBtjhK/DAK4lXhgqO9vCRHLt2eSqdEt 3BPfm7cHBu+CRrnfVFS+crbGpuOAJSSEJrJjms7uLx0AlfIrEDUhwei3zPptKzYRn/ KQekwoKTgBVrAjphaJ0D6TAGBL2aUUfyCCRo42qI=
Date: Fri, 19 Feb 2021 18:45:01 +0100
Message-Id: <20210219.184501.817904560961969387.he@uninett.no>
To: willem@nlnetlabs.nl
Cc: dnsop@ietf.org
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <eb84cf94-e3f2-fef0-8bb0-8bab093177db@nlnetlabs.nl>
References: <160712121645.11485.9271273951179383921@ietfa.amsl.com> <eb84cf94-e3f2-fef0-8bb0-8bab093177db@nlnetlabs.nl>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1SekTMT44eSwsw1Pqf3Z9lnikFQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt
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: Fri, 19 Feb 2021 17:46:55 -0000

> During the last hackathon at IETF-109, a new idea emerged where the
> version of a member zone in a catalog (indicated by the member zone's
> SOA serial number) is also in the catalog. This can help ensuring
> dissemination of member zones in a catalog from the primary to the
> secondary nameservers will happen in a timely fashion more reliably, and
> can also alleviate the burden on primary nameservers in cases where
> there are a large number of secondary nameservers serving a large number
> of zones.
>
> This is presented in the new section 5: "The Serial Property"

Hm, not sure I like that part of this.

I'm a fairly strong adherent of the KISS principle, and I have
problems with seeing that this solves a new and significant
problem.

The argument for having that at all seems to be somewhat weak to
justify the additional complexity:

   The current default mechanism for prompting notifications of zone
   changes from a primary nameserver to the secondaries via DNS NOTIFY
   [RFC1996], can be unreliable due to packet loss, or secondary
   nameservers temporarily not being reachable.

One, if you have significant packet loss to or from a given
secondary name server, it can be argued that you have chosen your
secondary unwisely, and that the right fix is to resolve the
packet loss issue and not to needlessly "complexify" the DNS
protocol to compensate for what's ultimately an unwise move.

Two, if a secondary name server is temporabily not reachable,
well...  The reason for that might be different.  If the name
server was restarted or the host rebooted, it's not unreasonable
to expect the name server to query for the SOAs for the zones it
acts as secondary name server for on startup.  If the reason is a
temporary loss of connectivity / network service, well -- is that
a sufficiently frequent issue to deal with in this manner?

I do realize that collecting all the SOA serials of the member
zones in the catalog zone will cause the update frequency for the
catalog zone to be, essentially, the "multiplication" of the
update frequency for all the member zones.  It is not entirely
obvious that this will be a net win in terms of the work
required for the primary name server(?)

That said, the "serial" property appears to be intended to be
optional, which is ~OK.

However, "burning" a new RR just for this purpose seems to me to
not be necessary, so I favour the scheme in 5.6 using a TXT
record instead.

Regards,

- Håvard