X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=PkViGbqeSzgxfAPS
	uJ4Q4/wKT/wWmMUT1MKufU6rLLal/go/I77MC2lD/j/zMcFx+igBDNHU4PvtEfsc
	XR8ztlbwdzZTgCaj/TXwh5UAR23EpqsI8IWZlYAr4IdNQolJl5EBderxtTEe8kcq
	z4+I/T+EI9SfRgF36TYzQ0xKQ84=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=eCOxHGNwhPvZ3UpRVC8PRY
	u2Rws=; b=UlGeHEUxHw+RQDnUGGtLrqPiNltk9BdDGi4Eu8imBjxXM7BxGUdn6E
	d6F1Wh5vUm26H4uMdnSU6pZ0kaTSlTFUN27IXgkwBZo2NmfUBxgp3O6tFDxXsNSW
	6hcGJ8MwWg9nhif9UHUyDzgNj8VFwyI4jrDrvMSfd1a1Tzfv1LPXg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.2 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Assigned, inter, 1112, alberta
X-HELO:	smtp-out-no.shaw.ca
X-Authority-Analysis:	v=2.1 cv=N9CJbzJB c=1 sm=1 tr=0 a=0g8qPGUHxEvai5om+WudJQ==:117 a=0g8qPGUHxEvai5om+WudJQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=PlQC-WsNAAAA:8 a=48vgC7mUAAAA:8 a=wiYxLJy5AAAA:8 a=_OZVCLxKcUsoy2RBpqAA:9 a=A_XxFGaD9uFszYNW:21 a=YOPH2fMOUwAIJf9-:21 a=QEXdDO2ut3YA:10
Reply-To:	Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Subject:	Re: getaddrinfo fails with EAI_NODATA for some valid hosts with A records
References:	<loom DOT 20160107T163448-78 AT post DOT gmane DOT org> <20160108111408 DOT GH20447 AT calimero DOT vinschen DOT de> <loom DOT 20160113T042110-649 AT post DOT gmane DOT org> <002701d14e24$49a2cbd0$dce86370$@comcast.net>
To:	cygwin AT cygwin DOT com
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Message-ID:	<5696BFAF.4080908@SystematicSw.ab.ca>
Date:	Wed, 13 Jan 2016 14:20:47 -0700
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version:	1.0
In-Reply-To:	<002701d14e24$49a2cbd0$dce86370$@comcast.net>
X-CMAE-Envelope:	MS4wfEr/E3ifr0xziJ+q+nuJ5/a46yZyAbhu3yG8cKb14TzRlqvlaYEUYEkR1CajKhZOq+izjbOrKPEdAjhyv9R39WMBCaNDl+GNy7806LjVi6qsmKydqFyD aW2R9AtL2Y5cuqOCgmR5pFbLysi08UY++G5dXElPLKT9qOyjDs0PGOoOvApZ6/BcOUahqqL78VQ9dw==

On 2016-01-13 10:03, Andy Hall wrote:
>> -----Original Message-----
>> From: cygwin
>> On Behalf Of Brian Inglis
>> Corinna Vinschen writes:
>>> On Jan  7 15:39, Brian Inglis wrote:
>>>> getaddrinfo fails with err 7 EAI_NODATA for some valid hosts
>>>> with A records. Err 7 EAI_NODATA is mapped from WSANO_DATA err
>>>> 11004 in Windows. Can anyone reproduce failure with problem
>>>> host name below?

>>> Yes, I can reproduce it, and it's a total surprise.
>>> I have no idea why Windows' getaddrinfo chokes on
>>> leapsecond.utcd.org at all.

>> Especially when after just one getaddrinfo call, the DNS cache is
>> populated with:
>> leapsecond.utcd.org
>> ----------------------------------------
>> Record Name . . . . . : leapsecond.utcd.org
>> Record Type . . . . . : 1
>> Time To Live  . . . . : 600
>> Data Length . . . . . : 4
>> Section . . . . . . . : Answer
>> A (Host) Record . . . : 244.34.36.97
>> so the DNS server is being contacted and responding normally, but
>> it would appear Windows GAI is failing to use that info. Has this
>> been reproduced on W10 so we can report this upstream? Is there any
>> support without an account for upstream W7 reports?

> DNS just translates URLs to IP addresses.  It is no surprise that
> works.   However, addresses in the range 240.0.0.0 - 255.255.255.255
> are reserved.   Windows is probably blocking that as a "favor".
> Net Range	240.0.0.0 - 255.255.255.255 CIDR	240.0.0.0/4 Name
> SPECIAL-IPV4-FUTURE-USE-IANA-RESERVED Handle	NET-240-0-0-0-0 Parent
> Net Type	IANA Special Use Origin AS Organization	Internet Assigned
> Numbers Authority (IANA) Registration Date Last Updated	2013-08-30
> Comments	Addresses starting with 240 or a higher number have not been
> allocated and should not be used, apart from 255.255.255.255, which
> is used for "limited broadcast" on a local network.
> This block was reserved by the IETF, the organization that develops
> Internet protocols, in the Standard document and in RFC 1112. The
> documents can be found at: http://datatracker.ietf.org/doc/rfc1112
> RESTful Link	http://whois.arin.net/rest/net/NET-240-0-0-0-0 See Also
> Related organization's POC records. See Also	Related delegations.

See also IANA services and ports reservations which have been ignored
since Windows devs got a connection to the world outside their PC
(cough Citrix!)

Reserved just means it won't be assigned, but as illustrated by my
OP and Linux tests, it has been usable since CIDR/VLSM came in RFCs
1517-1519 in 1993, and routable since RFC 1812 in 1995 supported
Classless Inter Domain Routing and Variable Length Subnet Masking.

The private reserved address ranges are bogon territory for routers;
the most that can be said about 240/8 is possible bogosity: that
space is available for global internet use without any guarantees
what devices, hosts, protocols, and services will interoperate.

IANA considered releasing the 248M addresses for assignment a few
years ago but decided it was not worth it, as it would only delay
exhaustion of IP V4 space for 18 months, and some crufty old gear
and stacks (cough Windows!) may not support it (as we saw and you
said) for some functions.

Regardless of that, the DNS lookup function should operate normally:
implementing mechanism not policy; if some higher layer wants to
apply a policy on use of those addresses, *THAT*'s what we have
filters for.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -