To do an MX lookup over Tor, this command has worked for for years:

  $ torsocks dig @"$dns_server" -t mx -q "$email_domain" +noclass +nocomments +nostats +short +tcp +nosearch

It just hangs forever and does not matter which DNS server is
supplied. In the past 8.8.8.8 worked. It’s unclear whether there is a
bug in the software or whether the network is broken, but certainly
it’s a defect for dig to not timeout. By default it should timeout
after 5 seconds.

First of all, why do you spam info@isc.org? The ISC pages clearly state how you should report bugs in BIND 9.

Second, it’s not clear where the bug is. I would recommend running the dig with -d argument and also using strace -f to see where the full command gets stuck.

* Ondřej Surý <ondrej@sury.org> [2024-09-04 11:16]:

First of all, please read your own source before taking a hostile
posture with uncivil tone. I will quote it for you here and give you
the exact URL¹.

In particular, be sure to read the last sentence where email is
explicitly solicited for this scenario. The Gitlab instance as a bug
tracker is a non-starter due to a broken CAPTCHA as a barrier to
entry. It is therefore an exclusive website and I am in the excluded
group.

Please also familiarize yourself with Debian policy². Search for
“Don't file bugs upstream” on that page. Note as well the Debian
Social Contract³ which ¶3 states “We will not hide problems”. That
principle implies bug tracker access particularly when upstream
resources are exclusive.

The “-d” parameter is undocumented (another bug) and in this case it
has no effect. No output is generated before the hang. When “strace
-f” is used as follows:

  $ torsocks strace -f dig @"$dns_server" -d -t mx -q "$email_domain" +noclass +nocomments +nostats +short +tcp +nosearch

The tail of the output when it hangs is as follows:

===8<----------------------------------------
…
mprotect(0x7efeadb8d000, 4096, PROT_READ) = 0
mprotect(0x7efeae19a000, 4096, PROT_READ) = 0
mprotect(0x56499f748000, 4096, PROT_READ) = 0
mprotect(0x7efeae1ce000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7efeae16c000, 101230)          = 0
readlink("/etc/malloc.conf", 0x7ffdd2b44370, 4096) = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efeae184000
madvise(0x7efeae184000, 4096, MADV_DONTNEED) = 0
munmap(0x7efeae184000, 4096)            = 0
getuid()                                = 1000
geteuid()                               = 1000
futex(0x7efeadf547c0, FUTEX_WAIT_PRIVATE, 2, NULL
===8<----------------------------------------

Footnotes:

¹ https://www.isc.org/reportbug/
² https://www.debian.org/Bugs/Reporting
³ https://www.debian.org/social_contract

No, it’s not a bug.

This probably means that dig isn’t executed at all.

The last few lines are useless. Full output is needed.

Ondrej
--
Ondřej Surý (He/Him)

Since the strace indicates the program gets stuck inside jemalloc, I’ve tried to recompile dig with and without jemalloc and the aforementioned behavior doesn’t happen when BIND 9 is not compiled with jemalloc.

This can be hardly fixed on BIND 9 side as it happens before the control is passed to the main library.

I’ll leave it up for the torsocks maintainer to decide whether this is problem in torsocks or in jemalloc.

#0  futex_wait (private=0, expected=2, futex_word=0x7ffff7cd57c0 <init_lock+64>) at ../sysdeps/nptl/
futex-internal.h:146                              #1  __GI___lll_lock_wait (futex=futex@entry=0x7fff
f7cd57c0 <init_lock+64>, private=0) at ./nptl/lowlevellock.c:49
#2  0x00007ffff76ab3d2 in lll_mutex_lock_optimized (mutex=0x7ffff7cd57c0 <init_lock+64>) at ./nptl/p
thread_mutex_lock.c:48                            #3  ___pthread_mutex_lock (mutex=mutex@entry=0x7ff
ff7cd57c0 <init_lock+64>) at ./nptl/pthread_mutex_lock.c:93
#4  0x00007ffff7c923a0 in malloc_mutex_lock_final (mutex=0x7ffff7cd5780 <init_lock>) at include/jema
lloc/internal/mutex.h:151                         #5  je_malloc_mutex_lock_slow (mutex=mutex@entry=0
x7ffff7cd5780 <init_lock>) at src/mutex.c:90      #6  0x00007ffff7c21249 in malloc_mutex_lock (mutex
=0x7ffff7cd5780 <init_lock>, tsdn=0x0) at include/jemalloc/internal/mutex.h:217
#7  malloc_init_hard () at src/jemalloc.c:2118    #8  0x00007ffff7c22755 in malloc_init () at src/je
malloc.c:298

#9  imalloc_init_check (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2658
#10 imalloc (dopts=<optimized out>, sopts=<optimized out>) at src/jemalloc.c:2689
#11 je_malloc_default (size=40) at src/jemalloc.c:2722
#12 0x00007ffff7fcd900 in malloc (size=40) at ../include/rtld-malloc.h:56
#13 _dl_map_object_deps (map=map@entry=0x7ffff7f07580, preloads=preloads@entry=0x0, npreloads=nprelo
ads@entry=0, trace_mode=trace_mode@entry=0, open_mode=open_mode@entry=-2147483648) at ./elf/dl-deps.
c:463                                             #14 0x00007ffff7fd6a6d in dl_open_worker_begin (a=
a@entry=0x7fffffffac30) at ./elf/dl-open.c:592    #15 0x00007ffff776dfca in __GI__dl_catch_exception
 (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at ./elf/dl-error-skelet
on.c:208                                          #16 0x00007ffff7fd61c6 in dl_open_worker (a=a@entr
y=0x7fffffffac30) at ./elf/dl-open.c:782

#17 0x00007ffff776dfca in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized ou
t>, args=<optimized out>) at ./elf/dl-error-skeleton.c:208
#18 0x00007ffff7fd65b8 in _dl_open (file=0x7ffff7fba04c "libc.so.6", mode=<optimized out>, caller_dl
open=0x7ffff7faf9bf <tsocks_init+127>, nsid=<optimized out>, argc=3, argv=0x7fffffffdd98, env=0x7fff
ffffddb8) at ./elf/dl-open.c:884                  #19 0x00007ffff76a4438 in dlopen_doit (a=a@entry=0
x7fffffffaea0) at ./dlfcn/dlopen.c:56             #20 0x00007ffff776dfca in __GI__dl_catch_exception
 (exception=exception@entry=0x7fffffffae00, operate=<optimized out>, args=<optimized out>) at ./elf/
dl-error-skeleton.c:208                           #21 0x00007ffff776e07f in __GI__dl_catch_error (ob
jname=0x7fffffffae58, errstring=0x7fffffffae60, mallocedp=0x7fffffffae57, operate=<optimized out>, a
rgs=<optimized out>) at ./elf/dl-error-skeleton.c:227

#22 0x00007ffff76a3f27 in _dlerror_run (operate=op
erate@entry=0x7ffff76a43e0 <dlopen_doit>, args=args@entry=0x7fffffffaea0) at ./dlfcn/dlerror.c:138
#23 0x00007ffff76a44e9 in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>, fi
le=<optimized out>) at ./dlfcn/dlopen.c:71        #24 ___dlopen (file=<optimized out>, mode=<optimiz
ed out>) at ./dlfcn/dlopen.c:81                   #25 0x00007ffff7faf9bf in init_libc_symbols () at
./src/lib/torsocks.c:233                          #26 tsocks_init () at ./src/lib/torsocks.c:332
#27 0x00007ffff7fb6616 in tsocks_once (o=0x7ffff7fc2060 <init_once>, init_routine=0x7ffff7faf940 <ts
ocks_init>) at ./src/common/compat.c:94

      #28 0x00007ffff7fcf9ce in call_init (
    env=0x7fffffffddb8, argv=0x7fffffffdd98,          argc=3, l=<optimized out>)
    at ./elf/dl-init.c:74                         #29 call_init (l=<optimized out>, argc=3,
    argv=0x7fffffffdd98, env=0x7fffffffddb8)          at ./elf/dl-init.c:26
#30 0x00007ffff7fcfab4 in _dl_init (                  main_map=0x7ffff7ffe2e0, argc=3,
    argv=0x7fffffffdd98, env=0x7fffffffddb8)          at ./elf/dl-init.c:121
#31 0x00007ffff7fe5a80 in _dl_start_user ()          from /lib64/ld-linux-x86-64.so.2
#32 0x0000000000000003 in ?? ()                   #33 0x00007fffffffe09e in ?? ()
#34 0x00007fffffffe0cc in ?? ()                   #35 0x00007fffffffe0cf in ?? ()
#0  futex_wait (private=0, expected=2, futex_word=0x7ffff7cd57c0 <init_lock+64>) at ../sysdeps/nptl/
futex-internal.h:146                              #1  __GI___lll_lock_wait (futex=futex@entry=0x7fff
f7cd57c0 <init_lock+64>, private=0) at ./nptl/lowlevellock.c:49
#2  0x00007ffff76ab3d2 in lll_mutex_lock_optimized (mutex=0x7ffff7cd57c0 <init_lock+64>) at ./nptl/p
thread_mutex_lock.c:48                            #3  ___pthread_mutex_lock (mutex=mutex@entry=0x7ff
ff7cd57c0 <init_lock+64>) at ./nptl/pthread_mutex_lock.c:93
#4  0x00007ffff7c923a0 in malloc_mutex_lock_final (mutex=0x7ffff7cd5780 <init_lock>) at include/jema
lloc/internal/mutex.h:151                         #5  je_malloc_mutex_lock_slow (mutex=mutex@entry=0
x7ffff7cd5780 <init_lock>) at src/mutex.c:90      #6  0x00007ffff7c21249 in malloc_mutex_lock (mutex
=0x7ffff7cd5780 <init_lock>, tsdn=0x0) at include/jemalloc/internal/mutex.h:217
#7  malloc_init_hard () at src/jemalloc.c:2118
#8  0x00007ffff7c22755 in malloc_init () at src/jemalloc.c:298
#9  imalloc_init_check (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2658
#10 imalloc (dopts=<optimized out>, sopts=<optimized out>) at src/jemalloc.c:2689
#11 je_malloc_default (size=40) at src/jemalloc.c:2722
#12 0x00007ffff7fcd900 in malloc (size=40) at ../include/rtld-malloc.h:56
#13 _dl_map_object_deps (map=map@entry=0x7ffff7f07580, preloads=preloads@entry=0x0, npreloads=nprelo
ads@entry=0, trace_mode=trace_mode@entry=0, open_mode=open_mode@entry=-2147483648) at ./elf/dl-deps.
c:463                                             #14 0x00007ffff7fd6a6d in dl_open_worker_begin (a=
a@entry=0x7fffffffac30) at ./elf/dl-open.c:592    #15 0x00007ffff776dfca in __GI__dl_catch_exception
 (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at ./elf/dl-error-skelet
on.c:208                                          #16 0x00007ffff7fd61c6 in dl_open_worker (a=a@entr
y=0x7fffffffac30) at ./elf/dl-open.c:782

#17 0x00007ffff776dfca in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized ou
t>, args=<optimized out>) at ./elf/dl-error-skeleton.c:208
#18 0x00007ffff7fd65b8 in _dl_open (file=0x7ffff7fba04c "libc.so.6", mode=<optimized out>, caller_dl
open=0x7ffff7faf9bf <tsocks_init+127>, nsid=<optimized out>, argc=3, argv=0x7fffffffdd98, env=0x7fff
ffffddb8) at ./elf/dl-open.c:884                  #19 0x00007ffff76a4438 in dlopen_doit (a=a@entry=0
x7fffffffaea0) at ./dlfcn/dlopen.c:56             #20 0x00007ffff776dfca in __GI__dl_catch_exception
 (exception=exception@entry=0x7fffffffae00, operate=<optimized out>, args=<optimized out>) at ./elf/
dl-error-skeleton.c:208                           #21 0x00007ffff776e07f in __GI__dl_catch_error (ob
jname=0x7fffffffae58, errstring=0x7fffffffae60, mallocedp=0x7fffffffae57, operate=<optimized out>, a
rgs=<optimized out>) at ./elf/dl-error-skeleton.c:227
#22 0x00007ffff76a3f27 in _dlerror_run (operate=operate@entry=0x7ffff76a43e0 <dlopen_doit>, args=arg
s@entry=0x7fffffffaea0) at ./dlfcn/dlerror.c:138

#23 0x00007ffff76a44e9 in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>, fi
le=<optimized out>) at ./dlfcn/dlopen.c:71        #24 ___dlopen (file=<optimized out>, mode=<optimiz
ed out>) at ./dlfcn/dlopen.c:81                   #25 0x00007ffff7faf9bf in init_libc_symbols () at
./src/lib/torsocks.c:233                          #26 tsocks_init () at ./src/lib/torsocks.c:332
#27 0x00007ffff7fb6616 in tsocks_once (o=0x7ffff7fc2060 <init_once>, init_routine=0x7ffff7faf940 <ts
ocks_init>) at ./src/common/compat.c:94           #28 0x00007ffff7faf74b in tsocks_initialize () at
./src/lib/torsocks.c:711                          #29 0x00007ffff7fb3235 in syscall (number=number@e
ntry=2) at ./src/lib/syscall.c:628                #30 0x00007ffff7c9503b in os_overcommits_proc () a
t src/pages.c:627                                 #31 je_pages_boot () at src/pages.c:789
#32 0x00007ffff7c206a5 in malloc_init_hard_a0_locked () at src/jemalloc.c:1834
#33 0x00007ffff7c20fe1 in malloc_init_hard () at src/jemalloc.c:2129

#34 0x00007ffff7c22755 in malloc_init () at src/jemalloc.c:298
#35 imalloc_init_check (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2658
#36 imalloc (dopts=<optimized out>, sopts=<optimized out>) at src/jemalloc.c:2689
#37 je_malloc_default (size=72704) at src/jemalloc.c:2722
#38 0x00007ffff74a57ba in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#39 0x00007ffff7fcf9ce in call_init (env=0x7fffffffddb8, argv=0x7fffffffdd98, argc=3, l=<optimized o
ut>) at ./elf/dl-init.c:74                        #40 call_init (l=<optimized out>, argc=3, argv=0x7
fffffffdd98, env=0x7fffffffddb8) at ./elf/dl-init.c:26
#41 0x00007ffff7fcfab4 in _dl_init (main_map=0x7ffff7ffe2e0, argc=3, argv=0x7fffffffdd98, env=0x7fff
ffffddb8) at ./elf/dl-init.c:121                  #42 0x00007ffff7fe5a80 in _dl_start_user () from /
lib64/ld-linux-x86-64.so.2                        #43 0x0000000000000003 in ?? ()
#44 0x00007fffffffe09e in ?? ()
#45 0x00007fffffffe0cc in ?? ()                   #46 0x00007fffffffe0cf in ?? ()
#47 0x0000000000000000 in ?? ()

Ondrej
--
Ondřej Surý (He/Him)

dig doing MX lookups over tor, which further suggests the problem is
with torsocks. However, I must say I did not touch torsocks
recently. In fact, I have pinned torsocks version 2.3.0-3 because bug
1069949 broke torsocks version 2.4.0-1.

Version 2.3.0-3 of torsocks still functions for other applications. It
only quit working for dig. So apparently dig uses some network
facility that other apps do not which was recently broken in torsocks
despite torsocks being pinned to version 2.3.0-3.

MX lookups by way of torsocks+dig only broke relatively recently. I
suppose a package I upgraded or installed recently must have some kind
of interplay with torsocks or dig, though nothing looks obvious in the
apt logs.

Anyway, whoever tries to tackle this problem: if you cannot reproduce
it, try torsocks version 2.3.0-3 with bind9-dnsutils version
1:9.18.28-1~deb12u2.

Sorry for the erroneous report against bind9-dnsutils.

Hey,

What you mean by "torsocks alternatives"?

You say it is reproducible with
torsocks 2.3.0-3 is old-oldstable
bind9-dnsutils  1:9.18.28-1~deb12u2 is olstable

Well just pin a binary and mix it with newer stuff from other releases is not
support and will break, because the glib versions have been updated and other
base libraries. At least you need to rebuild the old torsocks for your
Bookworm system. This may be a workaround for you to get torssocks working
again, but still than you are on your own and Debian cannot help you anymore
with that setup.
We can only support combinations for software within one released version,
otherwise we can't even update core libraries.
Btw. only stable currently Trixie and by some extend oldstable Bookworm is
supported anyways.

Sorry to hear, that you are still hold back by 1069949 to update - but we
cannot do miracles :(

If I try out your command on my sid system I end up with #1069949. So I tend
to merge it with that bugreport, that is  already reported upstream.

Regards,

hefee