Control: retitle 995975 UDP socket from DNS keeps listening on 0.0.0.0
Control: reassign 995975 libevent-extra-2.1-7
Hallo,
* Richard Lewis [Sat, Oct 09 2021, 03:45:03PM]:
> Sorry, im not sure how to make gmail sensibly so i may have mangled
> the quoting. Thanks for replying - and I'm sure there is indeed a
> significant change ive done something wrong, or misunderstood
> something.
>
> On Sat, 9 Oct 2021 at 14:59, Eduard Bloch <e...@gmx.de> wrote:
> >
> > > I set "BindAddress: localhost" in /etc/apt-cacher-ng/acng.conf
> >
> > So, please do a "grep -i bindaddr /etc/apt-cacher-ng/*.conf" and report
> > what's there.
>
> grep -i bindaddr /etc/apt-cacher-ng/*.conf
> /etc/apt-cacher-ng/acng.conf:56:# BindAddress: localhost 192.168.7.254
> publicNameOnMainInterface
> /etc/apt-cacher-ng/acng.conf:58:BindAddress: localhost
> /etc/apt-cacher-ng/acng.conf:379:# BindAddress value.
>
> ie, nothing other than comments and the setting in acng.conf
Okay so far.
> > That does not make sense. First, apt-cacher is not apt-cacher-ng (its a
> > different package). Second: no listening ports are bound after the
> > startup in apt-cacher-ng.
> >
> > > ss -tunlp|grep apt
> > > udp UNCONN 0 0 0.0.0.0:41044 0.0.0.0:*
> > > users:(("apt-cacher-ng",pid=2584993,fd=11))
> > > tcp LISTEN 0 250 127.0.0.1:3142 0.0.0.0:*
> > > users:(("apt-cacher-ng",pid=2584993,fd=10))
> >
> > I cannot see 0.0.0.0:3142 here, and especially not in TCP context. What do
> > you mean?
>
> the issue is the udp line not the tcp line. the tcp line is exactly
> what i expected. the udp should either not be there at all or should
> say 127.0.0.1:41044. at least, that is what i think the output means.
It's most likely a dangling UDP socket from the evdns resolver library.
I have seen them before and they were one of the reasons why I switched
DNS resolution to libc-ares now (another reason is the SRV record
support).
I am not sure whether this is a security risk, though. The resolver
expects a response from the peer somehow. If you expect it to be extra
paranoid and listen only on a specific interface for its client
activities, that would be probably huge implementational effort for very
little security gain.
> > The UDP socket is probably the DNS resolver.
>
> it's certainly nothing to do with the usual dns resolvers running on my
> system.
> (unless you are saying that apt-cacher-ng includes a DNS resolver?)
Yes, I was refering to DNS resolver CODE in the application.
So, reassigning this to libevent now. The issue is reproducible in a
quick test in a container, and it disappears in the Sid version (which
using c-ares resolver instead of evdns).
Best regards,
Eduard.
