Bug 1325695

Summary: CUPS performs reverse DNS lookups even "HostNameLookups off" is set
Product: Red Hat Enterprise Linux 7 Reporter: Robert Scheck <redhat-bugzilla>
Component: cupsAssignee: Zdenek Dohnal <zdohnal>
Status: CLOSED CURRENTRELEASE QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: high    
Version: 7.2CC: fweimer, jpopelka, mdshaikh, psklenar, redhat-bugzilla, thozza, zdohnal
Target Milestone: rc   
Target Release: 7.4   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-27 16:20:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1298243, 1380362, 1393869    

Description Robert Scheck 2016-04-10 17:48:37 UTC 
Description of problem:
For the configuration of CUPS see bug #1324662 - configure CUPS as described
in the previously mentioned bug report and start it. Use e.g. strace to see
which reverse DNS lookups are fired while visiting the CUPS web interface (use 
the external IP address, not localhost, e.g. http://example.net:631):

  strace -p <PID of CUPS> -ff -s 4096 2>&1 | grep "htons(53)"

--- snipp ---
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 22
connect(22, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.122.1")}, 16) = 0
gettimeofday({1460310250, 649964}, NULL) = 0
poll([{fd=22, events=POLLOUT}], 1, 0)   = 1 ([{fd=22, revents=POLLOUT}])
sendmmsg(22, {{{msg_name(0)=NULL, msg_iov(1)=[{"4\354\1\0\0\1\0\0\0\0\0\0\3[v1\21fd3b:d910:cd43::2]\0\0\1\0\1", 39}], msg_controllen=0, msg_flags=0}, 39}, {{msg_name(0)=NULL, msg_iov(1)=[{"l^\1\0\0\1\0\0\0\0\0\0\3[v1\21fd3b:d910:cd43::2]\0\0\34\0\1", 39}], msg_controllen=0, msg_flags=MSG_WAITALL|MSG_SYN|MSG_RST|MSG_ERRQUEUE|MSG_WAITFORONE|MSG_CMSG_CLOEXEC|0x861c0010}, 39}}, 2, MSG_NOSIGNAL) = 2
poll([{fd=22, events=POLLIN}], 1, 5000) = 1 ([{fd=22, revents=POLLIN}])
ioctl(22, FIONREAD, [114])              = 0
recvfrom(22, "4\354\201\203\0\1\0\0\0\1\0\0\3[v1\21fd3b:d910:cd43::2]\0\0\1\0\1\0\0\6\0\1\0\0\0231\0@\1a\froot-servers\3net\0\5nstld\fverisign-grs\3com\0x*X(\0\0\7\10\0\0\3\204\0\t:\200\0\1Q\200", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.122.1")}, [16]) = 114
gettimeofday({1460310250, 650723}, NULL) = 0
poll([{fd=22, events=POLLIN}], 1, 4999) = 1 ([{fd=22, revents=POLLIN}])
ioctl(22, FIONREAD, [114])              = 0
recvfrom(22, "l^\201\203\0\1\0\0\0\1\0\0\3[v1\21fd3b:d910:cd43::2]\0\0\34\0\1\0\0\6\0\1\0\0\0231\0@\1a\froot-servers\3net\0\5nstld\fverisign-grs\3com\0x*X(\0\0\7\10\0\0\3\204\0\t:\200\0\1Q\200", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.122.1")}, [16]) = 114
close(22)                               = 0
--- snapp ---

The IP address fd3b:d910:cd43::2 (obfuscated using random IPv6 ULA) is the
host performing the HTTP connect to 631/TCP ("client").

Version-Release number of selected component (if applicable):
cups-1.6.3-22.el7.x86_64

How reproducible:
Everytime, see above.

Actual results:
CUPS performs reverse DNS lookups even "HostNameLookups off" is set.

Expected results:
No reverse DNS lookups when "HostNameLookups off" is set.
Comment 2 Robert Scheck 2016-04-10 17:59:05 UTC 
Cross-filed case 01614836 on the Red Hat customer portal.
Comment 3 Robert Scheck 2016-04-16 00:13:47 UTC 
Bug #1325692 comment #3 also applies here, too. With the same questions.
Comment 7 Zdenek Dohnal 2016-12-12 13:04:45 UTC 
Hi Robert,

I managed to reproduce this issue, I will look into why it does reverse dns lookup.
Comment 13 Florian Weimer 2017-01-19 16:07:26 UTC 
This:

sendmmsg(22, {{{msg_name(0)=NULL, msg_iov(1)=[{"4\354\1\0\0\1\0\0\0\0\0\0\3[v1\21fd3b:d910:cd43::2]\0\0\1\0\1", 39}], msg_controllen=0, msg_flags=0}, 39}, {{msg_name(0)=NULL, msg_iov(1)=[{"l^\1\0\0\1\0\0\0\0\0\0\3[v1\21fd3b:d910:cd43::2]\0\0\34\0\1", 39}], msg_controllen=0, msg_flags=MSG_WAITALL|MSG_SYN|MSG_RST|MSG_ERRQUEUE|MSG_WAITFORONE|MSG_CMSG_CLOEXEC|0x861c0010}, 39}}, 2, MSG_NOSIGNAL) = 2

is a *forward* DNS lookup for a syntactically invalid DNS name, something like:

[v1.fd3b:d910:cd43::2]

although the length field for the second label is off by one, along with the overall packet length (17 vs 18, 39 vs 40).  I assume this corruption is due to your obfuscation attempt.

Something within CUPS calls getaddrinfo on this name, for the AF_UNSPEC family (because the above is a parallel A/AAAA query).  This could be the result of a CUPS misconfiguration.
Comment 14 Robert Scheck 2017-01-19 16:55:01 UTC 
The CUPS configuration is mentioned at bug #1324662 comment #0. And the
fd3b:d910:cd43::2 is the client IP address connecting to fd3b:d910:cd43::3,
which is the CUPS server. And yes, I didn't pay attention if the changed
IPv6 address has the same length - sorry.
Comment 15 Zdenek Dohnal 2017-02-08 13:35:13 UTC 
After clean installation of RHEL-7.3 situation totally reversed. This bug now seems it is not no longer in RHEL-7.3, but bug #1325692 appeared. Robert, would you mind testing if these bugs are still in RHEL-7.3?
Comment 16 Robert Scheck 2017-02-08 13:44:48 UTC 
Yes, I will retest this based on RHEL 7.3.