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

Ben Schwartz <bemasc@google.com> Wed, 05 August 2020 19:06 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 76EC53A0E66 for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 12:06:23 -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 g87H377IIc2Q for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 12:06:19 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 666BA3A0E65 for <dnsop@ietf.org>; Wed, 5 Aug 2020 12:06:19 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id c19so4988936wmd.1 for <dnsop@ietf.org>; Wed, 05 Aug 2020 12:06:19 -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=up4SwHr3TLYHN2Mpmcxc5gL+ZqJsV/7CqB0FXCvqB9A=; b=buyNTqpiCVIA1g/9qEBy3HdqaePz9SDfSmZMpp5wYVnTjzD9KtFyq71MnAF/bZ8t+A +XULoB1EQZp4jfmIz/SKR/L2HCVaaD7Fdkb15epGeF84SQu+vJwqp4K5JUPcryBmjHsY sfwTe2+yl//WZdBgPasWCV4rvr53NA7rfxkRGP/4Buu/jOsWBIW1DKWItPYcP5viQnql KZ7jTVOUSSGu6wrNtIGTv8Ge0ZsHXlrCJIAoeHd5ot+zzwYGaCmot0R0Jf9jpewJMjLE asKCSDzGRR2/lFmpBY0n5PG/7mM1eVXiHoN+Tpsib0q/Qzncxaufv5feRTjUhkOhxHgx EGlg==
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=up4SwHr3TLYHN2Mpmcxc5gL+ZqJsV/7CqB0FXCvqB9A=; b=pD+kL3ltiZ/5lNzMxhmo1UvasIl75n0aAsyY4f6nts6jcThbRTGNYSb9pPedwyfBVV +lTenQgxQexU0TcAUU0FpziWTdvD6VFkukspZE0jEP8GDM42zjZtrLsSkMUy6GXXk0P6 AuYcghexrSOvXFBfZFlh43Q/cOwzyE71NvdU35vUVdLZ3SaH3JnkUDuoaNnLO5grLJbM j8hdIrkABfNj/elGAiqyXLG5mRhNcIuSGqSgePArngBi8dB7KgBm1xpDwtfcN5gAICaA jUgs2EorLluLVYYdVoVxvkosGD7bHNVJ+ybT/ka2vRES4hHpHWaNU+ViNNYOv7KPUY2G Cv0A==
X-Gm-Message-State: AOAM530tL8cWJVfiEUNa3c24llluaMnjtNrnCJCaOmVVHuRTMVj0csBR /RhWQmi2INnoPhcCOcnxgXJd1cNW4IQXQet9HtGkxQ==
X-Google-Smtp-Source: ABdhPJxj1RZIgYPu6AdJxe26JJZZm+vRFvjMPJG0XVIeTdhKMqqObLKtV6mfsVHu6wFpne7JHPyFhjR2fEv+sSKoJvo=
X-Received: by 2002:a1c:a757:: with SMTP id q84mr4300256wme.1.1596654377581; Wed, 05 Aug 2020 12:06:17 -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> <cd6021e7-4aad-c2fc-e9ef-948fbeab0809@powerdns.com>
In-Reply-To: <cd6021e7-4aad-c2fc-e9ef-948fbeab0809@powerdns.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 5 Aug 2020 15:06:06 -0400
Message-ID: <CAHbrMsC6gnDASJOjf1LyTGFioHTUOub0Pk6EN+roOukNSq+6Ow@mail.gmail.com>
To: Pieter Lexis <pieter.lexis@powerdns.com>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000009532d05ac2611f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ftJ6drvCp0AgE0UQHfrqYPmZlrs>
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: Wed, 05 Aug 2020 19:06:24 -0000

Thanks for the review!  I'd appreciate it if other authoritative server
implementors could comment on this proposal.  If they agree then I'm happy
to make this change.

On Wed, Aug 5, 2020 at 2:51 PM Pieter Lexis <pieter.lexis@powerdns.com>
wrote:

> On 8/5/20 8:03 PM, Brian Dickson wrote:
> >
> >
> > On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz
> > <bemasc=40google.com@dmarc.ietf.org
> > <mailto:40google.com@dmarc.ietf.org>> wrote:
> >
> >     On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis
> >     <pieter.lexis@powerdns.com <mailto:pieter.lexis@powerdns.com>>
> wrote:
> >     ...
> >
> >     Conceptually, AliasMode is not a CNAME: it only affects SVCB queries
> >     (not other RR types), and can safely be implemented entirely as an
> >     RFC 3597 Unknown RR Type.  That suggests that it is at least safe,
> >     and perhaps least-surprising, for the authoritative server to put
> >     all responses for other owner names in the Additional section, as
> >     the current text seems to indicate fairly clearly.
> >
> >
> > I beg to differ, in that I would view AliasMode as a constrained CNAME.
>
> I agree with Brian here. Compliant DNS servers (be it auth or recursor)
>  MUST treat an Alias-mode SVCB (or derived) record as a CNAME for the
> purposes of processing that SVCB or derived record.
>
> i.e. foo.example.com SVCB 0 srv1.example.net == (logically)
> foo.example.com CNAME srv1.example.com when QType = SVCB, but not for
> any other QType.
>
> > 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)
>
> +1 to this summary. It reflects how I see the semantics of alias mode as
> well.
>
> > (I am not sure of the question/issue of including the SOA, or where that
> > would go, but I'll defer to anyone who knows or has an opinion. My gut
> > says, do whatever gets done for CNAME.)
>
> The SOA MUST go in the packet. As a compliant resolver talking to an
> auth that does not implement SVCB will follow the chain and the auth
> will respond with NODATA (and thus the SOA).
>
> After reading section 4.2, I also think that a resolver that implements
> this MUST include the SOA as well if the final target has no SVCB
> record, to indicate that the answer to the actual question
> (example.com|SVCB) yielded NODATA after alias chaining. A compliant
> client can ignore the fact that the DNS says NODATA and use the A/AAAA
> records from the ADDITIONAL section (or send a query for them based on
> the final target).
>
> > All the in-bailiwick stuff is essentially an optimization. Authority
> > servers may not implement that, and would still be compliant if they did
> > not.
> > Resolvers MUST be prepared to handle the non-inclusion of in-bailiwick
> > stuff from authority servers, as this would not be an error or violation
> > of the (eventual) RFC.
>
> Yes.
>
> >     P..S. The text on this point has recently
> >     changed:
> https://github.com/MikeBishop/dns-alt-svc/pull/199#discussion_r444979971.
> >     One of the questions there is what should happen for
> >     AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick.  The draft
> >     says "Clients and recursive resolvers MUST follow CNAMEs as
> >     normal.", but it no longer says anything about authoritatives.
> >
> >
> > IMHO, I think this is correct, or at least consistent with what I wrote
> > above. (If there are any inconsistencies, could you highlight what those
> > would be, please?)
>
> I believe you are correct.
>
>
> Cheers,
>
> Pieter
>
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
>