CentOS7 搭建 DNS 域名解析服务器

[TOC]

主要参考知识

centOS7下DNS服务器的安装与配置 - csdn - 主要参考

CentOS73使用BIND配置DNS服务器(一) - csdn - 主要参考

四、bind（named）配置文件 - csdn

Linux系统下搭建DNS服务器——DNS原理总结 - csdn - 从概念层面看 DNS 解析

DNS正反向解析库配置篇(一) - csdn - 正反向解析文件配置

DNS配置详解 BIND实现正向解析和反向解析 - cnblog - 正反向解析文件配置

DNS域名解析服务--Named服务 - 说明详细

搭建DNS服务器 - - 域名解析文件配置说明

Linux中DNS配置 - csdn - 配置文件语法检查用的比较好

linux中dns服务器的搭建 - csdn - nslookup 使用的比较好

其他扩展知识

反向域名解析有什么功能？ -

Centos7/RHEL7中的ifconfig、netstat、route几个常用指令被替代 - csdn

运维小技巧：使用ss命令代替 netstat,和netstat说再见 - csdn

Linux安装nslookup - csdn

如图:

修改前先备份： cp -p /etc/namedconf /etc/namedconfbak // 参数-p表示备份文件与源文件的属性一致。

修改配置： vi /etc/namedconf ， 配置内容如下：

检查一波

添加配置： vi /etc/namedrfc1912zones ， 配置内容如下：

基于 namelocalhost 模板，创建配置文件： cp -p /var/named/namedlocalhost /var/named/namedreadingzt

配置正向域名解析文件 namedreadingzt ： vi /var/named/namedreadingzt ，配置内容如下：

说明：

授权 named 用户 chown :named /var/named/namedreadingzt

检查区域文件是否正确 named-checkzone "readingzt" "/var/named/namedreadingzt" ，如图：

基于 namelocalhost 模板，创建配置文件： cp -p /var/named/namedlocalhost /var/named/named1921680

配置反向域名解析文件 named1921680 ： vi /var/named/named1921680

授权 named 用户 chown :named /var/named/named1921680

检查区域文件是否正确 named-checkzone "0168192in-addrarpa" "/var/named/named1921680" ，如图：

重启 named 服务，让配置生效 systemctl restart named

配置 ifcfg-xxxx vi /etc/sysconfig/network-scripts/ifcfg-enp0s3 ， 具体内容如下：

如图：

重启网络服务，让配置生效 systemctl restart networkservice

bind-utils 软件包本身提供了测试工具 nslookup

nslookup testreadingzt , 或者，如下图：

nslookup 1921680232 , 或者，如下图：

产生原因

服务器（不一定是Web服务器）是作为网关或代理，以满足客户的要求（如Web浏览器或我们的CheckUpDown机器人）来访问所请求的URL 。此服务器收到无效响应从上游服务器访问履行它的要求。

含义

这通常并不意味着上游服务器已关闭（无响应网关/代理） ，而是上游服务器和网关/代理不同意的协议交换数据。鉴于互联网协议是相当清楚的，它往往意味着一个或两个机器已不正确或不完全编程。

502错误的HTTP周期

任何客户端（如Web浏览器或我们的CheckUpDown机器人）经过下列循环时，与您的Web服务器沟通：

获取您的网站IP地址的IP名称（您的网站URL的领导’ http:// ‘ ） 。这查找（转换的知识产权名称， IP地址）所提供的域名服务器（ DNSs ） 。

打开一个IP套接字连接到该IP地址。

写一个HTTP数据流通过该插座。

从您的响应的Web服务器收到一个HTTP数据流。此数据流包含状态码的值是由HTTP协议。解析此数据流的状态码和其他有用信息。

这个错误发生在最后一步时，上面的客户端收到一个HTTP状态码，它确认为502 ‘ 。

固定502错误

一般这个问题是由于不良的IP之间的沟通后端计算机，包括您可能尝试访问的在Web服务器上的网站。在分析这个问题，您应该清除浏览器缓存完全。

如果您上网时在您尝试访问的所有网站上都看这个问题，有两种可能

1 ）你的ISP了重大设备故障/过载或

2 ）有问题的内部互联网连接如您的防火墙无法正常运作。

在第一种情况下，只有您的ISP可以帮助您。在第二种情况下，你需要解决什么，那就是阻止你进入互联网。

如果您只有在部分尝试访问的网站中出现此问题，那就很可能是一个问题，即这些网站之一，其设备故障或超载。联系网站的管理员。

固定502错误- CheckUpDown

在网络上使用代理和缓存增加。我们CheckUpDown机器将总是试图连接到的真正的计算机主机，实际上就是您访问的网站，但是我们并不能完全控制，我们的HTTP请求实际上结束了。如果只有一个环节的计算机处理我们的HTTP请求被打破，然后一个错误，如502可以很容易地发生。

　　B/S结构跟C/S结构的区别所谓B/S结构，就是只安装维护一个服务器（Server），而客户端采用浏览器（Browse）运行软件，即浏览器/服务器结构。

　　B/S结构的优点是维护方便，能够降低总体拥有成本。客户端运行软件，就像我们平时上网浏览网页一样，有个浏览器（通常是IE50）就行了，不用安

　　装其它软件。而且通过电话线也可以运行软件。B/S结构的软件所有的维护、升级工作都只在服务器上进行，而客户端就能获得最新版本的软件。

　　相对于C/S结构，尽管C/S结构相对于更早的文件服务器来说，有了很大的进步，但与B/S相比，缺点和不足是很明显的。

　　首先，B/S比C/S的维护工作量大大减少了。C/S结构的每一个客户端都必须安装和配置软件。假如一个企业共有50个客户站点使用一套C/S结构的

　　软件，则当这套软件进行了哪怕很微小的改动后（比如增加某个功能），系统维护员都必须进行这样的维护；将服务器更新到最新版本；将客户端原有的软件卸载，

　　再安装新的版本，然后进行设置，最为可怕的是客户端的维护工作必须不折不扣的进行50次。若其中有部分客户端是在另外一个地方，则系统维护员还必须跑到该

　　地方再进行卸载、安装、设置的工作。 若某个客户端，忘记进行这样的维护，则该客户端将会碰到版本不一致的问题而无法工作。

　　而B/S结构，客户端不必安装及维护。如果我们将前面企业的C/S结构的软件换成B/S结构的，我们看看软件升级后，系统维护员如何维护：

　　系统维护员只要将服务器的软件升级到最新版本就行了。其他客户端，只要重新登录系统，使用的就已经是最新版本的软件了。

　　其次，B/S相对C/S能够降低总体拥有成本， C/S软件一般是采用两层结构的。而b/s采用的是三层结构。

　　两层结构中，客户端接受用户的请求，客户端向数据库服务提出请求，数据库服务将数据提交给客户端，客户端将数据进行计算（可能涉及到运算、汇总、统计等等）并将结果呈现给用户。

　　在三层结构中，客户端接受用户的请求，客户端向应用服务提出请求，应用服务从数据库服务中获得数据，应用服务将数据进行计算并将结果提交给客户端，客户端将结果呈现给用户。

　　这两种结构的不同点是，两层结构中客户端参与运算，而三层结构中客户端并不参与运算，只是简单的接收用户的请求，显示最后的结果。由于三层结构中的客户端并不需要参与计算，所以对客户端的计处算机电脑配置要求是比较低的。

　　另外，由于从应用服务到客户端只传递最终的结果，数据量较少，使用电话线也能够信任。而采用C/S两层结构，使用电话线作为传输线路可能因为速度太慢而不能够接受。

　　采用三层结构的b/s的配置可以是提高服务器的配置，降低客户端的配置。这样增加的只是一台服务器（应用服务和数据库服务可以放在同一台计算机电脑中）的价格，而降低的却是几十台客户端机器的价格。起到了降低总体拥有成本的作用

　　C/S、B/S及三层结构（下） 谢攀 (转帖)

　　上一期，作者在本文上半部分介绍了对C/S结构、两层模式、三层模式的看法，以及实现三层模式的技术手段，接下来作者将探讨B/S结构

　　和三层模式的实现方法。

　　三层结构编程要点

　　对此笔者不想讲太多理论，只给大家一句经典名言，这句话每个程序员都应该牢牢记住：All business logic in the Middle Tier（所

　　有的商业逻辑处在中间层上）。如果不这样，你开发的三层结构程序就不专业，或者只是C/S模式的翻版产品。这句话虽然很简单，要达

　　到这一境界却需要大量的经验积累。

　　另一个要领是: 一定要尽量减少应用服务器与前台程序的数据传递量以及Round Trip。因为如果你的三层结构存在频繁的Round Trip，那

　　么你开发的应用服务器效率一定非常低下，当同时进入10个连接时，你就会发现应用服务器接近瘫痪。

　　在开发三层结构的系统时，应该养成一种好习惯，就是在系统分析或者设计报告中，较为详细地描述如何解决商业逻辑、如何有效降低数

　　据传递量，以及只使用必要的Round Trip。只有这样，别人才能与你一起探讨你的解决方案是否合理，是否有更有效的实现方式。同时，

　　经过不断归纳，提高自己的系统分析能力。

　　在开发大量用户连接的应用服务器时，多线程技术是必要的，否则当应用服务器在处理一个用户的请求时，另一用户只能等待，如果这种

　　等待的时间太长了，用户就会对软件失去信心。还有一个是分布式的概念，你可以根据商业逻辑来切分，开发并发布多个应用服务器解决

　　不同的商业逻辑；或者你可以将运行应用服务器的多个进程分布在不同的服务器中，并根据访问流程自动引导用户到合理的应用服务器

　　中。

　　正是因为三层结构比C/S复杂，所以你要成为三层结构的高手，一定要经过一段较长的时间和大量项目的锻练。但三层结构体现了一个开

　　发人员与系统人员的专业素质，因为它涉及太多东西: 技术工具的选型、模块化和组件化思想、前后台功能的分割等等。从真正意义上来

　　讲，只有三层结构的项目才能完整反映软件项目的每个过程。

　　B/S模式与发展

　　主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸

　　收了两者的优点。

　　我们知道单纯的B/S方式，虽然很令人兴奋，并且最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现

　　你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有

　　希望的结果、报表制作能力不足等。

　　为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的。打个比方，Stateless就是这样一种情形：你与你的用户中

　　间有一道墙，你并不知道墙另一边的用户长得什么样子，甚至是男是女你都不知道，然后你通过墙上的一个小窗递给他一件礼物，至于礼

　　物最终的流向，你也一无所知，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。

　　笔者以为现在发展起来的ASP、JSP、Java技术，都是在弥补HTTP协议存在的无状态缺陷，但即使有了这些工具，仍会觉得网页编程无法随

　　心所欲，因为这些技术再先进，也无法解决HTTP协议基于Stateless的事实。

　　也许有人会问，这些动态网页开发技术是如何在一定程度上避免了Stateless的弊端的？以基于IIS的ASP技术来说，它使用Session变量来

　　实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。

　　这里还要提一下Socket。Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是

　　有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！

　　目前基于Web的多层结构采用的底层技术主要有SOAP＋State类协议或者HTTP＋State类协议。这里有一个Delphi程序员的好消息，从

　　Delphi 6开始引入WebSnap包（一种Web Provider产品），它的设计者被Borland公司称为Borland历史上最伟大的工程师之一。它同时支

　　持HTTP与SOAP协议，也采用了一种类似Session变量的模式来实现有状态(State)。它可以说是目前市面上最强大的基于平台的

　　Browse/Server开发工具之一，其不足是它还不能称为完全的RAD工具，而且门槛较高。为什么不是ASP或者ASPNET呢？笔者认为ASP不是

　　基于平台的，它是基于脚本语言的，它的运行效率不高，而且它的调试困难。在Delphi 7中还引入了IntraWeb控件包，笔者以为它是一种

　　真正意义上的网页RAD开发工具，与WebSnap配合更会如虎添翼。

　　Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N Tier开发的最高境界，笔者以为是大型商业软件架构的首

　　选。笔者在前面很少提到消息机制，主要是怕大家混淆了概念，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机

　　制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无

　　论是效率还是实现的复杂性来讲都是要考虑的问题。

　　软件开发人员的选择

　　笔者愿意把软件设计看成音乐艺术，它有许多流派，也有主流，但并不意味着别的思想被彻底抛弃。比如单层结构或C/S方式，许多人仍

　　然在用，而且很擅长。笔者不鼓励读者抛弃这些传统的东西，笔者的意思是要扩大眼界，开放思想。而多层反映的是一种集成的思想，以

　　安全、高效、图形方式整合系统，以组件思想逐步构架整个公司的商业逻辑，并降低最终用户使用成本。其最核心的思想是集中，所有中

　　间层是集中的，可以在不同的服务器上运行不同的商业逻辑组件（比如NET），但这个逻辑组件一定是提供给所有前端程序使用的。现在

　　许多企业都在走系统集中的道路，集中可以带来无限的好处，但没有软件平台的支撑，集中是非常肤浅的。我们追求的不单纯是机器的集

　　中，机器的集中会同时带来网络带宽的压力，只有应用集中了，才能最终达到合理配置资源的目的，这也是为什么我们要用多层体系、要

　　用分布式思想来构建企业应用的真正原因。

　　笔者以为，在软件开发的今天，作为一名专业人员，如果总在单层或C/S构架下，永远形成不了系统思想，只有多层体系才能真正体会软

　　件生命周期的理念，从需求分析形成商业逻辑到系统设计、数据库结构设计、组件化程序编写、测试、推广，一个好的N Tier系统一定要

　　踏实地做好各个阶段的工作。这不像程序语言的变化或者开发环境的简单变换，因为它是一种开发思想与开发模式的完全变革，所以它也

　　一定是一个过程，不可能要求自己在一两个月内就能真正体会并开始驾驭N Tier模式，但商业模式变了，开发思想也要变，你必须也只能

　　让自己去适应新的思想，才能成为一名更加专业的开发人员。一旦你进入了N Tier的殿堂，并熟练掌握了这种开发模式，就会发现你开始

　　逐渐形成了软件开发的系统思想，并且在这个领域上越走越在前面，开发也会越来越有激情。

　　编后语：可怜的程序员

　　“真累！”时常听到软件开发人员这么说。软件开发是一个高强度的工作，这是共识，无论对于体力还是脑力都是一个考验，因此不少程

　　序员常常自嘲为“吃青春饭”的人。本人此前也做过几年软件开发，我也深谙其中的辛苦。我知道，对于软件开发人员而言，赶工期、赶

　　进度、封闭开发、长时间的加班加点等很多人已经习以为常，不过和心理上承受的压力相比, 这点痛实在算不得什么，软件技术的更新日

　　新月异，要在这一行立足，就必须时刻追踪技术发展，不然掉队事小，掉饭碗事大。C/S模式刚刚掌握，又流行起B/S架构，对高深莫测的

　　J2EE、CORBA还是一知半解，NET又接踵而至。掌握VB太基础，掌握Delphi也才刚刚跨入程序员大门。要想待遇高，那得掌握VC或者BC，

　　若论工作机会多还数Java迷。最近又流行Web Services，也一定要弄明白，但要真正理解Web服务，掌握XML是前提。头儿有一天谈到

　　UML，也要补上……“可怜的程序员，何时是尽头！”

　　作为程序员的你是否在工作中陷入过这个误区，也为此苦恼过？或许你已经走出了这个阴影，或许你对此能轻松对付，你是否愿意让大家

　　分享你的经验和观点，无论如何，如果你对这个话题感兴趣，欢迎你和大家一起来讨论。

　　转自

SQL Server 2012在升级之前我们需要做一些准备。首先必须验证软件和硬件需求;准备足够的资源，用于测试和实现新系统。但是，您可能忽略了一些重要方面--处理SQL Server数据的客户端应用程序。

　　这正是SQL Server 2012的Upgrade Assistant(升级助手)的作用。Upgrade Assistant提供了一种自动处理机制，用于测试从SQL Server 2005、2008或2008R2移植到SQL Server 2012的应用程序兼容性。使用Upgrade Assistant,可以检测升级过程中可能发生的功能和性能问题。Upgrade Assistant可以验证应用程序的SQL Server 2012 Transact-SQL查询，可用于检测和纠正应用程序源代码的兼容性问题。

　　Upgrade Assistant是由微软和Scalability Experts Inc合作开发。Upgrade Assistant使用工作负载测试，对旧版本的SQL Server与SQL Server 2012的应用程序性能进行比较。如果按照产品文档所描述的步骤(同时考虑用户界面的结构)，就可以确定可能影响应用程序的问题，如弃用的特性或Transact-SQL语法变化。

　　Upgrade Assistant测试过程

　　Upgrade Assistant可以指引您验证应用程序在SQL Server 2012的兼容性。在开始之前，要先创建用于运行示例工作负载的测试环境。理论上，可以在生产数据库上执行测试，但是这种方法存在一定的风险。因为这不仅会对运行的应用程序、后台数据库和网络本身的性能产生负面影响，而且如果出现命名冲突或事务中断，就有破坏应用程序和数据完整性的风险。

　　至少，您的测试环境应该包含一个数据库服务器，然后在其上安装当前版本的SQL Server(2005、2008或2008 R2)及Upgrade Assistant服务器还必须支持SQL Server 2012升级。此外，您必须从所测试的应用程序连接数据库服务器。应用程序应该是一个测试系统，以便执行自动化过程，完全补全应用程序的特性。如果使用生产应用程序来执行测试，那么您很可能只能检查到较小比例的功能。

　　一旦建立了测试环境，您就可以使用SQL Server Upgrade Assistant,执行以下步骤：

　　备份相关系统和用户数据库，获取示例工作负载。Upgrade Assistant会将工作负载捕捉为跟踪文件，其中记录了有代表性的应用程序数据库查询记录。

　　基于第一步创建的备份和跟踪文件，建立基线环境。在这个过程中，运行SQL Server Upgrade Advisor,确定数据库跟踪文件和备份文件中的升级问题。这时，您应该解决所有出现的问题，才能继续Upgrade Assistant后面的步骤。

你好，很高兴回答你的问题。

如果我们的网站想要在互联网中被访问，我们需要了解建站的几要素。

1公网IP

我们需要申请公网IP，互联网的用户通过此IP才能访问你的站点内容，如：120221201117。但是公网IP一般都被运营商、云厂商或其他企业所购买，因此我们需要单独购买公网IP。

2域名

通过IP的形式访问站点不太友好，而且较难记忆。因此需要通过一个方便记忆的域名来解析到公网IP，此时我们通过此域名就可以直接访问你的站点内容，如：。域名我们可以在万网、dnspod等提供域名解析服务的厂商那申请、购买等。

3租用托管服务器

服务器是我们运行站点服务的地方，为了保证我们的站点服务724不间断运行，需要服务器所在环境电源稳定、合适的温度、能够上网等前提条件。最重要的是服务器要稳定，性能要符合网站业务的发展，而买一台服务器价格昂贵。租用IDC机房的服务器需要根据流量、服务等收取不等费用。

4网站备案

无论我们的网站托管在哪，都需要进行备案，否则有可能被封禁。

以上是建站的几个重要方面，要根据我们的网站定位，选择合适的建站方式：

1记录自己的日常

这类需求如果我们不考虑站点编辑自由度，可以使用51cto、csdn、简书、掘金等免费平台。这样可以将以上建站因素排除掉，而且不用维护。

2对外提供服务或站点自由编辑

这类需求可以自控，因此需要自建，为节约成本，建议租用云服务器并按需站扩展，购买公网IP、域名解析服务等。

总结

建站绝不是简单租用一台服务器就可以的，而是一些列步骤共同完成，而且还需要根据站点需要合适的服务器配置，投入一部分精力用于维护，这样才能让我们的站点稳定提供服务。

最后建站不易，希望我的回答对你有帮助。

我是木讷大叔爱运维，欢迎关注，与你分享运维路上的点点滴滴。

阿里云服务器偶尔连接不上的问题出现在我做了一些TCP优化之后，出现了公司内网偶尔会出现连接不上服务器的问题，但是切换其他的网络就可以正常连接。

1，登陆服务器查看资源使用top，vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层。

2，本地使用ping服务器外网ip正常返回，无丢包，延迟也正常。

3，登录服务器查看tcp相关数据。

发现在卡顿时有大量tcp syn包被丢弃，数值一直在增长。

在查阅资料并结合实际情况后，发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。

后想起，之前同事为改善time_wait连接数过多问题曾改过该内核参数。

解决办法是，关闭tcp_tw_recycle：

再观察，发现服务已正常，偶尔连接不上的现象消失。

我们先来man一下这两个参数(man tcp)：

cp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）

关于tcp_timestamps详情请见： https://toolsietforg/pdf/rfc7323pdf

开启tcp_tw_recycle会启用tcp time_wait的快速回收，这个参数不建议在NAT环境中启用，它会引起相关问题。

tcp_tw_recycle是依赖tcp_timestamps参数的，在一般网络环境中，可能不会有问题，但是在NAT环境中，问题就来了。比如我遇到的这个情况，办公室的外网地址只有一个，所有人访问后台都会通过路由器做SNAT将内网地址映射为公网IP，由于服务端和客户端都启用了tcp_timestamps，因此TCP头部中增加时间戳信息，而在服务器看来，同一客户端的时间戳必然是线性增长的，但是，由于我的客户端网络环境是NAT，因此每台主机的时间戳都是有差异的，在启用tcp_tw_recycle后，一旦有客户端断开连接，服务器可能就会丢弃那些时间戳较小的客户端的SYN包，这也就导致了网站访问极不稳定。

主机A SIP:P1 (时间戳T0) ---> Server 主机A断开后

主机B SIP:P1 (时间戳T2) T2 < T0 ---> Server 丢弃

经过此次故障，告诫我们在处理线上问题时，不能盲目修改参数，一定要经过测试，确认无误后，再应用于生产环境。同时，也要加深对相关内核参数的认识和理解。

本文解决灵感来自于 https://blog51ctocom/hld1992/2285410

https://blogcsdnnet/chengm8/article/details/51668992