《UNIX/Linux系统管理技术手册-读书笔记-第十六章

DNS：域名系统

1. DNS概述

1.1 什么是DNS

1.2 DNS查询流程（以vangogh.cs.berkeley.edu为例）

1. 客户端查询本地递归服务器（如ns.cs.colorado.edu）
2. 本地服务器向根服务器查询 → 被引荐到**.edu顶级域服务器**
3. 向.edu服务器查询 → 被引荐到**berkeley.edu权威服务器**
4. 向berkeley.edu查询 → 被引荐到**cs.berkeley.edu权威服务器**
5. 向cs.berkeley.edu查询 → 获得最终A记录答案
6. 沿途所有节点缓存结果（TTL控制有效期）

工具验证：dig +trace 或 drill -T 可手动跟随完整授权链。

1.3 DNS服务模式变迁

2. DNS客户端配置

2.1 /etc/resolv.conf —— 指定名称服务器

示例：

search atrust.com booklab.atrust.com
nameserver 63.173.189.1
nameserver 174.129.219.225

行为：按顺序查询服务器，超时后尝试下一个（默认超时5s）。DHCP通常自动填充该文件。

2.2 /etc/nsswitch.conf —— 名称解析顺序

hosts: files dns

• files：优先查询/etc/hosts（用于引导期间或覆盖特定映射）
• dns：查询DNS
• 可根据需求调整顺序（如先dns再files）

💡 推荐保留files在前，确保系统在DNS不可用时仍能解析自身和关键主机。

3. DNS名称空间与资源记录

3.1 关键概念

3.2 常见资源记录类型

CNAME限制：

• 区的apex（根域，如example.com本身）不能是CNAME（RFC1033）
• 解决方法：使用AWS Route 53/CloudFlare的“别名”功能（对外表现为A记录，自动同步目标IP）

3.3 SOA记录关键字段

忘记更新序列号是DNS管理最常见的错误，会导致变更无法传播到从服务器。

3.4 反向区（PTR记录）重要性

• A/AAAA和PTR必须匹配，否则会导致某些服务认证失败（如SSH的VerifyReverseMapping）
• 示例：A记录ns1.atrust.com. IN A 63.173.189.1，对应PTR在189.173.63.in-addr.arpa区中：1 IN PTR ns1.atrust.com.

3.5 轮询式DNS负载均衡（Round Robin）

为同一名称配置多个A记录：

www IN A 192.168.1.10
     IN A 192.168.1.11
     IN A 192.168.1.12

DNS服务器以轮询顺序返回，实现简单的负载分散。粗糙方案，生产环境建议使用专业负载均衡器。

4. BIND配置（核心）

4.1 BIND概述

📖 推荐版本：BIND 9（本书讨论），BIND 10开发中，BIND 4/8已过时。

4.2 named.conf核心语句

4.3 options语句关键配置

安全最佳实践：

• 对外部可见的服务器设置recursion no
• 用allow-query限制区传输（allow-transfer）
• 避免成为“开放式解析器”（Open Resolver）

4.4 zone语句（主/从/根提示/转发）

主服务器（Master） ：

zone "example.com" {
    type master;
    file "forward/example.com";
    allow-query { any; };
    allow-transfer { slaves; };
};

从服务器（Slave） ：

zone "example.com" {
    type slave;
    file "slave/example.com.cache";   # 从服务器本地缓存
    masters { 192.168.1.1; };         # 主服务器IP
};

根提示（Root Hints） ：

zone "." {
    type hint;
    file "root.cache";
};

转发区（Forward） ：

zone "partner.com" {
    type forward;
    forwarders { 10.0.0.1; };
};

4.5 view语句（DNS分割）

示例：

view "internal" {
    match-clients { 192.168.0.0/16; };
    recursion yes;
    zone "example.com" {
        type master;
        file "internal/example.com";
    };
};

view "external" {
    match-clients { any; };
    recursion no;
    zone "example.com" {
        type master;
        file "external/example.com";
    };
};

顺序重要：限制最多的视图放前面，否则any会提前匹配。

5. DNS安全机制

5.1 访问控制与TSIG

TSIG配置步骤：

1
2
3

# 生成共享密钥（128位示例）
dnssec-keygen -a HMAC-SHA256 -b 128 -n HOST master-slave1
# 将密钥放入两个服务器的named.conf（用include引入安全文件）

named.conf密钥定义：

key master-slave1. {
    algorithm hmac-sha256;
    secret "owKt6ZW0lu0gaVFkwOqGxA==";
};

在zone语句中应用：

allow-transfer { key master-slave1.; };

时钟同步：TSIG依赖时间戳，需用NTP保持服务器时钟同步（差异>5min会导致验证失败）。

5.2 DNSSEC（DNS Security Extensions）

部署步骤（简要） ：

1. 生成KSK和ZSK：dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
2. 使用dnssec-signzone签名区文件
3. 将.signed文件配置到named.conf
4. 将DS记录提交给父区（注册商）

维护：

• ZSK定期轮换（3个月~1年），采用“预公布”方案
• 签名的区文件不可手动编辑，需重新签名

DNSSEC配置复杂，新手建议使用托管DNS服务（如AWS Route 53已内置DNSSEC支持）。

5.3 开放式解析器风险

• 可被任何人利用进行DNS放大攻击（反射攻击）
• 建议用allow-recursion限制仅为内部用户服务
• 测试：访问DNS TOOLS网站“Open Resolver Test”

5.4 chroot环境运行named

1

named -t /var/named/chroot -u named

• 限制named进程可见文件系统范围
• 需在chroot中复制必要文件（/dev/null、区文件、配置等）

6. 调试工具

6.1 dig —— 核心查询工具

6.2 drill（DNSSEC调试增强版）

1
2

drill -T example.com    # 从根开始跟踪授权链（类似dig +trace）
drill -S example.com    # 沿信任链跟踪DNSSEC签名

6.3 nslookup / host

• 更简单的查询工具，适合快速检查
• nslookup example.com
• host -t MX example.com

6.4 rndc —— 运行时控制

7. 常见错误与排查

7.1 常见日志消息

7.2 检查残缺授权（Lame Delegation）

父区授权了不存在的名称服务器，或子区未接受授权。

诊断方法：

1
2

dig @a.gtld-servers.net example.com NS   # 检查父区授权
dig @ns1.example.net example.com SOA     # 检查子区是否响应

7.3 正向/反向区不一致

• A记录和PTR记录不匹配导致认证延迟或失败
• 修改IP后务必同步更新反向区

7.4 忘记更新序列号

• 从服务器不会加载新数据
• 修复：更新主服务器序列号 → 等待刷新周期 → 或手动rndc reload example.com

8. 本章核心命令速查表

DBA视角补充：

• 数据库集群内部DNS：如MongoDB、Cassandra等分布式数据库通常使用DNS（SRV记录或A记录列表）发现集群节点。确保内部DNS稳定可靠是数据库高可用的前提。
• 连接字符串与DNS：应用数据库连接字符串使用域名而非IP，便于迁移和灾备切换（通过修改DNS即可切换流量）。需注意DNS TTL设置，太长的TTL会导致切换延迟。
• 数据库的PTR记录：某些数据库安全配置会检查客户端IP反向解析，确保PTR记录正确可避免认证延迟。
• 内部DNS自建 vs 托管：对于生产数据库集群，推荐使用自建BIND或内部托管DNS服务（如AWS Route 53 Private Hosted Zone），避免依赖公网DNS解析内部服务。
• 动态DNS更新：在DHCP环境中，结合BIND的动态更新（nsupdate）可自动为数据库节点注册DNS记录，简化节点扩缩容的DNS维护。
• DNSSEC与数据库：DNSSEC主要用于公网安全，内部数据库服务通常不需要启用（增加复杂性和延迟）。