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

And another point regarding DNS vs HTTP mechanisms: Is there any concerns
regarding clients with DoH/DoT stubs but that rely on getaddrinfo() from
the system for Classic DNS? Would HTTP be more palatable for those clients?
Then again, if a client has a full DoH/DoT implementation, maybe easier for
them to add a Classic DNS implementation than it would be for many
recursives to add an HTTPS server.

On Tue, Apr 28, 2020 at 10:59 AM Eric Orth <ericorth@google.com> wrote:

> 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
> tag.
>
> 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 <kondtir@gmail.com> wrote:
>
>> Are you planning to replace
>> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01
>> with draft-pp-add-resinfo ?
>>
>> -Tiru
>>
>> On Fri, 24 Apr 2020 at 22:16, Paul Hoffman <paul..hoffman@icann.org
>> <paul.hoffman@icann.org>> 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
>>> Add@ietf.org
>>> https://www.ietf.org/mailman/listinfo/add
>>>
>> --
>> Add mailing list
>> Add@ietf.org
>> https://www.ietf.org/mailman/listinfo/add
>>
>