Bug 20844 - getaddrinfo() fails in some instances with AF_UNSPEC set
Summary: getaddrinfo() fails in some instances with AF_UNSPEC set
Status: RESOLVED WORKSFORME
Alias: None
Product: glibc
Classification: Unclassified
Component: network (show other bugs)
Version: 2.24
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-20 02:17 UTC by Ezra Umen
Modified: 2017-01-02 16:04 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2016-11-22 00:00:00
fweimer: security-


Attachments
Example of failure (367 bytes, text/x-csrc)
2016-11-20 02:17 UTC, Ezra Umen
Details
getaddrinfo failure network capture (1.33 KB, application/vnd.tcpdump.pcap)
2016-11-22 21:55 UTC, Ezra Umen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ezra Umen 2016-11-20 02:17:04 UTC
Created attachment 9652 [details]
Example of failure

getaddrinfo()  fails with error code -2, message "Name or service not known", when ai_family is set to AF_UNSPEC for certain hostnames, but succeeds for AF_INET. I tested this using the hostname "outlook.office365.com".

The dig output for the domain is:
; <<>> DiG 9.11.0-P1 <<>> outlook.office365.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30287
;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 7, ADDITIONAL: 12

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;outlook.office365.com.		IN	A

;; ANSWER SECTION:
outlook.office365.com.	151	IN	CNAME	lb.geo.office365.com.
lb.geo.office365.com.	216	IN	CNAME	outlook.office365.com.g.office365.com.
outlook.office365.com.g.office365.com. 216 IN CNAME outlook-namnorthwest.office365.com.
outlook-namnorthwest.office365.com. 269	IN A	132.245.31.226
outlook-namnorthwest.office365.com. 269	IN A	132.245.3.130
outlook-namnorthwest.office365.com. 269	IN A	132.245.80.146
outlook-namnorthwest.office365.com. 269	IN A	132.245.92.210
outlook-namnorthwest.office365.com. 269	IN A	132.245.58.98
outlook-namnorthwest.office365.com. 269	IN A	132.245.36.34
outlook-namnorthwest.office365.com. 269	IN A	132.245.88.194
outlook-namnorthwest.office365.com. 269	IN A	132.245.15.210
outlook-namnorthwest.office365.com. 269	IN A	132.245.49.2

;; AUTHORITY SECTION:
office365.com.		109420	IN	NS	ns2.msft.net.
office365.com.		109420	IN	NS	ns3.msft.net.
office365.com.		109420	IN	NS	ns1.msft.net.
office365.com.		109420	IN	NS	ns1a.o365filtering.com.
office365.com.		109420	IN	NS	ns4a.o365filtering.com.
office365.com.		109420	IN	NS	ns2a.o365filtering.com.
office365.com.		109420	IN	NS	ns4.msft.net.

;; ADDITIONAL SECTION:
ns4a.o365filtering.com.	260	IN	A	157.55.133.11
ns2.msft.net.		111581	IN	A	208.84.2.53
ns2.msft.net.		87888	IN	AAAA	2620:0:32::53
ns1.msft.net.		59	IN	A	208.84.0.53
ns1.msft.net.		59	IN	AAAA	2620:0:30::53
ns4.msft.net.		2613	IN	A	208.76.45.53
ns4.msft.net.		87949	IN	AAAA	2620:0:37::53
ns2a.o365filtering.com.	260	IN	A	157.56.116.52
ns1a.o365filtering.com.	260	IN	A	157.56.110.11
ns3.msft.net.		59	IN	A	193.221.113.53
ns3.msft.net.		59	IN	AAAA	2620:0:34::53

;; Query time: 1 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sat Nov 19 18:11:16 PST 2016
;; MSG SIZE  rcvd: 663
Comment 1 Florian Weimer 2016-11-22 18:55:32 UTC
What's the output from 

dig outlook.office365.com AAAA

?  And would you please attach a full packet capture (tcpdump -i INTERFACE -w getaddrinfo.pcap -s 0 port 53) to this bug while the bug occurs?  Or send it to me privately in case you do not want to disclose your IP address information in this bug.
Comment 2 Ezra Umen 2016-11-22 21:55:03 UTC
Created attachment 9661 [details]
getaddrinfo failure network capture

Contains some unnecessary DNS requests from firefox.
Comment 3 Ezra Umen 2016-11-22 21:55:34 UTC
I've attached the output of the packet capture, though it does include a few extraneous entries from firefox.

Output of dig outlook.office365.com AAAA                                              ~
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.4-P1 <<>> outlook.office365.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43927
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;outlook.office365.com.		IN	AAAA

;; ANSWER SECTION:
outlook.office365.com.	24	IN	AAAA	2a01:111:f400:f3ab::2
outlook.office365.com.	24	IN	AAAA	2603:1036::2
outlook.office365.com.	24	IN	AAAA	2603:1036:404:16::2
outlook.office365.com.	24	IN	AAAA	2603:1036:120:2c::2
outlook.office365.com.	24	IN	AAAA	2a01:111:f400:534b::2
outlook.office365.com.	24	IN	AAAA	2603:1036:3:106::2
outlook.office365.com.	24	IN	AAAA	2a01:111:f400:5388::2
outlook.office365.com.	24	IN	AAAA	2603:1036:3:18::2
outlook.office365.com.	24	IN	AAAA	2603:1036:102:108::2
outlook.office365.com.	24	IN	AAAA	2a01:111:f400:2cfd::2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 22 15:48:00 CST 2016
;; MSG SIZE  rcvd: 319
Comment 4 Florian Weimer 2016-11-30 15:41:46 UTC
The pcap file indicates that two A queries are sent, and no AAAA query.  The queries are sent in parallel, with different source ports.  This is rather odd.  With the glibc stub resolver, there should be an A query and an AAAA query, from the same source port.

Is a VM involved somewhere?  Did you capture the packets in the VM or outside of it?
Comment 5 Florian Weimer 2017-01-02 16:04:45 UTC
My best guess is that this is a known issue in the VirtualBox DNS forwarder implementation, and not a glibc bug.