Created attachment 1736654 [details]
strace of the host command

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?