[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt
Philip Homburg <pch-dnsop-5@u-1.phicoh.com> Thu, 18 July 2024 13:42 UTC
Return-Path: <pch-b538D2F77@u-1.phicoh.com>
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 E8363C169438 for <dnsop@ietfa.amsl.com>; Thu, 18 Jul 2024 06:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14bKE1HaPckV for <dnsop@ietfa.amsl.com>; Thu, 18 Jul 2024 06:42:32 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33652C15109F for <dnsop@ietf.org>; Thu, 18 Jul 2024 06:42:25 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1sUROo-0000MXC; Thu, 18 Jul 2024 15:42:22 +0200
Message-Id: <m1sUROo-0000MXC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-5@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <172047613820.448901.257008321714722865@dt-datatracker-5f88556585-j5r2h> <ABA9F522-FCF4-40CB-817D-B230E09BB23F@verisign.com> <m1sTdpf-0000LYC@stereo.hq.phicoh.net> <FD3C1248-2EC5-4599-8278-066255DEC16B@verisign.com>
In-reply-to: Your message of "Wed, 17 Jul 2024 17:54:36 +0000 ." <FD3C1248-2EC5-4599-8278-066255DEC16B@verisign.com>
Date: Thu, 18 Jul 2024 15:42:21 +0200
Message-ID-Hash: 5YBYYT5WQYWCTKGVRJEKTY7OI7JIFGGL
X-Message-ID-Hash: 5YBYYT5WQYWCTKGVRJEKTY7OI7JIFGGL
X-MailFrom: pch-b538D2F77@u-1.phicoh.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Wessels, Duane" <dwessels@verisign.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cf8JTfRSVm2FVlL_7scLv3Q-eGg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
> > If a DNS zone has no meaningful SOA Serial number then the > > SOA-SERIAL ZONEVERSION option SHOULD NOT be returned in a reply. > > Im not sure about this. Since every zone will have a SOA record, > and every SOA record will have a serial value, I suppose the question > becomes whether or not a serial number is meaningful. I dont know > how a name server would determine meaningfulness. > > What would be the harm in returning a SOA-SERIAL zone version if > it were not supposedly meaningful? A user/client can see the value > by querying SOA directly. In my experience, putting garbage in a data field is likely to lead to problems later. Some implementations just don't have a sensible version number. With In the context of zone transfers, you need at least two poperties: if anything changes in the zone, then the zone's version also changes. Second, a sequence of version numbers viewed over a period of time, days or weeks, is increasing in serial arithmatic. Some implementations of authoritative servers just don't have that. However, if there is consensus that returning such version numbers in ZONEVERSION is fine, then I don't want to spoil the fun. Just making sure the issue was not overlooked. > > The second addition: > > > > The ZONEVERSION option as defined in this draft SHOULD NOT be used by > > recursive resolvers, client-side forwarders, etc. to decide when to flush > > a cache or otherwise how long to cache data. > > Im okay with something like this, but can you provide any more text > about why they should not use zone version data in caching decisions? A new version of a zone should have no impact on how long data is cached. The TTL value of resource record is meant for that. It might be tempting to also include the version number of the zone in the decision when to declare data as stale, however some zones may see very frequent updates and this may reduce the life time of some resource records in the cache below what is reasonable.
- [DNSOP] Fwd: New Version Notification for draft-i… Wessels, Duane
- [DNSOP] Re: Fwd: New Version Notification for dra… Philip Homburg
- [DNSOP] Re: Fwd: New Version Notification for dra… Wessels, Duane
- [DNSOP] Re: Fwd: New Version Notification for dra… Dave Lawrence
- [DNSOP] Re: Fwd: New Version Notification for dra… Joe Abley
- [DNSOP] Re: Fwd: New Version Notification for dra… Philip Homburg
- [DNSOP] Re: Fwd: New Version Notification for dra… Petr Špaček
- [DNSOP] Re: Fwd: New Version Notification for dra… Shane Kerr
- [DNSOP] Re: Fwd: New Version Notification for dra… Petr Špaček
- [DNSOP] Re: Fwd: New Version Notification for dra… Wessels, Duane
- [DNSOP] Re: Fwd: New Version Notification for dra… Petr Špaček