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

Daniel Migault <mglt.ietf@gmail.com> Mon, 27 July 2020 18:45 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C60F3A1D57 for <add@ietfa.amsl.com>; Mon, 27 Jul 2020 11:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt7AHmnX57gD for <add@ietfa.amsl.com>; Mon, 27 Jul 2020 11:44:58 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5723A1CF8 for <add@ietf.org>; Mon, 27 Jul 2020 11:44:44 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id p25so8857223vsg.4 for <add@ietf.org>; Mon, 27 Jul 2020 11:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S7geGc3MO79yRxmySJoQ73rihcuMx5t6K1mg0Q9OFUs=; b=d2HnZNZFhdxlqlrwHGPoh+nliU6AVIWlcTpAh6MKxlHVBo4HqaJjBvHqdmNXBoxxAh 2uxlTuyMWF+Q75f2mTXzGWNGJxi+0zdXhJ1Tnw/iepvjP2yaQoacRKkCJyCFD7EdFBB/ Fdt49Si9OJVgSMIdVOvLcsA30V/2T3TeSlFCuZwPGPKFjJ0ag4kRFuX/6qGkrxo/Bk/k JNYzMvtSNcbslFsiDCBtnAZVEDsYgimftcWgDvpwEnhgCKF8I1J8FtdpaBp21+5g4aGm f0T5Wc54mDQ2UO/pEvVSUag18WtEQJFc0hKaQgIly6DVb51FXBO/6Ut05+gQN0GNMK9q q+EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S7geGc3MO79yRxmySJoQ73rihcuMx5t6K1mg0Q9OFUs=; b=p24zakvxptEouna4Lq3SPbUwdcG9bbh5fKSBFiUjePrn4Rp8hkdZmh6mJgERDAXgLh zSSpf37XU5iU+xYdce/P0Z+jT379bUFnryqqcZDfX83o2jbET6CZxkDjur9Uu80IvySY p2Q2Y50geew4styrVappT4HgrZDhqm3vIQWNxymlJ/ctqV+NNEZ9Vet0oqkT9C//xpho V3s8+IXRE3YCzFD9XtffrtgSH5w/uyVaUAez1U872k7iyezBnXW+hEge6IlqGmz3O9EY Su6kI+1qs37KgI7ruwyrh3az26VSO/vs+DLa30h3YLJlWR/zHTRYaQuMr4sZM4X1FoWX iD1Q==
X-Gm-Message-State: AOAM530XQvsU6Vt6gbeGsXWoyY88AmrmqvCnx8n9xpX1EHK48+r9jRoa jQSxsSTWKXmC8QcYMYsLeQO44ByUQoy+0ZUL3li83Nu5
X-Google-Smtp-Source: ABdhPJzmbved34o9HVlfry+Ls84BcpwSV1GLBzke9JpF4LXqPoAexze4XKQvrZNbNxbwznLKOhU59X3NDYH7mDwEUrc=
X-Received: by 2002:a67:f696:: with SMTP id n22mr18460510vso.169.1595875483917; Mon, 27 Jul 2020 11:44:43 -0700 (PDT)
MIME-Version: 1.0
References: <159078807168.11416.12425165143603046178@ietfa.amsl.com> <MW3PR15MB3785F6A2720F1E4ABB77AAE3E38F0@MW3PR15MB3785.namprd15.prod.outlook.com> <CADZyTkkMAfv2ktC=oHOy32JCriBJ6x1=7+W1B4FGX9FqsnjQdA@mail.gmail.com> <20200727145502.GA7147@nic.fr>
In-Reply-To: <20200727145502.GA7147@nic.fr>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 27 Jul 2020 14:44:32 -0400
Message-ID: <CADZyTkkc3Mw2jUwPPOn=PjgWmsE4mR7cfGLH9MCHXxTNJuda9A@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000531fe605ab70b718"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/DNuOwIuQ2nADgW7Dz2ljGYgE1G0>
Subject: Re: [Add] New Version Notification for draft-mglt-add-rdp-02.txt
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 18:45:07 -0000

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 <bortzmeyer@nic.fr>
wrote:

> On Fri, May 29, 2020 at 08:21:59PM -0400,
>  Daniel Migault <mglt.ietf@gmail.com> 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.

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


> 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.
>
> <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>


> 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.)
>
> <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>

> 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.
>
>
> <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