[Bug network/27048] New: Problem resolving one specific name (DNS problem)

[Bug network/27048] New: Problem resolving one specific name (DNS problem)

[eric.brunet at ens dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=27048

            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=13035&action=edit
Output of the strace command

Hi,

This website suggests very strongly to report bugs to one's distribution first,
in my case the fedora. I did that, see 

https://bugzilla.redhat.com/show_bug.cgi?id=1904670 

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={sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("195.5.209.150")}, msg_namelen=16,
msg_iov=[{iov_base="\xb1\xde\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x05\x6c\x6f\x67\x69\x6e\x04\x6c\x69\x76\x65\x03\x63\x6f\x6d\x00\x00\x01\x00\x01",
iov_len=32}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0 <unfinished ...>

recvmsg(20, {msg_name={sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("195.5.209.150")}, msg_namelen=128->16,
msg_iov=[{iov_base="\xb1\xde\x83\x80\x00\x01\x00\x0c\x00\x08\x00\x00\x05\x6c\x6f\x67\x69\x6e\x04\x6c\x69\x76\x65\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\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\x6c\x67\x04\x70\x72\x6f\x64\x06\x61\x61\x64\x6d\x73\x61\x0e\x74\x72\x61\x66\x66\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\x74\x6d\x01\x61\x03\x70\x72\x64\x04\x61\x61\x64\x67\x06\x61\x6b\x61\x64\x6e\x73\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\x01\x00\x00\x00\x2a\x00\x04\x14\xbe\x89\x62\xc0\x9d\x00\x01\x00\x01\x00\x00\x00\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\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x33\x2d\x31\x32\x39\xc0\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\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x09\x06\x61\x35\x2d\x31\x33\x30\xc1\x76\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\x61\x31\x38\x2d\x31\x32\x38\xc1\x76\xc0\xaf\x00\x02\x00\x01\x00\x02\x64\xba\x00\x0a\x07\x61\x31\x31\x2d\x31\x32\x39\xc0\xaf",
iov_len=65535}], msg_iovlen=1, msg_control=[{cmsg_len=32,
cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD,
cmsg_data={tv_sec=1607172731, tv_usec=554317}}, {cmsg_len=17,
cmsg_level=SOL_IP, cmsg_type=IP_TOS, cmsg_data=[0]}], msg_controllen=56,
msg_flags=0}, 0) = 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 server
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 host
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/27048] Problem resolving one specific name (DNS problem)

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27048

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
                 CC|                            |carlos at redhat dot com
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to eric.brunet from comment #0)
> Is there anything I can do to help?

This doesn't seem related to glibc at all.

If the resolution of the name works as expected (DNS stub resolver in glibc +
your configured recursive resolver) then the rest of the problem is on the
network or the server end. The network issue might be a local issue with
filtering or a remote issue with filtering.

You will have to debug this more and come back with a conclusive example
showing a defect in the C library, or other library.

I am able to login to login.live.com just fine from my systems using Fedora 32
on x86_64. So this looks like a local issue relevant to your network.

-- 
You are receiving this mail because:
You are on the CC list for the bug.