IETF Logo Mail Archive

Re: [DNSOP] unsolicited HTTPSSVC responses

Paul Vixie <paul@redbarn.org> Wed, 27 May 2020 00:00 UTC

Return-Path: <paul@redbarn.org>
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 C34783A0BED for <dnsop@ietfa.amsl.com>; Tue, 26 May 2020 17:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 plWxjMkOM-3K for <dnsop@ietfa.amsl.com>; Tue, 26 May 2020 17:00:21 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131133A0BDA for <dnsop@ietf.org>; Tue, 26 May 2020 17:00:21 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C18BCB074A; Wed, 27 May 2020 00:00:19 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Ben Schwartz <bemasc@google.com>
Cc: dnsop <dnsop@ietf.org>, Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Date: Wed, 27 May 2020 00:00:19 +0000
Message-ID: <1687531.9LHNgfQPbD@linux-9daj>
Organization: none
In-Reply-To: <CAHbrMsAGJ+32C2fyzwZU3iPUg3naX4K1OFX8O+7ocwGp4S=yPg@mail.gmail.com>
References: <CAMOjQcHAKC6ge2te8eqPz3JFmmLrpBoTSt2yKKxFXHpQEyjLqg@mail.gmail.com> <1852098.ajqZCkXiOD@linux-9daj> <CAHbrMsAGJ+32C2fyzwZU3iPUg3naX4K1OFX8O+7ocwGp4S=yPg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HPG4q1tXLcrfe7c8vLNLBMMM2Ok>
Subject: Re: [DNSOP] unsolicited HTTPSSVC responses
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, 27 May 2020 00:00:23 -0000

On Tuesday, 26 May 2020 23:56:30 UTC Ben Schwartz wrote:
> On Tue, May 26, 2020 at 7:06 PM Paul Vixie <paul@redbarn.org> wrote:
> ...
> 
> > and the responder knows
> > the additional data (that is, it should not make extra queries to find it
> > just
> > for additional data reasons.)
> 
> The current text does not have this caveat: it recommends that the
> recursive perform those extra queries before replying, because they will
> otherwise have to be performed by the client at higher cost.

i think that's overly prescriptive. the client may already have the data in 
private cache from its prior work, or it may be striping its DNS queries 
across several full resolvers and therefore able to get the data faster if you 
don't provide it than if you take the time to fetch it before you answer.

> However, it
> also says "recursive resolvers MAY ... produce a reply that omits some of
> the associated RRSets ... when responding before fully chasing dependencies
> would improve performance", so a compliant recursive resolver could
> certainly implement the behavior you're describing.

nice. that's all the rope i'd ask for.

-- 
Paul

v2.23.0 | Report a Bug | By Email