阿里云DNS免费版解析限额10万次/天，超出2299%，自建权威DNS服务器

赵文宇
0 阅读4分钟

目录：

  • 阿里云DNS免费版解析限额政策与影响
  • 基于CoreDNS自建DNS权威解析服务器
  • 调整域名解析服务器配置
    • 添加胶水记录
    • 修改域名解析的DNS服务器
  • 遇到的问题
    • 顶点域名有 CNAME 记录，不能再有其他任何记录类型
    • DNS攻击风险应对
  • 下一步: 运维监控与国内外地域解析

藏云阁的域名 cncfstack.com 是在阿里云平台申请和管理的，为节省成本一直使用的免费版本，最近收到了阿里云的通知 自2026年6月24日起，云解析DNS-公网权威解析免费版将增加单域名日解析量限制 。

限速通知 限速通知

新政策的免费版本 10万次/日 ，我立马去看了我的域名解析统计，居然超出 2299%。

DNS解析统计 DNS解析统计

那这政策调整对我们的域名解析影响还挺大，想着升级看下企业版本的价格（企业账号无法使用使用个人版本）

企业版本价格 企业版本价格

企业版本最便宜一档就是 1168元/个域名/年

这种突然的公有云IT成本支出对有盈利的企业可能不算什么，但是对我们是需要权衡的额外成本压力。

经过评估考虑了以下几种方案：

  • 方案一：升级到付费的企业版本。
  • 方案二：调整域名的 TTL 增加缓存来减少解析请求次数。
  • 方案三：将域名迁到其他公有云平台。
  • 方案四：自建DNS。

由于成本是最大顾虑，以及国内公有云服务都是互相参考，其他云平台也会有相应的限制，所以方案一和方案三不行。

调整 TTL 是目前低成本且还可以继续使用阿里云免费DNS的方案，但是考虑到我还有国内外不同的解析需求。

经过综合评估后，最后还是决定自建DNS；以下是我们自建DNS的过程和遇到的问题。

基于CoreDNS自建DNS权威解析服务器

技术选型 CoreDNS。多年前还是以 bind 为主流的 DNS 服务器，但在云原生场景下 CoreDNS 是新的选择，并且 CoreDNS 在 CNCF 也早已经毕业了，足够满足生产的软件质量需求。

由于目前还没有建立大规模的 Kubernetes 集群，所以 CoreDNS 环境的搭建还是基于 Docker Compose 的方案

services:
  coredns:
    image: registry.cncfstack.com/docker.io/coredns/coredns:1.14.3
    container_name: coredns
    restart: unless-stopped
    ports:
      - "53:53/udp"
      - "53:53/tcp"
      - "5380:5380/tcp"
      - "9153:9153/tcp"
    volumes:
      - ./Corefile:/Corefile
      - ./zones:/zones
    command: -conf /Corefile

启动 CoreDNS 核心是 Corefile 和 域名zone 两个配置文件

.:53 {
    log
    errors
    reload 30s
    health :5380
    prometheus :9153
    loadbalance round_robin

    file /zones/cncfstack.com.db cncfstack.com {
        reload 30s
    }

    cache 300
}

还有一个 zones/cncfstack.com.db 文件（配置文件IP地址进行了脱敏）

$TTL 60

@   IN  SOA ns1.cncfstack.com. support.cncfstack.com. (
        2025060401
        7200
        3600
        1209600
        3600
)

@       IN  NS      ns1.cncfstack.com.
@       IN  NS      ns2.cncfstack.com.
ns1     IN  A       1.1.1.1
ns2     IN  A       2.2.2.2

@       IN  A       1.2.3.4
www     IN  A       1.2.3.4
test    IN  A       6.7.8.9

CoreDNS 配置完成后即可进行验证

[root@aliyun coredns]# dig +short test.cncfstack.com @1.1.1.16.7.8.9

调整域名解析服务器配置

CoreDNS 创建完成后是一台权威DNS服务器，即解析该域名最权威的DNS服务器，但这时并不能直接用于互联网使用，因为这个DNS服务器还没有在全球同步。

还需要修改 域名与网站 中的配置，注意这里不是 云解析DNS 。域名与网站是管理和交易域名的产品，而云解析DNS是对域名添加DNS记录解析的，解析限速的是云解析DNS产品。

还需要两步：

添加胶水记录

将DNS服务器域名和 DNS 服务器 IP 地址的映射关系注册到顶级域名注册局，用以添加胶水记录（Glue Record）。

在阿里云上的修改位置：

阿里云上修改胶水记录 阿里云上修改胶水记录

胶水记录（Glue Record） 是 DNS 中解决循环依赖问题的特殊 A/AAAA 记录。

例如域名 cncfstack.com 的权威 DNS 服务器是 ns1.cncfstack.com

cncfstack.com.  IN  NS  ns1.cncfstack.com.

现在有人要查询 www.cncfstack.com，进行递归解析过程：

1. 根DNS: 去问 .com 的 DNS
2. .com DNS: cncfstack.com 的 NS 是 ns1.cncfstack.com，去问它
3. 客户端: ns1.cncfstack.com 的 IP 是什么？（就是这里，一开始都不知道这个域名的解析是什么，又发起一轮递归解析进入死循环）
4. .com DNS: 这个你得问 cncfstack.com 的权威 DNS
5. 客户端: 但 cncfstack.com 的权威 DNS 就是 ns1.cncfstack.com 啊！
6. 死循环！ ❌

这就是循环依赖：要查 ns1.cncfstack.com 的 IP，需要先问 cncfstack.com 的权威 DNS；但权威 DNS 的地址本身就是 ns1.cncfstack.com。

胶水记录的解决方案就是在上级域名注册商（.com 的 DNS）处，额外存放 ns1.cncfstack.com 的 A 记录（相当于添加一个静态 hosts 解析记录）。在阿里云上通过修改 自定义DNS Host，阿里云会自动向上级域名注册商同步

; 在 .com 的 DNS 中
cncfstack.com.    IN  NS  ns1.cncfstack.com.
cncfstack.com.    IN  NS  ns2.cncfstack.com.
ns1.cncfstack.com.  IN  A   121.40.25.167    ← 胶水记录
ns2.cncfstack.com.  IN  A   147.224.246.164  ← 胶水记录

修改域名解析的DNS服务器

上一步骤只是告诉上级域名注册商（.com 的 DNS），ns1 和 ns2 两台权威DNS服务器的对应的 IP 地址。接下来还需要正式修改域名的DNS解析服务器

将域名的 DNS 查询请求正式指向自建 DNS 服务器。

在输入框中，完整填写上一步创建的 DNS 服务器主机名，例如 ns1.cncfstack.com 和 ns2.cncfstack.com。

单击确定。DNS 服务器地址的修改将在全球范围内传播，通常需要 24-48 小时完全生效。

为确保网站、邮箱等服务在切换过程中不中断，务必在执行此步骤前，将原 DNS 服务商的所有解析记录完整迁移至自建 DNS 服务器。这样在正式生效前使用的还是阿里云的DNS解析，正式生效后使用自建DNS解析，都有DNS解析记录才不会导致解析失败影响服务运行。

遇到的问题

顶点域名有 CNAME 记录，不能再有其他任何记录类型

顶点域名有 CNAME 记录，不能再有其他任何记录类型，这是 DNS 协议的一个硬性规定。顶点域名就是不带任何前缀的域名本身，例如 cncfstack.com 就是定点域名，而 www.cncfstack.com 就是子域名。即只能有一条 CNAME 记录，其他 MX/TXT 等类型的解析都不能在存在。

由于顶点域名 cncfstack.com 是有 CDN 配置，并且也有腾讯企业邮箱的配置，所以之前在阿里云上同时存在 CNAME 和 MX 解析记录，阿里云DNS系统打破了这个协议标准（可能是在产品层面做了优化进行了特殊处理）。CoreDNS 是严格准守这个协议标准的，在添加了 CNAME 后，即使配置了 MX/TXT 时解析的记录任然是 CNAME 的值。

所以在迁移到自建 CoreDNS 时，按照阿里云的配置会导致腾讯企业邮箱服务异常。

我的解决方案是：

server {
    listen 80;
    listen 443 ssl;
    server_name cncfstack.com;
    ssl_certificate /data/cloud-services/nginx/ssl/cncfstack.com_ecc/fullchain.cer;
    ssl_certificate_key /data/cloud-services/nginx/ssl/cncfstack.com_ecc/cncfstack.com.key;
    return 301 https://www.cncfstack.com:443$request_uri;
}

这个方案可以解决上述问题，但是也有缺点，就是需要经过多轮DNS解析和跳转，对页面加载性能有一定的影响。

DNS攻击风险应对

由于 DNS 服务开放到互联网上，具有一定的安全风险。即使没有恶意攻击，也可能因为配置不当导致 DNS 作为普通递归解析 DNS 服务器使用，作用类似 8.8.8.8，导致大量资源和性能开销。

因此在CoreDNS配置特别注意 forward 配置。如果是内网使用可以添加 forward 来代理解析外部的域名，在本文的场景下只需要作为权威服务器只解析自己的域名即可，那就不需要配置 forward 。

下一步: 运维监控与国内外地域解析

在 Corefile 配置了 prometheus :9153 可以通过 Prometheus 来采集监控数据，使用 Grafana 看板进行展示。下一步将搭建 Prometheus + Grafana 指标监控，并添加 CoreDNS 的监控采集与定制 CoreDNS Grafana 版本。

另外，藏云阁整体是面向国内用户的，国外用户有更好的选择没必要使用。并且目前国外的请求压力较大，因此计划将国外的请求解析到一个单独的位置。可以使用 geoip 插件结合 MMDB 地理IP数据按照请求来源返回不同的解析。

avatar
文章
阅读
粉丝