Re: [Add] Comparative DoH Discovery DNS RR Types

[Christian Huitema <[e-mail]>]

On 6/29/2020 4:57 PM, Michael Richardson 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 heard EKR make two arguments for using CNAME: not just middlebox
compatibility, but also software simplicity. The latter is interesting,
and might be worth explaining a bit. The way I understand it, Mozilla
would rather use a well known API like getaddrinfo(), rather than a more
capable API that supports different record types. I can guess that this
is a software simplicity/complexity trade-off. I suppose that the more
capable API tend to be implemented slightly differently on different
OSes, which leads to more complex code with a variety of #ifdef to
accommodate the different platform, more tests, and probably more bugs.
But I may be getting it wrong, and I would rather hear what Mozilla
actually thinks...

-- Christian Huitema