如何搭建DNS服务器？

搭建DNS服务器步骤如下：

1、安装bind服务 。

2、配置bind的主配置文件，将侦听53端口和dns请求查询设置为所有主机 。

3、配置区域文件，添加自己的域名，定义正向解析和反向解析信息  。

4、进入/var/named/目录，创建正向解析配置文件和反向解析配置文件。

5、修改正向解析配置文件，添加解析记录。

6、修改反向解析配置文件，添加反向解析记录。

7、防火墙允许53端口通过，设置服务器开机自动启动dns服务。

8、dns服务器将本机ip设置为dns地址 。

9、配置完成验证解析记录正常。

1.首先得有自己的一个域名，可以参考freenom免费顶级域名2.使用Cloudxns接替管理 3.拥有自己VPS 1.安装Docker 可以参考 https://www.gitbook.com/book/yeasy/docker_practice/details或者按照以下安装 使用脚本自动安装 curl -sSL https://get.docker.com/ | sh 执行这个命令后，脚本就会自动的将一切准备工作做好，并且把 Docker 安装在系统中。 阿里云的安装脚本 curl -sSL http://acs-public-mirror.oss-cn-hangzhou.aliyuncs.com/docker-engine/internet | sh DaoCloud 的安装脚本 curl -sSL https://get.daocloud.io/docker | sh 2.安装动态域名客户端 这里使用zwh8800的客户端https://github.com/zwh8800/cloudxns-ddns首先，拉取镜像： docker pull zwh8800/cloudxns-ddns 然后，编写一个很简单的配置文件，文件名必须为 cloudxns-ddns.gcfg，把它放到某个文件夹中（如/home/zzz/cloudxns-ddns/config，下面以此为例子) [CloudXNS] APIKey="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" SecureKey="xxxxxxxxxxxxxx" [Domain] Data="home.lengzzz.com" Data="haha.lengzzz.com" 上面 APIKey 是你在 CloudXNS https://www.cloudxns.net/AccountManage/apimanage.html 申请的 key，填进去即可。下面是你想要动态的域名，可以写很多。 然后，启动镜像即可。 docker run --name cloudxns-ddns -d -v /home/zzz/cloudxns-ddns/log:/app/log -v /home/zzz/cloudxns-ddns/config:/app/config zwh8800/cloudxns-ddns 依葫芦画瓢就可以运行了 为防止后台停止运行加入restart参数 docker run --name cloudxns-ddns --restart=always -d -v /home/zzz/cloudxns-ddns/log:/app/log -v /home/zzz/cloudxns-ddns/config:/app/config zwh8800/cloudxns-ddns

引子：

外网DNS是用户访问网站的第一道门，如果外网DNS调度不准确，会出现跨网，跨地域等问题，调度问题是外网DNS关注的首要问题。如何让用户就近接入？有没有好的设置方法可供参考？

调度问题直观的表现是VIEW设置多少个，ACL是否匹配正确。ACL设置一般企业会采购IPIP库的结果，国内基本可以得到正确的结果，海外的IPIP归属地也不会有很大的波动。如果请求能正常到达要访问的权威服务器，看似就万事大吉了。但是在观察业务数据的时候，发现问题并没有那么简单。

这是一个演变的过程，按照改进的过程叙述。

第一步：国内一般的方法是华北，华东，华南，三个地域建ns。海外选择离业务近的点建ns。中国和海外的ns设置不同的地址。自建权威服务器注册到DNS服务商。按照地域顺序往后排序。每个view配置相同的ns。认为DNS解析会按照最近的NS来请求。

问题：

前两台NS会收到很多访问的请求，用户的来源IP和之前给这个NS设定的覆盖范围也不一致，其他的NS请求量相对低。和用户分布的趋势不符合。

如果这样的话，即使分了ACL，也没有达到多个NS覆盖多个的问题。用户域名请求的时间仍旧很高。那么local DNS不是应该像很多NS同时发请求，然后选择一个就近的接入，以后就按照这个NS来请求吗？

当然不会，这样用户还需要在不同的NS上随机挑选，这样更加增加了local DNS的请求时间。

local DNS第一次解析域名的时候，ns的地址是由.com权威提供的，本地递归DNS最终是缓存权威DNS上的ns记录。.com权威提供的方式是通过glue记录。在注册域名的时候，需要额外填写。

glue记录是非常容易忽略的一个问题，应该搭建常规的DNSserver并不是必须的选项，因此常常会忽略，我也是在注意到问题之后，才发现对glue记录并不了解。

加入没有glue记录，local DNS拿到了请求之后，还要在询问NS地址是什么，

查看 www.baidu.com 的glue记录：

请求命令：

dig www.baidu.com

位于返回请求的ADDITIONAL SECTION中。

实验验证一下第一次请求的过程：

先来看一下请求的TTL值

第二次递减：

第三次递减：

变为0:

重新开始请求：

看下对应的抓包过程：

第一次请求的过程：

A.root-servers.net198.41.0.4美国

E.root-servers.net192.203.230.10美国

分别像这几个根存问结果：

首先像 J.root-servers.net192.58.128.30美国 询问，

给服务器回复了 *.gtld-servers.net的地址 .com顶级域

com回复之后，继续往下看：

com回复了baidu的ns

本地递归DNS最终是缓存权威DNS上的NS记录。

如果想实现按照NS调度，不同的View应该配置不同的NS地址，用户请求从com得到请求之后，再去查询NS ，就会按照NS配置的地址到想让他去的NS解析了。不足之处，第一次因为从glue拿地址，所以第一次没有办法实现智能解析

minimal-responses

如果是yes，当产生响应的时候，服务器将只会按照需要将记录添加到authority和additional的数据部分。（例如，delegations，negative responses）。这样会改善服务器的性能。默认值为no。

---