Re: [PATCH] No-lookup DNS ACLs

This patch has passed the 10-day standown period and has no audit objects.

I only note that it uses class member dynamic array definitions (foo[];)
definitions. The C++ feature will break build on some compilers we need
to support (clang for FreeBSD9).

Once that is fixed this patch can go in.

Amos

On 25/12/2012 9:08 a.m., Tsantilas Christos wrote:
> No-lookup DNS ACLs
>
> Currently, dst, dstdom, dstdom_regex (and other?) DNS-related ACLs do
> DNS lookups if such a lookup is needed to convert an IP address into a
> domain name or vice versa. This creates two kinds of problems:
>
> - It is difficult to identify requests that use raw IP addresses in
> Request-URI or Host headers. One would have to use something like
> url_regex and possibly req_header to identify those before using dst
> ACLs to match the request destination against a known IP subnet. IPv6
> would only make this harder.
>
> - It is difficult to use dst* ACLs in options that support fast ACLs
> only. If an async lookup is required, the answer will be unpredictable
> (now) or DUNNO (when the ACL bugs are fixed), possibly with warnings and
> other complications.
>
> This patch adds a -n option to dst, dstdom, dstdom_regex and other
> DNS-related ACLs. The option 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 with a -n option would immediately declare a
> mismatch without any warnings or lookups.
> Please note that -n prohibits lookups in Squid's DNS caches as well.
>
> This patch also adds an ACL flags mechanism to help us easily add new
> flags for acls. The supported flags for an acl type configured in ACL
> constructor.
>
> Extra care taken for the -i/+i regex flags. These flags are not normal
> flags because they can be applied everywhere in acls values:
> acl dstdomain_regex -i dom1 dom2 +i dom3 -i dom4
>
>
>
> This is a Measurement Factory project.
>
> Regards,
> Christos
Received on Sat Jan 26 2013 - 10:11:56 MST