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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Thomas,

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


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.

--

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.

--

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?


--

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?

# Nits

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

cheers, thanks!




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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux