Project

General

Profile

Bug #6592

AI_ADDRCONFIG fails all resolutions when only loopback is present

Added by Robert Mustacchi over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
lib - userland libraries
Start date:
2016-02-01
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

With the introduction of 5096, the checking of the AI_ADDRCONFIG flag became more strict and it was observed that if a zone only had loopback devices, than something like ping, which calls getaddrinfo (and ultimately getipnodebyname) with AI_ADDRCONFIG would fail to resolve 'localhost' despite its presence in /etc/hosts.

The problem comes down to the fact that when AI_ADDRCONFIG is specified, we verify which interfaces are up to determine whether or not to return addresses of that type. According to RFC 3493, loopback interfaces should be ignored for making this determination. Generally speaking, this makes sense. If you only have an IPv6 loopback device, but do have non-loopback IPv4 addresses, then it doesn't make sense to then return IPv6 addreses, because you generally will not be able to reach them. The same is also true when the loopback and non-loopback devices are swapped.

However, this becomes problematic when we consider a zone which has no non-loopback interfaces. At that point, according to AI_ADDRCONFIG it would, strictly speaking, have no interfaces up at all, hence why it fails because there are no results. While this does fit the letter of the RFC, it's both a regression from before 5096 and also not generally desirable behavior. While it's true that users in this state would not be able to route out, they shouldn't have all requests fail at this point, as it means that anything referring to the local host will fail.

The proposed approach is that when we see that there are no non-loopback devices available, we'll instead opt to consider them and proceed with the request based on the loopback devices. This may mean that entries in /etc/hosts or other name service modules could return addresses that don't work, but this seems like the lesser of the two evils at this point and matches the more traditional behavior of the name service routines without the use of AI_ADDRCONFIG in these situations.


Related issues

Related to illumos gate - Bug #5096: getaddrinfo doesn't properly handle AI_ADDRCONFIG | AI_V4MAPPEDClosed2014-08-14

Actions

History

#1

Updated by Electric Monk over 4 years ago

  • Status changed from New to Closed

git commit 96088c8326643135b996338d1fe5a68aac181f31

commit  96088c8326643135b996338d1fe5a68aac181f31
Author: Robert Mustacchi <rm@joyent.com>
Date:   2016-02-24T04:02:53.000Z

    6592 AI_ADDRCONFIG fails all resolutions when only loopback is present
    Reviewed by: Dan McDonald <danmcd@omniti.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

#2

Updated by Marcel Telka 4 months ago

  • Related to Bug #5096: getaddrinfo doesn't properly handle AI_ADDRCONFIG | AI_V4MAPPED added

Also available in: Atom PDF