From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E51C53971C35; Thu, 10 Dec 2020 16:38:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E51C53971C35 From: "eric.brunet at ens dot fr" To: glibc-bugs@sourceware.org Subject: [Bug network/27048] New: Problem resolving one specific name (DNS problem) Date: Thu, 10 Dec 2020 16:38:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: eric.brunet at ens dot fr X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 16:38:38 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27048 Bug ID: 27048 Summary: Problem resolving one specific name (DNS problem) Product: glibc Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: network Assignee: unassigned at sourceware dot org Reporter: eric.brunet at ens dot fr Target Milestone: --- Created attachment 13035 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D13035&action=3Ded= it Output of the strace command Hi, This website suggests very strongly to report bugs to one's distribution fi= rst, in my case the fedora. I did that, see=20 https://bugzilla.redhat.com/show_bug.cgi?id=3D1904670=20 but got no answer so far. Also,I believe the bug does not depend on the distribution because it also affects android smartphones. I must assume that there is some similar code between glibc and android's libc. I am now copying the description of the fedora bug. ------------------------------------------------------------ Hi My system seems unable to get the IP for the domain login.live.com from the= DNS server of my ISP. I am not sure if the problem is with the libc (I tried to select the relevant component, libbind, I hope I got it right) or with the = name server from my ISP. I am afraid no one will be able to replicate the bug, as said name server refuses connections from the outside, but I still think it deserves to be investigated and I tried hard to give all the relevant information. The name server of my ISP is 195.5.209.150. It works well for nearly everything: % host www.live.com 195.5.209.150 | grep "has address" a-0010.a-msedge.net has address 204.79.197.212 But host doesn't give any answer for login.live.com % host login.live.com 195.5.209.150 ;; Connection to 195.5.209.150#53(195.5.209.150) for login.live.com failed: connection refused. Also, nothing works for that domain: I can't open http://login.live.com with firefox, and I can't connect to my skype account. This is why I think it is= an issue with the part of the libc dealing with name resolver, and not simply = with the host binary. Another important point is that my android smartphones have the same issue, but I think they are using the same libc internally? Am I correct? Note that I can get the IP from another nameserver % host login.live.com 8.8.8.8 | grep 'has address' | head -1 www.tm.a.prd.aadg.akadns.net has address 20.190.137.7 And note also that I can get the IP from my ISP nameserver using dig: dig +short login.live.com @195.5.209.150 | tail -1 40.126.9.66 this means that my ISP's nameserver is correctly working at least partially! (is dig using a method different from host to resolve names?) I tried to explore the issue using strace: % strace -s1000 -x -f -o strace.log host login.live.com 195.5.209.150 Here are the two relevant lines: sendmsg(20, {msg_name=3D{sa_family=3DAF_INET, sin_port=3Dhtons(53), sin_addr=3Dinet_addr("195.5.209.150")}, msg_namelen=3D16, msg_iov=3D[{iov_base=3D"\xb1\xde\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0= 5\x6c\x6f\x67\x69\x6e\x04\x6c\x69\x76\x65\x03\x63\x6f\x6d\x00\x00\x01\x00\x= 01", iov_len=3D32}], msg_iovlen=3D1, msg_controllen=3D0, msg_flags=3D0}, 0 recvmsg(20, {msg_name=3D{sa_family=3DAF_INET, sin_port=3Dhtons(53), sin_addr=3Dinet_addr("195.5.209.150")}, msg_namelen=3D128->16, msg_iov=3D[{iov_base=3D"\xb1\xde\x83\x80\x00\x01\x00\x0c\x00\x08\x00\x00\x0= 5\x6c\x6f\x67\x69\x6e\x04\x6c\x69\x76\x65\x03\x63\x6f\x6d\x00\x00\x01\x00\x= 01\xc0\x0c\x00\x05\x00\x01\x00\x00\x00\x75\x00\x17\x05\x6c\x6f\x67\x69\x6e\= x03\x6d\x73\x61\x0a\x6d\x73\x69\x64\x65\x6e\x74\x69\x74\x79\xc0\x17\xc0\x2c= \x00\x05\x00\x01\x00\x00\x00\x56\x00\x2a\x03\x77\x77\x77\x02\x74\x6d\x02\x6= c\x67\x04\x70\x72\x6f\x64\x06\x61\x61\x64\x6d\x73\x61\x0e\x74\x72\x61\x66\x= 66\x69\x63\x6d\x61\x6e\x61\x67\x65\x72\x03\x6e\x65\x74\x00\xc0\x4f\x00\x05\= x00\x01\x00\x00\x00\x56\x00\x0c\x04\x70\x72\x64\x61\x04\x61\x61\x64\x67\xc0= \x36\xc0\x85\x00\x05\x00\x01\x00\x00\x01\x19\x00\x1b\x03\x77\x77\x77\x02\x7= 4\x6d\x01\x61\x03\x70\x72\x64\x04\x61\x61\x64\x67\x06\x61\x6b\x61\x64\x6e\x= 73\xc0\x74\xc0\x9d\x00\x01\x00\x01\x00\x00\x00\x2a\x00\x04\x28\x7e\x09\x08\= xc0\x9d\x00\x01\x00\x01\x00\x00\x00\x2a\x00\x04\x14\xbe\x89\x4b\xc0\x9d\x00= \x01\x00\x01\x00\x00\x00\x2a\x00\x04\x28\x7e\x09\x49\xc0\x9d\x00\x01\x00\x0= 1\x00\x00\x00\x2a\x00\x04\x14\xbe\x89\x62\xc0\x9d\x00\x01\x00\x01\x00\x00\x= 00\x2a\x00\x04\x14\xbe\x89\x60\xc0\x9d\x00\x01\x00\x01\x00\x00\x00\x2a\x00\= x04\x28\x7e\x09\x06\xc0\x9d\x00\x01\x00\x01\x00\x00\x00\x2a\x00\x04\x28\x7e= \x09\x42\xc0\x9d\x00\x01\x00\x01\x00\x00\x00\x2a\x00\x04\x14\xbe\x89\x45\xc= 0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x33\x2d\x31\x32\x39\x= c0\xaf\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x39\x2d\x31\= x32\x38\xc0\xaf\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x14\x07\x61\x31= \x32\x2d\x31\x33\x31\x06\x61\x6b\x61\x67\x74\x6d\x03\x6f\x72\x67\x00\xc0\xa= f\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x35\x2d\x31\x33\x30\xc1\x= 76\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x37\x2d\x31\x33\= x31\xc0\xaf\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x31\x2d= \x31\x32\x38\xc0\xaf\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x0a\x07\x6= 1\x31\x38\x2d\x31\x32\x38\xc1\x76\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x= 00\x0a\x07\x61\x31\x31\x2d\x31\x32\x39\xc0\xaf", iov_len=3D65535}], msg_iovlen=3D1, msg_control=3D[{cmsg_len=3D32, cmsg_level=3DSOL_SOCKET, cmsg_type=3DSO_TIMESTAMP_OLD, cmsg_data=3D{tv_sec=3D1607172731, tv_usec=3D554317}}, {cmsg_len=3D17, cmsg_level=3DSOL_IP, cmsg_type=3DIP_TOS, cmsg_data=3D[0]}], msg_controllen= =3D56, msg_flags=3D0}, 0) =3D 493 (I am attaching the whole strace.log.) I am not an expert in the DNS protocol, but it seems to me that the name se= rver replied to the request. For instance, I can see the IP address 40.126.9.66 (from dig's answer) as \x28\x7e\x09\x42 in the recvmsg string. And still ho= st gives me a "connection refused". So it seems to me that my ISP's nameserver sends some answer that the name resolver library is unable to understand. Maybe the nameserver's answer is incorrect, or maybe there is a bug in the resolver library, I am not able to say. I initially wanted to file a bug against glibc directly, but the glibc bug system strongly suggests to first try with one's distribution first. I have an uptodate fedora 32 on x86_64 with bind-libs-9.11.24-2.fc32.x86_64 (and same version number for bind-utils, etc.) Is there anything I can do to help? --=20 You are receiving this mail because: You are on the CC list for the bug.=