Re: [Last-Call] [EXTERNAL] Re: Artart last call review of draft-ietf-add-ddr-07

Tommy Jensen <Jensen.Thomas=40microsoft.com@xxxxxxxxxxxxxx> · Wed, 29 Jun 2022 23:54:48 +0000

Hey Thomas,

Thank you for the feedback. I’ve issued a PR to address these items but will include the edits here for inclusivity (inline prepended with “[TommyJ]”).

https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/77

Thanks,
Tommy (the other one)

From: Tommy Pauly <tpauly@xxxxxxxxx> 

Sent: Wednesday, June 29, 2022 2:59 PM

To: Thomas Fossati <thomas.fossati@xxxxxxx>

Cc: art@xxxxxxxx; add@xxxxxxxx; draft-ietf-add-ddr.all@xxxxxxxx; last-call@xxxxxxxx

Subject: [EXTERNAL] Re: Artart last call review of draft-ietf-add-ddr-07

Hi Thomas,

Thanks for the review! I’ve opened up an issue for tracking the resolution to these:

https://github.com/ietf-wg-add/draft-ietf-add-ddr/issues/73

Best,

Tommy

On Jun 28, 2022, at 3:52 PM, Thomas Fossati via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Thomas Fossati

Review result: Almost Ready

This looks like a very useful document.  It's short but packed with

information.  It's largely very well written, though I found Section 4.1

slightly harder to parse than the rest and I think that area needs some

(small) editorial tweaks before the document can be shipped.

# Minor issues

Why the following isn't a MUST NOT?

  Clients SHOULD NOT automatically use a Designated

  Resolver without some sort of validation, such as the two methods

  defined in this document or a future mechanism.
[TommyJ] MUST NOT is probably more appropriate (changed); the SHOULD NOT is an artifact of prior discussions changing the scope of the document.

--

This bit is puzzling:

  A client MUST NOT use a Designated Resolver designated by one

  Unencrypted Resolver in place of another Unencrypted Resolver.

There seems to be some context missing to explain why a client should

found itself in that position.  What I seem to understand from the text

that follows:

  As these are known only by IP address, this means each unique IP

  address used for unencrypted DNS requires its own designation discovery.

  This ensures queries are being sent to a party designated by the

  resolver originally being used.

is that clients must go through the designation process when their

network attachment changes / they are re-configured WRT their UR. And

that's because there is strict administrative coupling between a UR and

its DRs that would be subverted otherwise.

I am scanning this for the first time and I may be off on a tangent

space, but if my reading is correct, then the text could be reorganised

a bit to make the context for the requirement clearer.

[TommyJ] This section was actually about not reusing a designation for Unencrypted Resolver 1.2.3.4 when configured with Unencrypted Resolver 2.3.4.5. Your next feedback item focuses on the next section of the document which tackles the “don’t reuse for the
 same IP address but diff networks” scenario. The following is my attempt at clarifying the text; what do you think?

[TommyJ] “A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted Resolver in place of any other Unencrypted Resolver. Instead, the client SHOULD repeat the discovery process to discover the Designated Resolver of the other
 Unencrypted Resolver. In other words, designations are per-resolver and MUST NOT be used to configure the client's universal DNS behavior. This ensures in all cases that queries are being sent to a party designated by the resolver originally being used. This
 cannot be guaranteed when designations are reused because Unencrypted Resolvers can only be identified by their IP address.”
--

I found this other bit hard to parse:

  Generally, clients also SHOULD NOT reuse the Designated Resolver

  discovered from an Unencrypted Resolver over one network connection

  in place of the same Unencrypted Resolver on another network

  connection.

What about:

  If a client is configured with the same Unencrypted Resolver's IP

  address on two different networks n1 and n2, a Designated Resolver

  that has been discovered on n1 SHOULD NOT be reused on n2 without

  repeating the discovery process.

instead?

[TommyJ] I can see why that is clearer; I tried to generalize this to the Nth case beyond the 2^nd case this way. Is this still clear, or have I reintroduced the parsing difficulty?

[TommyJ] “If a client is configured with the same Unencrypted Resolver's IP address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery
 process for each network.”

--

In the IANA section 

  IANA is requested to add an entry in "Transport-Independent

  Locally-Served DNS Zones" registry for 'resolver.arpa.' with the

  description "DNS Resolver Special-Use Domain", listing this document

  as the reference.

Ignorant question: is there an associated delegation of 'resolver.arpa.'

needed in the '.arpa.' zone?  Or is that not necessary?

[TommyJ] No. The name is special in that it refers to the resolver itself, not an address mapping or other property.

# Nits

I've submitted a PR with a few typos fixed.

[TommyJ] Thanks!

cheers, thanks!

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call