Re: Strange DNS SRV traffic resulting from stat() in 1.8.13.2
Jeffrey Altman <[email protected]> Mon, 25 Aug 2025 11:19:59 -0400
| Newsgroups | gmane.comp.file-systems.openafs.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Gunnar, Thanks for checking. Additional response inline ... > On Aug 25, 2025, at 3:41=E2=80=AFAM, Gunnar Krull = <[email protected]> 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