企业内部DNS主服务器架构的步骤

简介:

打算建立一个lnsjb.com的网站,首先要先去ISP申请一个公网IP地址,假设申请到的这个地址是172.16.0.1。有了IP地址之后去某个域名服务商那里申请lnsjb.com域名,如果审核通过了,那么服务商会提供管理员一套账号和密码来管理网站,与此同时,域名服务商还会提供两个DNS服务器专门用来面对公网用户解析lnsjb.com的地址。流程图如下:

wKiom1braDLhaZivAAAnoY7Cp2w640.png

如果公司比较壕,自己购置了DNS服务器,这样可以让公司内部人员实用递归查询解析lnsjb.com(外来用户必须使用迭代查询,因为递归查询很占内存),同时也可以公司内部的pop和mail域也可以使用这个私用DNS解析(但是这两个域是不能上公网的),整个规划图如下:

wKioL1bra-3xVLmBAACOHQ4tF-w912.png

这里看到,原本域名服务商指向的仅仅是lnsjb.com,但是现在指向了企业内部的dns服务器。这里示范如何配dns这台企业dns服务器,ns2的配置方法是一模一样的。


#yum install bind -y,安装完成之后,#vim /etc/named.conf,建立一个主配置文件。named.conf的样子如下:

wKioL1bqvqahylPOAABmK45SFEI683.png

先将目录文件夹定位/var/named,保存这个主配置文件并退出之后。然后就对应写里面三个红名的文件。


named.ca很简单,这是设定全球根服务器,#dig -t NS . > /usr/named/named.ca即可。

localhost.zone的写法如下(这里添加的注释在实际操作的时候是不能有的,文件并不认识#):

wKioL1bqvyWTxlVpAABFJEi_ohA797.png

named.local的写法如下(这里添加的注释在实际操作的时候是不能有的,文件并不认识#):

wKiom1bqvrOAHlziAABK3qxXwKY587.png

完事之后,用chown命令把这三个文件加上面的named.conf的属组都要改成named。


然后就可以启动服务,#service named start,回车一下。然后可以正向解析验证,#dig -t A localhost,反向解析验证命令就是#dig -x 127.0.0.1。此时应该能看到localhost与127.0.0.1正反解析都已经对应了。


如第二个手绘图那样,现在已经将域名服务商的NS记录指向了我们公司内部的DNS主服务器和DNS从服务器,此时就可以建立企业内部的名称服务器了。重新#vim /etc/named.conf,刚刚只是把named.conf实现最基本的dns解析功能,也就是仅仅是一台缓存服务器而已,现在是lnsjb.com加入进去,使这个文件具体化,丰富化。于是在我们刚刚建立的named.conf结尾处加上这样的内容:

wKioL1bqx06jE9SJAABfeBuhMtI084.png

然后就是写上面的“lnsjb.com.zone”和“172.16.zone”了,他们的长相跟上面的localhost.zone差不多,毕竟都是zone描述文件。


lnsjb.com.zone下面除了www域还有pop域和mail域,于是它的写法如下:

wKioL1bqywWyCS0RAABX42j6Idk314.png

注意,上面的文件我虽然写了CNAME,只是说明CNAME的用法,实际的文件里,有A就不能有CANME,有CNAME就不能有A。所以说,应该把CNAME那一行删除掉。

172.16.zone的写法如下,做到一一对应:

wKiom1bq0EWQI61jAABOoQNI2Zg492.png

保存退出之后,使用#named-checkzone “域名” 域名文件 来分别检查正反解析文件的语法错误。


然后#service named restart,重启dns服务。然后可以测试,比如#dig -t A www.lnsjb.com,看一下是不是说好的172.16.0.1。或者是#dig -t A www.lnsjb.com @127.0.01,指定是使用本机来解析www.lnsjb.com。


#dig -t MX  lnsjb.com @127.0.0.1,这是测试邮件交换器。

4a36acaf2edda3ccb41d249c06e93901203f9295

结果输出里有一个flags,flags里有一项aa,这个aa代表“权威答案”,即@后面指定的DNS服务器正好是负责你要查询的域名。如果flags没有aa,代表反馈的内容不是权威答案,是从缓存得来的,或者是访问而来的。




 本文转自 苏幕遮618 51CTO博客,原文链接:http://blog.51cto.com/chenx1242/1752351

相关文章
|
1月前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第31天】 随着数字化转型的加速,云原生技术已经成为推动企业IT架构现代化的关键力量。本文深入探讨了云原生架构的核心组件、实施策略以及面临的主要挑战。通过分析容器化、微服务、DevOps和持续集成/持续部署(CI/CD)等关键技术,揭示了如何利用这些技术实现敏捷性、可扩展性和弹性。同时,文章还讨论了企业在采纳云原生实践中可能遇到的安全性、复杂性和文化适应性问题,并提供了解决这些问题的策略和建议。
|
28天前
|
运维 Cloud Native 持续交付
云原生架构的未来演进:打造灵活、高效的企业IT基础
随着数字化转型的不断深入,企业的IT基础设施正经历着从传统架构向云原生架构的根本转变。本文将探讨云原生技术的最新发展趋势,分析其在提高业务敏捷性、降低运维成本以及促进技术创新方面的关键作用。我们将重点讨论如何借助容器化、微服务、DevOps和持续交付等核心技术,构建一个能够适应快速变化市场需求的云原生生态系统。通过实际案例分析,揭示企业在迁移到云原生架构过程中面临的挑战与解决策略,为读者呈现一幅云原生技术赋能企业未来的蓝图。
|
3天前
|
Linux 网络安全 Apache
使用树莓派搭建个人网站,并发布到外网可访问:实用步骤解析
使用树莓派搭建个人网站,并发布到外网可访问:实用步骤解析
|
5天前
|
安全 数据安全/隐私保护 数据中心
服务器中毒怎么办?企业数据安全需重视
互联网企业包括基础层、服务层和终端层,后者涉及网络服务、内容提供、应用服务等。随着业务发展,企业积累了大量数据,数据安全成为关注焦点,尤其是防范服务器中毒导致的数据泄露。中毒迹象包括文件消失、程序异常、启动项可疑、运行缓慢、杀毒软件失效、系统语言改变、蓝屏或黑屏、主页篡改、广告弹窗、程序图标篡改等。中毒原因可能源自源程序漏洞、FTP漏洞、不安全的上网行为和弱后台口令。处理中毒需断网、备份重要文件、运行杀毒软件、在DOS下杀毒、恢复系统并更改网络密码。预防措施包括打补丁、安装杀毒软件、定期扫描、谨慎点击链接和下载、不随意执行附件程序等。
|
8天前
|
人工智能 并行计算 PyTorch
Stable Diffusion 本地部署教程:详细步骤与常见问题解析
【4月更文挑战第12天】本教程详细介绍了如何在本地部署Stable Diffusion模型,包括安装Python 3.8+、CUDA 11.3+、cuDNN、PyTorch和torchvision,克隆仓库,下载预训练模型。配置运行参数后,通过运行`scripts/run_diffusion.py`生成图像。常见问题包括CUDA/CuDNN版本不匹配、显存不足、API密钥问题、模型加载失败和生成质量不佳,可按教程提供的解决办法处理。进阶操作包括使用自定义提示词和批量生成图像。完成这些步骤后,即可开始Stable Diffusion的AI艺术创作。
22 2
|
10天前
|
存储 人工智能 编译器
存算一体新兴力量:解析我国企业在存储创新、技术路径上的多元化探索
存算一体新兴力量:解析我国企业在存储创新、技术路径上的多元化探索
|
13天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【4月更文挑战第10天】 随着数字化转型的不断深入,企业对信息技术基础设施的要求日益提高。云原生架构作为一种新兴的设计理念和技术集合,以其灵活性、可扩展性和容错性,正在成为推动企业技术革新的关键力量。本文将探讨云原生技术的核心组件、实施策略以及面临的主要挑战,并分析如何通过采纳云原生架构来优化业务流程和提升服务效率。
|
1月前
|
Cloud Native 安全 Devops
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第30天】 随着数字化转型的深入,企业正迅速采纳云原生技术以适应不断变化的市场环境。本文探讨了云原生架构的关键组成部分,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps实践,并分析了它们如何促进企业的敏捷性和可扩展性。同时,文章也识别了企业在采用云原生技术时面临的安全、文化和技术挑战,并提出了相应的解决策略,以帮助企业在云时代保持竞争力。
|
1月前
|
XML Java 数据格式
使用java解析XML文件的步骤
使用java解析XML文件的步骤
10 0

相关产品

  • 云解析DNS
  • 推荐镜像

    更多