Skip to content

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

Verified 2 min read

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

Tested onStandard / Datacenter · Build 26100.33650 · x64
E1
Build
26100.33650
Edition
Standard / Datacenter
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Concept

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.

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.

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).

  • 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.
Terminal window
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:

192.168.50.105 lab.local

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

  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.

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