This issue was observed on a Linux x64 host with _dnsmasq_ running as a local (caching) DNS server. On such a system the file _/etc/resolv.conf_ may be missing, and the default (libc) behaviour will be to query the local server instead. `man 5 resolv.conf` states > If this file does not exist, only the name server on the local machine will be queried, and the search list contains the local domain name determined from the hostname. However the retrieval logic of DNS servers in _packages/fcl-net/src/netdb.pp_ does not account for this, and will continue with no servers configured (i.e. an empty `DNSServers` array). The same happens if the file exists, but has no explicit `nameserver` entries. Any attempt to use `ResolveHostByName()` or similar functions will thus fail, and likely higher-level routines will see some `ESocketError: Host name resolution for "host.example.com" failed.` exception. (In my program `TFPHTTPClient` did.) I'm suspecting that this even affects fpc's own programs like *fppkg* - see <https://wiki.freepascal.org/Issues_3.2.2#Linux> where it's reported with a host name resolution failure. I think the resolver initialization in _netdb.pp_ should mimic the libc logic of falling back to the local DNS server in these cases. This can be achieved by substituting the (IPv4) loopback address 127.0.0.1 as the only entry in `DNSServers`. The attached patch does this and solved the problem on my test system. A long-term solution would probably be to migrate all resolver function to calling the libc implementation directly (_packages/fcl-net/src/cnetdb.pp_). Regards, NiteHawk [netdb_resolver_fallback.patch](/uploads/71ea6b7329a52303aa43bec850e112dd/netdb_resolver_fallback.patch)