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

Ben Schwartz <bemasc@google.com> Tue, 11 August 2020 20:15 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 70FB53A0C58 for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 13:15:15 -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 YUL4jPrOEK7u for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 13:15:11 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 7DB623A0C4D for <dnsop@ietf.org>; Tue, 11 Aug 2020 13:15:11 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id g19so105120ioh.8 for <dnsop@ietf.org>; Tue, 11 Aug 2020 13:15:11 -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=khc9xJRTRS/5PXknuJXd0v0s8884FG8YFjyTzjRUqMw=; b=TnHxq1CxujzL9lLbodm0nSal8oq0snsGrSZRJwoHHK+Gjl1u62yPVzH9g5x/5N1ir5 g2/QCP29BDy8Jq8toogBMnC1W7LKN2TE04742ka5Ki/E1JchecRLyC4wRwAw+5zJkrPw r4rhCkAwXcOilWtVq6EX7RyimgrCf7NR4vwmuO6QmJiMNTgxDTW4QEapc2ZwqGg7+vB6 JPkgijHndOupFv3wmUB3s+pcqXLcQpsXuw16r110iu6L+RbHQR2k+mh3XMu1eCnhaJb4 290AWcPzsSm0QrhLt0F6VVKNtFMyOgKJYAWRgUFEGieqV0+fb0hnNs92BF6lVF6qxvgt 7QDQ==
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=khc9xJRTRS/5PXknuJXd0v0s8884FG8YFjyTzjRUqMw=; b=g5wjabw+mJ0Oxr38bkAFHWdcq8qCO1A3Oon5IcFmTjAw2lTvMNI2tqe8R6s1b5Ai8H Xr5rroPfxzzZym38j8KFWGF1Cb/ripox9UbI99z7kOuvNZqL4UzJqy9ppnxdsbxj9Kaa 2T2uNPLlQDUYPN1rQHkqtu8TAZgsK9QkDTi/gkP+6mSjM3sLqRnVfHl8w/K8wjKLM/ge X62D/osXWLK5WtqIza0FGT4Hh1MS63E+FX7kMK8f3qfAgBmfYPls0fkVKSa/u65oqkSc xmsbVWIWOid7wIuvscLsiZs/l7n4oKeR6gMBI0sGuy0ZfnahF671rwPmNlTTtRZzvi+l uQMg==
X-Gm-Message-State: AOAM532nnnjlVo4tdvlx637r5u8xWFJMIsR6W1V6p1/fPp/rLQZni1Ye uCNCapTnvZ+kPRxIMZPLZORYWC8hPlV0gCeDpPsnaA==
X-Google-Smtp-Source: ABdhPJxPYNHNJKXucknsGP53QhUrCNi+XkaraR80xFPz5Oqex8OBDZmYmetR7LvnuyOg7dJarh2nzsPpP7p7LUanvjY=
X-Received: by 2002:a6b:ce11:: with SMTP id p17mr24460594iob.125.1597176910574; Tue, 11 Aug 2020 13:15:10 -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>
In-Reply-To: <alpine.DEB.2.20.2008102304160.21650@grey.csi.cam.ac.uk>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 11 Aug 2020 16:14:59 -0400
Message-ID: <CAHbrMsCePLp=vaw3fgf611TfnFpeUaV3xkCT5BSH3yzu-XZ1rg@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="0000000000006ce25605ac9fba77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nac33RnZz5ikRLyLeyqO8SOuN_g>
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 20:15:16 -0000

Thanks for that warning, Tony.  It sounds like we should stick to the
Additional section, and not alter the Answer contents.

I've tried to incorporate the feedback from this discussion into a proposed
change that avoids imposing new requirements, but enables the CNAME chain
optimizations identified by Brian Dickson and specifies SOA behavior as
proposed by Pieter Lexis:
https://github.com/MikeBishop/dns-alt-svc/pull/238/files?short_path=d44bc72#diff-d44bc722e745a4e66186057a4127f461

This change would replace Section 4.1 with the following text:

When replying to a SVCB query, authoritative DNS servers SHOULD return
any useful in-bailiwick records in the Additional section.  Authoritative
servers MAY implement this Additional section processing by applying the
following procedure to each returned SVCB record:

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.

All follow-up queries MUST retain the original query's "DNSSEC OK" setting.

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}}.

On Mon, Aug 10, 2020 at 6:17 PM Tony Finch <dot@dotat.at> wrote:

> Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> >
> > What I would suggest is the following, paraphrased (i.e. please clean it
> up
> > before using in the I-D, if you agree it's the right semantics):
> >
> >    - In-bailiwick CNAME, SVCB, A, and AAAA records SHOULD be added (and
> for
> >    CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be
> iteratively
> >    processed for inclusion)
> >    - CNAME and SVCB records MUST be placed in the Answer section (because
> >    of existing CNAME rules and because of RRTYPE match to the query)
> >    - A and AAAA records MUST be placed in the Additional section (since
> >    those would not match the query RRTYPE of SVCB)
>
> I've only skimmed this thread, so I might be repeating something that's
> already agreed... but I want to emphasize that a new RR type specification
> will have impossible interop problems if it tries to put records in the
> ANSWER section that aren't expected by existing DNS software.
>
> "Unexpected" means anything that isn't part of a CNAME or DNAME chain on
> the way from the original query name to an RRset of the query type.
>
> If a resolver queries for the owner of SVCB record (or a CNAME pointing at
> one) then anything related to the RDATA of the SVCB record(s) has to go in
> the ADDITIONAL section, or there will be sadness.
>
> It was a very long time before DNAME was usable and even within the last
> 10 years there was software that would choke on DNAME records in the
> ANSWER section that it didn't expect.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Shannon, Rockall: Variable 2 to 4. Moderate, occasionally slight. Drizzle.
> Moderate or poor.
>