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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 21, 2025 at 02:28:40PM +0200, Alexandre Rossi wrote:

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?

Yes, please.

Maybe also my choice of port 3128 could be better aligned with
auto-apt-proxy search order.

TBH I don't want to commit to any specific search order. auto-apt-proxy
tries to detect a proxy by sending HTTP requests to possible locations
where a proxy might be. If that location DROPs packages (instead of e.g. REJECTing them), then the whole process lows down. If the targets just
REJECT connections immediately insted of letting the client timeout,
then whatever search order can be processed really quickly.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAmiAE1QACgkQ/A2xu81G C97UTRAAlvD21b6UBrcbenI4EEsBYbrLHYjfrjmpujTzWH2w7CU6v+BKcsdcb2fL p3L8Kt5Nm+Q3Dwl9l5tHuskV15HIWUY0JSpw0xlEa1tiKWTUwceyHvN53X8Xd4hc XbWbHN362bZzxfSu9aZ4C4+np+AprNH9xwKuWmyZrr8cbtIzExWHKTO8jEotKiMN XZLfYmjtciTjb/voxx1eW9If127Jfg5Dr0PrycZDoesXcloH4466wkfytse8YYCl QUK9YRHw6JhzZIG7/6+FiEYTUIxP1uJz9ZgHxbYI2aAm61XBBuJpodDo7z0f+K4t IdD9bKv6SeGfKG4U/advPa3kJ0rKrM5xFl6j8JuZoS77Blk/t8YrfGpmZaZR/cnS jEu49fKZBxeZXKL1+iqEwWAWvzk5DwzfY+jdMot5isoZ3JUNZW9uaWafN1UQri2P MBichdtr0/ljohIFWQ1G57jPKtpLoJWYozTFRR/QDvphb6fQZYkyu5BECB+5OM7Q hIdbrdvcbPU9dheugN0pWQF6YX3VElq2+zrK8mSqci8SdNRvGtB4EXouMivup/nh w8KC0bfhmzXlvfR9RR1svSOLxVW5SGWtmxYqsJiCZtHOzBquO5jGhI4GeZJTtt99 CRI05IGdGGQ/nCXU7FWNdAXvUzsdyrFxvG2H/fqg/iEdS8Qq7/o=
=rHth
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 22 Jul 2025 19:40:23 -0300
Antonio Terceiro <[email protected]> wrote:

TBH I don't want to commit to any specific search order. auto-apt-proxy
tries to detect a proxy by sending HTTP requests to possible locations
where a proxy might be. If that location DROPs packages (instead of e.g. REJECTing them), then the whole process lows down. If the targets just
REJECT connections immediately insted of letting the client timeout,
then whatever search order can be processed really quickly.

I just created an merge-request[1] which lowers the default timeout's to 1 second and also adds configuration parameters via apt.conf(5) to allow
changing those as well as changing the cache timeout for a new lookups
because in internal networks i don't believe that admins change the
ip's of their proxies/cachers that often so a higher timeout wouldn't hurt if wanted.

[1] https://salsa.debian.org/debian/auto-apt-proxy/-/merge_requests/10

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)