tmux: problems with DNS queries

When starting a sysutils/tmux session or tmux pseudo terminals these entries can be found in the Unbound logfile:
Code:
Nov 03 20:26:45 unbound[326:0] info: 127.0.0.1 tmux?772?.?4. A IN
Nov 03 20:26:45 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:26:45 unbound[326:0] debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_new
Nov 03 20:26:45 unbound[326:0] info: resolving tmux?772?.?4. A IN
Nov 03 20:26:45 unbound[326:0] info: processQueryTargets: tmux?772?.?4. A IN
Nov 03 20:26:45 unbound[326:0] info: sending query: tmux?772?.?4. A IN
Nov 03 20:26:45 unbound[326:0] debug: sending to target: <.> 193.XXX.XXX.XXX#53
Nov 03 20:26:45 unbound[326:0] debug: cache memory msg=108478 rrset=102966 infra=3596 val=0
Nov 03 20:26:46 unbound[326:0] debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply
Nov 03 20:26:46 unbound[326:0] info: iterator operate: query tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: response for tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: reply from <.> 193.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] info: query response was THROWAWAY
Nov 03 20:26:46 unbound[326:0] info: processQueryTargets: tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: sending query: tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] debug: sending to target: <.> 193.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] debug: cache memory msg=108478 rrset=102966 infra=3596 val=0
Nov 03 20:26:46 unbound[326:0] debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply
Nov 03 20:26:46 unbound[326:0] info: iterator operate: query tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: response for tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: reply from <.> 193.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] info: query response was THROWAWAY
Nov 03 20:26:46 unbound[326:0] info: processQueryTargets: tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: sending query: tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] debug: sending to target: <.> 217.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] debug: cache memory msg=108478 rrset=102966 infra=3596 val=0
Nov 03 20:26:46 unbound[326:0] debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply
Nov 03 20:26:46 unbound[326:0] info: iterator operate: query tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: response for tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] info: reply from <.> 217.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] info: query response was NXDOMAIN ANSWER
Nov 03 20:26:46 unbound[326:0] info: finishing processing for tmux?772?.?4. A IN
Nov 03 20:26:46 unbound[326:0] debug: cache memory msg=108668 rrset=102966 infra=3596 val=0
Nov 03 20:26:46 unbound[326:0] info: 127.0.0.1 tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:26:46 unbound[326:0] debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_new
Nov 03 20:26:46 unbound[326:0] info: resolving tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] info: processQueryTargets: tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] info: sending query: tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] debug: sending to target: <.> 217.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] debug: cache memory msg=108668 rrset=102966 infra=3596 val=0
Nov 03 20:26:46 unbound[326:0] debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply
Nov 03 20:26:46 unbound[326:0] info: iterator operate: query tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] info: response for tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] info: reply from <.> 217.XXX.XXX.XXX#53
Nov 03 20:26:46 unbound[326:0] info: query response was NXDOMAIN ANSWER
Nov 03 20:26:46 unbound[326:0] info: finishing processing for tmux?772?.?4. AAAA IN
Nov 03 20:26:46 unbound[326:0] debug: cache memory msg=108858 rrset=102966 infra=3596 val=0
Nov 03 20:26:46 unbound[326:0] info: 127.0.0.1 tmux?772?.?4.local. A IN
Nov 03 20:26:46 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:26:46 unbound[326:0] info: 127.0.0.1 tmux?772?.?4.local. AAAA IN
Nov 03 20:26:46 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:29:26 unbound[326:0] info: 127.0.0.1 tmux?772?.?4. A IN
Nov 03 20:29:26 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:29:26 unbound[326:0] info: 127.0.0.1 tmux?772?.?4. AAAA IN
Nov 03 20:29:26 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:29:26 unbound[326:0] info: 127.0.0.1 tmux?772?.?4.local. A IN
Nov 03 20:29:26 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Nov 03 20:29:26 unbound[326:0] info: 127.0.0.1 tmux?772?.?4.local. AAAA IN
Nov 03 20:29:26 unbound[326:0] debug: worker request: max UDP reply size modified (65535 to max-udp-size)
Tmux has been initialized within a local LAN like this:
ssh -t myotherbox.local tmux
What me bothers are the queries to external DNS-servers (see XXXs).
How can this be prevented?
 
That's quite interesting. I am seeing queries as well for tmux, tmux.domain1.com, tmux.domain2.com where it cycles through each domain in my /etc/resolv.conf. I only see the gethostname(3) calls by grepping through the source code. That makes sense because of the hostname in the status bar. I don't see any function calls from a quick grep search.

EDIT: I don't see any DNS hostname lookup function calls from a quick grep search.
 
Last edited:
Any input is welcome.
Sometimes there is none for those who know what they are doing. People like myself (thanks God there are not many) who don't even know that he is talking to professionals, even those who may be run his own ISP as they laugh about it. Give me the best that you can think of, relevance or not; I will find a single line in that text that I never thought about, and I will use it here ... or elsewhere. Other than that, please accept my apologies. I'm figured it out last week through an responder. The Big dogs are everywhere here at FreeBSD. I just thank you guys for taking the time out to throw us future FreeBSD kings a bone :)
 
A rainy and otherwise boring day let me do some experiments on the issue.

My conclusion is that Unbound receives completely valid requests for resolving a domain name, and it simply tries to resolve it. For example we can run manually drill "tmux(772).%4", and we simply would expect hat unbound does whatever it is configured to do, usually to recursively resolve that domain name starting at the zero level domain "." and of course it would already bail out at the top level domain "%4" which does not exist nowadays, nonetheless unbound has to and correctly does preemptively fullfil that request. Therefore, I cannot see any misconfiguration at the side of unbound.

Apparently, the request comes from tmux. I tried to find some hints about a configurable parameter in tmux(1), but I didn't find anything useful.

Back to unbound. Even, if this is not a misconfiguration, unbound.conf(5) settings may be utilized, to prevent that these requests leave the local network. Once, I added the following lines to /etc/unbound.conf, unbound responds to the requests immediately by itself with the result code NXDOMAIN:
Code:
...
local-zone: "local" static
local-zone: "%0" static
local-zone: "%1" static
local-zone: "%2" static
local-zone: "%3" static
local-zone: "%4" static
local-zone: "%5" static
local-zone: "%6" static
local-zone: "%7" static
local-zone: "%8" static
local-zone: "%9" static
...
Code:
# drill "tmux(772).%4"
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 36990
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; tmux\(772\).%4.    IN    A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Nov  7 20:25:27 2015
;; MSG SIZE  rcvd: 30
Perhaps, you need to extend the list up to "%999", I don't know. Don't be afraid about the unbound performance. I use about 20000 local-zone: "some-domain.zzz" static entries for blocking advertisement-, malware-, and tracking-domains in my home network, and unbound does not seem to suffer from this additional load. From my experience, it won't suffer either from another 1000 static local void zones.

The entry local-zone: "local" static is quite useful also in another respect, since this prevents unbound from recursively passing tons of these Zeroconf mDNS requests, which accidentally went down the (u)DNS route, to its external peers.
 
I ran a quick test with tmux 2.1.0 installed by MacPorts on Mac OS X 10.11.1, and I did not see the issue in the query log of the configured name server.

However, my FreeBSD box (on which I can easily reproduce the issue) is a gateway/server (nameserver 127.0.0.1) while the Mac is a pure client computer (nameserver <gateway IP>). Perhaps this makes a difference.
 
For a quick check do tcpdump -ni <interface> port 53 and then in another session start tmux.
On FreeBSD you might get an output from Tcpdump like this, which is a DNS query to your nameserver:
Code:
# tcpdump -ni bge0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:38:49.460012 IP 172.xxx.xxx.141.58440 > 172.xxx.xxx.100.53: 41843+ [1au] A? tmux(860).%0. (41)

The committer ask for tests other than FreeBSD. So if you run Tmux on i.e. OpenBSD or Linux or anything else, please leave a note here or on the bugzilla link above.
I get no output from tcpdump(1) when running Tmux on a Linux system here. This is with the default configuration.
 
Has anyone suggested that this might be due to some convoluted prompt string containing the hostname?
 
Convoluted meaning a long, complex prompt string that might contain a value that causes the hostname to be resolved but is not obvious about it. Which variable it is in would depend on the shell.
 
The "normal" (normal as in "provided example code") way to do it is like so in .shrc or another file read by the shell:
Code:
# set prompt: ``username@hostname$ ''
PS1="`whoami`@`hostname | sed 's/\..*//'`"
case `id -u` in
  0) PS1="${PS1}# ";;
  *) PS1="${PS1}$ ";;
esac
Does hostname(1) use any DNS resolve functions?
 
Last edited by a moderator:
Faint whiff of syslogd? Name, pid and a small power-of-2 number.

EDIT: but no smoke.

The culprit might be w -n, trying to look up the creative hostnames.

Juha
 
tmux creates an active login entry into /var/run/utx.active for each session. It uses that odd invented hostname, it's convenient to see who's who, after all. Then someone/something else runs w -n or something similar, which does not understand the convention and is tricked into gethostbyname or similar. Check /etc/profile, /home/*/.profile and all those for all the shells for an innocent looking who. Could be in the crontabs too.

Just guessing, but it would fit the symptoms.

Juha
 
Old thread but I ran into this myself. The DNS requests are done as soon as you open a window. A single CTRL-B C (Create new window) seems to illicit a DNS request, it doesn't appear to be caused by anything else. At first I though it might be something in my status line but even the default does this.

I've looked through the tmux code, ran truss(1) on the process, it really doesn't look like it's tmux that's causing it. Perhaps it's actually libevent. If I have some time (and energy) I'll have a deeper look some time this week.

For posterity's sake: tmux-2.2_1, libevent2-2.0.22_1 running on 11-STABLE r305190.
 
This issue still exists. :-( I have contacted the maintainer of tmux (mat@). If there is no reply I will possibly open a PR.
I am wondering why this only happens on FreeBSD... and not NetBSD or Linux.
 
I noticed entries in my named.log (bind) when creating a new tmux session as well
tmux new -s test

edit: the last line in the PR above says it's a problem with tcsh not tmux
 
Back
Top