Re: [Add] Drafts on upgrading stub-to-resolver communication to encrypted

Eric Orth <> Tue, 28 April 2020 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B2E63A1701 for <>; Tue, 28 Apr 2020 07:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qDAWZ9Sa-oBF for <>; Tue, 28 Apr 2020 07:59:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1DB43A16A9 for <>; Tue, 28 Apr 2020 07:59:15 -0700 (PDT)
Received: by with SMTP id x18so25004136wrq.2 for <>; Tue, 28 Apr 2020 07:59:15 -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 :cc; bh=WmNPZGnDm0SzHy3LOEe0KTpJGlHHcN2CimRnnMMvSrs=; b=Ew1rBMKvbEDDEj5/E55urHyXHUyZlqIEBbAskbJkyyFsvDFd0OsPv9Bg1w1bSAFwZw lAioGfpuoHxU3nnNJtKGiVJrBcxDh4z64m7es1a3FjMBDsWgue6qhhpzIO16C0C7ZDBN CDwGFzuar7HfXW+5CnAO6qaCWqtdNH8aJeGhXn08C7NzprPMU1DD0LvAIMM5mxIAG1Fn V6aERyaBcaKz6ZPmLuqbwyfDQlRFS5g79KAbiL7OgURQTYZmPstbU3+OLSxd70l9qU3c LmrYwthEVB8MHH/DWTjHH2or0NhQUw5pYlK+xBIalJs1xhb9TMVnC0IcX8DAkw82HHiz dpjQ==
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:cc; bh=WmNPZGnDm0SzHy3LOEe0KTpJGlHHcN2CimRnnMMvSrs=; b=uCXuW5ZdnGGhiUIXMDVJGhkB+z5XzHStQ0eLVDQ4EDOaQD/gZwSRx6WKkURtXF6B4s 3323r/7gifuy/pypLoxF+BFqRHYsCB8ZJbgx/E9pquVJGXs70EB7r8O6TVISjx/JBmv/ jtjdBlgh7uAfwBFZcEBCX7WC31dLaijfVgKoyNNU/KmkYjAMcQriSiEQq/LOBlOfI2jj AvtNaskdvaJgftg5XFeI2vG1hUaNouYg17gBT1hGp5utNsLp7VsfKiKYaY2vO4Pq4+v2 ObPXlkGuGfdEkk6qH7doT3B1eL4sdFulW8hrWP7FEvePbIKBleXKIbAYeREvyd5uVYgp M+Ow==
X-Gm-Message-State: AGi0PuY1RgJU1BPaAZJxxnL1WuqS35lyS0oRAxengsKS6ZyjLD25wHYl SqZXaiBl++skckUMR463CKltfEKVdRNasInfzF9QBps6C3g=
X-Google-Smtp-Source: APiQypLwTlCC6UTqNGod3p/lmZtVSemQzuu0ZglGVlQFdI3GczKe/R7KF63ssvQg+HVVHDdRQpQC+Rrj4hwTc8pLXZs=
X-Received: by 2002:adf:e58e:: with SMTP id l14mr32156839wrm.186.1588085953595; Tue, 28 Apr 2020 07:59:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Tue, 28 Apr 2020 10:59:02 -0400
Message-ID: <>
To: ADD Mailing list <>
Cc: Paul Hoffman <>
Content-Type: multipart/alternative; boundary="000000000000237ab805a45b13bc"
Archived-At: <>
Subject: Re: [Add] Drafts on upgrading stub-to-resolver communication to encrypted
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: Tue, 28 Apr 2020 14:59:28 -0000

I generally support both documents and would support ADD adoption.

Re draft-pp-add-stub-upgrade: I do worry that it goes a little bit too far
into "policy" in laying out a specific algorithm, even if it's full of
options to allow clients to choose their own behavior.  Might be better if
framed more explicitly as a "descriptive example" rather than the
prescriptive way to implement it.  But I find the draft overall helpful
just for clearly laying out both the opportunistic DoT and the DoH resinfo

Re draft-pp-add-resinfo: Definitely think this is the best overall draft we
have for the common problem of retrieving resolver information.  I'm
personally conflicted on the HTTP-based mechanism.  Others have made some
solid arguments against it already in this thread, but I would be sad to
lose our best option for a secure mechanism.  It's correct that the DNS IP
address typically comes from insecure DHCP, but in many cases that is only
exposed on the limited local network or maybe the IP was set on the machine
rather than using DHCP, so the resinfo messages could sometimes (often?)
have a much bigger exposure.  Then again, since the internet seems not
quite ready for CAs to widely give certs for IP addresses, maybe it would
be best to remove it from this draft and create a new draft in the future
once the mechanism becomes more viable.

On Tue, Apr 28, 2020 at 10:19 AM tirumal reddy <> wrote:

> Are you planning to replace
> with
> draft-pp-add-resinfo ?
> -Tiru
> On Fri, 24 Apr 2020 at 22:16, Paul Hoffman <
> <>> wrote:
>> Greetings again. We have just published two drafts,
>> draft-pp-add-stub-upgrade and draft-pp-add-resinfo, to address the easier
>> problem that this WG wanted to tackle, namely how a stub can upgrade from
>> plain DNS to encrypted DNS for the resolver it is currently using. The
>> method in draft-pp-add-stub-upgrade is quite simple, but it includes all of
>> the variables that we have heard in the discussion over the last year. The
>> format in draft-pp-add-resinfo is the minimum needed for stub upgrade, but
>> will also possibly be useful for the more difficult discovery protocols
>> being discussed in the WG.
>> Please let us know if you find these documents useful for the discussion
>> of direct upgrade instead of discovery. Also, please let us know if we have
>> missed any salient points. If so, we could ask the chairs to make these
>> into WG documents.
>> --Paul Hoffman and Puneet Sood
>> Name:           draft-pp-add-stub-upgrade
>> Revision:       00
>> Title:          Upgrading Communication from Stub Resolvers to DoT or DoH
>> Document date:  2020-04-24
>> Group:          Individual Submission
>> Pages:          7
>> Abstract:
>>   This document describes methods for a DNS stub resolver to upgrade
>>   its communications with a known recursive resolver to include
>>   encrytion using DoT or DoH.  This protocol is designed for the
>>   scenario where the stub resolver already has the IP address of the
>>   recursive resolver.
>>   Other protocols under develpment address scenarios where the stub
>>   resolver wants to discover recursive resolvers that use DoT or DoH.
>>   This document does not cover such discovery.
>> Name:           draft-pp-add-resinfo
>> Revision:       00
>> Title:          DNS Resolver Information Self-publication
>> Document date:  2020-04-24
>> Group:          Individual Submission
>> Pages:          9
>> Abstract:
>>   This document describes methods for DNS resolvers to self-publish
>>   information about themselves.  The information is returned as a JSON
>>   object.  The names in this object are defined in an IANA registry
>>   that allows for light-weight registration.  Applications and
>>   operating systems can use the methods defined here to get the
>>   information from resolvers in order to make choices about how to send
>>   future queries to those resolvers.
>> --
>> Add mailing list
> --
> Add mailing list