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

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Jul 2020 16:55:02 +0200

On Fri, May 29, 2020 at 08:21:59PM -0400,
 Daniel Migault <[email-masked]> wrote 
 a message of 218 lines which said:

> Please find an update version of the DNS Resolver Discovery Protocol (DRDP)

To tell the truth, I do not completely understand the protocol, or the
problem it tries to solve. But I work on that. A high-level
description would help. Section 2 is quite confusing. It says "The
DNS client may obtain the contextual resolving domains via various
way, including a configuration or via DHCP Options [I-D.btw-add-home]"
and later "This document describes two mechanisms for a DNS client to
retrieve resolving domains", these mechanisms being different from the
ones mentioned in the first sentence.

First question, about the concept of "resolving domain". 5.1 says
"FQDN - such as resolver.example.com - and the domain part (
example.com ) is designated as the resolving domain". The term "the
domain part" is unclear. Does it mean "the FQDN without the
most-specific label"? If the resolving service is
foo.bar.example.eu.org, is the resolving domain bar.example.eu.org?
(5.3 seems to imply this.)

Second, I do not get the relationship between "resolving domain" and
"resolving domain list". What is called "resolving domain" in 5.1
seems to be a "resolving domain list" in 5.2.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 27 Jul 2020 14:44:32 -0400

Hi,

Thanks for the comment. Please see inline my responses. I am working on
updating the draft.

Yours,
Daniel

On Mon, Jul 27, 2020 at 10:55 AM Stephane Bortzmeyer <[email-masked]>
wrote:

> problem it tries to solve. But I work on that.

<mglt>
I will work on clarifying the text.
</mglt>

> A high-level
> <mglt>
My intention here was to say that DRDP takes some parameters and can be
started. More specifically, the DNS client can start DRDP several time with
different parameters. Currently the parameters mentioned in the document
are a resolving domain (rd) or a pointer to a a list of resolving domains
(rd_list). Both resolving domain and resolving_domain list are FQDN. The
discovery can be perform as follows:

drpd -rd example.com
drpd -rd example.net
drpd -rd_list list.example.org
....

In each case a set of resolvers with associated characteristics are
returned.

The current draft leaves open how one DRDP client gets the necessary
parameters to start the discovery. The parameters can be configured in the
application, other alternatives can include some specific provisioning
methods such as a specific DHCP option. The draft describes a mechanism to
derive these parameters from the Recursive Name Server option. I tend to
agree that this would be clarifying to have one document that differentiate
DRDP and the way the DRDP client can be configured.

I think the confusion of the text is that the text currently considered
resolving domains as an input to drdp. Leaving it open on how the DRDP
client how the resolving domains are retrieved, it described two mechanisms
to retrieve these resolving domains: 1) through the list of resolving
domains and 2) through the Recursive Name Server option. I tend to think it
would be clearer to consider that DRDP may have different inputs and
describe ways to retrieve these inputs.

Will update the document.

</mglt>

> <mglt>
I would say this is what the text suggests but that needs to be refined a
bit.

The motivation for defining the resolving domains as opposed to the
resolving service FQDN was to introduce a sort of abstraction which was
expected to be useful when something is notified to the end user or if a
selection is needed. The selection was expected to represent the trust an
user has with one of the operator  of the resolving service. In that sense
the hostname of the server is not necessarily relevant in the sense that
the most important information is orange, verizon, videotron, google,
cloudflare..... We also noticed that in a lot of cases the resolver fqdn is
hostname.intelligible_domain and we chose to designate intelligible_domain
as the resolving domain.

Now the mapping between the resolving service and the resolving domain does
not work all the time. DRDP makes the correspondence between the resolving
domain and the resolving service. The correspondence between the resolving
service and the resolving domain is only a guess  and in the example
foo.bar.example.eu.org, a few candidates could be derived.
bar.example.eu.org, example.eu.org.

As you seem to point out, determining a resolving domain from the resolving
service name is mostly necessary to derive the resolving domain from the IP
address received by the DHCP server which may not be part of DRPD itself.

</mglt>

> <mglt>
The resolving domain (example.com) is what you use to discover the
resolvers, typically,
_dns.example.com. SVCB ?
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 correct that in section 5.1 and 5.2 I am using example.com in both
cases which is misleading.

I will address this in the next version.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 27 Jul 2020 15:00:26 -0400

On Mon, Jul 27, 2020 at 2:45 PM Daniel Migault <[email-masked]> wrote:

>
> a resolving domain list (rd_list.example.net) contains a list of
> resolving domains. You get the different resolving domains

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.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 27 Jul 2020 17:06:50 -0400

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

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 27 Jul 2020 22:16:16 -0400

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 <[email-masked]> wrote:

> 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

-- 
Daniel Migault
Ericsson