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

Ben Schwartz <> Fri, 24 April 2020 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6D233A1155 for <>; Fri, 24 Apr 2020 11:09:17 -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 H1ukafuOGQ6c for <>; Fri, 24 Apr 2020 11:09:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83DCB3A1151 for <>; Fri, 24 Apr 2020 11:09:15 -0700 (PDT)
Received: by with SMTP id j2so12023762wrs.9 for <>; Fri, 24 Apr 2020 11:09: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=EpTGwIqDLZdt9DjcPKbmoTmV93rJUfVsG2+cTvzb57s=; b=K2s3ahSoEgAWVHoTq9dHtZCEtvsS7KOhiXIkkFwSmk2Fp8YR31hAOZHHRmWk+xK81o ya8ApmQ6j6D4jdi9bY651DYn/ss/JyG0ieDUey+yvdFq1F0bDx6BSt72qigeVphUsay+ zFrrGpsF6FI/QxUhQfoZh8q3yZqJ+S9v3b3CfY9LEm3Fmcf1I4jxrHorH+WiCJZHKOrH W4OdqOg45luN7FOOn0T7gjUH+ZS75iIBz+n0EiY7pJ4nQcQgcVKa/MnkbMTG7GAvC62s i1ZN+KPqXzo3gdNgy/vMV97dMMHT60NNofyaXct3a5ZN5W47Dotv2658aYGLxfEi79vy 40iA==
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=EpTGwIqDLZdt9DjcPKbmoTmV93rJUfVsG2+cTvzb57s=; b=U2xOVHp6boP4D98G5BktpD/IDGzEgaXaLxgVDIq4IZYC92l59VwXA3Y27IVSL2QqOs 5KEtNzgDG4h+oUJpFkbRhleEshpjPsxb54h1pFaOgUrs1pcKY7lz1KV6uTpKG0RitAzJ QGh6XYrifON2z6eO9qEVMCe+zRL3ZTaNCcT5MGWQCD3ZmmTS5DQ6oBCqUXgyorYS5kaw j37nIl3z/c3L2JYUnepBT7xqgtqT2mwfc/ebnLIfDjT9WunZ+DKH260AyhKwdt81QjCl N2r9cRDGLEZ7IeSwdTDMu6kWKe4djPCbRUc/0KSjwlU2Pd9v/qOfWSx8MxnJVwyU9j44 5TDQ==
X-Gm-Message-State: AGi0PuYTgC9plc9oLj3fQpGiQqfCRWPCXSE4wTq6rY2W7E0vHNgtxMSu 2YBwGatN90z96wJ+JT9dnDfERTWdZzctC0zhq9L3c9jR
X-Google-Smtp-Source: APiQypL1lBV8S9FiJDAzufmaeY6sxiQ3gZLO8jmKZvjOa+LCBDhRcVKv+5Lxcz0TPy/ECtESjnpGnGn+ZKsOwr9m0Xk=
X-Received: by 2002:adf:cd12:: with SMTP id w18mr12642274wrm.177.1587751753594; Fri, 24 Apr 2020 11:09:13 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Fri, 24 Apr 2020 14:09:01 -0400
Message-ID: <>
To: Paul Hoffman <>
Cc: ADD Mailing list <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000004cd63b05a40d4339"
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: Fri, 24 Apr 2020 18:09:18 -0000

Thanks for the updated drafts.  I think RESINFO is the most promising path
for resolver upgrade, and I'd like to see it implemented.

The one major change I suggest is to remove the entire HTTPS mechanism from
the RESINFO draft.  This mechanism creates a great deal of complexity,
doesn't follow good practices for HTTPS, and doesn't obviously enable any
additional use cases.  Having multiple competing mechanisms also makes
interoperability less likely.

If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism could
always be added in a later draft.

On Fri, Apr 24, 2020 at 12:46 PM Paul Hoffman <>

> 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