第二大脑 / Knowledge Bank

dns-binding

11分钟阅读

域名解析绑定 (DNS Resolution & Binding)

1. 定义

域名解析绑定是指把域名映射到具体资源（IP、CNAME、服务、平台）的过程。 本质是往 DNS 系统里写一条记录，告诉查询者”这个域名该往哪里走”。

形象记法：DNS 是互联网的”通讯录”，域名是人名，IP 是电话号。绑定就是”在通讯录里登记：张三 → 138xxxx”。

2. 核心概念

概念含义备注
域名 Domain人类可读的地址，如 example.com从右往左分级：根 → TLD → 二级
DNS 记录一条”域名 → 值”的映射A / CNAME / MX / TXT 等
DNS 服务器存储/查询记录的服务器权威服务器 / 递归服务器
TTL (Time To Live)记录缓存时间（秒）越短切换越快，但查询压力越大
解析 Resolver帮用户查 DNS 的服务器如 8.8.8.8、114.114.114.114
绑定 Binding把域名指向特定资源通常在域名商或云厂商控制台操作

3. DNS 解析链路

浏览器输入 example.com
        │
        ▼
本地 DNS 缓存 ─── 命中？返回 ────┐
        │ 未命中                  │
        ▼                         │
操作系统配置的递归 Resolver         │
(8.8.8.8 / 运营商 DNS)            │
        │                         │
        ▼                         │
根服务器 (.root)                  │
        │ 指向 .com TLD            │
        ▼                         │
TLD 服务器 (.com)                  │
        │ 指向权威服务器            │
        ▼                         │
权威服务器 (example.com 的 NS)     │
        │ 返回 A / CNAME 记录      │
        ▼                         │
浏览器拿到 IP，发起 HTTP 请求 ◄───┘

一次完整解析要走”根 → TLD → 权威”三跳，但每一级都有缓存，绝大多数查询都能在递归服务器命中，毫秒级完成。

4. 常见记录类型

记录类型作用例子
A域名 → IPv4 地址example.com → 1.2.3.4
AAAA域名 → IPv6 地址example.com → 2606:2800::
CNAME域名 → 另一个域名（别名）www.example.com → example.com
MX邮件服务器指向处理该域邮件的服务器
TXT任意文本，常用于所有权验证example.com → "google-site-verification=xxx"
NS该子域由哪台服务器解析委托解析权时用
SOA区域权威信息主服务器、管理员邮箱、序列号

5. 常见绑定场景与命令

# ── 查询域名解析 ──
dig example.com              # 默认查 A 记录
dig example.com A            # 显式查 A
dig example.com CNAME        # 查 CNAME
dig @8.8.8.8 example.com     # 指定用 8.8.8.8 这个 resolver 查
dig +short example.com       # 只看结果 IP，简洁输出
 
nslookup example.com         # 老牌工具，跨平台
host example.com             # 简洁版查询
 
# ── 看完整解析链路 ──
dig +trace example.com       # 从根服务器一路追到权威服务器
 
# ── 本机覆盖绑定（测试用）──
# /etc/hosts (macOS/Linux)
# 127.0.0.1   myapp.local
# 编辑后立即生效，绕过 DNS，常用来本地绑定域名测试

控制台绑定操作（以常见云厂商为例）：进入域名管理 → 添加记录 → 选类型 (A/CNAME) → 填主机记录 (如 @、www) → 填值 (IP 或目标域名) → 设 TTL → 保存。DNS 全球生效通常几分钟到 48 小时。

6. 对比辨析表

对比项A 记录CNAME 记录
指向IPv4 地址另一个域名
性能少一跳解析多一跳，要先解析目标域名
能否在根域用能不能，根域只能用 A/AAAA
典型场景直接指向服务器 IP别名指向云服务（CDN、对象存储、SaaS）
改 IP 时要改记录改目标域名的解析即可

根域（zone apex，如 example.com 本身）不能挂 CNAME 是 RFC 规定，因为根域还要承担 SOA、NS 等记录，CNAME 会”独占”域名。云厂商的 ALIAS/ANAME 记录是私有的折中方案。

7. 典型工作流

场景 A：域名绑定到自己的服务器

  1. 服务器拿到公网 IP（如 1.2.3.4）
  2. 域名控制台加 A 记录：@ → 1.2.3.4
  3. 加 www 别名：www → example.com（CNAME）或直接 www → 1.2.3.4（A）
  4. dig example.com +short 确认返回该 IP

场景 B：域名绑定到云服务（如对象存储 / CDN / GitHub Pages）

  1. 云服务给你一个目标域名（如 xxx.cloudfront.net）
  2. 域名控制台加 CNAME：www → xxx.cloudfront.net
  3. 在云服务控制台把 www.example.com 加入”允许的域名”白名单
  4. 访问 www.example.com 时，DNS 解析到云服务，云服务再据 Host 头返回内容

这是场景 B 的典型实战。云服务（Vercel）给目标域名 cname.vercel-dns.com，你在域名商（阿里云）加一条 CNAME 指过去，再回 Vercel 等验证。整个过程约 10 分钟。

实例：Vercel + 阿里云绑定子域名 tiktok.yyqtccc.top

第 0 步：域名实名认证（阿里云强制，未实名解析不生效）

  • 控制台 → 域名列表 → 上传身份证，审核几小时到 1 天

第 1 步：Vercel 侧添加自定义域名

  • 项目 Settings → Domains → 输入 tiktok.yyqtccc.top → Add
  • 此时会显示 ⚠️ Invalid Configuration，并提示需要的 CNAME 记录： 
    Type:  CNAME
Name:  tiktok
Value: cname.vercel-dns.com

第 2 步：阿里云侧配置 DNS 解析

  • 云解析 DNS → 添加记录：
字段填什么
记录类型CNAME
主机记录tiktok ← 只填子域前缀，不要填完整域名
解析线路默认
记录值cname.vercel-dns.com
TTL默认（10 分钟）

第 3 步：回 Vercel 等待验证

  • 几分钟后点 Refresh，状态从 ⚠️ Invalid 变 ✅ Valid Configuration 即成功
  • HTTPS 证书 Vercel 自动签发（再等几分钟）
  • 访问 https://tiktok.yyqtccc.top 与 xxx.vercel.app 内容一致；以后 git push 两地址自动同步，无需再改配置

验证命令

dig tiktok.yyqtccc.top +short    # 能解析到 Vercel 地址即生效
ping tiktok.yyqtccc.top          # 同样可验证

想让根域 yyqtccc.top 也能访问：Vercel Add 根域 → 加一条 A 记录（主机记录 @，值通常是 76.76.21.21）；www 同理加 CNAME，Vercel 可设自动跳转到主域。

实例常见坑

  • 一直 Invalid Configuration：大概率 DNS 还没传播（等 10-30 分钟），或主机记录填成了完整的 tiktok.yyqtccc.top
  • 实名没过就配置：解析不生效，先等审核
  • 根域不能用 CNAME（见第 6 节辨析），只能用 A 记录

场景 C：本地开发用域名测试

  1. 编辑 /etc/hosts：127.0.0.1 myapp.local
  2. 浏览器访问 http://myapp.local 直接走本地
  3. 改完立即生效，不依赖 DNS

8. 常见误区

  • ❌ “改了 DNS 记录立刻全网生效” → 错，要看 TTL 和各 resolver 缓存；TTL 越短生效越快，但仍需时间
  • ❌ “根域也能用 CNAME 指向云服务” → 错，根域不能挂 CNAME；云厂商用 ALIAS/ANAME 等私有方案绕过
  • ❌ “解析不到 IP 一定是 DNS 坏了” → 不一定，可能是 NS 委托没配、本地 /etc/hosts 覆盖、或 resolver 缓存了旧值
  • ❌ “TTL 设得越短越好” → 不一定，TTL 短切换快但查询量大、解析慢；稳定期建议调长
  • ❌ “/etc/hosts 和 DNS 是一回事” → 错，hosts 是本机静态覆盖，优先级高于 DNS，且不传播

8.5 关联知识点：IP 地理定位 (IP Geolocation)

和 DNS 同属”IP 相关”这条线，容易被误解，单独澄清一下。

判断一个 IP 属于哪个国家/城市，靠的是查表，不是任何入侵手段。

原理：

  1. IP 是公开、有规律地分配的：全球 IP 由 IANA 分给各大洲注册机构（亚太是 APNIC），再分给各国运营商。“哪段 IP 归哪国/哪运营商”是公开登记信息，任何人可查（WHOIS）。
  2. 有现成的 IP→地理位置数据库：如 MaxMind GeoIP、IP2Location，把”IP 段 ↔ 国家/城市”整理成表。服务端拿到来源 IP 查表即可，类似看电话区号猜城市。
  3. 来源 IP 是对方主动送上门的：任何 TCP 连接都自带源 IP（见 socket.md 四元组），服务器本来就要知道往哪回数据，无需”获取”。
IP 地理定位网络入侵
手段查公开数据库（被动）利用漏洞（主动攻击）
数据来源对方连接时自带的源 IP突破防线去拿
合法性完全合法、极常见未授权即违法

类比：看来电显示的区号判断对方在哪，不是”入侵对方电话”。 网站按 IP 判断地区做限制(geo-blocking)、合规、反滥用是常规操作，和攻击无关。

注意：IP 定位只到国家/城市级、不精确，且能被 VPN/代理改变（看到的是出口 IP 的位置），它不追踪”你本人”。

9. 延伸阅读 / 关联概念

  • ping / traceroute — 验证解析后的 IP 是否可达
  • CDN — 通过 CNAME 接入，按用户位置返回最近节点 IP
  • DNS over HTTPS (DoH) / DNS over TLS (DoT) — 加密 DNS 查询，防窃听和劫持
  • HTTP 重定向 vs DNS 绑定 — 一个在应用层跳转，一个在网络层指向，作用层级不同
  • RFC 1035 — DNS 协议规范，定义了记录类型和报文格式

关系图谱

反向链接