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

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

 



Thank you for the feedback, Thomas! And no silly questions or waste of time here, better to overthink through everything than risk missing something before inking an RFC.

 

Thanks,

Tommy

 

From: Thomas Fossati <Thomas.Fossati@xxxxxxx>
Sent: Thursday, June 30, 2022 4:38 AM
To: Tommy Jensen <Jensen.Thomas@xxxxxxxxxxxxx>; Tommy Pauly <tpauly@xxxxxxxxx>
Cc: art@xxxxxxxx; add@xxxxxxxx; draft-ietf-add-ddr.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [EXTERNAL] Re: Artart last call review of draft-ietf-add-ddr-07

 

Hi Tommy (J and P),

 

Tommy Jensen <Jensen.Thomas@xxxxxxxxxxxxx> wrote:

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

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

 

That's a great improvement, thanks!  In particular, the sentence:

 

  [...] In other words, designations are per-resolver and MUST NOT be

  used to configure the client's universal DNS behavior.

 

explains the logic well.

 

I find the last sentence still a bit hazy, but I don't want to drag you

into a potentially never-ending refinement loop; ship it!

 

> > 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 2nd 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.”

 

LGTM

 

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

 

Yes, in hindsight I asked a pretty silly question :-)  Sorry for wasting

your time on this.

 

Cheers, Tommy F 😊

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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