Re: [dns-privacy] Restarting the discussion of draft-ietf-dprive-unilateral-probing

Puneet Sood <> Tue, 30 August 2022 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B00EBC157B44 for <>; Tue, 30 Aug 2022 14:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.606
X-Spam-Status: No, score=-17.606 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EDWFYsylLI5Y for <>; Tue, 30 Aug 2022 14:10:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::112a]) (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 (Postfix) with ESMTPS id 25E6CC152597 for <>; Tue, 30 Aug 2022 14:10:10 -0700 (PDT)
Received: by with SMTP id 00721157ae682-3378303138bso290505957b3.9 for <>; Tue, 30 Aug 2022 14:10:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=ue38EEOX/nDRI2nkfcvCUerfuF0VzYQn02MRvENOqbQ=; b=PJxj5V6Ofs+mzOCQXpmySlUUlgOK75MA87/31rrDeB7XaX04gm/hJYRhLJTfRlyV6r atusZoe+nQjy4B1fhVfTWTN34G2gYJr+Zn+/9Wy8u7/PXcQtvmsov6WIuhbV0OLT/pGa F9ykog9MAkoJAcDViq3zFO17FoJsF336cjl051hk4ZpdX/D/NqGU50y4Ox6kmtRKpbpD L964hHjSQk8Au8FmhThwNhevdDCr2qyxwH6tSY6PJW4PjHrvHWoYpuaiCuXRhf8+9lFa ZPeSbGp34kIUkrDWZnFlxwfj5o9rsF09bj6JibdtXNadL8FHB3a0x2FG2UjBCzmpjOPi f3PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=ue38EEOX/nDRI2nkfcvCUerfuF0VzYQn02MRvENOqbQ=; b=6/YbeUmryLkDFOolpiBfdNJ2M1w/5wv0LMZCuRQRyZEGD6D3xWweRXHiNKKBuKSudX /MlXoXT35yDzLw0elJ1kx8RItSbcykFfP6Vv5UqWiZpqK8xmiAsV7qNUfwkbljp4oWEz 4+ePgL7bWarPDUTDZvUOsBjgaIh+YWiPmWI+jFaxHOrLaB0E2CHLr6XzBrVqeCVnd+7I A1SFvIUPaHw2lBi8mR9ljb3MRsdBn5fGFOMu1RggwfWxmolIj+N4zbNAOmNegktWYvNg y/KgFFOaSvIGhdNpB0s+6TVqosBaSZCWSqyBjurL6MM4nDv9/McX2/ve7GTJ4vs3MBMZ +ppg==
X-Gm-Message-State: ACgBeo0NvvJK8Jhq9pwt3P5mGJnBgH1OHzmxBimgtZkZEhe1H5ipP9bd V8fWCtwAGyltCkdXZO7Aj5SEN/D+/mtnJma3kdw8O9lIANRGDILG
X-Google-Smtp-Source: AA6agR67PW5xPTTkvAbvMgkKQ/w3xRRDI1/qRqKWpOyGPbZ0knJhieqSBtS4GlGTxVX8sRAVRFbLy2zR2CkA8+TdEKU=
X-Received: by 2002:a81:1187:0:b0:340:8567:fbed with SMTP id 129-20020a811187000000b003408567fbedmr15640478ywr.54.1661893809075; Tue, 30 Aug 2022 14:10:09 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Tue, 30 Aug 2022 23:09:57 +0200
Message-ID: <>
To: Paul Hoffman <>
Cc: DNS Privacy Working Group <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dns-privacy] Restarting the discussion of draft-ietf-dprive-unilateral-probing
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Aug 2022 21:10:13 -0000

Hi Paul,

I reviewed the document before my vacation but did not get around to
sending them earlier. Sending comments now. Will send minor comments

Suggest DoET or DoQTH as abbreviations for encrypted transports. Using
DoET in my comments below for conciseness.

Comment on organization: The document goes into a lot of detail on the
per-nameserver state to track and the actions to take on various
events (sections 4.4, 4.6.1-4.6.5). While this is useful guidance for
an implementor, the details will vary across implementations and are
not of interest to readers interested in the protocol at a higher
level. Suggest moving these implementation dsections *after* the
higher level protocol details in section 4.

* Section 4.1 High-level overview (for recursive resolver)
The description here is in the context of a single NS IP. It needs to
be broadened to the available NS IP set for the query/zone. Generally
any NS IP with working encryption should be preferred over Do53.

In addition a conservative resolver may want to distribute queries
across both Do53 and DoET to avoid sending too many queries over DoET.

Also consider the possibility that the resolver is sending queries
from multiple source IPs (applies to large scale operators). This
affects the state tracking variables in section 4.4.

* Section 4.6.6 Encrypted Transport Failures

On failure should check other NS IPs for the same zone instead of
going to Do53 on same IP.

* Section  Avoid EDNS Client Subnet
The recommendation to avoid ECS seems out of place in this document.
In practice GPDNS and possibly other DNS resolvers already send ECS
over plaintext. This decision would be orthogonal to unilateral

* Section 4.6.10 Resource Exhaustion
Suggestion: Only initiate encrypted probing/connections after a
minimum number of queries to a server. Not enough value to
probe/maintain DoET state for a server which gets a small number of
queries a day. Different operators could have different policies for


On Tue, Jul 12, 2022 at 8:46 PM Paul Hoffman <> wrote:
> Greetings again, and thank you to everyone who contributed comments on the -00 draft. As you can see, we published the -01 draft yesterday, and would love to get some discussion happening on the list to help focus the discussion at IETF 114. (I say "we" because dkg and Joey were kind enough to add me as a co-author!)
> As you can see from the diffs, there are a lot of changes in -01. The most significant technical change is the addition of a new field, E-last-response, the timestamp of the most recent response received on an established connection. This makes the checks for persistence more accurate.
> There are still some issues to be resolved in the draft; they are marked with "FIXME". In specific:
> - Should Extended DNS Errors (EDEs) be passed on to clients that have requested them? Is this different between encrypted and unencrypted transport?
> - Should resumption tickets be used when encrypted transport fails?
> - Should we further refine (past what is already in the document) what to do when encrypted transport fails? A few examples are given.
> We also have a few open issues tracked in our GitLab repo at <>.
> Please review any/all of the above, and if you have a comment, please open a new thread here on the mailing list. We can also take new issues here or in the tracker, and we know that all issues should be resolved here on the list.
> DPRIVE has a short meeting at IETF 114 (we're in a slot with the ADD WG, and they have three draft that about to go to IESG ballot), but it would be great if we can spend it working on issues instead of the typical slideware presentation just listing the issues.
> --Paul Hoffman
> _______________________________________________
> dns-privacy mailing list