[OpenAFS] Strange DNS SRV traffic resulting from stat() in 1.8.13.2

[Jeffrey Altman]

Hi Gunnar,

Thanks for checking.   Additional response inline ...

> On Aug 25, 2025, at 3:41=E2=80=AFAM, Gunnar Krull =
<gklists@cs.uni-goettingen.de> wrote:
>=20
> Hi Ryan, hi Jeffrey,
>=20
> after seeing this issue, I looked into our nameserver log files and =
found similar entries.
>=20
> There are many queries for _afs3-vlserver including a filename. =
Sometimes the full path is included but in that case the "/afs/" prefix =
is omitted.
> The @sys is not involved here.
>=20
> The queries are made for each domain suffix that is configured in =
/etc/resolv.conf with the "search" directive.
>=20
> Here are some selected queries:
>=20
> * queries from Debian Bookworm with OpenAFS Client 1.8.13-1, Kernel =
6.1.0-38-amd64
> 24-Aug-2025 19:30:56.916 client @0x7fa6b6f11168 =
2001:638:60c:310::XXX:XXX#34611 (_afs3-vlserver._udp.htaccess): query: =
_afs3-vlserver._udp.htaccess IN SRV + (2001:638:60c:310::81:212)
> 25-Aug-2025 08:13:19.303 client @0x7fa6b793c168 =
2001:638:60c:310::XXX:XXX#52502 =
(_afs3-vlserver._udp.htaccess.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.htaccess.informatik.uni-goettingen.de IN SRV + =
(2001:638:60c:310::81:212)

The above queries are ok.  The application is attempting to open =
/afs/.htaccess which doesn=E2=80=99t exist and the OpenAFS cache manager =
is trying to resolve it as a rw-path to the cell =
htaccess.informatik.uni-goettingen.de which doesn=E2=80=99t exist.

The AuriStorFS client does not attempt to resolve cell aliases via DNS =
SRV or AFSDB queries but these queries are not unreasonable.

>=20
> * queries from Ubuntu 24.04 with OpenAFS Client 1.8.13.2-1ubuntu1, =
Kernel 6.14.0-28-generic
> 24-Aug-2025 01:26:34.718 client @0x7fa6b794e168 172.27.1.150#36732 =
(_afs3-vlserver._udp.timewarrior.json.informatik.uni-goettingen.de): =
query: _afs3-vlserver._udp.timewarrior.json.informatik.uni-goettingen.de =
IN SRV +E(0) (134.76.81.212)

The above two queries could be for the path /afs/timewarrior.json which =
is being resolved as an alias to the non-existent time =
warrior.json.informatik.uni-goettingen.de cell.  These queries are =
expected.

> 24-Aug-2025 17:46:05.241 client @0x7fa6b783f168 172.27.1.155#41379 =
(_afs3-vlserver._udp.informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-pr=
efix/usr/share/desktop-directories.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-pre=
fix/usr/share/desktop-directories.informatik.uni-goettingen.de IN SRV =
+E(0) (134.76.81.212)

The above queries are unexpected.  The path being access is =
/afs/informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-prefix/usr/share/d=
esktop-directories which should not be searched for as a cell or cell =
alias.  A lookup is being performed for =
"informatik.uni-goettingen.de/user/b/xxxx.xxxx/ulsi-prefix/usr/share/deskt=
op-directories=E2=80=9D as a single path component.

If your end user can reproduce this query, it would be interesting to =
strace the process and see what syscalls are being executed.

> 25-Aug-2025 07:15:47.756 client @0x7fa6b79fe168 172.27.2.4#34129 =
(_afs3-vlserver._udp.informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/=
.google_authenticator.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.=
google_authenticator.informatik.uni-goettingen.de IN SRV +E(0) =
(134.76.81.212)

Likewise a lookup is being performed for =
=E2=80=9Cinformatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.google_auth=
enticator=E2=80=9D as a single path component.

An strace of the originating process would be useful to examine.

> 25-Aug-2025 07:50:09.586 client @0x7fa6b6e9e168 172.21.0.1#35881 =
(_afs3-vlserver._udp.kateconfig.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.kateconfig.informatik.uni-goettingen.de IN SRV +E(0) =
(134.76.81.212)


This query is likely for /afs/.kateconfig which is ok.

> 25-Aug-2025 07:50:09.626 client @0x7fa6b6e9e168 172.21.0.1#38919 =
(_afs3-vlserver._udp.editorconfig.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.editorconfig.informatik.uni-goettingen.de IN SRV =
+E(0) (134.76.81.212)

This query is likely for /afs/.editorconfig which is likely ok.

> 25-Aug-2025 07:50:10.098 client @0x7fa6b78c5168 172.21.0.1#51962 =
(_afs3-vlserver._udp.kateproject.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.kateproject.informatik.uni-goettingen.de IN SRV =
+E(0) (134.76.81.212)

This query is likely for /afs/.kateproject which is ok.


> The OpenAFS servers are running on Debian Bookworm with version =
1.8.13-1.

The OpenAFS database and fileservers are uninvolved in the client side =
queries but thank you for letting us know.

>=20
> The DNS SRV records for afs are configured on our nameservers.

The Ubuntu 24.04 6.14.0-28-generic kernel supports BPF scripting so it =
might be possible for someone to write a script to capture the path =
components passed to afs_linux_lookup() and afs_linux_create() when the =
dentry->d_parent is /afs.

I do not believe OpenAFS fstrace logging has any trace points which =
would record the path component values at those entry points.

Jeffrey Altman