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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 06 August 2020 18:03 UTC

Return-Path: <brian.peter.dickson@gmail.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 3143B3A0D6F for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 11:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pIvgNIaHYgaK for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 11:03:21 -0700 (PDT)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 21E503A0D6E for <dnsop@ietf.org>; Thu, 6 Aug 2020 11:03:21 -0700 (PDT)
Received: by mail-vs1-xe29.google.com with SMTP id n4so4154554vsl.10 for <dnsop@ietf.org>; Thu, 06 Aug 2020 11:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lM5cYc1aWKmoEDlPadP9SmbJeQ65MfBA55d1rF9U6oA=; b=o7T30KSytdLjfdesQ8Jr6nSCxiNatIQ1C0nlbFDgYdzgH3NT0Q+AdlfQa3HIu7GQsz izkFtGBKSFbEiyVGQ21L3jQcufuEHn2imQnRDOiUaC/OiR6IHgkQhEVEAk6sekWzYCBN eNgFzOA8eZyx968r3pktUmWZuPD107LcpsnagR+92MTkgyVJWjsllH1Ijh/CbGPMXPNd hc6UvjqHgE3Iuonl9wEOTmblx+t7XhinLhBd+CFUX4TGDz1ggJRFUXG3ounIjKufF/D+ IuBw8aikYuO15UrYx/ci9T/ufR+lrov6nh0+K6pQ0EQdmuuERayIf4ABeRtTCTXRnDMu mOpg==
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=lM5cYc1aWKmoEDlPadP9SmbJeQ65MfBA55d1rF9U6oA=; b=PlW9okjJMDwomMJl+ajS2z8hnR+BqL1slDOCCimLPjGBLTmTpRkK9KnF8daiLjDPJT Yg08vBzCtDV5+QZuDuxFP3ZsUacxriMi2/8WrOW7aC7gxOC81QwbUdZ/NgsvQzm7so5t p6c3vXK7ddW0vBJs3w4Yjjp5mgiPuv4LLbpHDH17P2Rsbvga3ELjN9VpPEtUGpKpjYv+ txLpvj67iMLPTdbeBGF3cAu6OAYPCmU51UCqYb91L28uInqi6eYoM5DByrpuGIJpC9FM nzhQX9a57M6h3ugjRdM9+Jtc0HaKGA7K9kmd3Acwdj7lGxUNtdFEOCEh4rr+ZDNh9FFY W8wg==
X-Gm-Message-State: AOAM532JJssgt0x0lDJqqZC9yWfyjnbUydGByvsPGRFCethKL83oIza2 mmeHjUo97aHn1knqQReOwgviQPRa+bD5VTtg7H+2NglutRc=
X-Google-Smtp-Source: ABdhPJy8OOAttOWWKCB0YTM08C3bEcoqKc+hwJlurYuWNWdZgrW+cWGyaDbeGfj1yCD9RCbvOXnM3tAu7PHJCEsNtxU=
X-Received: by 2002:a67:3249:: with SMTP id y70mr7563328vsy.199.1596737000138; Thu, 06 Aug 2020 11:03:20 -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> <8BC20DED-784F-4004-9E56-8BB2F6356FA7@isc.org> <9390cb8a-677f-7309-b466-c45643827b22@powerdns.com> <DCAF1704-B545-4AB8-8133-85E7280ADCD6@isc.org>
In-Reply-To: <DCAF1704-B545-4AB8-8133-85E7280ADCD6@isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 6 Aug 2020 11:03:08 -0700
Message-ID: <CAH1iCioaitgh1JYNLcqawkg06WLG8FqmmDV0LkOrAaqUuNBNcQ@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Pieter Lexis <pieter.lexis@powerdns.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b16b3705ac394d4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3RF2SgRLnmHnLpmk8WBTRvG9DOY>
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: Thu, 06 Aug 2020 18:03:23 -0000

On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews <marka@isc.org> wrote:

>
>
> I really don’t know how this thread got started with clear and unambiguous
> instructions to add all the records to the additional section.
>

The possibility of changing what is specified in the draft, was what
started this thread.
Your responses all suppose that it is not possible to change what is
specified in the draft.
It would be helpful (IMHO) to the conversation to give consideration to the
contents of the thread, from the perspective that the specs in the draft
are not absolutely set in stone and immutable.

Here's the quote from Ben:

I think Section 4.1 is pretty clear that everything goes in the Additional
section.  (But this can be changed!)



>
> "Cooperating DNS recursive resolvers will perform subsequent record
> resolution (for SVCB, A, and AAAA records) and return them in the
> Additional Section of the response. Clients either use responses included
> in the additional section returned by the recursive resolver or perform
> necessary SVCB, A, and AAAA record resolutions. DNS authoritative servers
> can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional
> Section to responses for a SVCB query."
>
> Yes this means you need may need to change additional section process to
> chase other records.  Named was already doing this for one type and with
> HTTPS and SVCB needing we made the processing general.  Yes, it also means
> that one has to add CNAMEs to the additional section when processing HTTPS
> or SVBC.
>
>
We can all read, and we understand what the current draft says.
That's NOT what is being discussed (how to interpret those words).
What IS being discussed in this thread is whether it may be more sensible
to align the process of handling the "alias" form in a manner more
consistent with how CNAME processing happens.
It is a proposal to change the spec itself, rather than an alternate
interpretation of what the current draft of the spec says.

This is why I suggested that, while it is not CNAME per se, treating it as
"constrained alias applicable only to SVCB queries" isn't a huge leap, and
would simplify the code for handling alias form, on both the server and
client side of a lookup.

If the standard says they belong in the Answer section (as I am
suggesting), I think the expected BIND client-side handling of SVCB records
(alias and non-alias, if in-bailiwick) and CNAME records if they are both
placed in the answer section by the server should be okay, in both
situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB
handling logic is added.

Brian