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

[Ben Schwartz <[e-mail]>]

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 <[e-mail]>
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
>
> 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.
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>