[DNSOP] Re: Last Call: <draft-ietf-dnsop-zoneversion-09.txt> (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

Petr Špaček <pspacek@isc.org> Thu, 04 July 2024 08:55 UTC

Return-Path: <pspacek@isc.org>
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 8C885C1D4CF2; Thu, 4 Jul 2024 01:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=isc.org header.b="ER93/30A"; dkim=pass (1024-bit key) header.d=isc.org header.b="Wqutb1El"
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 WNCHC2B0NkRV; Thu, 4 Jul 2024 01:55:45 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 9D2B7C180B7F; Thu, 4 Jul 2024 01:55:45 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 665633AB26C; Thu, 04 Jul 2024 08:55:45 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 665633AB26C
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1720083345; cv=none; b=d0k+YwToiroDszBYgMqDgSrAd5potZI9BnpcH0x14auj10wK2whAOR0hk0tSUWnFas2fTS3JxsLCjFC8GYOU/YSCDGjDvgnGXWLUsLUuv0GUxJEIdwNqoR8kwh0WVy9FwMb00hV/7EJfd4QnMjpqw1pwad+1CaH+q92PrEJL+Ss=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1720083345; c=relaxed/relaxed; bh=+aFJzy1Cxm4aL+jNnm399kfTikn/nwCBjP1NLi1S+T8=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=KG33XrCtMUy/bmgBlZ209JEVNCsy4v61zpiTYU2c0bKgZT6nS9qLtraWIgydebK57saOewlw4KRGDrd+NGzuafmM44OeIr0UAoi6S+tST43j3o7XKrZc9e3KGjpFpWOvHGlWgL8Fey/ANG1k37fMq0AL1eE0SNVaIw748A5e9Co=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 665633AB26C
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1720083345; bh=6eD+6M9fGw9G8FjpbgUA2WjyqXCDszzgC1mf0npk8E4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=ER93/30AHJiRyHb0hDw0Lbs/KLl7LpgC37Kyurc2ojCuRsVnJvE+ATWYFwg4guTBI hDW6rqGmtWQ/aJdsGuLdAaFCpYNqLOOyLKKUnLMur9VBMSGnoa0OnOq9qtTdoEbBid U3JANAqhcBO9ERZ/bCyP4zZpJFeTjH+dwvyTW4Kg=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 61C9CA835A3; Thu, 4 Jul 2024 08:55:45 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 398D6A8359F; Thu, 4 Jul 2024 08:55:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 398D6A8359F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1720083345; bh=+aFJzy1Cxm4aL+jNnm399kfTikn/nwCBjP1NLi1S+T8=; h=Message-ID:Date:MIME-Version:To:From; b=Wqutb1ElT62MJJS7NcMgYsDnHD6sIFSfm+6kcKz22t/pn02YqaS43E67nqxt8DYpS NoLRGeN0Qs0XuTIDjQBit1pAr3hpAL9hSRAGPSmGFGg4yBAq72IjZqQSZYEOrjRcu8 Z/tXV2OFc6yTpN3wqHISKPX0NnKC0pdY5qUvxoiQ=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id PyHuUxUDc18v; Thu, 4 Jul 2024 08:55:45 +0000 (UTC)
Received: from [192.168.0.157] (ip-86-49-236-114.bb.vodafone.cz [86.49.236.114]) by zimbrang.isc.org (Postfix) with ESMTPSA id 6448AA83350; Thu, 4 Jul 2024 08:55:44 +0000 (UTC)
Message-ID: <ec1f12e5-8fa8-49ee-aa32-35824017a2af@isc.org>
Date: Thu, 04 Jul 2024 10:55:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Joe Abley <jabley@strandkip.nl>
References: <abce75c4-af10-4fd1-9e99-8c4718996eec@isc.org> <B5D55688-06AA-491A-AD12-1E1A998CF7B0@strandkip.nl>
From: Petr Špaček <pspacek@isc.org>
Content-Language: en-US
Autocrypt: addr=pspacek@isc.org; keydata= xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmWT+REFCQelsxMACgkQq9WHzfBlga7y 2Q//Ug58UI9mlnD/guf9mHqpJIMrBs/vX8HlzylsDcZUBTp2TJpzNh/CygPWrHY+IvA9I9+t Ygp0sB+Z9OtVZgW3bpWJ0iWe6N89Q0kwOuhJ75LsfR1V73L5C826M6bLQjYTj6HiwS9Nf+N0 jADhEV/p1KtCuZfwBkYJ4ZM+Na0zWerGPkGw9T9O0gfs0ePehzJ5V0OK0nCqMuC1h8o/rhCb vRCmxdAbNjrOrgKa7HN5DadP/tKstJMM09aXlT5q96fRIyCQyqXQoCrijCWvgAxgjABdh1TB /XsYvBC8+4wy5ZBtTcnxXGrMhrSxU2/vIK6RjDju7OIRClMNepEzvt0gNzxwwxIXVOzl5ioC i/Okovk1rZneFFxbVvaMyIJgY/hShJV7Ei+5S9UZUv6UUmRQ6zukeiSVZrtXs6fWLVlUnBDl Cv/fXi25hrymqNfPSBSB0tyc6YepR1Rq9omTni6DYmEHQuhPMHJ2fuiNNyBaH+9EI7go5e0J LvXVLJGXkMdTcmYHja1pDjmQ1K71gewfPWGFmn0JTa92GuZJaR/4MVePvoV0NTpCP0HiKIg5 0+AOdpvkJReFKTQOX08SwkUkgvy9h9WjBMpD5ymMs4gjJwXtcT1+aVtj9Xcw6tQde9Yyjxde a6UZ3TUfys8qZ8ZKmMKTaCUFukKzWDJMZ91V1b/OwU0EX84n/gEQANARNXihDNc1fLNFZK5s O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC ZZP5UgUJB6WzVAAKCRCr1YfN8GWBrgxpD/949Tz7EtrE9e2yJ4np+y7uW8EDusVM3QsBdkYk yaQTupITew8WWQtNF/QK/MKRi+e/382t78nBq+T7G9PrRi7E4WS9dXdgJiFz25h3mC4TABJZ b6MLcEreLWTaqnR/D6F3AnNXh7GJFY4E6PAwC60W0R9G6R0E+2XeZX011NEGiBMvgZnqzzjU L9h8Gz7a/EsQync4cvLbruPt/UaOV0khKTefsOFj3q3wLY6qN2qw7HfgFRBCh6ME2XRvnwAd iv0pF4HRbXoFalkAsNEYkWQ6mkJjdYCHOWm3TWqXhalgGKqIOrQyMpH2mJpZllKBQiBiQMUz qz0cO9OqBk3xvNLplI3VNcC0WeQ8LEqyYKth2T78hVaIw8K0IcVmZQwXVxL03gojaJ5bK2O+ 2FfqKMcIiU+bqaTXntx+FYRQKblsUBYD77uU9sPVyKWIiHvukLTx7GY1ttn6gZDSIek/tTR7 oaei+xLh5JUgZpMZ4JHnirDWHbrJzYN95e8HWA/+qAOTsa+igZGsc6yA1oJIAnCwkclcLAgc x3GVVeEL+/b9CugZ+1OfbxlRK7gAeu0kyKiEXrUvCQPnPByIIfj4I4IvZO4552cmmnbn31f9 X/9nw+M4qAqOK7bRg65ucv71TayUehNJrfJSYx6P1tXIwzu19tIgtdWTcsszNWALfaUFtg==
In-Reply-To: <B5D55688-06AA-491A-AD12-1E1A998CF7B0@strandkip.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: VI6BSQSVDUOUPSKW4UU5XPP4XAZFEAUH
X-Message-ID-Hash: VI6BSQSVDUOUPSKW4UU5XPP4XAZFEAUH
X-MailFrom: pspacek@isc.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: 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/7AfXuc7Xi9XMH7W31eJodzHn5xA>
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 04. 07. 24 10:28, Joe Abley wrote:
> Hey,
> 
> On 4 Jul 2024, at 09:15, Petr Špaček <pspacek@isc.org> wrote:
> 
>> To be clear:
>> Let's not hang too tight on this particular example. It could be 
>> something crazy like
>>
>> qname.zone1.test. CNAME target2.example.
>> target2.example. CNAME final.example.net.
>> final.example.net. A 192.0.2.1
>>
>> (i.e. zone names have nothing in common except for the root)
> 
> Yep. I still think the language you quoted would benefit from some 
> clarification though. Perhaps:
> 
> 1.2. Terminology
> 
> ADD:
> 
> In this document, an "enclosing zone" of a domain name means a zone in 
> which the domain name is present as an owner name, or any parent of that 
> zone. For example, if B.C.EXAMPLE and EXAMPLE are zones, but C.EXAMPLE 
> is not, the domain name A.B.C.EXAMPLE would have the enclosing zones 
> B.C.EXAMPLE, EXAMPLE and the root zone.
> 
> 3.2 Responders
> 
> OLD:
> 
>     A name server that (a) understands the ZONEVERSION option, (b)
>     receives a query with the ZONEVERSION option, (c) is authoritative
>     for the zone of the original QNAME, and (d) chooses to honor a
>     particular ZONEVERSION request responds by including a TYPE and
>     corresponding VERSION value in a ZONEVERSION option in an EDNS(0) OPT
>     pseudo-RR in the response message.
> 
> 
> NEW:
> 
>     A name server that (a) understands the ZONEVERSION option, (b)
>     receives a query with the ZONEVERSION option, (c) is authoritative
>     for one or more enclosing zones of the original QNAME, and (d) chooses to honor a
>     particular ZONEVERSION request responds by including a TYPE and
>     corresponding VERSION value in one or more ZONEVERSION options in an EDNS(0) OPT
>     pseudo-RR in the response message.
> 
> 
> OLD:
> 
>     A name server MAY include more than one ZONEVERSION option in the
>     response if it supports multiple TYPEs.  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.
> 
> 
> NEW:
> 
>     A name server MAY include more than one ZONEVERSION option in the
>     response if it supports multiple TYPEs.  A name server MAY also
>     include more than one ZONEVERSION option in the response if it is
>     authoritative for more than one enclosing zone of the corresponding QNAME.  A
>     name server MUST NOT include more than one ZONEVERSION option for a
>     given TYPE and LABELCOUNT.

Sounds clearer to me. I gather there's no appetite to make the wire 
format more generic and I think it's also fine.

Only comment I have is that LABELCOUNT could have been TYPE-dependent so 
a new TYPE could define different mechanism to identify zone, but hey, 
wasting 1 byte is not a big deal in the age of multi-gigabyte videos 
playing in the background constantly.



Unrelated thoughts:

### OPCODE
Currently the document sorta implicitly talks about DNS queries - mainly 
implied by the structure of section 3.2 and listed possible answer types 
and RCODEs.

Should the document be explicitly limited to OPCODE=QUERY, or is there 
value in allowing other opcodes?

E.g. RCODE=YXRRSET comes to mind, where it could be useful for 
OPCODE=UPDATE as well as OPCODE=QUERY.

Oh, it just occured to me:
What if I throw in OPCODE=QUERY QTYPE=AXFR/IXFR just for fun.
Allow? Disallow? Leave undefined?



### Error handling advice
While re-reading it once more I wonder if sections 3.1 Initiators and 
3.2 Responders should have some more words about when to do when various 
MUST/SHOULDs are violated?

Say initiator gets answer with exactly duplicated ZONEVERSION. What now?
And what if LABEL and TYPE are duplicate but with different SERIAL 
values? What now?

Drop it on the floor as signal FORMERR in both cases? Or process and 
display as usual in the first but drop the second case? Or what?


This is my generic complains with dnsop documents - they often do not 
say what's expected behavior when constraints are violated. We can take 
it as a though experiment and see where we get.


Ad one specific case which _is_ defined:
 > A name server MUST ignore invalid ZONEVERSION options present in the 
query message.

Does that mean that server MUST ignore ZONEVERSION query with 60 000 
bytes of payload and proceed as usual? I would say it warrants FORMERR :-)


If you think I'm insane, well, you might be right! In my defense I've 
spent last year dealing with weird attacks misusing DNS protocol so I'm 
in the under-contant-attack mood...

-- 
Petr Špaček
Internet Systems Consortium