It also needs to support whatever hostname resolution systems the local system administrator has chosen to use. DNS is the most common, yes, but mDNS is in comm

It also needs to support whatever hostname resolution systems the local system administrator has chosen to use. DNS is the most common, yes, but mDNS is in common use (for .local hostnames, via Avahi or mDNSResponder), you might need LLMNR to interoperate with Windows environments, and in legacy environments you might also need to support things like NetBIOS Name Service (Samba nss_winbind) or even NIS (There is a deep irony here that mDNS, LLMNR and NBNS all use the DNS packet format on the wire!) Sometimes the argument given is that these resolvers should be implemented via a service which listens on localhost, with resolv.conf pointed at. Unfortunately, this assumes you can translate the responses from querying all of these protocols to DNS packets. This isn't true: There's no way to encode an IPv6 address scope in a DNS packet (because they're machine-local considerations). In mDNS and LLMNR, this isn't a problem because the scope is implicit - take it from the sockaddr_in6 of the received packet. This means link local addressing doesn't work. (n.b. gethostbyname can't support link local addressing either, but getaddrinfo can. This is one reason for gethostbyname's deprecation in favor of the latter API)