|
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
😊 |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
