[DNSOP] Re: Last Call: <draft-ietf-dnsop-zoneversion-09.txt> (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC
Joe Abley <jabley@strandkip.nl> Thu, 04 July 2024 08:00 UTC
Return-Path: <jabley@strandkip.nl>
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 E0DEDC157937 for <dnsop@ietfa.amsl.com>; Thu, 4 Jul 2024 01:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
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 bWCE7VYmDMdO for <dnsop@ietfa.amsl.com>; Thu, 4 Jul 2024 01:00:42 -0700 (PDT)
Received: from st43p00im-zteg10073501.me.com (st43p00im-zteg10073501.me.com [17.58.63.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0529BC16943A for <dnsop@ietf.org>; Thu, 4 Jul 2024 01:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; t=1720080041; bh=N7zpfGEOljiRuvSw+eu/7HSyxrf5GGYaZqK6NvNB2oA=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To; b=EO0WOhbEk3YHGwPl5o/R/dfoqb8enru1RAaqBZYWktg96zJeDFaGHTvCG4jAsKQxf fiq53l1ukeuq1ylOtxq+nHFkH/6N6bqFE9lA+0shiwGa5V7xOjbdkXQCx34RfuPaDh OjSPYi5W+mfPEvH1vXOaZAzu643dFFpjjQuVyP+HbTFdt+YG3Fa8JHvb7x5nAMbx/H AYgin0NyV2qTMAD5lqmWmlSdll/giigpiP+U9ug6qjWzrZlKBZ674MS53ayharjMAk 1muGh/nlE2EhBUx7MK5buivJZ6mlVhM0CB7vmG0emO2aNaj3oArc8iRepEPOqsphza jFPfIQM79l9Bg==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com [17.42.251.41]) by st43p00im-zteg10073501.me.com (Postfix) with ESMTPSA id EE536A00471; Thu, 4 Jul 2024 08:00:38 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@strandkip.nl>
Mime-Version: 1.0 (1.0)
Date: Thu, 04 Jul 2024 09:00:25 +0100
Message-Id: <A5099CBA-AE2C-4857-A642-3730EA544320@strandkip.nl>
References: <8e769ae8-cb99-425c-adfe-4440f67e6a10@isc.org>
In-Reply-To: <8e769ae8-cb99-425c-adfe-4440f67e6a10@isc.org>
To: Petr Špaček <pspacek@isc.org>
X-Mailer: iPhone Mail (21F90)
X-Proofpoint-GUID: BXPpbBv2FAQq6ZOU9gzQQNdI30HE74AM
X-Proofpoint-ORIG-GUID: BXPpbBv2FAQq6ZOU9gzQQNdI30HE74AM
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-03_18,2024-07-03_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1030 mlxlogscore=967 mlxscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2407040055
Message-ID-Hash: 5EOWMQFPRKMM234SHHZPVEOAQLTYHJZ4
X-Message-ID-Hash: 5EOWMQFPRKMM234SHHZPVEOAQLTYHJZ4
X-MailFrom: jabley@strandkip.nl
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: dnsop@ietf.org, draft-ietf-dnsop-zoneversion@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Last Call: <draft-ietf-dnsop-zoneversion-09.txt> (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gUC1vS95BJvj8Kjx0SAKIn48l34>
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>
On 4 Jul 2024, at 08:38, Petr Špaček <pspacek@isc.org> wrote: > when re-reading this document I've realized one limitation which is not explicitly mentioned: > > --- > 3.2. Responders > > ... A name server MAY also include more than one ZONEVERSION option in the response if it is authoritative for more than one zone of the corresponding QNAME. A name server MUST NOT include more than one ZONEVERSION option for a given TYPE and LABELCOUNT. > --- > > The current option cannot be used to represent version info for answer like this: > > QNAME: > qname.zone1.test. A > > Answer: > qname.zone1.test. CNAME target.zone2.test. > target.zone2.test. A 192.0.2.1 > > When the responder is authoritative for both zones - zone1.test. and zone2.test. - then there's no way to represent ZONEVERSION for zone2.test. I think this is a consequence of the loose language you quoted "more than one zone of the corresponding QNAME". I think this language should be made clearer. I think it is vague, as written. I think the intention is that if the server is authoritative for zone1.example and zone2.zone1.example then a query for label.zone2.zone1.example could return ZONEVERSION data for both zone1.example and zone2.zone1.example using LABELCOUNT == 2 and 3, respectively. I don't think there was any intention that your example would result in ZONEVERSION data for zone2.test being returned. I agree it might be nice if there was a way to do that, but I haven't thought hard enough to have an opinion beyond "nice". I suppose one way to handle this would be to use an offset pointer for the zone name, à la label compression, rather than using LABELCOUNT. Then you could report a ZONEVERSION for any terminated list of labels present in the message, regardless of whether it is present in the QNAME. Maybe that would be hard to implement, though. Anyway, assuming my interpretation of that phrase above is accurate and there's no appetite to change the encoding, I don't know that there's a way of of phrasing the intent in a small handful of words. I think multiple sentences and probably an example will be required. Joe
- [DNSOP] Last Call: <draft-ietf-dnsop-zoneversion-… The IESG
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Petr Špaček
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Petr Špaček
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Peter Thomassen
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Joe Abley
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Petr Špaček
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Joe Abley
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Peter Thomassen
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… John Levine
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Wessels, Duane
- [DNSOP] Re: Last Call: <draft-ietf-dnsop-zonevers… Wessels, Duane