Skip to main content

Last Call Review of draft-ietf-dprive-unilateral-probing-11
review-ietf-dprive-unilateral-probing-11-dnsdir-lc-obser-2023-08-09-00

Request Review of draft-ietf-dprive-unilateral-probing
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team DNS Directorate (dnsdir)
Deadline 2023-08-28
Requested 2023-08-07
Authors Daniel Kahn Gillmor , Joey Salazar , Paul E. Hoffman
I-D last updated 2023-08-09
Completed reviews Dnsdir Last Call review of -10 by Florian Obser (diff)
Dnsdir Last Call review of -11 by Florian Obser (diff)
Artart Last Call review of -12 by Bron Gondwana (diff)
Opsdir Last Call review of -11 by Dhruv Dhody (diff)
Intdir Telechat review of -12 by Tommy Pauly (diff)
Dnsdir Telechat review of -12 by Florian Obser (diff)
Dnsdir Early review of -09 by Florian Obser (diff)
Intdir Early review of -06 by Haoyu Song (diff)
Secdir Early review of -07 by Rich Salz (diff)
Assignment Reviewer Florian Obser
State Completed
Request Last Call review on draft-ietf-dprive-unilateral-probing by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/5WhQZb0bA8xP160Z1v90vcuDMLw
Reviewed revision 11 (document currently at 13)
Result Ready w/issues
Completed 2023-08-09
review-ietf-dprive-unilateral-probing-11-dnsdir-lc-obser-2023-08-09-00
Unfortunately -11 introduced two issues Which I've already raised on the dpriv mailing list.

This is the text I sent to dpriv yesterday:
------------------------------------------------------------------------
   For example, consider an authoritative server named ns0.example.com
   that is served by two installations (with two A records), one at
   192.0.2.7 that follows this guidance, and one at 2001:db8::8 that is
   a legacy (cleartext port 53-only) deployment.

It doesn't have two A records. It has an A and AAAA record. I know
that Éric asked for a non-legacy IP example, but I don't think this makes
things better. I find it very confusing, usually the server would be
dual stacked so why would it do different things depending on the
address family? Maybe just go v6 only, thusly?

   For example, consider an authoritative server named ns0.example.com
   that is served by two installations (with two AAAA records), one at
   2001:db8::7 that follows this guidance, and one at 2001:db8::8 that is
   a legacy (cleartext port 53-only) deployment.  A recursive client who
   associates state with the NS name and reaches 2001:db8::7 first will

Same in 4.5:

   For example, if a recursive resolver can send a packet to
   authoritative servers from IP addresses 192.0.2.100 and
   2001:db8::200, it could keep two distinct sets of per-authoritative-
   IP state, one for each source address it uses, if the recursive
   resolver knows the addresses in use.  Keeping these state tables
   distinct for each source address makes it possible for a pooled
   authoritative server behind a load balancer to do a partial rollout
   while minimizing accidental timeouts (see Section 3.1).

It seems unlikely that the load balancer would do a address family
translation. Maybe:

   For example, if a recursive resolver can send a packet to
   authoritative servers from IP addresses 2001:db8::100 and
   2001:db8::200, it could keep two distinct sets of per-authoritative-
------------------------------------------------------------------------