IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Fri, 24 April 2020 16:45 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C863A0F69 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 09:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfwpN3tVUft4 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 09:45:41 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC433A0F47 for <add@ietf.org>; Fri, 24 Apr 2020 09:45:32 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 03OGjVvM025384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <add@ietf.org>; Fri, 24 Apr 2020 16:45:31 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 09:45:29 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Fri, 24 Apr 2020 09:45:29 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: ADD Mailing list <add@ietf.org>
Thread-Topic: Drafts on upgrading stub-to-resolver communication to encrypted
Thread-Index: AQHWGlfDK8eYheQJ4EC4wbCFDoXkXg==
Date: Fri, 24 Apr 2020 16:45:29 +0000
Message-ID: <E1091705-3E44-4284-AFE3-824052FBF5C2@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_038EFDFC-19CE-4149-9D00-6C2A210D8231"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-24_08:2020-04-24, 2020-04-24 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/Tc8tDIDWRem55YaIT4ARtBQQCs4>
Subject: [Add] Drafts on upgrading stub-to-resolver communication to encrypted
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 16:45:50 -0000

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

https://datatracker.ietf.org/doc/draft-pp-add-stub-upgrade/

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.


https://datatracker.ietf.org/doc/draft-pp-add-resinfo/

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.

v2.23.0 | Report a Bug | By Email