[OpenAFS] Strange DNS SRV traffic resulting from stat() in
1.8.13.2
Jeffrey Altman
jaltman@auristor.com
Fri, 22 Aug 2025 13:08:25 -0400
Ryan,
Since no one else has replied, I will try to explain what I think is =
happening although I have no idea why or how it is happening. I will =
also ask a few questions.
> On Aug 17, 2025, at 7:15=E2=80=AFAM, Ryan C. Underwood =
<nemesis-lists@icequake.net> wrote:
> I recently tried out the 1.8.13.2 client on my Ubuntu laptop,
> upgrading from a somewhat older client version.
What is the version of Ubuntu and most importantly, what is the kernel =
version?
> Historically, I have
> used @sys-based components in PATH as a way of centrally managing
> CLI tools without having to distribute them to every system I use.
> However, this has become problematic in the following way.
I=E2=80=99m not sure that @sys is involved. =20
>=20
> Immediately after system startup, all is well, my shell profile loads
> immediately and CLI commands also return immediately. However, after
> some time of system utilization, not necessarily including any heavy
> AFS usage, doing anything within my shell profile slows to a crawl.
> The reason is because of the AFS-based PATH component. Instead of
> stat() calls returning immediately, at this point each one creates
> many DNS roundtrips fetching some very strange SRV records that I do
> not recall seeing before, and which are perhaps malformed:
>=20
> 12:52:12.101148 IP 192.168.8.248.46167 > 192.168.8.1.53: 25095+ AFSDB? =
icequake.net/users/nemesis/bin/bash. (53)
> 12:52:12.245481 IP 192.168.8.1.53 > 192.168.8.248.46167: 25095 =
NXDomain 0/1/0 (128)
> 12:52:12.246822 IP 192.168.8.248.57487 > 192.168.8.1.53: 46166+ AFSDB? =
icequake.net/users/nemesis/bin/bash.icequake.net. (66)
> 12:52:12.407925 IP 192.168.8.1.53 > 192.168.8.248.57487: 46166 =
NXDomain* 0/1/0 (134)
> 12:52:12.408765 IP 192.168.8.248.60842 > 192.168.8.1.53: 45806+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash. (73)
> 12:52:12.612530 IP 192.168.8.1.53 > 192.168.8.248.60842: 45806 =
NXDomain 0/1/0 (148)
> 12:52:12.613264 IP 192.168.8.248.33038 > 192.168.8.1.53: 54461+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash.icequake.net. =
(86)
> 12:52:12.817311 IP 192.168.8.1.53 > 192.168.8.248.33038: 54461 =
NXDomain* 0/1/0 (154)
> 12:52:12.817829 IP 192.168.8.248.33177 > 192.168.8.1.53: 53983+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash. (73)
> 12:52:12.958650 IP 192.168.8.1.53 > 192.168.8.248.33177: 53983 =
NXDomain 0/1/0 (148)
> 12:52:12.959152 IP 192.168.8.248.50256 > 192.168.8.1.53: 12967+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash.icequake.net. =
(86)
> 12:52:13.124390 IP 192.168.8.1.53 > 192.168.8.248.50256: 12967 =
NXDomain* 0/1/0 (154)
> 12:52:13.125189 IP 192.168.8.248.47935 > 192.168.8.1.53: 56862+ AFSDB? =
icequake.net/users/nemesis/bin/bash. (53)
> 12:52:13.329797 IP 192.168.8.1.53 > 192.168.8.248.47935: 56862 =
NXDomain 0/1/0 (128)
> 12:52:13.330370 IP 192.168.8.248.58386 > 192.168.8.1.53: 55085+ AFSDB? =
icequake.net/users/nemesis/bin/bash.icequake.net. (66)
> 12:52:13.537502 IP 192.168.8.1.53 > 192.168.8.248.58386: 55085 =
NXDomain* 0/1/0 (134)
> 12:52:13.540776 IP 192.168.8.248.41895 > 192.168.8.1.53: 6729+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash. (78)
> 12:52:13.740662 IP 192.168.8.1.53 > 192.168.8.248.41895: 6729 NXDomain =
0/1/0 (153)
> 12:52:13.741143 IP 192.168.8.248.37102 > 192.168.8.1.53: 33110+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash.icequake.net.=
(91)
> 12:52:14.159513 IP 192.168.8.1.53 > 192.168.8.248.37102: 33110 =
NXDomain* 0/1/0 (159)
> 12:52:14.160055 IP 192.168.8.248.58652 > 192.168.8.1.53: 64126+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash. (78)
> 12:52:14.731726 IP 192.168.8.1.53 > 192.168.8.248.58652: 64126 =
NXDomain 0/1/0 (153)
> 12:52:14.732197 IP 192.168.8.248.41774 > 192.168.8.1.53: 19149+ SRV? =
_afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash.icequake.net.=
(91)
> [...]
There are two types of DNS queries being issued. The first type are DNS =
SRV queries for service =E2=80=9Cafs3-vlserver=E2=80=9D using protocol =
=E2=80=9Cudp=E2=80=9D. The second type of query are the deprecated DNS =
AFSDB queries the DNS SRV queries are intended to replace.
However, the queries are malformed and are leaking to the world every =
path that is traversed.
> Can someone explain what is going on here? Whatever is happening, it
> is bypassing the cache manager because the same strange queries are
> issued repeatedly as the shell profile executes. It's additionally
> painful in the case of my laptop, since the ultimate DNS server is on
> the other end of a VPN link.
Unless the afsd dynamic root functionality is disabled, DNS SRV or DNS =
AFSDB queries would be expected if the cache manager=E2=80=99s =
CellServDB does not contain a list of database servers for the cell =
=E2=80=9Cice quake.net=E2=80=9D. In particular we would expect to see a =
DNS SRV query for :_afs3-vlserver._udp.icequake.net and if that query =
failed, then a fallback query for DNS AFSDB =E2=80=9Cicequake.net=E2=80=9D=
. Those queries are not present in the above trace. As far as I can =
tell there are neither DNS SRV nor DNS AFSDB records published for ice =
quake.net.
What is odd about the above queries is that they contain the full path =
with the exclusion of the =E2=80=9C/afs/=E2=80=9C prefix. This is odd =
because it appears that the /afs/some-cell-name/path query is being =
treated as a single path component. For example:
icequake.net/users/nemesis/bin/bash
icequake.net/users/nemesis/bin/bash.icequake.net
icequake.net/users/nemesis/@sys/bin/bash
icequake.net/users/nemesis/@sys/bin/bash.icequake.net
The full path is usually not visible to a filesystem. One question to =
answer is whether these paths are being delivered to the afs lookup =
function or whether they are being constructed internally? Filesystems =
do not normally have visibility to full paths so I wouldn=E2=80=99t =
expect them to be constructed internally. If the paths are being passed =
to the afs lookup function, then the failure to separate the components =
for lookup is somewhere higher in the stack.
> I believe the previous version I was using (without this new behavior)
> was 1.8.10, but don't quote me on that.
What else changed between when 1.8.10 was installed and 1.8.13.2?
I am curious if you experience the same behavior problems with the =
AuriStorFS client. If you do, that is a strong indication that the =
problem is external to OpenAFS.
Jeffrey Altman