On 2024-11-26 00:53, Jonathan Lee wrote:
-n Disable lookups and address type conversions. If lookup or
conversion is required because the parameter type (IP or
domain name) does not match the message address type (domain
name or IP), then the ACL would immediately declare a mismatch
without any warnings or lookups.
For acls and use of -n is this considered faster over non use of the
flag?
When input address does not require a lookup (e.g., because the
information is currently available in IP or DNS cache), the matching
speed is the same with or without the -n flag.
In other cases, not doing a lookup is naturally faster than doing it,
but not doing a lookup may change the match/mismatch outcome, so
comparing speeds can be misleading. In these cases, the question is kind
of similar to asking "What is faster, aspirin or guillotine?"
What would be better for a system that is using its own DNS?
The answer depends on many factors unknown to me, including the cost of
incorrect (mis)matches and the cost of waiting for DNS lookups. If you
are not sure about tradeoffs in your environment, my recommendation is
to avoid -n because -n may change match/mismatch outcome.
When would we use -n versus when would we not?
We use -n when Squid should not lookup addresses. For example, when we
want to match transactions targeting domain name X but do not want to
match transactions targeting IP address Y that happens to resolve to
domain name X when using a reverse DNS lookup.
Also with use of caching updates would it be better to use -n ?
I assume you are asking about caching MS Windows updates. I do not know
the answer to that question, but suspect that the question itself is
missing essential details to allow for a meaningful answer. If the above
discussion does not let you answer this question, consider asking a more
specific question: Name the directive and the ACL while describing what
you are trying to optimize (i.e. defining "better").
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
