[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)

Paul Wouters via Datatracker <noreply@ietf.org> Mon, 17 June 2024 23:23 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDE3C1D530B; Mon, 17 Jun 2024 16:23:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171866661003.804.6572056160990742967@ietfa.amsl.com>
Date: Mon, 17 Jun 2024 16:23:30 -0700
Message-ID-Hash: TWVUNQSM33OC5M7YKHIXDBCDSPK4O25T
X-Message-ID-Hash: TWVUNQSM33OC5M7YKHIXDBCDSPK4O25T
X-MailFrom: noreply@ietf.org
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: draft-ietf-dnsop-zoneversion@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com
X-Mailman-Version: 3.3.9rc4
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Subject: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BgvKbzSSOk3AyT3gSGxX1ONYJ7w>
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>

Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Just a few hopefully minor issues to talk about.

In section 3.2, why is NXDOMAIN not listed? When asking for "foobar.nohats.ca",
couldn't it be useful to get the zone version, if the nameserver is
authoritative for "nohats.ca" and has no delegation for "foobar.nohats.ca." ?

What should an authoritative nameserver return as zone version if it is
configured as authoritative nameserver but can't get the zone version (eg
because "no permission to read file")  One way would be to allow it to return
a zero length for ANY type and define that as an error condition.

It seems DNAMEs could lead to involving two or more zones the nameserver is
authoritative for. How should this be handled? Only use the first DNAME's
zone's version?

The type leaves no room for proprietary (or somehow encrypted) zone versions,
as the DE advise states:

        In particular the reference should state clear instructions for
        implementers about the syntax and semantic of the data

If you did not mean to exclude encrypted zone version data, perhaps clarify
the advise to the DE? Or are those deployments meant to use the
"local/experimental" use, in which case calling it "private use" might be
better?

Have you considered leaving a small initial space for "RFC Required" policy?
Eg 0-15 ?  With only 253 types available, I'd feel happier with that,
especially if this supports proprietary types.

Should implementers be warned not to blindly copy this EDNS(0)
options from the query of a DNS client onwards? Doing this could cause
amplification attacks if some server uses a non-SOA-SERIAL type with a
long length.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

       A name server SHOULD include zone version information for

Can this be rephrased as:

        When asked for a zone version, a responding name server SHOULD
        include zone version information for [...]

Just to avoid implementers from reading this and adding it when the DNS
client did not ask for it.


        The OPTION-LENGTH for this type MUST be set to 6 in responses.

Maybe say:

        The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in
        responses.

I was initially confused and assumed it was talking about what this document
calls VERSION, so alternatively instead of saying what the OPTION-LENGTH is,
perhaps say:

        The VERSION length for SOA-SERIAL MUST be four octets, resulting in
        the OPTION-LENGTH for this EDNS(0) type option to be set to 6.


My OCD triggers on these unbalanced parentices:

        ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 (example.com.)")

(note it seemed to render badly in my browser, but copy&paste seemed to fix it again?)

The example dig command should have +norecurse :)

Why does the example contain an AUTHORITY SECTION for an AA answer
with data? Seems .com does that but other nameservers I tested do
not (eg nohats.ca or .nl). This makes it a bit unclear if the setting
of zoneversion requires that the Authority Section is included. Maybe
a clarifying note can be added? I assume this related to query minimalization?