> Thank for clarification, Michael. I believe my confusion comes from the > following paragraph:
" While subsequent connections to the same site (and subsequent packets in the same flow) will not be affected if the results are cached, the effects will be felt. The ACL results can be cached for a period of time given by the TTL of the DNS results, but the lookup must be performed again in a number of hours to days. " > I think keeping state to cache results is necessary for establishing > subsequent connection the same site. First, that paragraph is in the section on why one can't map from IP addresses to names (the reverse method). If you do the lookup on the first packet, there will be delay. Then you might cache that result for subsequent packets. In this case, doing the reverse lookup is far more dependant upon the TTL. > It seems that the cache lifetime is decided by TTL of DNS results, have > nothing to do with session state duration, correct? When doing forward resolution the policy needs to be updated whenever the IP address changes. The DNS TTL determines when you do another DNS request. > Cached results will be torn down after TTL of DNS results or Cached results > will be updated with new IP address, > Therefore it needs another DNS lookup. > Let me know if my understanding is correct. I think that the (TCP) session state should not be torn down even if the IP address result changes. Some implementations might decide differently, but this document is not about that part. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
