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

Mark Andrews <marka@isc.org> Mon, 22 March 2021 13:56 UTC

Return-Path: <marka@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 CF8503A1573 for <dnsop@ietfa.amsl.com>; Mon, 22 Mar 2021 06:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=Y4TuPsyr; dkim=pass (1024-bit key) header.d=isc.org header.b=f8nQDgsY
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 kh7fKsP7sO1p for <dnsop@ietfa.amsl.com>; Mon, 22 Mar 2021 06:56:02 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 AED1B3A156E for <dnsop@ietf.org>; Mon, 22 Mar 2021 06:56:02 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D1F243AB01C; Mon, 22 Mar 2021 13:56:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1616421361; bh=vEgrMUNMgpw76UfNehIGP71RdxbmrQ6YGc8lSm853x4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Y4TuPsyrit1m0tFpT+0EbpdWK1V1cy7FEBitsgtd8T8qUIJWnushjWjNDg3mWU1t8 bUucLPHY2BH+52qu9Kc52xiY/u1A5JcvzcYpP1CZkSA1rIcbIkavelG7q4yZMceR3J Wp2WrnumJgR08aKvNL/BoJs2hszuKMoKjqzAC2aY=
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B3F6116005D; Mon, 22 Mar 2021 13:56:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8F138160084; Mon, 22 Mar 2021 13:56:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org 8F138160084
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1616421361; bh=bBw+cEXn0jst/W/r2SFqUsPi0VkNEbeCEjvw07XIp04=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=f8nQDgsYe1akMghe1LanyuUCdtKTOiim7KObnHv681qmQreaB1FHmcczqXsnWGhcG o8TWVQY9a8bm33k3oiOpbl4lfFEGv40BPo5TILOL36h6TJRgkQRi0GGxbieFb4cl3a drmULm4TnZ/p5VzKdS08zO2eUdKjE18Y4xUfqBG0=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Uo4o8Q_w95al; Mon, 22 Mar 2021 13:56:01 +0000 (UTC)
Received: from [172.30.42.67] (n49-177-132-25.bla3.nsw.optusnet.com.au [49.177.132.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 9C9A016005D; Mon, 22 Mar 2021 13:56:00 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <047911f1-87b8-e798-d361-9927bef7e10c@nlnetlabs.nl>
Date: Tue, 23 Mar 2021 00:55:57 +1100
Cc: Pieter Lexis <pieter.lexis@powerdns.com>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <230672DF-D4F0-4AA1-BF96-516A184BC1C7@isc.org>
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> <b6b65c08-55c1-9f2c-a33b-29ab8e806d45@nlnetlabs.nl> <adad7e8a-280f-3ad6-4dac-eec954fe01bf@powerdns.com> <047911f1-87b8-e798-d361-9927bef7e10c@nlnetlabs.nl>
To: Willem Toorop <willem@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BvWxzgVh5rg1x3BPafZ7LgOmtDQ>
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: Mon, 22 Mar 2021 13:56:08 -0000


> On 22 Mar 2021, at 20:41, Willem Toorop <willem@nlnetlabs.nl> wrote:
> 
> Op 19-03-2021 om 18:03 schreef Pieter Lexis:
>> Hi Willem,
>> 
>> On 3/19/21 11:47 AM, Willem Toorop wrote:
>>> That'd be nice!
>> 
>> PR is here [1].
>> 
>>> Do you also have tests for peculiar/corner and failure cases?
>> 
>> I'm a little bit unsure what you men with this :).
> 
> Well, I am wondering how much the parser should just normalize or
> produce a syntax error instead. I noticed from the 7th example in your
> PR, that you automatically put the SvcParams in the correct order, so
> you apply normalization there in the sense that your parser sorts the
> SvcParams. So do Net::DNS and (unreleased) ldns b.t.w.

And BIND.

> But what about the keys in the "mandatory" SvcParam? Should they be
> sorted automatically? Or should the parser produce an error if they are
> not sorted? Currently both both Net::DNS and ldns sort them for you.

They MUST remain in the entered order unless the specification is
changed to say to sort them.  BIND preserves the order.

> What if keys appear double in the "mandatory" SvcParam? Should the
> parser produce an error or remove the doubles? Currently ldns removes
> them, but Net::DNS produces and error.

It’s an invalid record that should cause the zone load to fail
It’s an invalid record when received over the wire.

> What if keys that may not appear in "mandatory" (like key0 or mandatory
> itself) appear in the "mandatory" SvcParam? Should they be removed
> automatically or should they produce and error.

It’s a syntax error or an invalid record when received over the wire.
Note: key0 is mandatory.

> What if keys that are listed in "mandatory" do not appear in the RR.

It’s an invalid record that should be rejected by the parser or
an invalid record when received over the wire.

> What if there is a DNSSEC signature alongside the SVCB or HTTPS RR?
> Should normalization be applied to the rdata then?

Yes.  The signer deals with the wire format, not the text format.

> What if the SVCB and/or HTTPS is not parsed by an authoritative, but
> received via AXFR or IXFR?

Reject the transfer if the records are invalid.

> Or dynamic updates?

Return FORMERR to the updater.

> Also, I love the annotated RFC3597 format that Net::DNS produces and I
> think we should use that in the test-vectors!
> 
>> The code is here[2].
>> I've also opened a PR updating our parser for the draft-03 changes for
>> multiple values, that one also has some tests for the value parser[3].
>> 
>> Cheers,
>> 
>> Pieter
>> 
>> 1 - https://github.com/MikeBishop/dns-alt-svc/pull/307
>> 2 -
>> https://github.com/PowerDNS/pdns/blob/3a63bb5fca1c45a6e9dee808a56ca6cbea2be0d8/pdns/test-dnsrecords_cc.cc#L209-L230
>> 3 -
>> https://github.com/PowerDNS/pdns/pull/10074/files#diff-1c55ae7b2d1073637c05a035de9ef6688ecffb209e50b3bef8b3d9ea1c5a329dR308-R393
>> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org