getent hosts: Resolve Names the Way the System Does
getent hosts <name> resolves a hostname through the system’s NSS stack, including /etc/hosts and the configured resolver, matching what an application will actually see.
DNS tools like dig query a resolver directly and can disagree with what the program sees. getent goes through the same NSS path your application uses, so it reproduces the real resolution, including container /etc/hosts entries.
What it does
getent reads Name Service Switch databases per /etc/nsswitch.conf. getent hosts <name> resolves a host the way the C library does, honoring /etc/hosts, mDNS, and DNS in the configured order. getent ahosts shows all address families. It exits 2 when the key is not found, which is scriptable.
Common usage
getent hosts example.com
getent hosts postgres # resolve a service name (e.g. CI service container)
getent ahosts example.com # all address families (A and AAAA)
getent hosts "$DB_HOST" || echo "name does not resolve"Options
| Database / form | What it does |
|---|---|
| hosts <name> | Resolve a hostname via NSS (hosts + DNS) |
| ahosts <name> | All address families, with socket type info |
| hosts <ip> | Reverse-resolve an address |
| passwd / group <key> | Look up a user or group (see id) |
| (exit 2) | Key not found, usable in scripts |
In CI
When a service-container hostname like postgres or redis fails to connect, getent hosts postgres shows whether the name resolves at all from inside the job container. Because it uses the same NSS path as your app, it catches /etc/hosts injections that dig (which talks straight to a DNS server) would miss. A non-zero exit is a clean "name does not resolve" signal.
Common errors in CI
getent returning nothing and exiting 2 means the name does not resolve through NSS, the most common service-networking failure in CI. If dig resolves a name but getent does not, the resolver and /etc/nsswitch.conf disagree (e.g. hosts: line missing dns), which is exactly the kind of mismatch that breaks an app while looking fine to dig.