Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

Peter van Dijk <peter.van.dijk@powerdns.com> Fri, 19 March 2021 17:53 UTC

Return-Path: <peter.van.dijk@powerdns.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 475943A1B48 for <dnsop@ietfa.amsl.com>; Fri, 19 Mar 2021 10:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zrDYrZDrPzfk for <dnsop@ietfa.amsl.com>; Fri, 19 Mar 2021 10:53:20 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D031B3A1B4B for <dnsop@ietf.org>; Fri, 19 Mar 2021 10:53:13 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id 8812A6A267; Fri, 19 Mar 2021 18:53:09 +0100 (CET)
Received: from plato ([84.81.54.175]) by imap.open-xchange.com with ESMTPSA id 7x1XIAXlVGB7DAAA3c6Kzw (envelope-from <peter.van.dijk@powerdns.com>); Fri, 19 Mar 2021 18:53:09 +0100
Message-ID: <a484ac7f67248dcfe7b362253e2ac2c36da0b9b4.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Fri, 19 Mar 2021 18:53:09 +0100
In-Reply-To: <CAHbrMsDB0uEtXuiXwJxJpBfwEvsYMJ+oj6Wt5qdRDSPAaF07ZA@mail.gmail.com>
References: <161600103837.12472.4123883592260330100@ietfa.amsl.com> <CAHbrMsA3NzpY9RFNhWsvYgQ0hqcqEDuMUrw7HmGBJZ1+uaLtNA@mail.gmail.com> <600ED9AF-2C6F-429F-AF39-445E29E686EF@apple.com> <4DFDEFA6-4132-42CA-8DA7-D0537C5FC29A@isc.org> <99cdd98b-ac59-c96c-a73f-a58729c2ca52@nic.cz> <fbeb99ad-9ccc-1050-a0d2-3b6e5287ed7a@nlnetlabs.nl> <214c21bc-2d05-0c58-ba0f-4891bae0e343@powerdns.com> <CAHbrMsDB0uEtXuiXwJxJpBfwEvsYMJ+oj6Wt5qdRDSPAaF07ZA@mail.gmail.com>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2EGegHAiQJmhybQ3HzdinVw72So>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.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 Mar 2021 17:53:22 -0000

On Fri, 2021-03-19 at 10:42 -0400, Ben Schwartz wrote:
> Does anyone have an example of test vector presentation that they like? Perhaps it should be structured as a pair of zone files representing the same zone, one in SVCB format and one in RFC 3597.


tl;dr: +1 to that


I recently implemented CSYNC in PowerDNS, and was greatly aided therein
by RFC 7477 section 2.1.3, which I will quote here:

===

The following CSYNC RR shows an example entry for "example.com" that
indicates the NS, A, and AAAA bits are set and should be processed by
the parental agent for example.com.  The parental agent should pull
data only from a zone using a minimum SOA serial number of 66 (0x42
in hexadecimal).

example.com. 3600 IN CSYNC 66 3 A NS AAAA

The RDATA component of the example CSYNC RR would be encoded on the
wire as follows:

  0x00 0x00 0x00 0x42             (SOA Serial)
  0x00 0x03                       (Flags = immediate | soaminimum)
  0x00 0x04 0x60 0x00 0x00 0x08   (Type Bit Map)

===

In my case, I could take these hex octets, sprinkle in a few
backslashes, and make the test case fit *our* codebase:

test-dnsrecords_cc.cc:     (CASE_S(QType::CSYNC, "66 3 A NS AAAA",
"\x00\x00\x00\x42\x00\x03\x00\x04\x60\x00\x00\x08"))

Ever since I've been wondering what the best format would be, though,
so that vendors could exchange collections of test vectors. I already
imagined OARC maintaining that collection even!

I think your SVCB/3597 pairing might be that format. I know NLnetlabs
and ISC have tools that can even generate the latter from the former
(for supported types, of course), which makes testing and verifying
implementations very easy if the RFC also shows that pair, and even
allows users (and draft authors!) to do the same checks.

The only thing I wonder about is whether we can combine the 3597 format
with the 3 part breakdown 7477 did on the hexdump, which also is very
educational. Of course, nothing prevents us from doing both the
breakdown and a couple of 3597 pairings.

So, +1 from me!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/