Re: [dns-privacy] [art] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12
Rob Sayre <sayrer@gmail.com> Fri, 08 September 2023 02:38 UTC
Return-Path: <sayrer@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F89FC151081; Thu, 7 Sep 2023 19:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw7UCKZKqQPp; Thu, 7 Sep 2023 19:38:15 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6678C151077; Thu, 7 Sep 2023 19:38:15 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-99c3c8adb27so192143666b.1; Thu, 07 Sep 2023 19:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694140693; x=1694745493; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ekeqrhSxll+JuWvW6IWj+at8t9BjZ23NXd+i66UR5Sw=; b=NTIpxnpA1F38rp/DpI30eawsGNX5W+RcQzzlztW5GZNpCl4uRPfpbDhiJNyRfCUNHb E7HqgswoqxMGdi4vX+T0fLecNmAXy8BOejJ5NXVic5lokFY3rdcYMc0shsGKfQFWyzL2 HhKHCF9ufEDyuw+x5GU+JPjjmnFgVfmibDYyS2nvYDgRLA87b1n1hozhV/3CQHYCE6wI D9d4VypAgs5PBrpW/ck1b/Ln445TYtB075CWYVJacg/0QOIUxWKg0XboFzC9pcCUbhlr z9/qPe9+fT5k0iQ90eO8767k8IdtNU8LLRk8C6Ywjzy1wAMdp411KALjOVt8oZt0Spy8 vDHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694140693; x=1694745493; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ekeqrhSxll+JuWvW6IWj+at8t9BjZ23NXd+i66UR5Sw=; b=oWtxK9E4oVC/KCTpdBaB3RMYSysLoaBo+sL0Av8j/AanmTWFuIHSKiyaD7XRFhrny1 lGEGmjr4jh7+xOXjSBXvJa0lV93fqNLz24vaDkhyhMT6TR9r2qkX2+kfB3D4BKXesDlE CUmj8T7OXoaiJ+ewn80pJd7aRpS2/at9xAvIfC3edg4oarwM75fMdGvzjBLQyR3ntlib 02MxUlMRIMda4qDQ68r0kEQF5+xIFuy6ocscWq6+6BcKZeElqHTtJOLGd8bjjb6m/A67 wUHIrNo+K8hnpB9Auzy6AY//FZBqItmD2hzqzAODZAO0Zdc3EX9xmuPYnyZiPIjrpxXd M+RQ==
X-Gm-Message-State: AOJu0Yw8UZ0xyz2vLit3JJOY+Yzc9nCj+VvhbYATSW30GVZr7Cbtirlg CC/WrvYbfzz1AHTGwqSdex4VfX4eBfQIfG5CkeXDca0yQ1X2kw==
X-Google-Smtp-Source: AGHT+IGm7NeoHRPWaoXTQwl08wkmxBCyrzOvqupDBFg4RALvdfYgayEvApwAXHPGPzlVfP/18M2irMUFsapj4qR2Ts4=
X-Received: by 2002:a17:907:a05a:b0:994:1eb4:6898 with SMTP id gz26-20020a170907a05a00b009941eb46898mr752418ejc.9.1694140693073; Thu, 07 Sep 2023 19:38:13 -0700 (PDT)
MIME-Version: 1.0
References: <169409620800.15857.16759296263081674061@ietfa.amsl.com> <EC3FE6BF-3296-404F-A888-F2D3D0573FE4@icann.org> <932d01e4-1bc1-46b9-bd8b-76241b42461c@app.fastmail.com> <F7A25965-3570-4516-9D1B-74D0EA93DC4F@icann.org>
In-Reply-To: <F7A25965-3570-4516-9D1B-74D0EA93DC4F@icann.org>
From: Rob Sayre <sayrer@gmail.com>
Date: Thu, 07 Sep 2023 19:38:01 -0700
Message-ID: <CAChr6Sydrhs9i+WnzA9gBOuvGCE7_5ndNEJEmUTZLKxU6e9YrQ@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Bron Gondwana <brong@fastmailteam.com>, "art@ietf.org" <art@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "draft-ietf-dprive-unilateral-probing.all@ietf.org" <draft-ietf-dprive-unilateral-probing.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035d4320604cfdeb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/FxbbHw-KGL1kU6CABlDOhhrN1WQ>
Subject: Re: [dns-privacy] [art] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Sep 2023 02:38:16 -0000
On Thu, Sep 7, 2023 at 7:15 PM Paul Hoffman <paul.hoffman@icann.org> wrote: > On Sep 7, 2023, at 6:58 PM, Bron Gondwana <brong@fastmailteam.com> wrote: > >> Are you proposing a shorter value for "damping", or a note saying "1 > day is just the suggested value, you might choose a shorter one if you > want"? Or something else? > > > > I'm suggesting a backoff algorithm which isn't "single failure gives you > N hours of no retry" - particularly, if you have an existing encrypted > connection and it has a fault, my reading was that you don't retry at all > to form an encrypted connection, even when talking to somewhere that has > previously succeeded. I agree you don't want to try more than once per day > against a server that's never supported encryption, but if you have had > consistent success encrypting to a server, then a single failure, you don't > want to be treating that one the same! It's definitely worth retrying > faster than a full day later. > > This sounds like you want a smaller value than 1 day for `damping` then. > Because those parameters are only suggested defaults, a resolver operator > like you could simply change the 1 day to maybe 1 hour, with the risk of > slowing down resolution to that one nameserver. > I think you might want to rephrase this part. It seems like you really mean retries asymptotically approaching a 1 day timeout. What I've found works is exponential backoff that doesn't get too pessimistic, and also contains some amount of uncertain time intervals. It seems very dumb at first. But, if one piece breaks that may have nothing to do with DNS, you will get a stampede. Introducing a little bit of uncertainty can help. thanks, Rob
- [dns-privacy] Artart last call review of draft-ie… Bron Gondwana via Datatracker
- Re: [dns-privacy] [Ext] Artart last call review o… Paul Hoffman
- Re: [dns-privacy] [art] [Ext] Artart last call re… Bron Gondwana
- Re: [dns-privacy] [art] [Ext] Artart last call re… Paul Hoffman
- Re: [dns-privacy] [art] [Ext] Artart last call re… Rob Sayre
- Re: [dns-privacy] [art] [Ext] Artart last call re… Daniel Kahn Gillmor
- Re: [dns-privacy] [art] [Ext] Artart last call re… Rob Sayre