Always Use Hostnames, Not IP Addresses

Always Use Hostnames, Not IP Addresses

A guide to one of the most impactful — and most frequently ignored — best practices in enterprise infrastructure.

---

Why This Matters

IP addresses are infrastructure plumbing. Hostnames are the stable, human-readable contract that sits on top of that plumbing. When you hardcode an IP address into anything — a script, a config file, a connection string, a monitoring alert — you are coupling your work directly to a piece of infrastructure that will change. Servers get rebuilt, IPs get reassigned, subnets get renumbered. The hostname stays the same.

Using IP addresses instead of hostnames is the infrastructure equivalent of saving someone's phone number as "the guy with the red truck." It works right up until he gets a new truck.

---

Reason 1: IP Addresses Change. Hostnames Don't Have To.

Servers get migrated, rebuilt, moved between VLANs, and re-IPed during datacenter changes, DR failovers, and infrastructure refresh cycles. When that happens:

• A hostname reference: update DNS → everything pointing at the hostname works automatically.
• An IP address reference: hunt through every script, config file, connection string, and firewall rule that hardcoded that IP and update each one manually — hoping you find them all.

In a mature environment with dozens or hundreds of systems, the second scenario is not a minor inconvenience. It is an outage waiting to happen, and the failure will surface at the worst possible time.

---

Reason 2: Certificates Use Hostnames (or FQDNs), Not IPs

TLS certificates — the foundation of encrypted communication — are issued against hostnames and Subject Alternative Names (SANs), not IP addresses. When you connect to a service using an IP address, certificate validation fails or must be bypassed entirely.

• SSL/TLS connections require the hostname in the request to match the certificate's CN or SAN.
• Connecting by IP forces you to either add an IP SAN to every certificate (unusual, cumbersome, and not supported by all CAs) or disable certificate validation entirely — which defeats the entire point of using TLS.
• Tools like AppViewX, ManageEngine, and WinRM over HTTPS all rely on hostname-based certificate matching.

If your environment uses internal PKI (Root CA + Intermediate CA), every certificate you issue should be tied to an FQDN. Hardcoding IPs in connection strings means you'll either fight certificate errors constantly or run without encryption.

---

Reason 3: Kerberos Authentication Requires Hostnames

Kerberos — the authentication protocol used by Active Directory — is fundamentally built around hostnames, not IP addresses. Service Principal Names (SPNs) are registered against hostnames. When a client connects to a service by IP address:

• Kerberos cannot resolve the SPN from an IP address.
• Authentication falls back to NTLM — an older, weaker protocol.
• In hardened environments where NTLM is restricted or blocked, the connection fails entirely.

This is especially relevant for SQL Server, IIS, WinRM, and any other service that relies on Windows Integrated Authentication. Connecting by hostname ensures Kerberos is used and mutual authentication succeeds.

---

Reason 4: DNS Gives You Flexibility and Abstraction

DNS is not just name-to-IP resolution. It is an abstraction layer that gives you operational flexibility that hardcoded IPs completely eliminate:

• CNAME aliases — Point sqlprod.domain.com at the actual server hostname. When the server changes, update one DNS record. Nothing else changes.
• Load balancing / failover — DNS can be used to distribute connections across multiple backend IPs or to fail over by updating a record. Hardcoded IPs make this impossible without touching every client.
• Split-horizon DNS — Return different IPs for internal vs. external clients based on the same hostname. Hardcoded IPs break this entirely.
• DR / migration — Swing a hostname to a new server IP during a migration window. All clients follow automatically.

---

Reason 5: Readability, Auditability, and Documentation

Consider reviewing a firewall rule set or an Ansible playbook six months after it was written. Which is more immediately useful?

IP-based (bad)	Hostname-based (good)
10.10.14.52	sqlprod01.casino.local
10.10.8.17	vcenter.casino.local
10.10.8.201	dc01.casino.local

Hostnames are self-documenting. IP addresses require a lookup table that someone has to maintain and that is almost always out of date. In a security incident or an outage, time spent decoding IP addresses is time not spent fixing the problem.

This applies equally to firewall rules, monitoring configurations, Ansible inventory files, connection strings in application configs, and runbooks.

---

Reason 6: LogicMonitor, Monitoring Tools, and Alerting

Monitoring platforms like LogicMonitor identify and track devices by hostname. When a device is onboarded by IP:

• The device name in alerts and dashboards is a meaningless IP address.
• If the IP changes, the monitoring platform loses track of the device and may create a duplicate or orphaned entry.
• Historical performance data becomes disconnected from the current device.

Onboard all devices by FQDN. This ensures that even if an IP changes, the monitoring record remains continuous and alerts are immediately meaningful without requiring a lookup.

---

Reason 7: Ansible, Automation, and Configuration Management

Ansible and similar tools use inventory files that reference target hosts. Hardcoding IPs in inventory breaks:

• WinRM over HTTPS — Certificate hostname mismatch causes connection failure.
• Kerberos authentication — Falls back to NTLM or fails (see above).
• Readability and maintainability — A 300-host inventory of IP addresses is effectively unreadable.

# Bad - hardcoded IP
[windows_servers]
10.10.14.52

# Good - hostname with variables
[windows_servers]
sqlprod01.casino.local

[windows_servers:vars]
ansible_connection=winrm
ansible_winrm_transport=kerberos

Use FQDNs in all Ansible inventory files. If DNS is reliable (and it should be), there is no reason to use IPs.

---

When IP Addresses Are Acceptable

There are narrow, legitimate cases where IP addresses are appropriate:

• DNS server configuration itself — You must reference DNS servers by IP in network adapter settings, because DNS is needed to resolve everything else. Chicken-and-egg problem.
• Network device management — Switches, routers, and firewalls are often managed by IP when DNS may not be available during troubleshooting.
• Firewall rules at the network layer — Packet-level firewall ACLs operate on IPs. This is expected. The point is to use hostnames in application and service configuration wherever DNS resolution is available.
• Out-of-band management (IPMI/iDRAC/iLO) — Management interfaces may not always be in DNS. Document these separately.
• Bootstrapping — Initial server provisioning before DNS records are created may require IP temporarily. Remove and replace with hostname as soon as DNS is registered.

---

Quick Reference: Hostname vs. IP

Scenario	Use Hostname?	Reason
Ansible inventory	✅ Yes	WinRM/Kerberos, readability
SQL Server connection strings	✅ Yes	Kerberos auth, certificate matching, failover
TLS/SSL certificate references	✅ Yes	Certs are issued to hostnames
LogicMonitor device onboarding	✅ Yes	Persistent identity, readable alerts
WinRM connections	✅ Yes	Kerberos requires hostname
AppViewX / CLM tool targets	✅ Yes	Certificate SAN matching
Monitoring alert configs	✅ Yes	Readability, continuity through IP changes
DNS server addresses (NIC config)	❌ IP required	DNS needed to resolve everything else
Network ACLs / firewall rules	❌ IP required	Operates at network layer
IPMI / iDRAC / iLO	⚠️ Depends	Register in DNS if possible; document IP if not

---

Last reviewed: April 2026 | Applies to all systems and platforms in the environment.