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

简介:

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

 

 



相关文章
|
7月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
8月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1262 3
|
7月前
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
7月前
|
人工智能 监控 测试技术
告别只会写提示词:构建生产级LLM系统的完整架构图​
本文系统梳理了从提示词到生产级LLM产品的八大核心能力:提示词工程、上下文工程、微调、RAG、智能体开发、部署、优化与可观测性,助你构建可落地、可迭代的AI产品体系。
997 52
|
7月前
|
机器学习/深度学习 人工智能 搜索推荐
从零构建短视频推荐系统:双塔算法架构解析与代码实现
短视频推荐看似“读心”,实则依赖双塔推荐系统:用户塔与物品塔分别将行为与内容编码为向量,通过相似度匹配实现精准推送。本文解析其架构原理、技术实现与工程挑战,揭秘抖音等平台如何用AI抓住你的注意力。
1898 7
从零构建短视频推荐系统:双塔算法架构解析与代码实现
|
7月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
7月前
|
传感器 人工智能 算法
分层架构解耦——如何构建不依赖硬件的具身智能系统
硬件与软件的彻底解耦,并通过模块化、分层的架构进行重构,是突破这一瓶颈、构建通用型具身智能系统的核心基石。这种架构将具身智能系统解耦为三个核心层级:HAL、感知决策层和任务执行层。这一模式使得企业能够利用预置的技能库和低代码工具快速配置新任务,在不更换昂贵硬件的前提下,实现从清洁机器人到物流机器人的快速功能切换。本文将通过对HAL技术原理、VLA大模型和行为树等核心技术的深度剖析,并结合Google RT-X、RobotecAI RAI和NVIDIA Isaac Sim等主流框架的案例,论证这一新范式的可行性与巨大潜力,探讨硬件解耦如何将机器人从一个“工具”升级为“软件定义”的“多面手”,从而
1074 3
|
8月前
|
存储 自然语言处理 前端开发
百亿级知识库解决方案:从零带你构建高并发RAG架构(附实践代码)
本文详解构建高效RAG系统的关键技术,涵盖基础架构、高级查询转换、智能路由、索引优化、噪声控制与端到端评估,助你打造稳定、精准的检索增强生成系统。
1828 2
|
7月前
|
SQL 弹性计算 关系型数据库
如何用读写分离构建高效稳定的数据库架构?
在少写多读业务场景中,主实例读请求压力大,影响性能。通过创建只读实例并使用数据库代理实现读写分离,可有效降低主实例负载,提升系统性能与可用性。本文详解配置步骤,助你构建高效稳定的数据库架构。
|
8月前
|
存储 数据挖掘 调度
像架构拼乐高一样构建采集系统
本教程教你如何构建一个模块化、可扩展的某博热搜采集系统,涵盖代理配置、多线程加速与数据提取,助你高效掌握网络舆情分析技巧。
189 0
像架构拼乐高一样构建采集系统

相关产品

  • 云解析DNS