Hi, > > > Ouch. The issue is that resolving names might also slow things down, and > > > I wanted to avoid that. I think I got a simple enough parser for > > > /etc/that that should work, so we can resolve `apt-proxy` statically > > > without going outside for DNS. > > > > > > Can you test the attached patch? > > > > Yes, this would indeed work after adding the entry to /etc/hosts. > > ``` > > echo $(kdig +short -t A apt-proxy.$(dnsdomainname) @_gateway) apt-proxy > > |sudo tee -a /etc/hosts > > ``` > > Sadly this doesn't really fix the issue as the same is happening in a > > network > > with an SRV entry where it's not all fun and games /รถ\. > > SRV records are only checked *after* looking for localhost, (now > apt-proxy from /etc/hosts), gateway, and apt-proxy from DNS. Wasn't it > also a problem before?
I have the same slowness (30s+ for apt update to start downloading something) and narrowed it down to auto-apt-proxy. I have a SRV record announcing my proxy. This proxy is not running on the gateway host nor on localhost. I have firewall rules DROPping traffic on that apt-proxy host, except for port 3128, and this is what makes it very slow. If I remove the DNS record for `apt-proxy` host, the slowness is gone (or at least acceptable). Should I suggest an improvement on the document regarding this? Maybe also my choice of port 3128 could be better aligned with auto-apt-proxy search order. Thanks, Alex
