Package: bind9-dnsutils
Version: 1:9.16.27-1~deb11u1
Architecture: amd64
Dear Maintainer,
I needed to use docker under linux for testing purposes at work, where I
only have a Windows 11 PC. I installed a vagrant box under hyper-v, and
since I use bullseye on my own network at home, I chose the
'generic/debian11' vagrant box.
I had problems with connectivity from containers via the docker
'host-gateway', so started running tests.
I logged into a container and ran 'ping host-gateway' and found to my
surprise that the target IP address was an external address and not my
vagrant box (i.e. not actually the docker gateway host). This prevented
messages from inside my docker containers being forwarded to the correct
proxy.
I then ran 'dig host-gateway' on the container and on the debian11
vagrant box, and got the IP address 23.217.138.108. I logged onto one of
my home debian servers and confirmed that this is a public address
mapped to an akamaitechnologies.com host name.
My home debian11 server did not initially exhibit the same issue, so I
assumed there was something wrong with the vagrant box I was using, or
possibly the vagrant deployment script. However, the resolv.conf files
were pointing to different DNS servers - my server uses a local bind9
service on my LAN, which forwards to my ISP, while the vagrant box
configuration is using a few public DNS servers including 4.2.2.1 and
4.2.2.2.
I thought I should also check if there was an issue with the DNS server,
so I tried three further tests:
1) On the vagrant box I ran 'dig @[my local DNS server address]
host-gateway'. This time I got the expected response (no ANSWER section,
i.e. 'host-gateway not found'.
2) On my home server I ran 'dig @4.2.2.1 host-gateway', so forcing it to
use the same DNS server that the vagrant box had been using. Now I once
again got an ANSWER section including the address 23.217.138.108. My
home server runs debian 11 on bare metal, so this is not an issue with
vagrant or the vagrant box, or indeed with the Windows 11 hosting the box.
3) On my Windows PC I ran 'nslookup', set the DNS server to 4.2.2.1 and
asked it for the address of 'host-gateway'. I got the expected response
(service not found). This shows that this DNS server is not the source
of the spurious address.
These tests appear to demonstrate that the problem is not in the vagrant
deployment process, the vagrant box, or the DNS server at 4.2.2.1. The
only common factor associated with the spurious reply is the Debian 11
distro.
A few more tests revealed that this seems to happen whenever the
requested host name ends with the string 'gateway', and the DNS server
used is either 4.2.2.1 or 4.2.2.2. I did not get the same behaviour
using 8.8.8.8, nor with my employer's DNS servers or my own server, but
I didn't have time to try any others.
Obviously the case I stumbled on involved the docker 'host-gateway'
name, which was chosen by docker because it should not resolve to any
host on the Internet, allowing docker to insert its own binding with
local scope. I don't know if the 'fake' ANSWER section is inserted when
the real response contains an ANSWER. If yes, clients woud be unable to
access the expected functions of the real server. If not, then clients
would be directed to the wrong host only if there is no right host, so
no functionality would be affected. But either way clients may send
sensitive information to the akamaitechnologies host.
This seems to be very significant. Something seems to be recognising DNS
requests to 4.2.2.1, and injecting a fake ANSWER section in the reply,
directing clients to an akamaitechnologies host.
It seems possible this behaviour may be the result of malicious
contamination rather than an accidental bug.
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-15-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bind9-dnsutils depends on:
ii bind9-host [host] 1:9.16.27-1~deb11u1
ii bind9-libs 1:9.16.27-1~deb11u1
ii libc6 2.31-13+deb11u3
ii libedit2 3.1-20191231-2+b1
ii libidn2-0 2.3.0-5
ii libkrb5-3 1.18.3-6+deb11u1
ii libprotobuf-c1 1.3.3-1+b2
bind9-dnsutils recommends no packages.
bind9-dnsutils suggests no packages.
