Re: [PATCH] resolver: only exit the search path loop there are a positive number of results given

[Rich Felker <dalias@libc.org>]

On Fri, Mar 30, 2018 at 06:52:25PM +0000, William Pitcock wrote:
> In the event of no results being given by any of the lookup modules, EAI_NONAME will still
> be thrown.
> 
> This is intended to mitigate problems that occur when zones are hosted by weird DNS servers,
> such as the one Cloudflare have implemented, and appear in the search path.
> ---
>  src/network/lookup_name.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/network/lookup_name.c b/src/network/lookup_name.c
> index 209c20f0..b068bb92 100644
> --- a/src/network/lookup_name.c
> +++ b/src/network/lookup_name.c
> @@ -202,7 +202,7 @@ static int name_from_dns_search(struct address buf[static MAXADDRS], char canon[
>  			memcpy(canon+l+1, p, z-p);
>  			canon[z-p+1+l] = 0;
>  			int cnt = name_from_dns(buf, canon, canon, family, &conf);
> -			if (cnt) return cnt;
> +			if (cnt > 0) return cnt;
>  		}
>  	}

This patch is incorrect, and the reason should be an FAQ item if it's
not already. Only a return value of 0 means that the requested name
does not exist and that it's permissible to continue search. Other
nonpositive return values indicate either that the name does exist but
does not have a record of the quested type, or that a transient error
occurred, making it impossible to determine whether the search can be
continued and thus requiring the error to be reported to the caller.
Anything else results in one or both of the following bugs:

- Nondeterministically returning different results for the same query
  depending on transient unavailability of the nameservers to answer
  on time.

- Returning inconsistent results (for different search components)
  depending on whether AF_INET, AF_INET6, or AF_UNSPEC was requested.

I'm aware that at least rancher-dns and Cloudflare's nameservers have
had bugs related to this issue. I'm not sure what the status on
getting them fixed is, and for Cloudflare I don't know exactly what it
is they're doing wrong or why. But I do know the problem is that
they're returning semantically incorrect dns replies.

Rich