Re: [Add] New Version Notification for draft-mglt-add-rdp-02.txt

[Daniel Migault <[e-mail]>]

Hi,

Please find an update of the document addressing - at least partly - your
comments [1].

Yours,
Daniel

[1]
https://github.com/mglt/draft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd


On Mon, Jul 27, 2020 at 5:06 PM Daniel Migault <[e-mail]> wrote:

> Hi Ben,
>
> Thanks for the comment. First I agree that I should clarify the text and I
> am working on it.
>
> The intent of the list is to provide a "list of recommended resolvers".
> However, the list does not provide the resolvers as well as their
> characteristics. Instead it provides the resolving domain that can be seen
> as an indirection to these resolvers. As a result, the final candidate
> resolvers are retrieved from a SVCB query over the resolving domain. The
> resolver and associated characteristics of the resolver are clearly
> provided by the owner of the resolving domain and not the owner of the
> "list of resolvers".
>
> I think I understand what you mean by the violation of the principle of
> the DNS. This would typically be the case if connectivity information ( IP
> addresses for example) would be provided directly by the owner of the FQDN
> that represents the list of resolvers. It is a bit different here as PTR
> indicates an indirection.
>
> The reason I am using PTR is that I would like to use DNS only and not
> necessarily mandate that HTTP, FTP or email be mandatory.  In addition, the
> use of PTR enables some sanity checks of the resolving domains.
> I agree that this might not be very convenient for very very large list. I
> would envision that systems that need such very large lists of resolving
> domains may have their own mechanisms to provision resolving domains.
> EDNS buffer size of 1232 bytes will not cause fragmentation for an UDP
> packet and that size corresponds to the first 94 most popular domain
> names.  Of course more could be provided over TCP. Not saying that no
> other mechanisms should be considered, I believe that could be sufficient
> for many use cases without requiring an additional protocol (HTTP, FTP,
> email).
>
> Yours,
> Daniel
>
>
> [1] https://moz.com/top500
>
>
>
>
>
> On Mon, Jul 27, 2020 at 3:00 PM Ben Schwartz <[e-mail]> wrote:
>
>> On Mon, Jul 27, 2020 at 2:45 PM Daniel Migault <[e-mail]>
>> wrote:
>>
>>>
>>> a resolving domain list (rd_list.example.net) contains a list of
>>> resolving domains. You get the different resolving domains
>>> _b.rd_list.example.net PTR
>>>
>>
>> This is the part of the draft that seems strangest to me (apart from the
>> odd use of PTR).  It violates the usual expectation about data in the DNS:
>> records published by a domain provide information about that domain.  These
>> lists instead appear to provide information about the wider world.  The
>> "owner name" just indicates whose opinion this is.
>>
>> If you want to present this type of information, I would encourage you to
>> define a MIME type and distribute it using a general information transfer
>> system like HTTP, FTP, or e-mail.  The concerns about size (since these
>> lists could be arbitrarily large) are a hint that you're trying to store
>> the wrong sort of data in the DNS.
>>
>> Alternatively, if these lists are really meant to be "resolvers to use on
>> this network" or something like that, the text could be clearer about that,
>> with an explanation of how the user would learn the owner name.
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson