Pushed a new commit that resolves the FQDN issue, although I am not sure whether it is the correct fix or not.

It seems quite surprising that the lookup_ip() handling can differ quite a bit from basic lookup(), especially if more generic callers want to rely on lookup() for the wider applicability. Perhaps we should change generally change lookup_ip() to rely as completely as possible on lookup()? @bluejekyll thoughts?

I generally agree @djc. For some background here, the Hosts file lookup is only valuable in the context of IP lookups, which is why there's different code paths here. I agree with unifying them. There's a challenge here that as I remember was around the generic interface that lookup supports vs. the specific interface that lookup_ip offers. I'm not sure how easy it is to merge those two, and I think that's the issue you're running into @hch12907?

I need to look at this in more detail when I have time to offer some better guidance here.

The hosts file part seems kind of straightforward at least, since you could just handle it only for A/AAAA lookups. On the other hand, the IP lookup strategy seems harder to unify with the lookup_inner() code path, but maybe that's okay?

The main problem with merging lookup and lookup_ip mainly has to do with that one is dualstacked and one is not, yeah.

Maybe for now it would be good enough to just move the hosts file lookup from lookup_ip() to lookup() or lookup_inner(), only for A and AAAA queries?

Duplicating hosts lookup in both lookup and lookup_ip sounds more reasonable to me because the two functions follow very different code paths. The duplication is minimal, just a few lines long.

Overall, I think I'm ok with this change, on the Forwarder, I think we actually don't want the resolve config file to be referenced, if I enabled that in the past, it probably was a poor decision.

To be clear, I think this is ready to land if we could just clean up the setup for the Forwarded Authority.

I made a branch which makes use_hosts_file disabled for ForwardAuthority by default but not AsyncResolver: here.

If this is okay I can merge the branch back into this PR, but as an alternative I can drop 190a43a.

I think your branch looks okay, but I think it would be helpful to use an explicit enum rather than Option<bool> -- I think the semantics for the latter would be kind of hard to explain and not obvious in code review.

Would propose something like:

enum ResolveHosts {
    Always,
    Never,
    Default, // maybe not the best name? `Depends` or `Contextual` or ...
}

I opted to name the third variant Auto (so that it's mostly consistent with other Linux configs that go [true, false, auto])