On 2/26/21 12:45 PM, Justin Michael Schwartzbeck wrote: > For case 2 and 3, what you are saying is that the browser is requesting > the DNS lookup first, correct? Correct, but that does not really matter. > Hence the need for a reverse DNS from > squid, since squid does not know at that point what domain the IP > belongs to. Squid "does not know" because all Squid gets is an IP address (in those two cases). > 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. DNS does not support what feels natural to you. You are thinking of a name:IP cache entry that can be looked up by IP. That is a natural model, but it does not match reality. DNS simply does not have an interface that says "find me a name that maps to IP Y". DNS essentially has only one interface: "find me what maps to name X". That is it! There is just no way to ask a DNS server what name in its cache maps to an IP address. For reverse DNS lookups, the DNS client constructs an IP-based _name_ in a special in-addr.arpa DNS zone and uses that name to query the DNS server. For example, a "reverse" lookup for 127.0.0.1 is really a lookup for the "1.0.0.127.in-addr.arpa" name. And that lookup follows all the DNS rules about contacting authoritative servers for the zone, etc.; the DNS server does not really "know" that what you really want is a cached domain name for that 127.0.0.1 IP address. > 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. The IP may be stored, but it cannot be looked up using DNS. Alex. > On Fri, Feb 26, 2021 at 9:44 AM Alex Rousskov wrote: > > On 2/26/21 7:35 AM, Justin Michael Schwartzbeck wrote: > >> Yes, many HTTPS transactions do not expose destination domain > until it > >> is too late to decide whether to bump them, and reverse DNS > lookups are > >> often unreliable. > > > I wonder why this would be. > > I suspect you assume that a forward DNS lookup (A or AAAA query) answer > is always the "opposite" of a reverse DSN lookup (PTR query) answer. > AFAIK, that is not how DNS is defined. From DNS point of view, each of > those answers is totally independent -- there is no 1:1 or even 1:N > mapping between them; the answers even come from different DNS zones! A > caching DNS resolver would probably violate the DNS protocol if it uses > a cached A or AAAA record to answer a PTR query. Disclaimer: I am not a > DNS expert. > > > > From my understanding, when you open a > > browser and browse to www.google.com <http://www.google.com>, the very > > first thing that happens is you do a DNS resolution so that you know > > what IP to send the CONNECT request and subsequent HTTPS records > in the > > first place. > > What happens depends on the browser and the proxy port: > > 1. For forward proxies: Some browsers will not do DNS lookups. They will > send a CONNECT request to example.com <http://example.com>, allowing > Squid to do the DNS > lookup. In this case, Squid dstdomain configured with a host name will > work well. > > 2. For forward proxies: Some browsers do DNS lookups. They will send a > CONNECT request to one of the returned IP addresses. > > 3. For interception proxies: All browsers do DNS lookups. They open a > TCP connection to one of the returned IP addresses. > > In cases 2 and 3, Squid dstdomain will have to do a reverse DNS lookup > (PTR query). In many cases, that lookup either fails or returns a > different domain name than the domain the browser started with. > > > HTH, > > Alex. > > > > So we would have the IP already, and the hostname that was > > looked up already in the DNS cache, right? Why wouldn't squid just be > > able to reach in there, match the IP that DNS returned, and then pull > > that hostname out to compare against the ACLs? > > > > On Thu, Feb 25, 2021 at 2:57 PM Alex Rousskov > > <rousskov@xxxxxxxxxxxxxxxxxxxxxxx > <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx> > > <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx > <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>>> wrote: > > > > On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote: > > > > > I have thus far used dstdomain acl for bypassing ssl bump on > sites > > that > > > we don't want to decrypt, like banking sites. It seems to > work for > > some > > > sites, but not for others. > > > > Yes, many HTTPS transactions do not expose destination domain > until it > > is too late to decide whether to bump them, and reverse DNS > lookups are > > often unreliable. > > > > > > > I was thinking about this, and it seems to me that if we are > using the > > > squid proxy with a dns server, we should be able to check > the dns > > cache > > > for that IP, and find the associated hostname, and then match > > against that. > > > > When you use dstdomain, Squid will do a (reverse) DNS query > for you as > > necessary (including DNS cache lookups) unless you specify a > -n option > > that is documented to disable all such operations. > > > > > > In many cases, you should be using ssl::server_name instead of > dstdomain > > or dst ACL, but you may have to use a combination of various > ACLs to > > cover all the cases you care about. > > > > > > HTH, > > > > Alex. > > > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
