Re: [Add] Comparative DoH Discovery DNS RR Types

[Daniel Migault <[e-mail]>]

I agree that new RRtypes can be added but I am not convinced we need new
ones for the discovery. What is unclear to me is the use of  HTTPS as
opposed to SVCB for the DNS optionally over HTTP and most of the time over
TLS. I have the feeling that alpn could be used to determine HTTP.

That said RRtype are one aspect but I believe that we should also
agree/discuss what we expect from the discovery. Here are my thoughts on
what the discovery should achieve:

   REQ 1: DRDP MUST enable a DNS client to discover the available
   resolving services with their associated characteristics in order to
   proceed to a selection process.  The selection process takes
   resolving services identities and associated parameters and proceeds
   to the selection.
   Any sort of resolving service selection is outside the scope of DRDP.

   REQ 2: While the discovery process is triggered by the DNS client, a
   third party MUST be able to provide necessary input information so a
   resolving service discovery process can be triggered within a
   specific context.
   Provisioning protocols to provide this information is not as per say
   in scope of DRDP.  DRDP defines the format of the format for such
   input as well as a set of such inputs.

   REQ 3: Any information used in DRDP MUST be authenticated by its
   owner.  In particular, the characteristics associated to the
   resolving service MUST be certified by the resolving service operator
   / owner and MUST be associated a validity period.  In addition, a
   third party providing a set of inputs MUST authenticate that set.

   REQ 4: Information associated to the resolving services is intended
   to enable the selection process that is assumed to match the end user
   or application policy.  The selection process is out of scope of
   DRDP.  Information may carry some characteristics of a resolving
   service or hints that will help the selection.  In particular an
   operator of multiple resolving service MUST be able to associate a
   preference to the proposed resolving services.  To ease automation of
   the selection as well as to make multiple applications benefit from
   DRDP the information MUST be carried over a standardized format.


   REQ 5: DRDP MUST be designed to be used indifferently by a DNS client
   using any DNS transport protocol (Do53, DoT, DoH, ...).  However,
   DRDP SHOULD be able to restrict the information retrieved to a
   certain type of resolving service, i.e. Do53, DoT, DoH.

   REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS
   client or infrastructure and legacy client SHOULD be able to
   incrementally include DRDP.


[1] https://datatracker.ietf.org/doc/draft-mglt-add-rdp/

Yours,
Daniel

On Mon, Jun 29, 2020 at 7:58 PM Michael Richardson <[e-mail]> wrote:

>
> Paul Vixie <[e-mail]> wrote:
>     >> Just noting far we have a variety of suggestions on CNAME, URI,
> TXT, RESINFO
>     >> and HTTPSSVC (though I don’t think all have I-Ds as yet) - always
> nice to
>     >> see the ideas flowing. :-) As a practical person that in IETF land
> is
>     >> considered an implementer, I naturally feel inclined towards RR
> types that
>     >> already exist as this enables something to be rapidly deployed.
>
>     > the community apparently lacks coherence on the importance of rapid
> deployment
>     > as compared to the importance of technical excellence. if we're not
> going to
>     > add any more new RR types because they take ten years to become
> usable (see
>     > the SPF RR vs. the later _spf TXT RR), we should say that, and close
> the RR
>     > type registry, so as to avoid confusing newcomers.
>
>     > if on the other hand we're going to continue to evolve DNS in ways
> that
>     > include adding new RR types, and all the initiators who are stuck
> behind
>     > dumbass middleboxes who reject or butcher unknown RR types are going
> to fail
>     > hard and be excluded from the new applications and protocols in
> order to put
>     > more pressure on middlebox users/makers/distributors, we should say
> that.
>
>     > either way, nothing is temporary. whatever we use for resolver
>     > discovery will
>
> I'm with Paul. I prefer creating new RR types.
> There aren't that many dumbass middleboxes around, and those that are
> there,
> are usually put there intentionally, and they deserve what they get.
>
> I was among the first who did that back in 2002, and it wasn't that hard.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>


-- 
Daniel Migault
Ericsson