DNS服务器系列之二:高级配置之-DNS子域授权、区域转发、acl列表及view

简介:

一、DNS子域授权及区域转发

1、创建子域的原因

   现在有shuishui.com这个域,由于技术部门的独立壮大,现在想要专门分割出一个tech.shuishui.com这么一个子域,这个子域内有它自己的www,ftp,mail等主机。现在虽然有shuishui.com这个父域,但是它并不能解析tech.shuishui.com这个子域,因为在其数据库内压根就没有这么一条A记录。

2、BIND子域授权的实现前题

   在父域的配置文件中添加如下项:

   1)授权的子区域名称

   2)子区域的名称服务器

   3)子区域的名称服务器的IP地

3、服务器IP及域名等相关说明

   1)父域shuishui.com的DNS服务器的IP地址为:172.16.251.93

   2)子域tech.shuishui.com的DNS服务器的IP地址为:172.16.150.150

4、子域授权的实现

   1)在子域的DNS服务器上安装BIND

1
yum -y  install  bind

  2)安装bind成功后,为子域DNS服务器定义区域,区域名称为:tech.shuishui.com

wKiom1Mo5f7yLfZHAAAeJq1pnco304.png

 3)区域创建成功后,接下来创建区域数据库文件并创建资源记录  

wKioL1Mo5qGhaZjxAAA8Qdjjq3o235.png

  4)创建区域数据库文件后,执行接下来的六大步骤

wKiom1Mo5w7BtioMAABjs90Copg809.png

      当检查区域数据文件的时候,报错说是tech.shuishui.com.zone没有前的owner name,那就打开这个文件看看吧

wKioL1Mo50rho-tJAABEtUmZRG4178.png

   原来是SOA少了区域名称,别的地方应该没有问题,补上@后,再重新检查

wKiom1Mo57mRLe1JAADAOl3HYp4186.png

   重新检查六大步骤,已经没有问题了,说明此区域数据库文件没有语法错误

   5)检查子域DNS服务器是否可以正常工作

wKioL1Mo6C-z3wdPAABvWqGZ5Lw494.png

   6)子域授权

      现在子域的DNS服务器可以正常工作了,但是目前父域不能解析子域,子域也不可以解析父域,所以我们为了能让父域解析子域,要在父域的区域数据库文件中为子域进行授权。

wKioL1Mo6OGSuAGrAABY2nvLJvc208.png

   其资源类型为NS,说明它是一个DNS服务器,而named是一个tech,而不再是@,也不是当前区域的名称,这就意味着这个字符串是一个子区域的名称,任何一个DNS服务器NS后面所对应的FQDN都应该给它一个A记录。为了能同步到从服务器上,要在上面的序列号后面加1,只有主服务器的序列号大于父域的序列号才会同步成功。

   7)重启named服务,测试父域能否解析子域

wKiom1Mo6oaRRsuWAABGZUR-CnI840.png

   解析失败,又出问题了,那就只能查询日志了,看看什么情况

wKiom1Mo6sPx2RAwAACEyq-Fgw8890.png

   目前这台父域DNS服务器的IP为:172.16.251.93,这里说报的错的IP指向了子域DNS服务器的IP,那就去子域DNS服务器上看看日志

wKioL1Mo6yjDYePYAAB5SrPXQuY285.png

   这里报错说192.16.251.93这个主机询问www.tech.shuishui.com被拒绝,而是否允许询问是在其主配置文件中定义的

wKiom1Mo6-fxAsICAAB2bY6RXNk327.png

   这里面果然有这么一项,那就改成any吧,原来是localhost,只允许本机询问

   再重启named服务,这次看看父域能否解析子域成功

wKiom1Mo7HGgUhzlAAB5gQVFxNc086.png

   7)配置区域转发

   现在父域可以解析子域成功了,但是子域还不可以解析父域,因为在它的服务器上只有tech.shuishui.com这一个域,而没有shuishui.com这么个域,因此是不会去解析父域shuishui.com的。我们都知道,如果一台DNS服务器在解析非本机负责的区域时,会统统交给根,那我们就配置一个转发,让他不要转发给根,而是转发给相应的DNS服务器去解析,这就叫做区域转发。

wKiom1Mo7keBW44BAAAwb09iqwk489.png

   编辑子域的/etc/named.rfc1912.zones,为其添加指定的转发区域:

   ①、服务器类型为转发

   ②、转发到的服务器IP是172.16.251.93这台DNS服务器

   ③、转发模式为first。这里有两个选项,一个是first,就是在转发shuishui.com这域时,先要转发到172.16.251.93,如果解析不成功就转发给根。别一个是only,意思就是只转发给172.16.251.93,不成功也不会转发给根。

   8)尝试在子域上去解析父域,希望别再出错了

wKioL1Mo78jxdZrnAABqf0xrWYk696.png

 历经磨难终于成功了。

、DNS的访问控制列表及view功能

   1、view功能介绍

   view是视图的意思,实现将DNS服务器一切为N片,当来自不同的IP时就用不同的DNS服务器去解析,速度肯定会更快,当然用户体检就更好了,这就叫做DNS智能解析。举个例子来说,中国大陆的网络一直就有北联通,南电信这么一说,造成这一结果的根本原因就是因为两个网络之间的带宽太小了,这就避免不了网络之间的拥堵。比如人一家游戏公司,你用的是电信的网,而它的服务器是联通的,当你进入这个区玩儿游戏的时候,不卡死才怪,这么糟糕的用户体验,如果能留住用户,不得不说是一个奇迹,这也就是为什么游戏一般都有网通区、电信区的原因。而我们今天要做的就是定义这么一个view,让它根据用户IP自动去选择,如果是联通的IP,就走联通的服务器,如果是电信用户就去访问电信的服务器,让其实现智能DNS解析。

   2、acl

   如果想实现DNS的智能解析,这个必须先介绍清楚了

   acl:access control list,顾名思义就是访问抑制列表的意思,定义访问控制列表就是为了能够让其根据IP进行控制,哪些IP可以访问,哪些IP不可以访问,联通的用户走哪条路,电信的用户走哪条路。下面就开始介绍实现这高大上的DNS智能解析功能。

   3、view功能配置详解

   1)在/etc/named.rfc1912.zones中定义ACL及view

       只要在DNS服务器中使用view功能,那么所有的域都必须放到view中,那么/etc/named.conf中的"."域也必须给它剪切过来,放到view中,否则会报错的。这里定义两个访问控制列表:telecom及unicom,假设联通的IP是192.16段的,电信的IP是172.16段的,这里只是模拟,如果在真实环境中,就需要自己去统计这些联通和电信的IP了。然后定义三个view:telecom,unicom,default,定义default的意义就在于,你统计时肯定会有漏掉的IP,那就让它走这个默认的。

   定义telecom这个域,把/etc/named.rfc1912.zones中原来的zones都放在这个view中吧。对于view来说,它是有执行顺序的,如果你是联通的用户多,那就把unicom放到上面,如果是电信的多,那就把telecom放到上面,这里假设电信的多。

wKioL1Mo9pnwBllTAACUfzpgl7c582.png

   定义unicom及default的view

wKioL1Mo-OSSDVqHAABHGrtcbXA537.png

2)为服务器添加两个网卡,配置两个IP,一个负责解析电信用户的,另一个负责解析联通用户的

wKiom1Mo-VHTzbmsAACEciR4wls881.png

3)为两台服务器创建区域数据库文件,联通的就叫shuishui.com.unicom,电信的就叫shuishui.com.telecom。但是这两个区域数据库文件对应的是一个域名啊,这个千万别搞错了,我们这么做的原因就是为了让一个用户访问我们的主页时,会根据其IP自动去解析使用哪台服务器,从而提高用户体验,千奇别弄错了。

   ①、创建shuishui.com.unicom资源记录,192.16开头的

wKiom1Mo-oLgWGyIAAAsE1MdZZs759.png

  ②、创建shuishui.com.telecom资源记录,172.16开头的

wKioL1Mo-qej6lz7AAAtn_tMzhw990.png

   4)重启named服务,查看端口是否被监听

wKiom1Mo-w3jMOfPAABKN4fTHBE582.png

两台DNS服务器上的UDP,TCP 53号端口已经成功被监听

   5测试unicom这个view的解析

wKiom1Mo-4DxqENFAABsArwt3oI112.png

6)测试telecom这个view的解析

wKiom1Mo-7-CUHQkAABKlIGgMOc582.png

出问题了,telecom这个view解析不成功,查看日志吧

wKiom1Mo--_jKX53AADRHJcqz4o257.png

   报错说是shuishui.com.telecom这个permission denied,原来是权限问题啊,突然想起来,没有执行六大步骤,权限也忘了改了,那就把shuishui.com.telecom这个区域数据库文件的属组改成root吧,再重新测试解析

wKiom1Mo_GmTwODCAACCbaJXYzQ038.png

修改权限后解析成功

   这高大上的配置就这样搞定了。在配置之前,最好还是先把原理搞明白了,就容易的多了。谢谢观看!










本文转自 nmshuishui 51CTO博客,原文链接:http://blog.51cto.com/nmshuishui/1379440,如需转载请自行联系原作者
目录
相关文章
|
21天前
|
Prometheus 监控 关系型数据库
数据库同步革命:MySQL GTID模式下主从配置的全面解析
数据库同步革命:MySQL GTID模式下主从配置的全面解析
81 0
|
1月前
|
域名解析 存储 缓存
【域名解析DNS专栏】动手实践:手动配置DNS解析记录
【5月更文挑战第22天】本文介绍了DNS解析记录的概念及其手动配置步骤。DNS解析记录是将域名映射到IP地址的数据,常见类型包括A(IPv4)、AAAA(IPv6)和CNAME(别名)。配置步骤包括登录DNS管理平台,添加记录,选择记录类型,填写主机记录和记录值,设置TTL值,并保存。以阿里云为例的A记录配置示例也提供了具体操作。了解这些有助于更好地管理域名。
【域名解析DNS专栏】动手实践:手动配置DNS解析记录
|
28天前
|
域名解析 缓存 监控
【域名解析 DNS 专栏】解析失败的 DNS 重试策略与配置优化
【5月更文挑战第28天】DNS解析在数字化时代关键但常遇失败,可能由网络、服务器或域名错误引起。实施智能重试策略(如指数级增长的重试间隔)和配置优化(如选用可靠DNS服务器、设置缓存、监控预警)能提高成功率和系统稳定性。示例代码展示基本DNS重试函数,强调需按业务需求调整策略并配合监控以保证高效稳定的DNS解析。
|
1月前
|
缓存 测试技术 Android开发
深入了解Appium:Capability 高级配置技巧解析
Appium 提供多种进阶配置项以优化自动化测试,如 deviceName 作为设备别名,udid 确保选择特定设备,newCommandTimeout 设置超时时间,PRINT_PAGE_SOURCE_ON_FIND_FAILURE 在错误时打印页面源,以及测试策略中的 noReset、shouldTerminateApp 和 forceAppLaunch 控制应用状态和重启。这些配置可提升测试效率和准确性。
31 2
|
1月前
|
iOS开发 Python
mac:python安装路径,带你全面解析Python框架体系架构view篇
mac:python安装路径,带你全面解析Python框架体系架构view篇
|
1月前
|
分布式计算 Java 数据库连接
实时数仓 Hologres产品使用合集之该创建外部表maxCompute的这个服务器列表如何解决
实时数仓Hologres是阿里云推出的一款高性能、实时分析的数据库服务,专为大数据分析和复杂查询场景设计。使用Hologres,企业能够打破传统数据仓库的延迟瓶颈,实现数据到决策的无缝衔接,加速业务创新和响应速度。以下是Hologres产品的一些典型使用场景合集。
|
4天前
|
机器学习/深度学习 缓存 算法
netty源码解解析(4.0)-25 ByteBuf内存池:PoolArena-PoolChunk
netty源码解解析(4.0)-25 ByteBuf内存池:PoolArena-PoolChunk
|
6天前
|
XML Java 数据格式
深度解析 Spring 源码:从 BeanDefinition 源码探索 Bean 的本质
深度解析 Spring 源码:从 BeanDefinition 源码探索 Bean 的本质
17 3
|
5天前
|
存储 NoSQL 算法
Redis(四):del/unlink 命令源码解析
Redis(四):del/unlink 命令源码解析
|
6天前
|
XML Java 数据格式
深度解析 Spring 源码:揭秘 BeanFactory 之谜
深度解析 Spring 源码:揭秘 BeanFactory 之谜
13 1

相关产品

  • 云解析DNS
  • 推荐镜像

    更多