Re: [Last-Call] [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18

[Matt Brown <[e-mail]>]

On Thu, Oct 20, 2022 at 6:26 AM Daniel Migault <[e-mail]> wrote:
>
> Hi Matt,
>
> Following up with other minor concerns. You can see the changes below:
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/88a1700865f80862301f96937ac07071efd58660

Mostly LGTM thanks, just following-up on a few minor points below.

> On Mon, Oct 17, 2022 at 9:11 AM Matt Brown via Datatracker <[e-mail]> wrote:
>>
>> Minor Issues (aka Ready with Issues):
>>
>> 2 and 3.1: DNSSEC Resolver - is the exclusion of unsigned/non-DNSSEC resolvers
>> in the terminology and architecture overview intentional? Section 9 confirms
>> that DNSSEC is not required (only RECOMMENDED), so it is possible that both the
>> public and internal resolvers being used are not DNSSEC capable - therefore it
>> seems strange for the architecture overview and terminology to imply that
>> DNSSEC is required.
>>
> We considered DNSSEC on how the architecture can fit DNSSEC requirements. DNSSEC might me disabled. DNSSEC impacted our design in many aspects, so the baseline we took is to have DNSSEC enabled.

I think this is fine (to assume DNSSEC as a baseline), but unless the
public homenet zone is explicitly required to be a Signed zone, then I
think the terminology should encompass all potential use-cases, not
just the assumed default - e.g. in this architecture description the
resolvers should not be described as DNSSEC specific. Perhaps adopting
RFC8499 terminology in this section would both address this concern
and add further clarity by sticking to known terminology, it was the
unusual term "DNSSEC Resolver" that caught my eye here initially.

>> 3.2: The 4th paragraph begins describing "the main issue", the solution to
>> which is not explained in the paragraph, or in the referenced Section 4.2
>> (which is DNSSEC/DS specific vs the NS, A, AAAA context of the paragraph). In
>> either case, the semantics of how the DM treats the information it receives
>> from the HNA seems out of place in a section describing and primarily focused
>> on the mechanics of the communication channel itself. I suggest removing or
>> rewriting this 4th paragraph to improve the clarity.
>>
> The purpose of this paragraph is to highlight that HNA needs some information from the DM and vice versa. I suggest the following changes:
>
> OLD:
> The main issue is that the Dynamic DNS update would also update the parent zone's (NS, DS and associated A or AAAA records) while the goal is to update the DM configuration fil
> es. The visible NS records SHOULD remain pointing at the cloud provider's server IP address -- which in many cases will be an anycast addresses. Revealing the address of the HNA in the DNS is not desirable. Refer to {{sec-chain-of-trust}} for more details.
>
> NEW:
> It is worth noticing that both DM and HNA need to agree on a common configuration to set up the synchronization channel as well as to build and server a coherent Public Homenet Zone.
> Typically,  the visible NS records of the Public Homenet Zone (built by the HNA) SHOULD remain pointing at the cloud provider's server IP address -- which in many cases will be an anycast address. Revealing the address of the HNA in the DNS is not desirable. In addition and depending on the configuration of the DOI, the DM also needs to update the  parent zone's (NS, DS and associated A or AAAA records). Refer to {{sec-chain-of-trust}} for more details.

I find the new wording much clearer thanks. I still find it a little
out of place (discussing zone record semantics in a section on the
transport channel) - would moving the new text down to the subsequent
sec-pbl-homenet-zone section be better? Given what the new text is
describing is the contents of the public homenet zone, that seems like
a more natural location to find this note.

>> 4: I find the format of this section confusing and hard to understand with
>> sections 4.1-4.4 describing the information to be conveyed, but not how it is
>> conveyed, and then the message formats being described in 4.5. I suggest it
>> would be much clearer and more understandable to combine the details in 4.5.x
>> with the earlier sections (e.g. put the AXFR details from 4.5.1 into 4.1, and
>> the DNS update details from 4.5.2/4.5.3 into 4.2 and 4.3.
>>
>  We put the message format description in one section to avoid repeating many information. I prefer to have it in one place.

Noted. I disagree, but accept your decision and preference :)

>> Given the HNA is already opening a control connection to the DM, was
>> consideration given to re-using that connection (or a 2nd HNA initiated
>> connection to a different address if there is the need for different servers in
>> the DM implementation between control/sync channesl) to prevent the need for
>> opening any listening port on the HNA WAN addresses at all?
>
> We did not consider a self organisation between HNAs. We focused on the minimal setting.

I was not meaning 2 HNA devices in this comment, I meant a single HNA
could open 2 outbound connections (1 for control channel, 1 for
synchronization channel) - the difference to what is currently written
simply being that both are initiated by the HNA (rather than the DM
initiating the synchronization channel connection) in order to avoid
having to open a listening port externally.

Cheers

-- 
Matt Brown
DNS Directorate Member