https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212272
Bug ID: 212272
Summary: w(1): 'w -n' makes bogus DNS queries
Product: Base System
Version: 11.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs@FreeBSD.org
Reporter: citrin...@citrin.ru
Created attachment 174235
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=174235&action=edit
Path to revert r199655
When tmux is used, utmp file (/var/run/utx.active) contains strings like
tmux(1104).%1, tmux(1104).%2 and so on in hostname field.
'w -n' command tries to resolve tmux(PID).%PTS strings, which causes delay and
unnecessary load on root DNS servers.
This behavior was introduced in r199655:
https://svnweb.freebsd.org/changeset/base/199655
Problems with such behavior:
1. It not exactly matches documentation. Man says about -n flag "Do not attempt
to resolve network addresses (normally w interprets addresses and attempts to
display them as names)" and says nothing about resolving host to IP.
2. Even if man page will be updated to match current implementation this
behavior will be not consistent with other commands: -n for most other commands
means "no DNS resolving at all".
3. if tmux (and may be screen) is used, 'w -n' makes bogus DNS queries, which
end up on root DNS servers. I hope we don't want next paper like "Analysis of
DNS root server bogus queries" to contain paragraph about FreeBSD.
Patch to remove host->IP resolving (revert r199655) with -n is attached (patch
against stable/11, but should apply on head).
Another option is to check, that host string to contains only [a-zA-Z0-9_.]
before resolving. I don't like it because:
1. pre r199655 'w -n' behavior matches 'w -n' on NetBSD and -n flag in other
commands.
2. w.c is already complicated (for the simple task it performs) lets don't make
it more complicated
3. If somebody want to see only IP in 'w -n' output it is better to run sshd
with -u0 flag, than resolve twice: IP to host in sshd and host to IP in 'w -n'
command.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
