DNS服务解析,如何用bind构建主从架构的DNS服务器。

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析DNS,个人版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:

DNSDomain Name System,域名系统)

        在互联网上实现FQDN与IP地址的解析,这样避免了人们在访问站点时,记忆长串难懂的ip地址,只需要记忆人们容易理解的域名就行了。

        FQDN (Fully Qualified Domain Name,完全合格域名)

        FQDN------------------IP Address 正向解析

        IP Address------------FQND 反向解析

简述工作原理:

        我们大家都知道,全球一共有13台根节点服务器,当我们的DNS服务器收到一个解析请求时,会触发一个中断从用户模式转变到内核模式把报文接进来,当把第四层封装解开时,就知道用户访问的是53号端口,内核会把数据交给工作在用户空间的这个进程,然后named服务会查询自己的解析库,如果是本服务器负责解析的域,就直接返回权威答案,如果不是,将会找根节点服务器,经过一轮迭代后,把查询到的结果给客户端。

DNS服务程序:

        用的最多的就是bind,在安装好后主配置文件在/etc/named.conf,服务进程名named。

        启动服务后,会向内核注册使用一个ip与端口的套接字,监听在本机tcp53端口,和udp53端口。

下面让我们来用bind实现DNS解析吧:

实验规划:

                解析域:tuchao.com

                主DNS服务器:dns.tuchao.com    192.168.1.200

                从DNS服务器:ns2.tuchao.com    192.168.1.254

                host:

                www.tuchao.com    192.168.1.100

                www.tuchao.com    192.168.1.101

                mail.tuchao.com     192.168.1.106

                ftp.tuchao.com        192.168.1.120

                pop.tuchao.com      192.168.1.110

                ssh.tuchao.com  CNAME  pop

         功能:实现正反向主从DNS解析,从服务器能自动从主服务器同步区域数据,并且设定权限,主服务器只允许从服务器获取区域数据,从服务器不允许任何主机获取区域数据,保证安全性。

 

1、安装bind程序软件:

        # yum install bind -y

wKiom1N03LySB8VRAAGoNygpNu4051.jpg

2、修改主配置文件/etc/named.conf

用双斜线注释掉下面三行然后保存

        listen-on port 53 { 127.0.0.1; };

        listen-on-v6 port 53 { ::1; };

        allow-query     { localhost; };

wKioL1N03kWAgUuDAAF4s1jRBBw335.jpg

3、编辑包含的区域文件/etc/named.rfc1912.zones,增加一个tuchao.com区域。

zone "tuchao.com" IN {
        type master;
        file "tuchao.com.zone";
};

然后去/var/named/目录创建tuchao.com.zone这个区域文件。

每个区域文件的第一条记录必须是SOA记录,定义主dns服务器,以及相关信息。

这里两个IP地址指向一个主机名,是为了实现负载均衡,交替解析。

CNAME是别名。

wKiom1N04zGh8RXDAAD3RShBVqQ230.jpg

配置完成后保存退出,检查下有没有语法错误,看到OK就代表没有。

# named-checkconf

# named-checkzone "tuchao.com" /var/named/tuchao.com.zone 

wKiom1N05JfxqxeuAAC_WmdFv0c674.jpg

服务成功启动,并且已经侦听在tcp和udp的53端口上了。

wKioL1N05sXRKtcJAAFNwpuMsH4152.jpg

配置resolv.conf文件把DNS设为自己——nameserver 127.0.0.1

看下能不能正常解析。

# dig -t NS tuchao.com

wKiom1N06AyibeA-AAEvI82OPks532.jpg

# dig -t A www.tuchao.com

wKioL1N06DGB_FISAAEvI82OPks893.jpg

再试试能不能解析外网的域名,看来是可以正常解析的,因为不是本dns负责的区域,他会去找根。

# dig -t NS baidu.com

wKiom1N06RXA_5O6AAI6SPGOTlI253.jpg

接下来设置反向区域,实现反向解析。

编辑/etc/named.rfc1912.zones,增加一个1.168.192.in-addr.arpa区域。

wKiom1N06sHgg5LhAABnh4gBKcU608.jpg

创建1.168.192.zone反向区域文件,我们可以拷贝正向区域文件来修改。

# cp tuchao.com.zone 1.168.192.zone

# chown :named /var/named/*    ------------将文件的属组改为named

wKiom1N077rRtcNbAAEdxsE0Hz4114.jpg

保存后,重启named服务器,尝试反向解析。

# dig -x 192.168.1.106

wKioL1N08JCQ30lQAAFQgdWWHLc945.jpg

反向解析也成功了,现在配置从服务器。

编辑/var/named/tuchao.com.zone区域文件,添加一条NS记录,以及对应的A记录

wKioL1N09oqwZYsqAAEmOwm0xl8642.jpg

反向的也是如此

wKioL1N09wvjnanxAAFVTLjvgkY767.jpg

现在去配置从服务器的/etc/named.rfc1912.zones文件

然后启动从服务器上的named服务器,再到主服务器上重读配置文件,主服务器的区域文件就会自动同步到从服务器上。

wKiom1N1eaCyhFTzAADAXPGFlu4058.jpg

我们查看下从服务器的日志,是不是已经传送完成了?

wKioL1N1eoKhvlziAASE_ozWaeI603.jpg

我们再去slaves目录看下,有没有同步过来的区域文件。

# cd /var/named/slaves/

# ls

wKioL1N1ezexhq-OAACL72hSPGE097.jpg

已经有了吧,看下内容?

正向区域

wKioL1N1e5mDdK0YAAEsoyFeiHY441.jpg

反向区域

wKioL1N1e8vjvG5VAAGCHWupkUM605.jpg

和主DNS服务器一样的吧,试下能不能解析。

解析正常吧。

wKioL1N1g7fDv-j0AAHaLpW33DI080.jpg

如果要限制区域传送使用:allow-transfer { }

wKiom1N1iMmhZ3maAAC3TGyaSFU516.jpg

这样主服务器,只允许从服务器传送区域数据

从服务器设置不允许任何人传送区域数据:

wKioL1N1jp7B6CG3AADsqjX2o8s725.jpg

这样,我们的实验算是圆满完成了。

有问题欢迎与我交流QQ:1183710107

 

 

 

 

 

 本文转自qw87112 51CTO博客,原文链接:http://blog.51cto.com/tchuairen/1411976

 

 



相关文章
|
1月前
|
缓存 NoSQL Redis
Redis主从架构
当看到图示中红色标记的,就代表从节点挂载成功了。
19 0
|
1月前
|
弹性计算 运维 Java
解决方案测评(高效构建企业门户网站方案)基于ecs&云效&云解析DNS&VPC结合的自搭建方案报告
该文档是一个关于使用ECS、云效、云解析DNS和VPC结合的自搭建方案报告。主要内容包括前言部分,可能详细探讨了如何集成这些阿里云服务以构建自定义系统。由于提供的内容有限,具体的实施方案和细节未在摘要中体现。
185 2
|
1月前
|
网络协议 安全 数据挖掘
F5《企业DNS建设白皮书》中的DNS解析服务器最佳实践
F5《企业DNS建设白皮书》中的DNS解析服务器最佳实践
26 0
F5《企业DNS建设白皮书》中的DNS解析服务器最佳实践
|
1月前
|
人工智能 NoSQL 关系型数据库
主从模式(Master-Slave Architecture)在传统的计算机科学中指的是一种分布式系统架构
主从模式(Master-Slave Architecture)在传统的计算机科学中指的是一种分布式系统架构
129 5
|
28天前
|
网络协议 安全 分布式数据库
技术分享:分布式数据库DNS服务器的架构思路
技术分享:分布式数据库DNS服务器的架构思路
21 0
|
1月前
|
XML Java 数据格式
深度解析 Spring 源码:从 BeanDefinition 源码探索 Bean 的本质
深度解析 Spring 源码:从 BeanDefinition 源码探索 Bean 的本质
36 3
|
22天前
|
存储 安全 Java
深度长文解析SpringWebFlux响应式框架15个核心组件源码
以上是Spring WebFlux 框架核心组件的全部介绍了,希望可以帮助你全面深入的理解 WebFlux的原理,关注【威哥爱编程】,主页里可查看V哥每天更新的原创技术内容,让我们一起成长。
|
24天前
|
关系型数据库 分布式数据库 数据库
PolarDB-X源码解析:揭秘分布式事务处理
【7月更文挑战第3天】**PolarDB-X源码解析:揭秘分布式事务处理** PolarDB-X,应对大规模分布式事务挑战,基于2PC协议确保ACID特性。通过预提交和提交阶段保证原子性与一致性,使用一致性快照隔离和乐观锁减少冲突,结合故障恢复机制确保高可用。源码中的事务管理逻辑展现了优化的分布式事务处理流程,为开发者提供了洞察分布式数据库核心技术的窗口。随着开源社区的发展,更多创新实践将促进数据库技术进步。
28 3
|
1月前
|
XML Java 数据格式
深度解析 Spring 源码:揭秘 BeanFactory 之谜
深度解析 Spring 源码:揭秘 BeanFactory 之谜
25 1
|
1月前
|
SQL 缓存 算法
【源码解析】Pandas PandasObject类详解的学习与实践
【源码解析】Pandas PandasObject类详解的学习与实践

相关产品

  • 云解析DNS
  • 推荐镜像

    更多