At Tue, 24 Oct 2017 19:32:07 +0200, Edgar Fuß <e...@math.uni-bonn.de> 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. Ah, okay. > 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 AAAA record. How likely is that? I suspect different people could have different opinions on this point. Some people might say 1.2.3.4.numerical.org is unlikely enough and can be ignored. Some people might just disagree. Some other might even think it's not about likeliness but about flexibility (i.e., unless that's an invalid form the library should be able to work for it). So, especially for a portable application, I would say it should be handled at the application level: as already pointed out, setting AI_NUMERICHOST should prevent the unintended name resolution in the above example (I confirmed it with my test code). I believe that will work for almost all variants of getaddrinfo() implementations that way, whatever policy its developer has on what should happen for 1.2.3.4 with AF_INET6 but not AI_NUMERICHOST. -- JINMEI, Tatuya
