Hide Forgot
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.
Cross-filed case 01614836 on the Red Hat customer portal.
Bug #1325692 comment #3 also applies here, too. With the same questions.
Hi Robert, I managed to reproduce this issue, I will look into why it does reverse dns lookup.
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.
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.
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?
Yes, I will retest this based on RHEL 7.3.