域名解析服务器地址_内网私有域名解析

前言

域名及域名解析

大家可能知道，在网络发明之后的一段时间内，大家都采用IP+端口的方式来共同共享资源。 后来随着资源的增多，这种做法就变得非常不友好了。 例如，现在有254个IP，每个IP上有20个Web应用程序。 然后我们还要记住5080个IP+端口的组合，这简直太折磨人了。 于是在1983年，Paul 发明了域名解析服务和域名服务（DNS，Name）。 从此，大家开始使用域名来访问各种应用服务。 显然，与原来的IP+Port方式相比，域名的含义更加具体，也更容易记忆。

域名解析实际上对应的是一个IP和一串有意义的字符。 这是一种一对多的关系，即一个IP可能对应多个域名。 域名的管理单位称为域名注册机构，拥有顶级域名的管理权。 例如.net、.com、.org等都是顶级域名，域名注册机构对顶级域名拥有完全的权利。 就像上次提到的SSL根证书一样，光有域名注册机构是不够的。 他们不能直接向世界上所有公司或个人出售域名。 相反，域名注册商需要承担这部分工作。 比如我们熟悉的国内的万网、（现腾讯云域名）等，国外的Gandi等都是域名注册商。 顶级域名根据用途不同可以分为国家域名后缀和通用域名后缀。 国家专用域名后缀是指定供各个国家或地区使用的域名后缀，其余为通用域名后缀。 我们可以在域名注册商处购买域名后缀（也称为顶级域名）的子域名（也称为二级域名）。 例如，我们可以购买域名后缀为.com的域名（当然已经被注册了，我们只能购买尚未注册的域名）。 由于一些品牌效应，大多数域名后缀都会保留一些子域名，我们一般称之为优质域名。 一般来说，优质域名会比普通域名更贵。 当我们购买域名时，域名注册商会免费提供域名解析服务。 当然，我们也可以要求使用其他厂商提供的免费或付费域名解析服务，甚至构建自己的域名解析服务。

提醒

在中国，在公共互联网上构建域名解析服务需要一定的资质，否则您将面临警告和屏蔽的风险。

为了简单起见，我们一般将域名解析服务称为DNS服务。 在操作系统中，53端口被视为DNS服务（TCP/UDP服务）的标准端口，853端口被视为DNS over TLS（TCP服务）的标准端口。 另外，DNS over HTTPS（TCP服务）和DNS over Quic（新协议，UDP服务）的标准端口都是443。因此，现有的公开的DNS服务都使用标准端口，比如国内著名的114 DNS、阿里云DNS、腾讯云DNS、百度云DNS。 如果您想了解更多有关开放和可用的 DNS 服务的信息，您可以查看此处。

尖端

DNS按照功能不同可以分为权威DNS和递归DNS。 权威DNS负责管理一个或多个子域名，注册商提供的域名解析服务就属于这种类型。 递归DNS负责接收客户端的请求，并将查询到的域名对应记录返回给客户端，这意味着它本身不管理任何子域名，而只是中继别人告诉它的结果。

当我们使用DNS时，它（这里是递归DNS）会根据域名系统的结构逐级查询，如下图所示。 例如，现在我们要访问：

客户端（我们）向递归DNS请求解析； 递归 DNS 将首先询问其上游 DNS。 如果没有上游DNS，则只能询问DNS根服务器； DNS根服务器不知道具体的解析记录。 但它会告诉递归DNS顶级域名.com的DNS服务器； 然后递归DNS询问.com的DNS服务器； 这样一来，.com DNS服务器并不知道具体的解析记录，但它会告诉递归DNS二级域名的DNS服务器； 这样递归DNS就会向该域名的权威DNS询问； 那么，权威DNS响应对应的A记录（或AAAA记录）是什么呢？ 最后，递归DNS将解析结果告诉客户端（我们）。

那么问题来了，一个DNS可以同时是权威DNS和递归DNS吗？ 其实是不可能的，但是效果是可以达到的。 如果我们把权威DNS隐藏在递归DNS后面，那么对于顶级域名DNS来说，你指定的递归DNS就是它理解的权威DNS。 这里的隐藏是指当有对递归DNS的权威解析记录的请求时，递归DNS会按照规则将请求转发给其背后真正的权威DNS。 等待权威DNS返回解析记录后，递归DNS将结果返回给请求者（其他递归DNS或客户端）。

私有域名解析的必要性

以上均与公共域名有关。 为什么要考虑私有域名解析？ 首先，公有域名和私有域名本质上不可能有区别。 它们都是从域名注册商处购买的域名。 它们也可以不同，即私有域名是未购买的或非 ICANN 支持的域名（例如 .lisz 后缀）。 这样，我们就不再受域名是否在内网注册和申请的限制。

暗示

当然，我们应该避免使用带有ICANN支持的可注册域名后缀的域名，因为将来可能会有人购买这个域名。

其次，分析记录的内外分离要求。 随着基础服务架构和应用架构的不断发展，越来越多的云计算企业需要使用域名解析来连接内部服务。 如果我们直接使用权威的DNS来解析这些记录，意味着每个人都可以通过查询知道这些解析记录，有些人甚至可以粗略地猜测出服务架构，这不是很安全。 出于安全考虑，将同一域名的内部和外部解析记录分开可以在一定程度上提高安全性。

正如参考资料《内联网域名系统安全与保密风险研究》中提到的，“随着内联网规模的不断扩大，特别是国家电子政务内联网的建立和扩大，需要建设电子政务内网的国家级安全风险对内网域名系统的需求越来越迫切，内网域名系统将成为内网​​的核心基础设施，其安全问题也将受到越来越多的关注。 “私有域名解析，即内网域名系统的安全性起着决定性的作用。”

使用

笔者在实际使用AWS、Azure、阿里云、腾讯云等的过程中，还发现了私有域名解析的应用。 例如，云创建的每个VPS都会有一个内部FQDN（带后缀的多级域名）。 当您在VPS上使用dig命令查询该FQDN对应的A记录时，将返回VPS的内部IP。 在自己的设备上使用dig命令查询时，返回为空。 再比如，云计算厂商的VPS默认配置了自己的镜像源。 例如，腾讯云VPS默认的镜像源域名为，在公网上找不到该域名的解析记录。 可以看到，云计算厂商在架构中也在使用私有域名解析。

当然，云计算厂商也为用户提供基于VPC（私有网络）的私有域名解析服务，即私有域名解析服务只能被同一VPC内的VPS使用。 而且我们知道VPC属于用户个人，这意味着不同用户之间的私有域名解析服务完全不会互相干扰。

参考资料1中列出了私有域名解析在实际云服务中的四大应用场景：

尖端

域名解析分为正向解析和反向解析。 我们一般看到的“域名→IP”的域名解析是正向解析，而反向解析则是“IP→域名”。 一般来说，反向解析多用于邮件服务器的可信认证。 将IP与邮件服务器域名的正向和反向解析绑定，可以增强邮件服务器的可信度，降低被接收服务器判断为垃圾邮件IP的概率。

实践计划一

内网私有域名解析实际上是在内网构建权威DNS和递归DNS：权威DNS用于管理私有域名，递归DNS用于解析权威DNS记录和普通公网解析记录。 当然，在企业网络或机房集群网络中，一般会构建权威DNS集群和递归DNS集群，以提高可靠性和可用性。 权威DNS集群通常采用主从架构。 主节点作为域名解析操作的主要接收者，从节点会实时同步主节点记录。 当主节点检测到故障时，从节点自动升级为主节点。 并不是所有的集群都是这样，但是这样可以更好的避免因为主节点故障而无法更改域名解析。 由于这与使用软件设置DNS服务有关，所以这里不再过多讨论。

与权威DNS集群不同，内网递归DNS集群实际上一般都会暴露两个节点。 这和在公网上提供公网递归DNS服务是一样的。 例如114 DNS会告诉你设置两个DNS IP地址，分别是114.114.114.114和114.114.115.115。 为什么一定要这样？ 主要原因是通过冗余来提高可靠性和可用性。 我们可能简单地认为114 DNS只有这两个IP，但实际上它们背后有很多递归DNS服务器。 这两台服务器的作用并不是直接处理解析请求，而是为需要域名解析的客户端提供更快、更高效的使用递归DNS的方式。 类似于复杂的Web系统，首先在交换机上使用网关进行优化，然后在服务器上使用LVS进行负载均衡，然后使用多个服务后台分别处理相同的业务，最后将信息返回给用户。 这两个递归DNS节点还起到负载均衡的作用。

当然，这两个IP不是普通​​的IP，而是利用了技术的IP。 也就是说，互联网上会有多个服务器使用这两个IP，当我们向这两个IP发起请求时，BGP会根据客户端的地理位置和网络情况，定位到远离客户端的IP。 在两个最近的服务器上。 更客观的体验是，当我们从全国不同地区ping这两个IP时，我们发现延迟似乎相似且较短。 但无论我们的骨干网络建设得有多好，由于地理位置和跨网络（电信、联通、移动、教育网）带来的延迟是不可避免的。 对于短延迟的唯一可能的解释是，响应请求的机器实际上不是同一位置的两台相同的机器，而是不同位置的两台不同的机器。

选项二

上述方案考虑的问题较多，更适合大规模集群或者内网的实践。 然而，在小集群中它可能有点太大并且不必要。 事实上，小集群或者小团队的内网可以采用“二合一”的解决方案，即由一台服务器同时提供递归DNS和权威DNS。 由于小集群内网私有域名解析和公有域名解析不需要接近零的停机率，因此可以完全简化。 目前最流行的免费解决方案可能是 Home。

Home 是一款全网络广告拦截和反跟踪软件。 安装后，它将保护您的所有家庭设备，并且您无需安装任何客户端软件。 随着物联网和互联设备的兴起，控制整个网络环境变得越来越重要。

- - - 主页

Home之所以如此受欢迎，主要是因为其丰富的功能和简单的可视化操作，对于管理员来说非常人性化。 而且Home的部署也非常简单，支持多平台架构和多种一键部署方式。 例如，Home也可以使用容器一键部署在ARM芯片上。 虽然Home自带了简单的解析记录重写，可以满足大部分常见的内网私有域名的解析需求，但可能无法做一些更高级的解析记录，比如TXT记录。 虽然TXT记录不起IP和域名相互映射的作用，但TXT记录可以填写比较长的内容，非常适合验证域名的管理权限。 HTTPS证书的申请通常使用新的TXT记录。 验证方式，Page的自定义域名绑定也是如此。 因此，为了提供更完善的域名解析服务，建议添加权威DNS，可以是+Admin（交互界面）或者Bind9等。

考虑到友好的交互界面更容易使用，这里仅介绍Home+方案。 需要提前准备的环境包括：

家

由于Home官方已经提供了多平台架构镜像，我们可以直接使用。 -.yml文件如下：

代码语言：

复制

version: "3"
services:
  adgurad:
    image: adguard/adguardhome
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 80:80/tcp
      - 443:443/tcp
      - 3000:3000/tcp
    volumes:
      - ./work:/opt/adguardhome/work
      - ./conf:/opt/adguardhome/conf

使用 -up -d 命令启动 Home 实例。

初始化

使用浏览器访问：3000进行实例初始化设置。 根据页面提示设置用户名和密码，如下图。

初始化成功后，页面会自动跳转到登录界面（80端口）。

暗示

由于在实际环境中，我们不一定要在本地启动实例，所以可能需要使用服务器的IP来访问。 另外，如果Nginx或者其他服务本来就占用80端口，我们在配置端口映射时可能会将其设置为其他端口，那么自动跳转到的页面就不是首页了。 我们需要使用IP+映射80端口来定位主页。

私有域名转发

由于接下来我们要用它来管理权威域名解析，所以需要设置私有域名规则，即当Home收到内网自定义权威域名的请求时，会转发该请求。 这在Home中设置起来也相对容易。 如下图所示，添加一行规则，将所有匹配的二级域名请求转发到。

虽然和-Admin官方都提供了镜像，但是一起使用还是会出现一些莫名其妙的问题。 为了简单起见，作者参考官方的镜像构建了 /pdns 和 /-admin 两个镜像，一起使用更加方便好用。 如果你想了解更多，可以查看《形象构建》。

代码语言：

复制

version: "3"
services:
  pdns:
    image: zhonger/pdns:latest
    restart: always
    ports:
      - "753:53/tcp"
      - "753:53/udp"
      # - "8081:8081"
    environment:
      - PDNS_launch=gsqlite3
      - PDNS_gsqlite3_database=/var/lib/powerdns/pdns.sqlite3
      - PDNS_webserver_address=0.0.0.0
      - PDNS_webserver_allow_from=127.0.0.1,10.0.0.0/8,172.0.0.0/8,192.168.0.0/16
      - PDNS_api=yes
      - PDNS_api_key={Random Long String}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./powerdns:/var/lib/powerdns
  db:
    image: mysql:latest
    environment:
      - MYSQL_ALLOW_EMPTY_PASSWORD=yes
      - MYSQL_DATABASE=powerdnsadmin
      - MYSQL_USER=pdns 
      - MYSQL_PASSWORD=mypdns
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./pda-mysql:/var/lib/mysql
  app:
    image: zhonger/powerdns-admin:latest
    restart: always
    depends_on:
      - db
      - pdns
    ports:
      - "8080:80"
    logging:
      driver: json-file
      options:
        max-size: 50m
    volumes:
      - /etc/localtime:/etc/localtime:ro
    environment:
      - SQLALCHEMY_DATABASE_URI=mysql://pdns:mypdns@db/powerdnsadmin
      - GUNICORN_TIMEOUT=60
      - GUNICORN_WORKERS=2
      - GUNICORN_LOGLEVEL=DEBUG
      - OFFLINE_MODE=False # True for offline, False for external resources 

使用 -up -d 命令启动和 -Admin 实例。

初始化用户

-Admin本身不会自动初始化管理员用户，而是会将第一个注册的用户识别为管理员用户。 使用浏览器访问管理员登录页面：8080，点击链接跳转至注册页面，如下图所示。

如下图所示，填写您的姓名、邮箱、用户名和密码，点击按钮完成注册。 这里，-Admin默认使用邮箱头像作为用户头像。

初始配置

注册并登录后，将跳转至PDNS配置页面。 由于PDNS和-Admin实例位于同一网络，因此可以直接使用pdns替换PDNS实例的IP地址。 PDNS API KEY 是启动时设置的一长串字符 ()。 PDNS 最好与实际使用的 PDNS 一致，但不一致也没关系。 /pdns：当前版本实际上是4.6版本。 默认值 4.1.1 也是可以接受的。 然后单击按钮保存配置。

成功保存配置后，如果填写的信息正确，点击侧边导航中的PDNS，即可看到PDNS的各项配置信息。 如果填写错误，将没有任何信息。

添加域名

接下来，您可以点击侧边导航栏的新建，添加私有域名home.lisz。 如下图所示，我们需要填写的是域名，需要选择的是域名模板，一般就够了。 然后单击提交按钮。

添加新的分析记录

新域名添加成功后，我们可以在里面的域名列表中看到home.lisz。 点击进入域名解析。

这里我们以CNAME和A记录为例尝试添加新的解析记录。 如下图所示，点击左上角的添加，添加记录。 完成后，点击右上角的Apply，将解析后的记录提交给PDNS。

尖端

在实际的域名解析中，我们一般会采用CNAME和A记录的组合，相当于DNS解析层面的负载均衡。 A记录是域名和IP的关系，也就是说同一个域名可以有多个A记录。 CNAME记录是域名与域名之间的关系，两个域名的用途不同。 前者是给大家使用的，后者是给运维人员使用的。 当CNAME→A存在时，客户端会根据网络情况决定使用A记录对应的IP，从而提高用户体验。

验证权威DNS是否正常

向首页询问私有域名解析记录如下图，解析正常。

代码语言：

复制

─$ dig @127.0.0.1 -p 53 www.home.lisz
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> @127.0.0.1 -p 53 www.home.lisz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47193
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.home.lisz.                 IN      A
;; ANSWER SECTION:
www.home.lisz.          60      IN      CNAME   www101.home.lisz.
www101.home.lisz.       60      IN      A       192.168.1.1
;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Aug 23 17:05:15 JST 2022
;; MSG SIZE  rcvd: 79

验证递归DNS是否正常

如下图，向首页询问公共域名解析记录，解析正常。

代码语言：

复制

-$ dig @127.0.0.1 -p 53 www.baidu.com
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> @127.0.0.1 -p 53 www.baidu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8988
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.baidu.com.                 IN      A
;; ANSWER SECTION:
www.baidu.com.          831     IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       28      IN      CNAME   www.wshifen.com.
www.wshifen.com.        192     IN      A       45.113.192.102
www.wshifen.com.        192     IN      A       45.113.192.101
;; Query time: 244 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Aug 23 17:06:03 JST 2022
;; MSG SIZE  rcvd: 127

参考