Re: getaddrinfo(3) on numerical addresses

[John Nemeth]

On Oct 24,  7:32pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
}
} > I suspect there's some misunderstanding.
} Yes. It's about numerical IPv4 addresses being looked up with an AF_INET6 
hint.
} 
} check_ping tries to figure out whether it needs to call ping6 (suppose 
} wer'e on a system where ping6 is different from ping).
} Suppose that check_ping is invoked without -4/-6 and with -H 1.2.3.4.
} Now check_ping tries to figure out whether the -H argument is a/resolves to 
} a IPv6 address. To do so, it checks whether getaddrinfo() on the -H argument 
} (which is 1.2.3.4) with an AF_INET6 hint succeeds. But this triggers a DNS 
} lookup.
} Given this is a monitoring system, who's job it is to detect server failures, 
} marking random servers/switches as dead while the resolver is going mad and
} so check_ping on their numerical IPv4 times out is not particularily useful.

 This totally sounds like a bug in the monitoring system, not
a libc bug.  If it is depending on esoteric implementation defined
behaviour then it is buggy and needs to find another way to do
what it wants.

} I guess the point is what you expect getaddrinfo on 1.2.3.4 with a AF_INET6 
} hint to do. Well, you could have a search domain of numerical.org and 
} 1.2.3.4.numerical.org have an  record. How likely is that? 

 Irrelevant how likely it is.  If it is legal then getaddrinfo()
needs to handle it.

}-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=

Re: getaddrinfo(3) on numerical addresses

[Edgar Fuß]

> At least inet_pton parses a numerical IPv4 addresses without any dots.
Despite the man page claiming so, it actually doesn't (on 6.1):

#include 
#include 
#include 

int main(int argc, char *argv[]) {
char buf[16];
printf("%d\n", inet_pton(AF_INET, "1", buf));
return 0;
}

outputs "0" for me (which means failure).

Re: getaddrinfo(3) on numerical addresses

[Edgar Fuß]

> I suspect there's some misunderstanding.
Yes. It's about numerical IPv4 addresses being looked up with an AF_INET6 hint.

check_ping tries to figure out whether it needs to call ping6 (suppose 
wer'e on a system where ping6 is different from ping).
Suppose that check_ping is invoked without -4/-6 and with -H 1.2.3.4.
Now check_ping tries to figure out whether the -H argument is a/resolves to 
a IPv6 address. To do so, it checks whether getaddrinfo() on the -H argument 
(which is 1.2.3.4) with an AF_INET6 hint succeeds. But this triggers a DNS 
lookup.
Given this is a monitoring system, who's job it is to detect server failures, 
marking random servers/switches as dead while the resolver is going mad and
so check_ping on their numerical IPv4 times out is not particularily useful.

I guess the point is what you expect getaddrinfo on 1.2.3.4 with a AF_INET6 
hint to do. Well, you could have a search domain of numerical.org and 
1.2.3.4.numerical.org have an  record. How likely is that? 

Re: getaddrinfo(3) on numerical addresses

[Joerg Sonnenberger]

On Tue, Oct 24, 2017 at 05:17:19PM +0200, Edgar Fuß wrote:
> > That's what AI_NUMERICHOST is for?
> No (or so I think).
> I would like to save the resolver lookup if we know beforehand we don't need 
> it.

But that's the point of AI_NUMERICHOST. You don't know in advance if it
is necessary or not.

> 
> > It's not clear whether it should or should not parse the behavior
> I can't parse that sentence.

The gai implementation talks about the DNS fallback a bit and why it may
or may not be a bug.

Joerg

Re: getaddrinfo(3) on numerical addresses

[Joerg Sonnenberger]

On Tue, Oct 24, 2017 at 10:57:42PM +0700, Robert Elz wrote:
>   | 3. syntactically correct numerical IPv4 addresses contain digits and dots
> 
> Which is exactly what a domain name can contain.   The only reason that
> IP addresses (in textual format) are not currently valid domain names, is
> that there are currently no top level domains with all numeric labels.
> But who knows what ICANN will create next week?

At least inet_pton parses a numerical IPv4 addresses without any dots.
Add the implicit search domain from /etc/resolv.conf and you can get
names for gai that contains purely digits and are still ambigious on
whether they should be resolved via DNS or not.

Joerg

Re: getaddrinfo(3) on numerical addresses

[Edgar Fuß]

> That's what AI_NUMERICHOST is for?
No (or so I think).
I would like to save the resolver lookup if we know beforehand we don't need it.

> It's not clear whether it should or should not parse the behavior
I can't parse that sentence.

What's wrong with the following argument?
1a. domain name componentss consist of letters, digits and hyphens
1b. purely numeric components may be allowed, but are crazy
2. syntactically correct numerical IPv6 addresses contain at least one colon
3. syntactically correct numerical IPv4 addresses contain digits and dots
4. So a numeric IPv4 address can't be a a numeric IPv6 address, and vice 
   versa, and neither of them can be a FQDN.

First, try to inet_pton(AF_INET) (or equivalent) the argument. If that succeeds
-- with an AF_INET6 hint, fail
-- with an AF_INET hint or no hint, return the result
Next, try to inet_pton(AF_INET6) the argument. If that succeeds
-- with an AF_INET hint, fail
-- with an AF_INET6 hint or no hint, return the result
If both inet_pton()s fail, continue as normal.

Re: getaddrinfo(3) on numerical addresses

[Valery Ushakov]

In gmane.os.netbsd.devel.network Joerg Sonnenberger  wrote:

> On Tue, Oct 24, 2017 at 03:19:29PM +0200, Edgar Fu? wrote:
>> I've noticed[*] that on NetBSD, getaddrinfo(3) does a resolver lookup even 
>> if presented a numerical address. Is this on purpose? Would it have a 
>> drawback if it would first try to inet_pton() the address?
>> On Linux, it seems to avoid the resolver lookup.
> 
> That's what AI_NUMERICHOST is for? It's not clear whether it should or
> should not parse the behavior, see comments in the code.

My guess is that the caller doesn't pass an address that is always
numeric and does't pass the address family hint either - which is the
whole point of the exercise, I gather.

But in that case trying numeric first doesn't help.  In fact from a
*very* cursory glance at the sources, it's already trying numeric
first :).  The problem, I guess, is that the outer loop, so to say, is
over the address families.  So the problem is not that the fqdn lookup
is done before the numeric lookup for the same address family, but
that the fqdn lookup for some other address family is done before.

Again, this is from a very cursory look at the code, so it may be
completely wrong.  Caveat emptor.

-uwe

Re: getaddrinfo(3) on numerical addresses

[Joerg Sonnenberger]

On Tue, Oct 24, 2017 at 03:19:29PM +0200, Edgar Fuß wrote:
> I've noticed[*] that on NetBSD, getaddrinfo(3) does a resolver lookup even 
> if presented a numerical address. Is this on purpose? Would it have a 
> drawback if it would first try to inet_pton() the address?
> On Linux, it seems to avoid the resolver lookup.

That's what AI_NUMERICHOST is for? It's not clear whether it should or
should not parse the behavior, see comments in the code.

Joerg