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

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

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

 

 



相关文章
|
11天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
51 6
|
11天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
27 1
|
11天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
12天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
16天前
|
机器学习/深度学习 人工智能 自然语言处理
医疗行业的语音识别技术解析:AI多模态能力平台的应用与架构
AI多模态能力平台通过语音识别技术,实现实时转录医患对话,自动生成结构化数据,提高医疗效率。平台具备强大的环境降噪、语音分离及自然语言处理能力,支持与医院系统无缝集成,广泛应用于门诊记录、多学科会诊和急诊场景,显著提升工作效率和数据准确性。
|
19天前
|
消息中间件 编解码 开发者
深入解析 Flutter兼容鸿蒙next全体生态的横竖屏适配与多屏协作兼容架构
本文深入探讨了 Flutter 在屏幕适配、横竖屏切换及多屏协作方面的兼容架构。介绍了 Flutter 的响应式布局、逻辑像素、方向感知、LayoutBuilder 等工具,以及如何通过 StreamBuilder 和 Provider 实现多屏数据同步。结合实际应用场景,如移动办公和教育应用,展示了 Flutter 的强大功能和灵活性。
88 6
|
19天前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
6天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
19 2
|
1月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
67 0
|
1月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
54 0

相关产品

  • 云解析DNS
  • 推荐镜像

    更多