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

Ben Schwartz <bemasc@google.com> Wed, 12 August 2020 01:31 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 9B70B3A0E25 for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 18:31: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 osFO3UEYB-On for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 18:31:14 -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 55A373A0CE8 for <dnsop@ietf.org>; Tue, 11 Aug 2020 18:31:14 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id h4so955262ioe.5 for <dnsop@ietf.org>; Tue, 11 Aug 2020 18:31:14 -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=gPJ830GZ6u8lFgKaxcXkmjsCGyz52OfUSgJ/nc91lt4=; b=RCU/I2pWboRup7KjkmWJ6JeyFJJ8jSW5OBAsFjpY8x7333a9ybD6PdmM4S+ADR1p8o /fTTq4ZHu3AsBHGisK+1LcHv8S1/jQ8fyRgBFVnjWNYCbsYy4T7a5fAcFcgKkxJkQ3rh /HtwfCWhuqKkGUwmky5skBXeiKsx69yMb9xh31yTSLjHTPZSYl4v5xwxb2xWRxE2UnfT zx8l3K5rWnL87oQ9kTWirhdCJv6NM1h5Ul1Hk684WBLvq/Q7j0GEYqi0Wn2/EFiepBdr Zefuyz2y5xlUdhEgy/mKV2OnhXC6u9NJAXZ+iZmpkw3f7DpQBCIsYp/I7iek6FdOJdfr NTHg==
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=gPJ830GZ6u8lFgKaxcXkmjsCGyz52OfUSgJ/nc91lt4=; b=E5BO8KDcJkg2bStSf7EPTX05CfXDaB94OksTODcEgUsVlywnnXRLBTu1iy/Lju0Zpq 0foRT/dp5fRSkjecqFmg6nwBNNzNhR8MKVbYf7CCTvOSPuCHhZ/GaagFcTdL3o8FMyGy YIXF4otO7r0134zX8KMk/hLAYsfWjbc9DOJyhQhxGeBGJhuP/bg0I8XjWgIbpf88WNUx k8hiKsscVualHpRpUgfqUadWg9NHz2+rN5Qzbyd+65FMixVWpYyyvOIJQ5qLVHmkIvUL DFEPI4SY//pBEpp9X9pWA4K0H2ZRYjjkfYH+bP9zvQertNBpwaSAUmxcRsx8N/NfPvqh tDag==
X-Gm-Message-State: AOAM530aKWAkM1R8gnpE5wbJTA+RzgGGJpmkXMZMr5t8gYqXHRZu482R m8CE3SemfnQeXpVVfrc2+pCPDJd11qSA3G7tyffChQ==
X-Google-Smtp-Source: ABdhPJwAedgRPAhIvjOU6niQG8WP78wl7yJdYhDDFXR7PG6k/XIR5UKsh8lGkvxCfWSNsC9MHQZvl8DoAdodDuJTSco=
X-Received: by 2002:a05:6638:305:: with SMTP id w5mr30253662jap.10.1597195873172; Tue, 11 Aug 2020 18:31:13 -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>
In-Reply-To: <1CC367DE-4C2A-437C-9305-A57C072127D1@isc.org>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 11 Aug 2020 21:31:01 -0400
Message-ID: <CAHbrMsDo0h=t1FpzwFW-=qdLesxoy0AKudJ7hPsWnR5W28_90Q@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="000000000000b0300f05aca424d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1Dgeir5wwxSM5XGeD8ojccFXWus>
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, 12 Aug 2020 01:31:17 -0000

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