23、DNS与DHCP：BIND配置与企业架构实践

DNS与DHCP：BIND配置与企业架构实践

1. BIND区域委派

为减轻BIND主服务器的负载，可将区域委派给其他服务器，这些服务器会成为相应委派区域的主服务器。例如，对于 example.com ， va.example.com 可委派给弗吉尼亚州的服务器， tx.example.com 可委派给德克萨斯州的主服务器。以下是设置BIND区域委派的示例：

1.1 example.com主BIND服务器配置

在 named.conf 文件中，配置 example.com 区域为主区域， tx.example.com 区域为从区域：

#named.conf file on the master for example.com
zone "example.com" {
  type master;
  file "master/master.example.com";
};

zone "tx.example.com"  {
  type slave;
  file "slave/slave.tx.example.com";
  masters {10.1.2.53;};
};

1.2 example.com区域文件配置

在区域文件中，指定 example.com 的SOA和NS记录，以及 ns1 和 ns2 的A记录，然后进行 tx.example.com 的区域委派：

#example.com zone file on master
$TTL 1d ; default TTL is 1 day
$ORIGIN example.com.
@              IN      SOA   ns1.example.com. admin.example.com. (
               100        ; serial number
               2h         ; refresh =  2 hours
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; minimum = 2 hours + 20 minutes
               )
; main domain name servers
              IN      NS     ns1.example.com.
              IN      NS     ns2.example.com.
; A records for name servers above
ns1           IN      A      10.1.1.53
ns2           IN      A      10.1.1.54

# zone delegation being done in this section
#master is ns3.tx.example.com and slave is ns1.example.com
$ORIGIN us.example.com.
tx.example.com.         IN      NS      ns3.tx.example.com.
                        IN      NS      ns1.example.com.
ns3.tx.example.com.             A       10.1.2.53

1.3 ns3.tx.example.com服务器配置

在 /etc/named.conf 文件中，指定 tx.example.com 的主服务器为 ns3.tx.example.com ，并允许向 ns1.example.com 进行传输：

#on ns3.tx.example.com, our named.conf
options {
    allow-transfer {"none";};
};
zone "tx.example.com" {
        type master;
        file "master/master.us.example.com";
        allow-transfer {10.1.1.53;};
};

1.4 tx.example.com区域文件配置

区域文件的 $ORIGIN 设置为 tx.example.com ，包含 ns3.example.com 的SOA和NS记录：

#on ns3.tx.example.com, our zone file
$TTL 1d ; default TTL = 1 days
$ORIGIN tx.example.com.
@              IN     SOA   ns3.tx.example.com. hostmaster.tx.example.com. (
               100        ; serial number
               2h         ; refresh =  2 hours
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; minimum = 2 hours + 20 minutes
               )
                  IN      NS     ns3.tx.example.com.
                  IN      NS     ns1.example.com.

ns3               IN      A      10.1.2.53

2. 获取BIND帮助的途径

有许多邮件列表可提供BIND相关帮助，可在 https://lists.isc.org/mailman/listinfo 找到完整列表。以下是一些推荐的邮件列表：
| 邮件列表名称 | 作用 |
| ---- | ---- |
| bind-announce | 帮助你了解BIND的新版本发布情况 |
| bind-users | 包含关于BIND的常见问题 |
| dhcp-announce | 包含DHCPD的公告信息 |
| dhcp-users | 帮助解决DHCPD相关问题 |

此外，还有一些关于DNS和BIND的优秀书籍值得阅读，如Cricket Liu和Paul Albitz所著的《DNS and Bind》第5版，以及Cricket Liu所著的《DNS & Bind Cookbook》。ISC还在 http://www.dns-co.com/solutions/bind-subscription/ 提供BIND的专业支持，截至目前，最基本的支持年费为10,000美元。

3. BIND企业架构

在确定顶级域名（TLD）、注册商、域名和DNS软件后，下一步是决定如何在企业中部署DNS服务器。BIND支持主服务器、从服务器和缓存服务器，区域编辑在主服务器上进行，从服务器和缓存服务器从主服务器拉取编辑内容。区域数量和记录数量会影响BIND的性能。

3.1 域名空间分区

将域名空间划分为区域是架构的关键组成部分。一种方法是按区域划分区域，例如 example.com 在加利福尼亚州、德克萨斯州、弗吉尼亚州和新加坡设有办事处，可创建以下子域名：
- ca.example.com
- tx.example.com
- va.example.com
- sg.example.com

这些区域还可根据应用类型进一步划分，例如：
- 生产服务器可位于 prd.<site>.example.com
- 质量保证（QA）服务器可位于 qa.<site>.example.com
- 开发服务器可位于 dev.<site>.example.com

3.2 服务器命名

服务器的主机名可以是服务器类型和应用的组合，例如：
- web001-fe.prd.va.example.com ，表示弗吉尼亚州的一个Apache生产服务器，属于前端（fe）应用的一部分
- db002-erp.qa.tx.example.com ，表示德克萨斯州的一个MySQL QA数据库服务器，属于企业资源规划（erp）应用的一部分

3.3 服务器类型选择

BIND只支持一个主服务器进行区域编辑。主服务器可以使用Linux HA进行集群，如 http://www.linux-ha.org/wiki/Main_Page ，也可以使用单台主服务器。主服务器应位于网络连接最冗余、速度最快的站点。例如，如果德克萨斯州的带宽最大，则可将主服务器放置在德克萨斯州。

如果有大量子域名，可将子域名委派给其他DNS服务器，以减轻单台主服务器的负担。区域委派与转发不同，区域委派意味着子服务器负责区域数据，任何查询都应发送到子DNS区域服务器。

3.4 从服务器配置

每个站点至少应有两台从服务器。一种选择是每个子网至少有两台名称服务器，以避免路由器故障问题。但对于某些组织来说，这可能过于冗余，他们可能更倾向于每x个子网配置几台名称服务器。实际需要的从服务器数量取决于预期的查询数量和硬件类型。例如，如果选择十核处理器，且从服务器至少有两个十核处理器和大量物理内存（如512GB），则几台从服务器可能足以处理每秒数千次查询。

两台从服务器应列在客户端的 /etc/resolv.conf 文件中，但一半客户端应将一台从服务器列在前面，另一半客户端应将另一台从服务器列在前面，以实现负载均衡。

3.5 区域信息存储

可使用Git（ http://git-scm.com/ ）存储区域信息。Git的优点是具有版本控制功能，且采用去中心化模型，便于对区域文件进行编辑。

4. 理解DHCP

动态主机配置协议（DHCP）是一种为网络设备提供IP地址的简便方法。DNS和DHCP密切相关，一个提供IP地址，另一个提供IP地址与主机名的映射。DHCP可与DNS集成，当DHCP将IP地址分配给网络设备时，DNS会更新以反映设备名称。或者，可给DHCP IP地址预先指定名称，无需动态更新DNS。

企业使用DHCP的原因有很多，例如：
- 在使用Kickstart进行主机配置时提供IP地址
- 为企业网络中的无线客户端（如笔记本电脑和智能手机）提供IP地址
- 为互联网协议语音（VoIP）客户端（如VoIP电话）提供IP地址
- 为桌面计算机提供IP地址
- 为员工、访客和承包商的笔记本电脑提供IP地址
- 服务器通常不使用DHCP分配IP地址，而是使用静态IP地址。

5. DHCP企业架构

企业的安全工程师可能对DHCP持谨慎态度，因为难以追踪DHCP分配的IP地址。例如，如果某个IP地址发起攻击，在静态IP地址分配的情况下，可以在IP地址管理数据库中查找该IP属于哪个设备，然后进行追踪。而使用DHCP，除非进行了DHCP预留，否则该IP地址可能属于网络上任何支持DHCP的节点。

对于有线DHCP客户端，需要查看路由器/交换机的媒体访问控制（MAC）地址表，以确定设备连接到哪个端口，以及MAC地址的供应商ID。如果DHCP IP地址来自无线设备，则更难追踪，除非使用某种可扩展认证协议（EAP）。

5.1 DHCP的作用

DHCP仍可在企业架构中发挥作用。使用预留的DHCP IP地址，可以将IP分配给特定的MAC地址，有助于跟踪网络上的设备。然而，MAC地址可以被伪造，这只是攻击者需要突破的一层额外复杂性。

5.2 设备选择

企业中哪些设备应使用DHCP呢？可以确定的是，服务器不应使用DHCP分配的IP地址，而应使用静态IP地址，这样更易于管理。无线客户端和网络访客可以使用DHCP。如果使用EAP和Radius认证，则可以将DHCP分配的IP地址与用户名关联起来，便于进行计费。

对于启动Linux主机，可使用基于服务器MAC地址的静态预留DHCP。这可以实现预启动执行环境（PXE）引导，同时确保DHCP IP地址不会分配给恶意设备。

5.3 DHCP服务器数量和位置

在部署DHCP服务器之前，需要确定企业需要多少台DHCP服务器，以及每台服务器的位置。一种方法是在每个服务器网络上，将路由器配置为IP助手，将所有DHCP请求转发到一对DHCP服务器。由于DHCP仅在PXE引导安装过程中使用，因此不需要大量的DHCP服务器。一台强大的DHCP服务器可以同时处理数千个请求，因此对于1000个客户端，一对DHCP服务器应该足够。如果某个站点有5000台服务器，则五对DHCP服务器（每1000个客户端一对）应该足够。实际情况下，DHCP服务器能够服务的客户端数量取决于所使用的硬件和同时请求的数量。

6. 主DHCP服务器配置

6.1 下载和编译

可以从 https://www.isc.org/downloads 下载ISC DHCP，也可以使用Linux发行版自带的DHCP。与BIND类似，DHCP有ESV、当前版本和当前稳定版本。生产环境推荐使用当前稳定版本和ESV。截至目前，最新的ESV版本是4.1-ESV-R10。对于希望使用最新稳定版本的企业，可选择当前稳定版本；对于希望更新频率较低但更稳定的企业，可选择ESV。

下载后，需要进行编译：

$ ./configure
# make
# make install

6.2 使用Linux发行版安装

大多数Linux发行版都自带DHCP。例如，在CentOS中，可以使用yum仓库安装DHCPD：

$ yum search dhcp | egrep -i '^dhc'
dhcping.x86_64 : DHCP daemon ping program
dhcp-common.x86_64 : Common files used by ISC dhcp client and server
dhcp-devel.i686 : Development headers and libraries for interfacing to the DHCP
dhcp-devel.x86_64 : Development headers and libraries for interfacing to the
dhclient.x86_64 : Provides the dhclient ISC DHCP client daemon and
dhcp.x86_64 : Dynamic host configuration protocol software

需要安装的软件包是 dhclient 、 dhcp-common 和 dhcp 。使用发行版的yum仓库安装软件包可以避免自己编译的麻烦。

6.3 服务器配置文件

DHCP由客户端和服务器两个不同的组件组成。服务器上不需要客户端组件。服务器的配置文件是 /etc/dhcp/dhcpd.conf 。如果希望服务器本身使用DHCP获取IP地址，应在 /etc/sysconfig/network-scripts/ifcfg-eth0 文件中设置 BOOTPROTO=dhcp 。

需要注意的是，在CentOS/RedHat默认安装中，如果 /var/lib/dhcpd/dhcpd.leases 文件缺失，DHCPD将无法启动。可以使用 touch 命令创建该文件以启动DHCPD。

服务器的主配置文件有许多语句，这些语句按子句分组。DHCP对语法要求非常严格，因此在进行更改后，务必仔细检查语法，否则DHCP将无法启动。以下是一个示例 DHCPD.conf 文件：

#global settings
authoritative;
allow unknown-clients;
allow bootp;

option domain-name  "example.com";
option domain-name-servers  10.1.1.2,10.1.1.3;
option ntp-servers 10.1.1.4,10.1.1.5;

default-lease-time 3600;
max-lease-time 7200;

#subnet declaration
subnet 10.1.1.0 netmask 255.255.255.0 {
    option routers                  10.1.1.254;
    option subnet-mask              255.255.255.0;
    option broadcast-address        10.1.1.255;

    option domain-name              "dev.example.com";

    range 10.1.1.50 10.1.1.250;
}

#groups
group {
   # Specific TZ for database servers
   option time-offset              -21000;

   host myclient1 {
      option host-name "db001.example.com";
      hardware ethernet XX:XX:XX:XX:XX:XX;
      fixed-address 10.1.1.20;
      allow booting;
   }

   host myclient2 {
      option host-name "db002.example.com";
      hardware ethernet XX:XX:XX:XX:XX:XX;
      fixed-address 10.1.1.21;
      allow booting;
   }
}

7. DHCP故障转移

作为可靠企业基础设施的一部分，需要设置故障转移DHCP服务器。幸运的是，ISC DHCP支持主从模式，即如果一台DHCP服务器出现故障，另一台服务器可以接管DHCP IP地址分配。

7.1 服务器配置要求

主DHCP服务器和从DHCP服务器必须运行相同版本的DHCPD，并且使用NTP同步时间。它们应位于相同的网络中，并能够访问它们所服务的所有网络。

7.2 故障转移配置示例

可以在负载均衡模式下运行DHCPD并实现故障转移，也可以仅实现故障转移而不进行负载均衡。以下是一个负载均衡模式下的故障转移配置示例：

failover peer "failover-partner" {
    primary;
    address dhcp-primary.example.com;
    port 519;
    peer address dhcp-secondary.example.com;
    peer port 520;
    max‐response‐delay 45;
    max‐unacked‐updates 10;
    mclt 3600;
    split 128;
    load balance max seconds 3;
}

failover peer "failover-partner" {
    secondary;
    address dhcp-secondary.example.com;
    port 520;
    peer address dhcp-primary.example.com;
    peer port 519;
    max‐response‐delay 45;
    max‐unacked‐updates 10;
    load balance max seconds 3;
}

在这个示例中， split 值设置为128，表示50%的请求将发送到主服务器，50%的请求将发送到从服务器，有助于在两台服务器之间分担负载。如果主服务器出现故障，从服务器将开始响应主服务器的请求。

mclt 值是最大客户端领先时间值，即恢复中的主服务器在收到对等租赁数据库后，在开始承担主角色之前必须等待的秒数。 split 和 mclt 值仅在主服务器上定义，从服务器上不定义。 max response delay 值设置为45秒，表示主服务器在认为对等连接断开之前等待的时间。

max-unacked-updates 允许最多十次未确认的绑定更新，这意味着服务器在发送额外消息之前必须等待未决数据包的确认。

综上所述，通过合理配置BIND和DHCP，可以构建一个高效、可靠的企业网络基础设施。在实际应用中，应根据企业的具体需求和网络环境进行调整和优化。

8. DHCPD.conf文件详解

8.1 全局设置

全局设置适用于所有客户端，通常列在文件顶部。其中以 option 关键字开头的参数是DHCP选项，其他非 option 开头的参数则是专门针对DHCPD的。DHCPD可以对给定网络具有权威性，即它会响应所有DHCP请求，即使它不知道该IP地址。 unknown-clients 参数允许DHCP响应来自未在DHCPD文件中明确定义的客户端的请求。在企业中，通常会有多个权威的DHCPD服务器。

#global settings
authoritative;
allow unknown-clients;
allow bootp;

option domain-name  "example.com";
option domain-name-servers  10.1.1.2,10.1.1.3;
option ntp-servers 10.1.1.4,10.1.1.5;

8.2 租约时间

租约时间是DHCP配置的关键组成部分。如果配置的租约时间较短，客户端会频繁请求IP地址，可能会使DHCP服务器过载；而如果租约时间较长，客户端可能会长期占用IP地址。理想的租约时间取决于DHCP客户端的使用情况。例如，如果DHCP主要用于服务器镜像，较短的租约时间是合理的，因为客户端只在操作系统安装期间需要DHCP IP地址，之后可以分配静态IP地址。如果DHCP服务器用于虚拟专用网络（VPN）客户端和无线客户端，较长的租约时间可能有助于减轻DHCP服务器的负载。时间以秒为单位，以下示例中默认租约时间为一小时，最大租约时间为两小时。

default-lease-time 3600;
max-lease-time 7200;

8.3 子网声明

对于每个需要DHCP服务且连接到DHCPD服务器的子网，都需要进行子网声明。 DHCP range 选项指定了DHCPD服务器分配给客户端的IP地址范围，该范围取决于子网中可用的IP地址。在下面的示例中，子网掩码为 /24 ，我们选择了从 10.1.1.50 到 10.1.1.250 的200个IP地址作为DHCP范围，其余IP地址留作管理用途，如路由器、DNS服务器、DHCP服务器本身和其他服务。

#subnet declaration
subnet 10.1.1.0 netmask 255.255.255.0 {
    option routers                  10.1.1.254;
    option subnet-mask              255.255.255.0;
    option broadcast-address        10.1.1.255;

    option domain-name              "dev.example.com";

    range 10.1.1.50 10.1.1.250;
}

8.4 组设置

组是为一组DHCP客户端设置共同配置的一种方式。例如，我们要确保两台特定的笔记本电脑处于特定的时区，可以使用 option time-offset 通过DHCP指定。此外，为了确保这两个特定客户端下次上线时使用相同的IP地址，我们可以在组中使用 host 语句。

#groups
group {
   # Specific TZ for database servers
   option time-offset              -21000;

   host myclient1 {
      option host-name "db001.example.com";
      hardware ethernet XX:XX:XX:XX:XX:XX;
      fixed-address 10.1.1.20;
      allow booting;
   }

   host myclient2 {
      option host-name "db002.example.com";
      hardware ethernet XX:XX:XX:XX:XX:XX;
      fixed-address 10.1.1.21;
      allow booting;
   }
}

8.5 企业配置要点

企业中DHCPD配置文件的设置取决于底层网络基础设施和DHCP客户端的数量。一般来说，应仅配置所需数量的DHCP服务器，因为向网络设备分配IP地址如果出现恶意设备，可能会带来潜在的安全风险。有些企业只向已知MAC地址的设备分配DHCP IP地址，虽然这种策略并非万无一失，因为MAC地址可以被伪造，但它确实提供了一层额外的保护。

9. 总结与最佳实践建议

9.1 BIND配置总结

• 区域委派 ：通过将区域委派给其他服务器，可以减轻主BIND服务器的负载，提高性能和可管理性。在进行区域委派时，需要正确配置主服务器和从服务器的 named.conf 文件以及相应的区域文件。
• 企业架构 ：在企业中部署BIND时，要合理划分域名空间，根据区域和应用类型创建子域名。主服务器应放置在网络连接最稳定、带宽最大的站点，每个站点至少配置两台从服务器以实现负载均衡和故障转移。使用Git存储区域信息，方便版本控制和编辑。
• 获取帮助 ：利用邮件列表和相关书籍获取BIND相关的帮助和知识，必要时可考虑ISC提供的专业支持。

9.2 DHCP配置总结

• 功能与应用 ：DHCP为网络设备提供了便捷的IP地址分配方式，与DNS紧密相关。在企业中，可用于多种设备的IP地址分配，但服务器通常使用静态IP地址。
• 企业架构 ：考虑到安全问题，要合理规划DHCP服务器的数量和位置，使用预留IP地址和静态预留DHCP，以跟踪设备和防止恶意设备接入。
• 配置要点 ：正确配置DHCPD.conf文件，包括全局设置、租约时间、子网声明和组设置等。同时，要注意语法的正确性，避免因语法错误导致DHCP无法启动。
• 故障转移 ：设置故障转移DHCP服务器，确保在主服务器故障时，从服务器能够接管IP地址分配工作，保障网络的正常运行。

9.3 最佳实践流程图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始规划]):::startend --> B{选择DNS和DHCP软件}:::decision
    B -->|BIND和ISC DHCP| C(规划BIND企业架构):::process
    C --> D(划分域名空间):::process
    D --> E(配置主从服务器):::process
    E --> F(使用Git存储区域信息):::process
    B --> G(规划DHCP企业架构):::process
    G --> H(确定服务器数量和位置):::process
    H --> I(配置主DHCP服务器):::process
    I --> J(设置故障转移):::process
    F --> K(配置DHCPD.conf文件):::process
    J --> K
    K --> L([完成配置]):::startend

9.4 未来趋势与展望

随着企业网络的不断发展和变化，DNS和DHCP技术也将不断演进。未来，可能会出现更智能、更安全的IP地址分配和管理方式，如结合人工智能和机器学习技术，实现自动化的网络配置和故障诊断。同时，随着物联网设备的大量增加，对DHCP和DNS的性能和安全性提出了更高的要求，需要不断优化和改进现有的技术和架构。企业在构建网络基础设施时，应密切关注这些趋势，及时调整和升级自己的网络配置，以适应未来的发展需求。

在实际应用中，企业应根据自身的规模、业务需求和网络环境，灵活运用上述配置和实践建议，不断优化和完善网络基础设施，确保网络的高效、稳定和安全运行。