# Windows Web 服务器的 DNS 与主机名：先规划名字，再谈 TLS

> 选 A/AAAA/CNAME、内外网分离与 TTL，并在申请证书前验证名字确实解析到服务器。

**测试环境**

- 版本号: 26100.33650
- 版本: Standard / Datacenter
- 架构: x64
- 证据: E1
- 核验日期: 2026-10-29

## 一句话结论

在 IIS/Nginx 或证书之前，先定：

- 每个应用用哪个主机名；
- 它是**公网**、**内网**还是两者；
- 根域（`example.com`）还是子域（`app.example.com`）；
- 内网客户端由谁解析。

TLS、SNI、cookie 都依赖名字。事后改名比现在规划贵。

## 记录类型

| 需求 | 记录 |
|---|---|
| 名字 → IPv4 | `A` |
| 名字 → IPv6 | `AAAA` |
| 别名到另一个名字 | `CNAME` |
| 根域 | `A`/`AAAA`（或厂商 ALIAS/ANAME） |
| 邮件 | `MX`（不是 Web 服务器） |

CNAME 不能和同名其他记录共存，很多厂商也不允许根域 CNAME。用 `A`/`AAAA` 或厂商 alias。

## 公网与内网名字

常见：

- 公网 `app.example.com` → 公网 IP/反代；
- 内网 `app.internal.example.com` → 私网 IP；
- 或 split-horizon：同一名字内网解析私网、外网解析公网。

Split horizon 很强也容易配错。写清哪个 resolver 看到哪个答案。公网名字的证书仍需要公网验证路径（或 DNS-01）。

## TTL

- 迁移期用低 TTL（300–600 秒）。
- 切换后升回去。
- 长 TTL 让回滚变慢；极低 TTL 增加查询量。
- 不要同时改 DNS 和 TLS；一次只引入一个故障源。

## 验证解析

```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
```

从服务器、客户端网络、内网 resolver 各测一次。“我笔记本上正常”可能用了不同 DNS 视图。

实验室可用 hosts：

```text
192.168.50.105  lab.local
```

标明这是实验捷径；它不验证公网 DNS 或证书签发。

## 证书之前

1. 名字解析到服务器/代理。
2. 80/443（或 DNS-01）可达。
3. 名字在证书 SAN 里。
4. 代理保留 `Host` 并转发 `X-Forwarded-Proto`。

> **警告: 不要给不解析的名字签证书**
>
> ACME HTTP-01 要求名字能到服务器。DNS 指到别处，验证会失败，或者更糟：在错误主机上成功。

## 实验室边界

E1。实验室用 `lab.local`/hosts 做 IIS；没有配公网 DNS 或 split-horizon。生产前用真实 DNS 验证。

## 来源

- [Microsoft Learn — DNS 概述](https://learn.microsoft.com/zh-cn/windows-server/networking/dns/dns-top)
- [Microsoft Learn — Resolve-DnsName](https://learn.microsoft.com/zh-cn/powershell/module/dnsclient/resolve-dnsname)
- [RFC 1034 — 域名](https://datatracker.ietf.org/doc/html/rfc1034)

---

来源页面: https://winbook.fyi/zh/server/tls/dns/