Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

Ben Schwartz <bemasc@google.com> Tue, 11 August 2020 21:38 UTC

Return-Path: <bemasc@google.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 5613C3A0D32 for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 14:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 R7FUdiNcyLgk for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 14:38:13 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ABB3A0D33 for <dnsop@ietf.org>; Tue, 11 Aug 2020 14:38:12 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id b16so449061ioj.4 for <dnsop@ietf.org>; Tue, 11 Aug 2020 14:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tr+B2S93Z0EjfK5qboudmKjU/AFIeqLRlrK/N+uZp6k=; b=JMaYl95f03mxKLPyJGbJMw31X3mgoE+BleUQ/YZuOokS5tt4P29uEAi4s4rYaieqT2 drO6w46DdbLGY8FUmfQIr+J7VD1HU/iwrz7bp+iFYaTX9YzUrRXufjodk64wQAXSLUMv OwjgyDLGa+v9EssGdodLF5yH5L7kQPHAwMWMpjvCUpNaGq4FiQxHD36z7qqUBQNxXXXX v64n4IWoe0H7fcvJkax7dgNueQvZSmDAZ+N0/9wovQLGB3vI6a0YzlgE6oAO0jhfr1TD b3awBRjeCxD7ATIZBU/nSiLIWbsU2aFqkrEM1enxJm4hFHl/vT1silLnfjtxR0vmag0F 5Aqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tr+B2S93Z0EjfK5qboudmKjU/AFIeqLRlrK/N+uZp6k=; b=lIZDFhbjIaQp9v1n0UQvYS04AFWJHJVrrDDP+EePlCr1Uql7kWXbQySY0HHX2lNn8F rKzTXRSAgemkG3udiVWFs164bAMLxQ9ibjaBoie05hxfIKcomvdWFJA47tDuZMdFh47P qQu42YSxtCq2IrfS9RvHCJdQur3zFYQ6WBm6vJO1ObtXzUfe8J9btwU5DNMYW3f+mLMA xw0qG8Mo5rFOd0P1Cp8wr+OmkikshbpyURFqpRpTEUGuYp3JOfeUG+Y4+Bq2KIiQ+vnX 9h5gOds+rQHU8Czps/M3t7bokEJYORiYpDCTIXSugxRHUuxaduh33+9c0+LvV+fZHKza 6bWg==
X-Gm-Message-State: AOAM5313RXSI3c56RdggTYf8Zwi9eanahLG0a+oKXsbrwMzAgDLT9lT0 zT4rQjJrEq+50B9B7f2JyKk4Rmmu8NMAz+kG7N0Cqg==
X-Google-Smtp-Source: ABdhPJzmrowfBghDdvHFzutUXWbPPAl9x1vCXblCVPGAc7gZZFlOn9ozF3gIBUzNX5Ad1huy//QmrmCRZlWgtTm8zi4=
X-Received: by 2002:a05:6602:1343:: with SMTP id i3mr24251662iov.134.1597181892005; Tue, 11 Aug 2020 14:38:12 -0700 (PDT)
MIME-Version: 1.0
References: <00cfd965-bf69-d1cb-2df3-1a9bb110d7e0@powerdns.com> <CAHbrMsAJ-cbcW3v4T34f8-gzgzgHSkoBO545_Y3N8D6rof7Nmw@mail.gmail.com> <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com> <alpine.DEB.2.20.2008102304160.21650@grey.csi.cam.ac.uk> <CAHbrMsCePLp=vaw3fgf611TfnFpeUaV3xkCT5BSH3yzu-XZ1rg@mail.gmail.com> <alpine.DEB.2.20.2008112129160.21650@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.2008112129160.21650@grey.csi.cam.ac.uk>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 11 Aug 2020 17:38:00 -0400
Message-ID: <CAHbrMsBPyrgbbjx0_-w2Ysky63edtw3kKEBu7DrgDCfP_-GBBw@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>, Pieter Lexis <pieter.lexis@powerdns.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000057a51205aca0e3ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jqbo8qH0AN4HjWbPp6GSaruqaqs>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
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: Tue, 11 Aug 2020 21:38:16 -0000

On Tue, Aug 11, 2020 at 4:54 PM Tony Finch <dot@dotat.at> wrote:

> Ben Schwartz <bemasc@google.com> wrote:
> >
> > 1. If TargetName is not in-bailiwick and is not ".", terminate the
> procedure.
> > 2. If SvcPriority is 0:
> >     * If TargetName is ".", terminate the procedure.
> >     * Otherwise, perform a SVCB "follow-up" query for TargetName and add
> all
> >       returned records, including any records added by this procedure.
> >       If any SVCB records were added, terminate.
> > 3. Perform A and AAAA follow-up queries for TargetName (or for the owner
> name if
> >    TargetName is "."), and add all returned records.
>
> I think the actual wording you want here is "in the same zone" not "in
> bailiwick".
>
...

Thanks, I will make that correction.

...

> > If the server does not complete this procedure (e.g. due to response size
> > limits), it MUST remove any SOA records from the Additional section.
> > Recursive resolvers MAY use the presence of an SOA record in the
> Additional
> > section to enable negative caching of the follow-up queries, as in
> > {{?RFC2308}}.
>
> I'm not sure I understand this paragraph. Truncation is normally from the
> end of the additional section backwards, so it is really weird to drop
> records from the authority section first. SOA (start of authority) records
> go in the authority section not the additional section


In this procedure, "all returned records" for follow-up queries are added
to the Additional section.  Therefore, there could be SOA records in the
Additional section.  (However, I _don't_ think there could be SOA records
in both the Additional and the Authority sections at the same time.)

We could remove this requirement when TC=1.

- the authority
> section is all about gossiping zone cuts (i.e. SOA records) and nameserver
> records. I don't understand how negative cacheing is relevant to a
> positive response for a SVCB query.
>

Resolvers are recommended to perform several followup queries when
resolving SVCB records (Section 4.2).  If those records don't exist, it
would be nice to be able to inform the resolver of this so it can skip
them, as Pieter highlighted earlier in the thread.

The DNS doesn't allow a client to know that additional data doesn't exist
> when it is omitted from a response. It sucks, but that's the way it is.
>

Yes; this proposal would change that in this case.  If you think it won't
work, I'd love to know why.

(This is why most SMTP software doesn't actually use the additional
> section in MX responses.) You could in theory put a DNSSEC proof of
> nonexistence in the additional section, but I don't know of any software
> that will make intelligent use of it.
>

Similarly, this proposal would indeed put the proof of nonexistence there.
(The -01 draft already contains this instruction.)

Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Southeast Iceland: Southeasterly veering southwesterly 3 to 5. Slight or
> moderate. Fog patches, rain at times. Moderate or good, occasionally very
> poor.
>