Re: [Dots] Erik Kline's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

[[e-mail]]

Hi Erik, 

Thanks for the review.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Erik Kline via Datatracker [mailto:[e-mail]]
> Envoyé : jeudi 3 juin 2021 08:09
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Erik Kline's No Objection on draft-ietf-dots-rfc8782-bis-07:
> (with COMMENT)
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dots-rfc8782-bis-07: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/
> 
> 
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
> [S3] [comment]
> 
> * I don't know if it's really necessary to dredge up RFC 6296, but I
>   understand the desire for completeness.
> 

[Med] You got the intent about the completeness. The key point is that we are not recommending it, but just cite as one example where things may be broken. 

> [S4.4.1.1] [question]
> 
> * For "lifetime" in the case where a "target-fqdn" was given, should
> the
>   resolution library's knowledge of the DNS RR TTL value(s) be
> factored in?
> 
>   For example, what does lifetime=3600s mean for a hostname whose
> A/AAAA
>   RRs have only 5 minute lifetimes?  Is the DOTS server/enforcer
> expected
>   to continuously re-resolve every ${DNS_RR_TTL} and apply the
> policy for
>   up to the full 3600 seconds

[Med] Yeah. When possible, the client makes sure that the resolved addresses are valid during the mitigation lifetime. If a resolved address flushed out (e.g., DNS TTL expiry) while the mitigation is still active (pending lifetime!=0), the resolution library should be solicited. 

As we don't impose any requirement on the name resolution library (and especially whether it exposes a validity timeout), I suggest the following change: 

OLD:
      How a name is passed to an underlying name resolution library is
      implementation and deployment specific.  Nevertheless, once the
      name is resolved into one or multiple IP addresses, DOTS servers
      MUST apply the same validation checks as those for 'target-
      prefix'.  

NEW:
      How a name is passed to an underlying name resolution library is
      implementation and deployment specific.  Nevertheless, once the
      name is resolved into one or multiple IP addresses, DOTS servers
      MUST apply the same validation checks as those for 'target-
      prefix'.  These validation checks are reiterated by the DOTS
      client each time a name is passed to the underlying name
      resolution library (e.g., upon expiry of DNS TTL).


, or is the DNS RR TTL ignored once the
>   resolution has been confirmed to have succeeded or failed?
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.