# DNS and hostnames for a Windows web server: plan names before TLS

> Choose A/AAAA/CNAME records, split-horizon names and TTLs, then verify the name resolves to the server before requesting a certificate.

**Tested on**

- Build: 26100.33650
- Edition: Standard / Datacenter
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

Before IIS/Nginx or a certificate, decide:

- which hostname each app uses;
- whether it is **public**, **internal**, or both;
- whether the name is an apex (`example.com`) or a subdomain (`app.example.com`);
- who answers DNS for internal clients.

TLS, SNI and cookies all depend on the name. Renaming later is more expensive than planning now.

## Record types

| Need | Record |
|---|---|
| Name → IPv4 | `A` |
| Name → IPv6 | `AAAA` |
| Alias to another name | `CNAME` |
| Apex (`example.com`) | `A`/`AAAA` (or provider ALIAS/ANAME) |
| Mail | `MX` (not your web server) |

A CNAME cannot coexist with other records at the same name, and many providers do not allow CNAME at the apex. Use `A`/`AAAA` or the provider’s alias feature.

## Public and internal names

Common pattern:

- public: `app.example.com` → public IP / reverse proxy;
- internal: `app.internal.example.com` → private IP;
- or split-horizon DNS: the same name resolves to a private IP inside, public IP outside.

Split horizon is powerful and easy to misconfigure. Document which resolver sees which answer. A certificate for the public name still needs a public validation path (or DNS-01).

## TTL

- Use a low TTL (300–600s) during a migration.
- Raise it after cutover.
- A long TTL makes rollback slow; a very low TTL increases query load.
- Do not change DNS and TLS at the same time; isolate failures.

## Verify resolution

```powershell
Resolve-DnsName app.example.com -Type A
Resolve-DnsName app.example.com -Type AAAA
Resolve-DnsName app.example.com -Server 1.1.1.1
```

Test from the server, from a client network, and with the internal resolver. “It works on my laptop” may use a different DNS view.

For the lab, a hosts-file entry is acceptable:

```text
192.168.50.105  lab.local
```

Label it as a lab shortcut; it does not validate public DNS or certificate issuance.

## Before certificates

1. Name resolves to the server/proxy.
2. Ports 80/443 (or DNS-01) are reachable.
3. The name matches the certificate SAN.
4. The proxy preserves `Host` and sends `X-Forwarded-Proto`.

> **Caution: Do not issue a certificate for a name that does not resolve**
>
> ACME HTTP-01 needs the name to reach the server. If DNS points elsewhere, validation fails or, worse, succeeds on the wrong host.

## Lab boundary

E1. The lab used `lab.local`/hosts entries for IIS; public DNS and split-horizon were not configured. Verify with real DNS before production.

## Sources

- [Microsoft Learn — DNS overview](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-top)
- [Microsoft Learn — Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname)
- [RFC 1034 — Domain names](https://datatracker.ietf.org/doc/html/rfc1034)

---

Source: https://winbook.fyi/en/server/tls/dns/