linux动态DNS服务器架设

t40ulr3364

前言：随着网络的不断扩张，用户的数量不断增多，频繁修改DNS数据库中的记录真的很麻烦，也给管理员带来了不少麻烦事，所以采用动态DNS是最好的解决方案。Linux下用动态DNS服务的话，修需要bind8.0以上的软件，还要DCCP service v3.0以上的版本，因为只有3.0以上的版本才完全实现了对DDNS的支持。因此我们本实验的环境是在RedHat as 4.2上完成的。

1.      创建密钥：要实现DNS的动态更新，为了保证其安全性，需要创建动态更新的密钥，让其在进行更新时通过密钥加以验证。为了实现这一功能，需要一root用户的身份登录，创建密钥，注意密钥的存放路径，应该是在/var/named/chroot/etc下，截图如下

    

   上述dnssec-keygen命令的功能就是生成更新密钥，其中参数-a HMAC-MD5是指密钥的生成算法采用HMAC-MD5；参数-b 128是指密钥的位数为128位；参数-n USER ddns-key是指密钥的用户为ddns-key

2.      运行上面那条命令后产生的密钥名称为Kddns-key.+157+63785，那么查看一下该名称的公钥和私钥如下：

    

3.      由于我们待会需要的是密钥里面的信息，即是密钥里面的密文，所以我们可以查看一下公钥和私钥的密文：如下图所示
  

可以从上面的内容可以看出两把钥匙的内容是相同的，该密钥就是DHCP对DNS进行安全动态更新时的凭据。后面需要将该密钥分别添加到DNS和DHCP的配置文件中。

4.      编辑named.conf主配置文件，增加一个域为redhat.com，反向查找为0.168.192.in-addr.arpa，同时写入密钥文件的内容，截图如下：
   
 
注意：将密钥文件的写入是最为重要的，secret 里面得内容是我们上面第3所看到的内容，对于DNS的配置不清楚的话，可以查看《DNS服务器的架设》文档。
5.      DNS中区域文件的配置如下： yangzexin.redhat.com的区域配置文件如下：
  

192.168.10.in-addr.arpa的区域配置文件如下：

  

6.      对dhcpd.conf配置文件进行修改，修改结果如下图所示：

 

 

注意需要添加红色的部分，这也是提供跟DNS验证的东东。至于DHCP服务器的配置那就请看《单区域DHCP服务器的架设》，而且这个是比较简单的。

7.      启动DHCP服务和DNS服务，截图如下：
   
  

 

 

 

8.      启动windows2003的自动获取IP地址和windows XP客户端自动获取IP地址：截图如下：
  
  

 

 

 

9.  查看DHCP服务器中dhcpd.leasej记录，查看是不是以上两个IP地址别主机所申请了，如下图所示：
  

 

 

 

 

从上面可以看出以上的两台主机在DHCP服务器上申请的IP地址，同时还向DNS服务器发出请求更新（红色部分）。

10.  查看DNS日志信息和DNS记录的更新情况。
 

 

有DHCP服务器192.168.10.100向DNS服务器提出请求更新，并且将记录添加到了DNS的区域文件中去：下面看一下DNS的区域文件：

  

11.查看在客服端能不能对其进行解析，解析情况如下：

   

二．该实验过程中所碰到的问题：

1.一台主机用了双网卡，同时这两台主机的两块网卡采用了自动获取IP地址，结果DNS区域文件中的记录总是只有一条记录，这个是为什么呢？
  答：查看了一下dhcp服务器向DNS服务器提出申请信息时的日志文件，如下图所示：
     
 

从图中我们可以看出“update failed: RRset exists(value dependent) ……”从这句话可以看出：由于其中一块网卡的IP地址所对应的主机名在这里已经注册了，假设为abc.redhat.com    192.168.10.198在DNS中注册了，而此时另一块网卡的Ip地址为192.168.10.196，也想进行注册，可是DNS是不允许的，因为这块网卡的主机名也是abc,这样子的话网络就出现了重命名的现象，所以就只能注册一个，另外一个注册不了。（这个只是个人的见解，也不知道对不对，不过我想应该是没有错的吧！）然而上面的就是后来改成了单网卡，注册成功，而且没有问题。

2.在做实验的过程中，碰到了下面截图的问题。

 

从这个图中我们很清楚的知道，签名是无效的，也就是DHCP向DNS请求更新的时候，签名是无效的！结果失败了。

答：其实签名无效是因为在写dhcpd.conf和named.conf的文件时，密码的匹配和格式的不正确所导致的，因为上面那些密文都是手写进去的，所以结果出现了错误。特别是些如得格式一定要正确。（注：不同版本的Linux系统可能写法有所不同的）
    签名无效的另外一个原因就是DHCP服务器和DNS服务器的时间不同步的问题，导致签名错误，如果DHCP和DNS分别在不同的机器上实施的话，那么就会产生该问题的，这也是应该值得注意的问题。
3. 在做实验的过程中，碰到了下面截图的问题.
   
   答：从图中的信息可以看出是权限不够的问题，所以无法创建关于正向查找区域和反向查找区域的日志文件。那么权限在哪里修改呢？看下图几个地方：请确认可以一下其所有组权限和所有组：
            
       上面这个图是我修改过的，原本就是属于named组的，但是作为named组却没有写入的权限，所以结果就用这么一条命令chmod 770 var将其改了，那么在var下的子文件呢，也是要进行修改的，因为上面的两个日志文件是存在named目录下的，所以现在得看一下var目录下的named目录的权限了；
           
      上面named文件夹的权限也是我修改过的，因为named 文件夹是属于named这个组的，但是这个组却没有写入权限，所以也将其改为770的权限了，这样子话，就能够顺利自动的创建正向查找区域和反向查找区域的日志文件了，截图如下：
             
提示：其实有时我们的dns配置是没有错误的，但是DNS就是跑不起来，其实这个跟named用户和named组有很大的关系，因为DNS能够跑起来，很大程度上是靠named用户和named组来启动的，从上面的截图可以看出自动产生的系统区域文件都是属于named用户和named组的，所以这个也是很重要的，有时是用root用户和root组的，要记得把他们修改过来，特别是在复制模板的时候，要将其所属者和所属组改成named用户和named组。其实在这个实验中并没有拷贝模板问题，因为安装软件包的时候就已经默认将一切都给搞定了。如果你是在relhat 5.0的环境下来搭建DNS服务器的时候，是没有已经存在的区域文件，酷似都要去/usr/share/doc/bind-*/sample/*目录下拷贝那些文件到/etc/named/chroot/etc和/etc/named/chroot/var/named目录下，将其所属用户和组改为named，默认好像是root的，而且要注意权限问题。