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

Ben Schwartz <bemasc@google.com> Mon, 17 August 2020 14:43 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 3ED3E3A0BDE for <dnsop@ietfa.amsl.com>; Mon, 17 Aug 2020 07:43:30 -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 XNJuwIPMPRIA for <dnsop@ietfa.amsl.com>; Mon, 17 Aug 2020 07:43:28 -0700 (PDT)
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 8F3E93A0BD0 for <dnsop@ietf.org>; Mon, 17 Aug 2020 07:43:27 -0700 (PDT)
Received: by mail-wr1-x444.google.com with SMTP id l2so15266856wrc.7 for <dnsop@ietf.org>; Mon, 17 Aug 2020 07:43:27 -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=Ii3jJdDOWJ05TrC6Qp1ioGXZhwqqG1D70DMe9tYaMSg=; b=lFaDwrzaATvDXOaGPrVqOqb0EKzqP1M++9ONPc/Ag4SbHFNz3iLkMSu5Me658JpnFr UhP4hdQwocyLd9I6Pst/bPu4d8VLJiJ2KsenRRVAubIZ2pkCXwi3KqRuACotpBegBdZF RLsizIXfLtX1nm0o/aCm3I9hja6KN2nBXVDcfR/Eh1+mrbuLdGpy1wnZy6JgXfm3rHBb 8cr5O0Slq7mtri3BVt+Y7iiKFeNmElKn2GDxDEpmilSS0P0BZXHmd8aRGZTai9EkCnPI maeOG0IRpUzpFVLj6FQKoqa0EQhKDu6ewYhgWWyHllJlp8ZyYViHFbKIuclEHtpEcOxB JmLA==
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=Ii3jJdDOWJ05TrC6Qp1ioGXZhwqqG1D70DMe9tYaMSg=; b=IxGeCcs5dQi9OPHAChXBxGl0ExyTQUbu/IPW6xauXF1udrLLM5yZYgTJglnOEUDaPy RdPdU1/AAyFGkWoLB9MI+aI5qX1HRB/4aCmVwFDBzTYvqOP0OMfOrJo07fV5G3S00YaA LIb0drqWDMIOQWp4qFP115hi+ELTB5ivPyXMIaV++Ni33lW1G8e2qwgeyUmW8R0wglNF XJpW0CdKP7zKmreok1xK4c0CDI7AVM5By6c3uyAgU2KyddF0qk+djisHswIyuKL4G/uD xydyu1t9mDH1kwkYPANwpiaA67apB/N0VDzO5rMI2fI/i/uCnJXCWb1MVHsd9ME58s1B ea9A==
X-Gm-Message-State: AOAM533SRlCrLRkTWfGVgjYe/Y1N/nt2Fljx3aF3PGLDmAR0+OE+uReB iEcfJZLBfUVO+GV6T4i25ihkm6gPhhlJshYYueloXg==
X-Google-Smtp-Source: ABdhPJw5/UgY+Jga1yM0p6JleCeK6C7lgApRUyzFst5Bey2FWf5ERsBvAKBoSuDnCU1n6HmsYE6pSjEz5Z03GJ1r8rM=
X-Received: by 2002:a5d:43c4:: with SMTP id v4mr16385381wrr.426.1597675405797; Mon, 17 Aug 2020 07:43:25 -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> <CAHbrMsBPyrgbbjx0_-w2Ysky63edtw3kKEBu7DrgDCfP_-GBBw@mail.gmail.com> <CAH1iCioL1JrCHo2yuu-90dy4MpRfwUF9iaK-S=NdaXRtvyteXA@mail.gmail.com> <CAHbrMsD8e0mXER0-R7YmjR6GR6kP4rwdoL3uJcB83GPt+XgHcA@mail.gmail.com> <alpine.DEB.2.20.2008112319240.21650@grey.csi.cam.ac.uk> <CAHbrMsA3JyVR5PKGv9r99P9yoaFF5veskfqRnOMu1+V-61-02w@mail.gmail.com> <1CC367DE-4C2A-437C-9305-A57C072127D1@isc.org> <CAHbrMsDo0h=t1FpzwFW-=qdLesxoy0AKudJ7hPsWnR5W28_90Q@mail.gmail.com>
In-Reply-To: <CAHbrMsDo0h=t1FpzwFW-=qdLesxoy0AKudJ7hPsWnR5W28_90Q@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 17 Aug 2020 10:43:14 -0400
Message-ID: <CAHbrMsC0Kk7m=M+n9oWWjU8i_q9D_pMVnxJp03syQOJ3cOar6g@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>, Pieter Lexis <pieter.lexis@powerdns.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000ef99405ad13cbf8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DszVDtBXYVFKN5KL5tLCizXFutQ>
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: Mon, 17 Aug 2020 14:43:30 -0000

If anyone still wants changes to the -01 draft's text on Additional
section processing by the Authoritative server (
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-01#section-4.1),
please reply.  Otherwise, I'll assume that Mark and Tony's logic has been
convincing, and we'll leave this as-is.

Personally, I think that text, which encourages Additional section
processing and provides a hint about what's worth including, is sufficient,
and we should be able to define improved answering strategies in a future
draft if necessary.

On Tue, Aug 11, 2020 at 9:31 PM Ben Schwartz <bemasc@google.com> wrote:

>
>
> On Tue, Aug 11, 2020 at 9:16 PM Mark Andrews <marka@isc.org> wrote:
>
>>
>>
>> > On 12 Aug 2020, at 10:25, Ben Schwartz <bemasc=
>> 40google.com@dmarc.ietf.org> wrote:
>> >
>> > On Tue, Aug 11, 2020 at 6:18 PM Tony Finch <dot@dotat.at> wrote:
>> > Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
>> > ...
>> > > 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.
>> >
>> > I thought the target types were just A, AAAA, SVCB, so where does the
>> SOA
>> > come from?
>> >
>> > If one of the follow-up queries for those types returns NODATA, there
>> could be an SOA in the Authority section.  "all returned records" includes
>> all sections, so it would be copied into the Additional section (in this
>> procedure).
>>
>> The negative caching of NODATA/NXDOMAIN indication is tied directly the
>> QNAME, QTYPE and rcode.  In the Additional section there is such linkage.
>> See RFC 2308.
>>
>> If I have "example.net SVBC 0 www.example.net” and “example.net SOA …”
>> what exactly does the SOA record mean?
>> There is no records at www.example.net?  There is no SVBC record at
>> www.example.net?  There is no A or AAAA record at www.example.net? There
>> is no CNAME at www.example.net?
>
>
> It means "I completed this defined procedure so anything that's missing
> doesn't exist".  The recipient doesn't even need to look at the SOA RDATA;
> it's just acting as a flag.  The recipient _does_ need to know about the
> procedure, but it's essentially the same as the recursive resolver followup
> procedure in the next section.
>
>
>>   What if one can’t fit some of these RRsets but can fit a SOA?
>>
>
> The proposal text says "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."
>
>
>> What happens when you know there isn’t a SVBC, have a A RRset and know
>> nothing about AAAA?  Do you add the SOA or leave it out?  If you add it
>> then what does it imply?
>>
>
> I think support for AAAA is probably a prerequisite for implementing this
> (optional) procedure.
>
>
>> If one wants to have negative answers, included in the additional section
>> then I would suggest defining a EDNS option the returns <SOA Record sans
>> class and rdlen><target name><rcode><typelist-if-nodata> for unsigned zones
>
>
> That seems like a fine solution to me, though it certainly would need a
> separate draft.
>
>
>> and NSEC/NSEC3 negative data proofs for signed zones and require clients
>> to be DNSSEC aware.  RFC 2308, while it doesn’t state it, only adds SOA
>> records so non-DNSSEC clients/non-DNSSEC zones will get a cacheable
>> response.  There is enough information in the NSEC/NSEC3 proofs to maintain
>> a negative cache entries if all clients where DNSSEC aware.
>>
>
> FWIW, draft-ietf-svcb-https-01 already recommends this.
>
>
>> > On Tue, Aug 11, 2020 at 6:38 PM Tony Finch <dot@dotat.at> wrote:
>> > ....
>> >
>> > > It seems to me that returning a (downward) delegation could actually
>> be
>> > > useful.  So why not include that?
>> >
>> > Additional section processing does not normally include referrals.
>> >
>> > Do you know why not?  It seems like a logical thing to include, if you
>> predict that the resolver will be making a followup query for which you
>> have a delegation.
>>
>>
>> > That
>> > would be weird and new. I thought the point of the SVCB record was to
>> > appear to existing auth and recursive DNS servers as much as possible
>> like
>> > a bog standard RR type, i.e. just wire and presentation format and a bit
>> > of normal additional section processing.
>> >
>> > Is there a standard for "normal additional section processing"?  My
>> impression is that it is RR-type-dependent, so defining what should go
>> there is in the purview of this draft.
>> >
>> > Which is basically what the draft
>> > says now, though it unnecessarily respecifies additional section
>> > processing.
>> >
>> > Yes, the intent is to work well with "normal additional section
>> processing", but Pieter and Brian requested some behaviors or
>> clarifications in this thread, related to CNAME and SOA records, that are
>> either unclear or not supported with "normal additional section
>> processing".  Hence this proposal, which would leave us in the following
>> position:
>> > * Auths are not required to do any additional section processing
>> > * Auths SHOULD do some kind of additional section processing, details
>> unspecified
>> > * Auths MAY do this specific form of additional section processing,
>> which follows CNAME chains, enables negative caching, and (maybe) even
>> provides referrals when appropriate.
>> >
>> > Do you think this proposal would not actually work?  Or do you think
>> that it is simply too inconvenient to implement?
>> >
>> > I would also like to hear Pieter's perspective, since the proposal is
>> based on his request in this thread.
>> >
>> >
>> > Tony.
>> > --
>> > f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
>> > Mull of Kintyre to Ardnamurchan Point: Variable, mainly north or
>> northwest, 2
>> > to 4, occasionally 5 near the Mull of Kintyre and Tiree. Slight,
>> occasionally
>> > smooth in shelter, becoming slight or moderate later. Fog patches
>> developing.
>> > Moderate or good, occasionally very poor.
>> > _______________________________________________
>> > 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 <+61%202%209871%204742>              INTERNET:
>> marka@isc.org
>>
>>