Re: [Add] New draft: draft-pauly-add-resolver-discovery

"Chris Box (BT)" <> Fri, 29 May 2020 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6C1A3A0DAD for <>; Fri, 29 May 2020 09:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 BoF6BHK456bP for <>; Fri, 29 May 2020 09:43:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C22E33A0DA8 for <>; Fri, 29 May 2020 09:43:14 -0700 (PDT)
Received: by with SMTP id p15so1344330qvr.9 for <>; Fri, 29 May 2020 09:43:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+/KUfZuNzDkSOUHYCE4ZYrvKCf6DnUoDK33t5dEQRtE=; b=sU5SfJHgA/a7DQUgjYpu0Ww/1G2s/sfm0QWbolkVN1geA0msAcs+mFn7Tj3XQtA/Id gMqZo/PF+5XhNxG4YxIiRr8v20IuNbSkr2CyHqHW3aZhepdWTg+4Pg9lg2gTTOW4iSO2 OK4nl5eHJ2kyXauM4bkkVwPpkM69TcK9DeKZdq2TjdmzPCXT95r6xDwp2a5f8CIfB9fO Gj7bTpViuTwW5O1du4BWRA0MYLJh9UXPykPMGGtdSoAJcjX7kqNXBntiD31N2vcYdjNg W39v+BpDNQ77vrxxIusbyw2X1X5eQCN4H4AJtS4yvAeRygtgZNIlus6fZLqXN443qE92 ZzVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+/KUfZuNzDkSOUHYCE4ZYrvKCf6DnUoDK33t5dEQRtE=; b=NfUSviaTYMdnTcLcU5g/5I94sSIZb8ka3+KBODJqWI8gWa0dhvzE+IFJU4Jx93gs4p qWNGQt6SuyaGl0OP058FfaRTosvGpek4DZoD7eP41w9ygvGdFvqpx3CP9DRdj9h4ysi5 YTGXUNoPNieUmKL3Yc046ImvQvtMpHI961vuBHkl9J5VvxkSP553kp1eFN3GjCDHjYac qqTRJNiInVHPw0o9Fna+VV4WAO4BN5h82f0/5yDPlukZH8mXuj0AvrvpFYla4zc2wC3S kktcsZW6bQ1Pl45x4Br+53Bu5zftPp8/k8sHhuChNaNVcpH8U/XcMj2NKLvJbnADFzfL CU2g==
X-Gm-Message-State: AOAM531Q8rhvP0ypkmehO+ZI5CPvDXMVlXNKaOeQY6yKnFTF/idVO3bR C6Yxt2jxoKLg71HoCC+04NRvm6lX7RnQI0VyNlvuFoMW
X-Google-Smtp-Source: ABdhPJxzGwo0zw55fS0eX5edTv4OQXW+bA3v4AnZeerN82UYBLEqYEmuJeWb5A65yViDgJEq/jLmiOOlCq1Z4gfJERw=
X-Received: by 2002:a0c:b45b:: with SMTP id e27mr3571643qvf.85.1590770593496; Fri, 29 May 2020 09:43:13 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Chris Box (BT)" <>
Date: Fri, 29 May 2020 17:43:02 +0100
Message-ID: <>
To: ADD Mailing list <>
Content-Type: multipart/alternative; boundary="000000000000250aba05a6cc2457"
Archived-At: <>
Subject: Re: [Add] New draft: draft-pauly-add-resolver-discovery
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 May 2020 16:43:17 -0000

Thanks to the authors for this new draft. Having now read it, I'd like to
raise a few points for discussion.

*Section 3 Designated Resolvers*
This states

   Note that clients MUST NOT accept designations for effective top-
   level domains (eTLDs), such as ".com".
This can be hard to define, and I know there's a history of problems in
this space, so it feels like it requires a normative reference.
Would this be the best one?
If so, should it be renamed from "eTLDs" to "Public Suffixes"?

*3.2 Additional Designation with PvD JSON*
   Names that are listed in the "dnsZones" key in the JSON dictionary
   indicate other names that designate the resolver.  For each of those
   domains, clients SHOULD issue an SVCB query to the DoH resolver.

I would prefer to have some guidance in here about the number of dnsZones
that are considered reasonable to list (10? 20? 50?). And also clarify that
clients can form their own view on which of these should result in a SVCB

Perhaps the client could use the knowledge that SVCB answers might be
cached by its own OS and deal with those first, before then issuing
external queries for up to "n" zones that it thinks are the most likely to
be required? And perhaps we could guide the creator of the PvD that they
should return dnsZones ordered by likely popularity, from most to least?

*3.3 Mutual Confirmation with PvD JSON*
   Clients MUST validate the resolver designation by checking a resource
   hosted by the name indicated in "trustedNames".  The client first
   issues an HTTP GET request by appending "/.well-known/pvd" to the
   trusted name, using the "https" scheme.

If a Pvd claims to be designated for 10 dnsZones, and adds that all 10 are
also trustedZones, what should the client do? It sounds like it should send
10 SVCB queries, but if they are not validly signed, it should then follow
up with 10 GETs (each of which may in turn need A/AAAA queries). Or do you
envisage a different algorithm?

*References to whitelisting*
Section 6.3: Clients can also choose to only whitelist DoH servers that are
associated with many names.
Section 8: Such risk can be mitigated by further restricting the list of
resolvers that are whitelisted for direct use based on client policy.

It feels odd that whitelisting is mentioned in this draft but there is no
narrative on how it might work, and what it would need to take into
consideration. Do you intend to cover this in the separate document that
updates client behaviour?


On Thu, 21 May 2020 at 00:04, Tommy Pauly <>

> Hello ADD,
> We’ve just posted a draft of Adaptive DNS Privacy [1] that’s scoped down
> to talk about resolver discovery and designation mechanisms, both on local
> networks and over the wider Internet. This draft is targeted at the focus
> of the ADD group.
> This covers:
> - What it means to designate an encrypted resolver
> - How to discover resolvers using SVCB/HTTPSSVC records
> - How to validate designation either by validating DNSSEC on these
> records, or by performing validation with an HTTPS server
> - How to advertise a resolver on the local network
> - How to discover a “companion” DoH server to a directly known resolver
> Thanks to Tommy Jensen for his additional input on some of the
> local/direct resolver bootstrapping.
> We’ll be publishing other documents that update the behavior for client
> algorithms and the use of Oblivious DoH, but we wanted to present this
> portion individually as the group discusses how best to discover resolvers,
> etc.
> Best,
> Tommy
> [1] Previous, broader version, here:
> --
> Add mailing list