<div dir="ltr"><div><div><div>Thanks for your answers Alex.<br><br></div>For case 1, I understand that should not be a problem, since squid is the one asking for DNS resolution.<br></div>For case 2 and 3, what you are saying is that the browser is requesting the DNS lookup first, correct? Hence the need for a reverse DNS from squid, since squid does not know at that point what domain the IP belongs to. But they still had to query the DNS server, so that entry is in that DNS cache, and it should have the same domain as the lookup that the user entered.<br><br></div><div>So if I have a local dns (maybe dnsmasq) that both squid and the user use, from what I understand I should be able to use squid's dns_nameservers directive to point to that DNS, and it should return fine since it is stored right there in the cache.<br><br></div><div>If the user is trying to use a different DNS server other than the local one, then fine, I will just decrypt their traffic as punishment. 😁<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 26, 2021 at 9:44 AM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/26/21 7:35 AM, Justin Michael Schwartzbeck wrote:<br>
>> Yes, many HTTPS transactions do not expose destination domain until it<br>
>> is too late to decide whether to bump them, and reverse DNS lookups are<br>
>> often unreliable.<br>
<br>
> I wonder why this would be. <br>
<br>
I suspect you assume that a forward DNS lookup (A or AAAA query) answer<br>
is always the "opposite" of a reverse DSN lookup (PTR query) answer.<br>
AFAIK, that is not how DNS is defined. From DNS point of view, each of<br>
those answers is totally independent -- there is no 1:1 or even 1:N<br>
mapping between them; the answers even come from different DNS zones!  A<br>
caching DNS resolver would probably violate the DNS protocol if it uses<br>
a cached A or AAAA record to answer a PTR query. Disclaimer: I am not a<br>
DNS expert.<br>
<br>
<br>
> From my understanding, when you open a<br>
> browser and browse to <a href="http://www.google.com" rel="noreferrer" target="_blank">www.google.com</a>, the very<br>
> first thing that happens is you do a DNS resolution so that you know<br>
> what IP to send the CONNECT request and subsequent HTTPS records in the<br>
> first place.<br>
<br>
What happens depends on the browser and the proxy port:<br>
<br>
1. For forward proxies: Some browsers will not do DNS lookups. They will<br>
send a CONNECT request to <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>, allowing Squid to do the DNS<br>
lookup. In this case, Squid dstdomain configured with a host name will<br>
work well.<br>
<br>
2. For forward proxies: Some browsers do DNS lookups. They will send a<br>
CONNECT request to one of the returned IP addresses.<br>
<br>
3. For interception proxies: All browsers do DNS lookups. They open a<br>
TCP connection to one of the returned IP addresses.<br>
<br>
In cases 2 and 3, Squid dstdomain will have to do a reverse DNS lookup<br>
(PTR query). In many cases, that lookup either fails or returns a<br>
different domain name than the domain the browser started with.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
<br>
> So we would have the IP already, and the hostname that was<br>
> looked up already in the DNS cache, right? Why wouldn't squid just be<br>
> able to reach in there, match the IP that DNS returned, and then pull<br>
> that hostname out to compare against the ACLs?<br>
> <br>
> On Thu, Feb 25, 2021 at 2:57 PM Alex Rousskov<br>
> <<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>>> wrote:<br>
> <br>
>     On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote:<br>
> <br>
>     > I have thus far used dstdomain acl for bypassing ssl bump on sites<br>
>     that<br>
>     > we don't want to decrypt, like banking sites. It seems to work for<br>
>     some<br>
>     > sites, but not for others.<br>
> <br>
>     Yes, many HTTPS transactions do not expose destination domain until it<br>
>     is too late to decide whether to bump them, and reverse DNS lookups are<br>
>     often unreliable.<br>
> <br>
> <br>
>     > I was thinking about this, and it seems to me that if we are using the<br>
>     > squid proxy with a dns server, we should be able to check the dns<br>
>     cache<br>
>     > for that IP, and find the associated hostname, and then match<br>
>     against that.<br>
> <br>
>     When you use dstdomain, Squid will do a (reverse) DNS query for you as<br>
>     necessary (including DNS cache lookups) unless you specify a -n option<br>
>     that is documented to disable all such operations.<br>
> <br>
> <br>
>     In many cases, you should be using ssl::server_name instead of dstdomain<br>
>     or dst ACL, but you may have to use a combination of various ACLs to<br>
>     cover all the cases you care about.<br>
> <br>
> <br>
>     HTH,<br>
> <br>
>     Alex.<br>
> <br>
<br>
</blockquote></div>