企业官网建设流程全解析

1. 先搞清楚Azure DNS和“记录集”到底是个什么东西

1.1 为什么一开始就被“记录集”这个词卡住

我自己第一回用Azure DNS的时候，被“记录集”这个中文翻译搞懵过。我们平时用阿里云、腾讯云或者Cloudflare，添加解析记录都是“添加一条A记录”“加一条CNAME”，操作逻辑是单条单条来的。但是Azure Portal里摆着一个“记录集”按钮，点进去还要填“名称”“类型”“TTL”“IP地址”，我当时反应是：这玩意儿到底是一条记录，还是一组记录？

先给结论：Azure DNS里，记录集（Record Set）是一个管理单元，它把“同一个名称、同一种记录类型”的一组记录打包在一起。比如www.example.com下有两条A记录，一条指到1.2.3.4，一条指到5.6.7.8，这在Azure里就是一个A记录集，里面包含两个IP。你不能在这个记录集里再塞一条AAAA记录，也不能塞一条TXT记录，因为这个记录集的名字和类型已经确定了。

这个设计看起来很别扭，但你用一段时间就会发现，它天然避免了DNS配置里最经典的一个冲突：同一主机名下混入互斥记录。比如CNAME和A记录不能共存，这是DNS协议的老规矩。Azure直接用“记录集类型唯一”这个约束，把规则的边界写死在产品逻辑里了。换句话说，你在Portal里想犯这个错都犯不了。

所以你在看我的这篇东西的时候，请先把脑子里“单条记录”的概念替换成“记录集”。后面所有操作，包括创建、修改、删除、批量导入，都是以记录集为最小单位的。搞清这一点，你后面读文档、写脚本时思路就顺了。

1.2 在Azure DNS中“zone”和“record set”的关系

Azure DNS的顶层概念是DNS区域（DNS Zone），它对应一个DNS命名空间的授权区域，比如example.com。你把example.com这个区域建好之后，Azure会把托管该区域的四台权威DNS服务器地址分配给你，这四台服务器就是整个example.com的权威来源，你需要把这四台NS记录原样填到你的域名注册商那边，把域名的DNS服务委托给Azure。这一步不完成，后面你在Azure里配的所有记录集都不会生效。

区域之下才是记录集。记录集的全名由“相对名称”和“区域名”拼接而成。比如你在example.com区域里建一个名为www的记录集，它的FQDN就是www.example.com；如果你建一个空的相对名称（表现为“@”），那这个记录集就是zone apex，也就是example.com本身。这里有个细节，Zone内的SOA记录和NS记录也是以记录集形式存在的，创建区域时Azure会自动生成，不需要你自己去搭。

从资源层级来看，其实是：资源组（Resource Group）→ DNS区域（DNS Zone）→ 记录集（Record Set）→ 记录值。很多人直接开始在Portal里点“+记录集”，发现需要先选“区域”，然后才意识到自己连区域都还没建，那就得退回去先建区域。这是常见的入门卡点。

1.3 记录集支持哪些记录类型

Azure DNS支持的记录类型覆盖了日常能用到的绝大多数场景，在做方案选型之前最好先列个清单心里有数。

你注意到没有，里面没有“隐式CNAME”这种东西，也没有“URL转发记录”。Azure DNS不提供显式URL转发，你想实现“输入example.com自动跳到www.example.com”这类效果，要么靠应用层的重定向，要么用别名记录指向一个Azure资源。我后面会单开一章讲别名记录，它是Azure DNS最值得玩的功能，因为很多云厂商的DNS是没有这一层的。

2. 动手前需要搞明白的解析逻辑和参数

2.1 TTL：最容易忽略但影响极大的参数

TTL（Time To Live）是所有DNS记录都有的参数，表示递归解析服务器和客户端缓存这条记录的时间。Azure Portal里创建记录集时默认TTL是3600秒，也就是1小时。很多人不管这个值，直接保持默认，但生产环境里TTL选得不好，真的会出事故。

我举个例子。假设你要做一次业务迁移，把站点从旧机房切到云上，你提前一天把A记录集里的IP从旧地址改成新地址。如果TTL是默认的3600秒，那意味着即使你改完了，还有一些本地DNS服务器在整整一个小时里继续返回旧IP，用户访问的还是旧服务器。这还不是最糟的，如果用户那边运营商DNS强制缓存更长，你甚至要等24小时才能让全量流量切换过去。

所以我的建议是：在计划做IP变更之前，提前48小时把TTL临时调低到300秒甚至60秒。等变更完成、确认解析稳定之后，再把TTL调回3600秒。这个操作在Azure Portal里就是改一下数字的事，但这个习惯能帮你省掉无数个“为什么改了半天还没生效”的深夜。TXT验证记录这种一次性用途的记录，TTL不要设太长，验证完直接删除，避免后患。

2.2 记录集命名规则：@、*、相对名称

记录集创建页面里的“名称”这一栏，需要填的是相对名称，而不是完整域名。比如你的区域是example.com，想解析www.example.com，那名称栏填www就行。这是Azure DNS一个比较常见的误解点。

有几种特殊情况要特别说明：

• @：表示根域名/Zone Apex，即example.com本身。A记录、MX记录、TXT记录都可以建在@上，但注意CNAME不能建在@上，这是DNS协议规定死的事。
• *：通配符记录。建一个名为*的A记录集，所有未命中的子域名都会解析到这个IP。比如*.dev.example.com通配所有dev环境子域。但要注意通配符不匹配空标签，所以example.com这个apex不会被*命中。
• 子域委派：如果你在一个区域里建一个名为sub的NS记录集，并把里面NS值指向你自建的DNS服务器，那就等于把sub.example.com这个子域的所有解析权都甩给了那台服务器，这就是子域委派。我在实际工作里经常用这个方式把一些特定子域委派给内部DNS服务，避免所有解析都挤到Azure DNS上。

另外，名称里的大小写不敏感，但这个不敏感是体现在解析层面；在Portal和API层面，如果你用不同的写法去引用同一个记录集，Azure的判断还是以规范化之后的名称为准的。我见过有人把记录集名写成“WWW”后来又用“www”去查，结果怎么查都查不到，白白排查了半天。

2.3 为什么Azure DNS要强调“记录集”而不是“单条记录”

从产品设计角度看，记录集是Azure DNS和传统DNS管理员手感差异最大的地方。传统BIND或Windows DNS里，你可以往同一个名称下加很多不同类型的记录，比如www.example.com既有A记录，又有TXT记录，这在技术上是允许的。但在Azure DNS里，同一名称只能存在一个同类型的记录集，但可以存在多个不同类型的记录集。

换句话说：

• 可以同时存在：www.example.com的A记录集 + www.example.com的TXT记录集。
• 不能同时存在：www.example.com的CNAME记录集 + www.example.com的A记录集。
• 同一个A记录集里可以有多个IP。

这种设计的一个潜在影响是：当你修改记录集时，一次API调用会覆盖整个记录集里的所有值，而不是只在尾部追加一条。如果你用Portal操作，感觉不明显；但如果你用命令行脚本批量维护，就要格外小心，别把本应保留的旧值覆盖掉了。后面我会在实操章节里专门演示怎么通过“先remove再加”的方式避免误伤。

3. 记录集管理的完整实操过程

3.1 从创建区域开始：选“公网DNS区域”还是“私网DNS区域”

在Azure里新建DNS区域的时候，你会碰到一个选择：公网DNS区域还是私网DNS区域。这个决定很重要，因为它直接决定了这个区域的解析范围。

公网DNS区域，就是在公网互联网上生效的DNS区域。你注册的example.com就是典型的公网区域，全球任何一台能上网的DNS递归器都能查询到它，前提是你完成了域名注册商处的NS委托。私网DNS区域则绑定到你的虚拟网络（VNet），只在VNet内部生效，适合做内部服务发现，比如把db.internal.example.com解析到数据库服务器的内网IP，这个记录外面根本看不到。

实际项目中，我经常两套同时用：example.com放公网，作为对外服务的入口；internal.example.com建一个私网区域，绑定到生产VNet，用于内部微服务之间的相互调用。这里有一个坑，就是私网DNS区域不能跨租户共享，必须显式关联VNet；而且一个VNet可以关联多个私网区域，解析的时候会有优先级顺序，两个区域里如果有同名记录，排在前面区域的记录会胜出，这个优先级顺序要自己在配置里控制好。

3.2 用Portal和Azure CLI创建、更新、删除记录集

如果你只打算管理几个记录，用Portal点击操作就够了。进入DNS区域页面，点“+记录集”，填名称、选类型、填TTL、填记录值，保存即可。这个流程我不打算多讲，因为Portal操作没有太多可以展开的细节，关键是命令行方式。

我用Azure CLI演示一套完整的生命周期操作，这也是实际运维中我认为效率最高的方式。假设你已经登录了Azure，并且有权限操作目标资源组。

创建一个A记录集，名为www，包含两个IP：

az network dns record-set a create \ --resource-group myResourceGroup \ --zone-name example.com \ --name www \ --ttl 3600

这个命令执行完，其实只是创建了一个空的A记录集，还没有任何IP值。往里面添加IP，用的是add-record：

az network dns record-set a add-record \ --resource-group myResourceGroup \ --zone-name example.com \ --record-set-name www \ --ipv4-address 1.2.3.4 az network dns record-set a add-record \ --resource-group myResourceGroup \ --zone-name example.com \ --record-set-name www \ --ipv4-address 5.6.7.8

如果你要改IP，建议先remove旧值，再加新值。比如要把1.2.3.4换成2.2.2.2：

az network dns record-set a remove-record \ --resource-group myResourceGroup \ --zone-name example.com \ --record-set-name www \ --ipv4-address 1.2.3.4 az network dns record-set a add-record \ --resource-group myResourceGroup \ --zone-name example.com \ --record-set-name www \ --ipv4-address 2.2.2.2

删除整个记录集则是：

az network dns record-set delete \ --resource-group myResourceGroup \ --zone-name example.com \ --name www

这一套命令看起来简单，但有几点必须提醒：

第一，add-record不是幂等操作。如果同一个IP已经被记录在集里，再add一遍就会报重复。所以批量脚本里最好先查询当前记录集内容，判断是add还是skip。

第二，remove-record把某个IP移除后，如果记录集里没有任何IP了，记录集本身并不会被删除，它还是存在的，只是空的。空记录集不会产生任何解析效果，但会产生一条多余资源。需要的话，你可以手动删掉空的记录集。

第三，CLI里没有直接“更新某一条值”的操作，只有“加/删”动作。这个设计和我们之前讲的“记录集整体覆盖”逻辑是呼应的，理解了这个，写脚本时就不会觉得它难用，反而会觉得这样更符合DNS的语义。

3.3 批量导入导出：区域文件迁移时怎么做

当你手头已经有了一套跑在别处的DNS配置，想把记录全部迁到Azure DNS时，一条一条手动加肯定不现实。Azure提供了区域文件的导入导出功能，支持标准的BIND zone file格式。

导出命令：

az network dns zone export \ --resource-group myResourceGroup \ --name example.com \ --file example.com.zone

导入命令：

az network dns zone import \ --resource-group myResourceGroup \ --name example.com \ --file example.com.zone

这种zone file的格式对老DNS管理员来说非常亲切，但如果你一直用的是云厂商的图形界面，第一次看到可能会有点懵。它长这样：

$ORIGIN example.com. @ 3600 IN SOA ns1-01.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300 @ 3600 IN NS ns1-01.azure-dns.com. @ 3600 IN NS ns2-01.azure-dns.com. www 3600 IN A 1.2.3.4

有一个细节我栽过跟头：zone file里如果出现重复的记录(比如两条相同的A记录指向同一个IP)，导入时会直接报错，因为Azure DNS不允许记录集内有重复的记录值。而从某些老式DNS服务器导出的zone file里恰恰经常有这种重复。解决办法是在导入前先用脚本过滤一遍，或者在导入后查看错误日志，定位到具体是哪一条导致失败。总体上，导入功能适合“一次性迁移”，不适合“频繁同步”，因为每次导入都是全量操作，不是你改一行它同步一行。如果你要长期把多个来源的记录同步进Azure DNS，建议还是走Terraform或者写脚本调REST API，那样可控性高得多。

4. 别名记录：Azure DNS里被低估的高级玩法

4.1 别名记录的价值：避免“CNAME不能用于根域”的坑

在传统DNS的规则里，CNAME记录不能出现在Zone Apex，也就是说example.com不能直接用一个CNAME指向另一个域名。但是现实中我们经常想把根域名指向某个云服务，比如负载均衡器、CDN、应用网关，这些服务的域名本身又是一个CNAME或者动态变化的地址。你要么牺牲根域做A记录指向固定IP，要么就接受根域无法直接别名到云服务的限制。

Azure DNS的别名记录（Alias Record）就是为这个场景设计的。别名记录看起来类型还是A或AAAA，但它不是静态的IP，而是指向另一个Azure资源的“引用”。你选择目标资源之后，Azure会自动维护这条记录与目标资源状态之间的对应关系。目标资源的IP变化了，别名记录会自动跟着变，不需要你手动改。

我举个真实例子。你的Web应用部署在Azure应用服务（App Service）上，应用服务默认域名是yourapp.azurewebsites.net，它对应一个或多个IP。如果你在example.com区域里建一个根域的A记录集，开启“别名记录集”，然后目标资源选“应用服务”，那用户访问example.com时就会自动解析到应用服务当前的IP。整个过程你不需要知道那个IP具体是什么，也不需要担心应用服务扩容换IP之后解析失效。

4.2 示例：把根域解析到Azure负载均衡器、CDN或流量管理器

阿里云有类似的概念叫“解析线路”，腾讯云有“CNAME加速”，但Azure的别名记录的覆盖面可能是几个主流云里比较完整的。除了应用服务和负载均衡器，它还支持指向：

• Azure Front Door（全球入口服务）
• Azure CDN
• Azure Traffic Manager（流量管理器）
• Azure Public IP（公网IP资源）
• 另一个DNS区域内的记录集

创建别名记录的Portal操作很简单：在“+记录集”页面里，类型选A（或AAAA），然后勾选“别名记录集”，会自动弹出一个目标资源选择框。如果你要用CLI，可以用类似这样的写法把根域A记录集指向一个流量管理器Profile：

az network dns record-set a create \ --resource-group myResourceGroup \ --zone-name example.com \ --name "@" \ --target-resource "/subscriptions/<subscription-id>/resourceGroups/myResourceGroup/providers/Microsoft.Network/trafficManagerProfiles/myTMProfile" \ --ttl 300

注意这里的--target-resource是一整条Azure资源ID，必须完整。如果你填错了资源ID，命令可能会成功，但记录不会生效，因为Azure找不到这个资源。所以推荐的操作是先到目标资源的“属性”页面复制Resource ID，别手敲。

这里我想强调一个使用场景，很多人用Traffic Manager做多区域故障转移时，只在Traffic Manager里配了Endpoint，却忘了在DNS区域里建别名记录指向这个Traffic Manager。结果Traffic Manager配置得很漂亮，但用户访问根域名时，DNS还是解析到固定的旧IP。实际上，Traffic Manager本来就不直接对外提供IP，它只是一个DNS路由器，最终一定是要靠一条别名记录才能把域名解析“转发”到它那里。

4.3 别名记录和自己的其他DNS记录如何协同

别名记录和普通A记录是可以共存的，但有一个限制：同一记录集内，别名记录不能和普通记录值混用。也就是说你不能在一个A记录集里既填IP又开别名记录。如果你需要一部分流量走云服务，一部分流量走固定IP，就要在更上层做分流（比如用Traffic Manager配多个Endpoint），而不是在同一个记录集里混着写。

我以前接过一个项目，客户想实现“主区域故障时切到备用静态IP”的效果。他们试图在同一台记录集里同时配置别名记录和IP，结果发现门户连保存都不让保存。正确做法是在Traffic Manager里配两个Endpoint，一个是Azure资源，一个是外部IP，让健康检查和故障转移在Traffic Manager层面完成，DNS区域里只保留一条别名记录指向Traffic Manager。

另外，如果你用了Azure CDN，还要注意CDN自定义域名的绑定方式和别名记录之间的关系。一般流程是：先在CDN端绑定custom domain，然后在DNS区域里建一个CNAME（CDN场景通常都允许在子域上用CNAME，比如cdn.example.com指向你的CDN endpoint），或者对根域用别名记录。我记得有一次CDN自定义域名怎么都验证不通过，最后发现是TTL太长，验证服务器读到的还是旧值。把TTL临时降到60秒再触发验证，就秒过了。

5. 常见问题与排查技巧实录

5.1 解析不生效的第一反应：先查NS委托，再查TTL缓存

“我在Azure DNS里加了记录，但就是解析不出来”是讨论区出现频率最高的问题。这种问题我在群里带过很多次新人，总结出来的排查顺序基本是固定的。

第一步，确认域名注册商那边的NS记录是否已经改成Azure给你的四个NS地址。很多人建好区域之后忘了做这一步，或者改了但注册商那边提示“NS修改可能需要24-48小时生效”，然后就什么都不管了。你可以用dig工具验证：

dig example.com NS +trace

如果最后几行显示的是azure-dns.com相关的NS服务器，说明委托已经生效；如果显示的还是原来注册商或者老DNS服务商的NS，那问题就在委托环节，此时你在Azure里再怎么折腾记录都白搭。

第二步，确认你查询的确实是公网权威DNS。有时候你自己电脑上用nslookup查不到，是因为本机递归DNS缓存了旧值。我习惯用下面的命令同时查权威DNS和公共DNS的答案：

nslookup -type=A www.example.com ns1-01.azure-dns.com

直接指定Azure NS服务器查询，绕开本地缓存，这样能判断到底是权威侧的问题，还是缓存侧的问题。顺便说一句，网络上很流行的那些“DNS优选”“最快DNS推荐”的帖子，本质上是推荐更快、更稳的递归DNS服务器，解决的是客户端解析速度问题；而你在Azure DNS里配置的是权威DNS，这是两个完全不同的层面。别把两者混为一谈，你换再多电脑端的DNS，也影响不了Azure权威服务器的响应，除非你配置了域委派。

第三步，检查TTL。我之前专门说过TTL的问题，如果刚才查权威服务器已经能看到新记录，但公共递归DNS还在返回旧值，基本就是TTL没到期的缓存问题。此时唯一能做的只有等。所以生产环境的变更，一定要养成提前降TTL的习惯。

5.2 删除记录集和反向解析的坑

删除记录集看起来是最简单的操作，但实际上有几个坑值得说一下。

第一个坑是：在Azure DNS里，当你把包含多条记录值的记录集删掉时，整个记录集一起没了，而不是只删其中某条。如果你只想删一条，必须用remove-record而不是delete。我在3.2节里已经演示过，这里再强调一遍，是因为我见过不止一个人用delete命令把整个记录集清空，然后回来问“我原来的其他IP去哪了”。

第二个坑是反向解析。你创建正向记录集（比如把mail.example.com解析到某个IP）之后，Azure并不会自动帮你创建这个IP的PTR记录。邮件服务器做反查时，查的是IP对应的PTR记录，这个记录不一定在Azure DNS里，可能在你的IP所属方那里配置。所以凡是涉及邮件服务器的场景，一定要额外确认反向解析记录，不然你的邮件很容易被对方当成垃圾邮件拒掉。Azure的公网IP资源里，可以在“配置”里设置“反向DNS”，这里填的域名要和正向解析对应上，否则验证不通过。

第三个坑是资源锁。如果你给DNS区域加了资源锁（Resource Lock），在删除区域或者记录集时可能会遇到“无法删除”的错误。这不是Azure出错，是锁在起作用。我之前给一个生产环境的DNS区域加了“只读锁”，之后调试时想删掉一条测试记录集，怎么删都报错，排查了半天才想起来是自己加锁了。所以如果你遇到删除失败，先去检查资源锁状态。

5.3 把Azure DNS和自建DNS的思路结合起来

聊到自建DNS，我多说两句。很多有一定Linux基础的朋友喜欢自己搭DNS服务器，比如用BIND在服务器上做域名解析。这种做法在一些特定场景下确实合理，比如内部网络需要解析大量内网主机名，或者需要做复杂的解析策略分流。但如果你只是想把一个对外域名的解析托管起来，自建DNS的运维成本其实很高：要做高可用，要防DDoS，要监控，还要关注递归和权威不同角色之间的安全隔离。我见过几起因为自建DNS服务器被攻击导致整个域名解析瘫痪的案例，影响面非常大。

更合理的做法是分层。外部权威解析交给Azure DNS这种托管服务，内部特殊解析交给自建DNS或者Azure私有DNS区域。想让两者协同工作，关键在于子域委派。比如你希望内部的jenkins.example.com由内部DNS服务器解析，而外部的www.example.com由Azure DNS解析，那你就在Azure DNS里建一个名字为jenkins的NS记录集，指向你内部DNS服务器，然后让整个jenkins子域的所有记录都只在内部DNS里维护。这样外面看到的还是Azure的NS，但内部子域的实际解析已经被你接手了。

有人在Linux上修改DNS配置后重启网络发现配置被还原，这通常是因为网络管理器或者systemd-resolved接管了/etc/resolv.conf。这个问题在自建DNS时特别常见，但它和Azure DNS没有直接关系。我这里提一下，是因为很多人在同一个项目里同时搞托管DNS和自建DNS，遇到客户端解析不对时，容易分不清是哪一层出了问题。我的排查习惯是：先把客户端DNS指向公共DNS，递归查询一下目标域名；如果正常，再切回内网DNS，对比两次结果差异，基本就能定位问题出在权威记录还是内部解析链路。

6. 从“能用”到“用得稳”的经验心得

6.1 用资源锁和诊断日志保护DNS配置

DNS配置的变更影响往往是全局性的，一条错误的记录可能让整个站点的用户访问失败。所以我对DNS区域的态度是：能少动就少动，要动就必须有防护。

资源锁（Resource Lock）是第一道防线。给生产DNS区域加一个“只读锁”，任何误操作都改不了记录，只有先移除锁才能变更。听起来很简单，但真的能救命。我见过因为自动化脚本参数写错，把生产环境整批记录集全部清成空集的案例——如果当时有只读锁，这种事故根本不会发生。

第二道防线是诊断日志。Azure DNS支持把查询日志发送到Log Analytics Workspace，你可以查看到底有哪些客户端在查询你的记录，查询量多大，有没有异常高频的查询模式。这个功能默认不开启，需要手动配置诊断设置。我个人建议所有生产区域都开启，尤其当域名遭到流量攻击或异常解析请求时，日志能帮你分清情况：是攻击者伪造了源IP，还是某个客户端的配置出现了循环查询。

第三道防线是配置的版本管理。虽然Azure Portal里没有原生的“DNS变更历史”功能，但你可以通过把zone export出来的文件纳入Git仓库，每次变更后提交一次，这样任何变更都能回溯。我自己习惯在每周巡检时导出一次zone文件，和上一周的做diff，一眼就能看出这一周里哪个记录被改过。这个习惯帮我发现过好几次被同事误改的记录。

6.2 自动化管理记录集的节奏

当你管理的域名多了，Portal和CLI手敲都会变得低效，这时候需要把记录集管理纳入基础设施即代码（IaC）的体系。Azure DNS可以用Terraform管理，也可以用Azure Resource Manager模板，甚至用GitHub Actions做定时同步。

Terraform管理记录集的思路大概是这样的：为每个记录集定义一个resource，例如：

resource "azurerm_dns_a_record" "www" { name = "www" zone_name = azurerm_dns_zone.example.name resource_group_name = azurerm_resource_group.example.name ttl = 3600 records = ["1.2.3.4", "5.6.7.8"] }

Terraform的好处在于，它会把记录集收敛到你声明的状态，如果你在代码里删掉了某个记录的定义，下一次apply时就会把对应的记录集删掉。这就是所谓的“声明式管理”。不过要提醒的是，如果你的环境里既有Terraform又有Portal手动维护的记录，一旦两者状态不一致，Terraform可能会把手动加的记录当作“漂移”清掉。所以用IaC之前，先确定“唯一事实来源”，不要一会儿用代码一会儿用手点。

自动化这件事，我的建议是循序渐进。如果只有几个域名，先不用上复杂的CI/CD流程，写一个简单的shell脚本把export、diff、import串起来，每周跑一次就够了。等规模大了，再上Terraform和操作审批流程。一上来就上重型自动化，磨合成本远高于收益，这是很多团队容易犯的过度工程问题。

6.3 对DNS记录集的管理保持敬畏

最后说点不太技术但很重要的话。DNS是我认为所有云服务里，最需要“敬畏心”的一项。它没有熔断机制，没有回滚按钮，改错了就得靠TTL慢慢等缓存过期，这个过程中用户看到的就是网站打不开、邮件发不出去，而且你毫无办法立刻挽回。相比之下，改错一台服务器配置，你还能登上去立刻改回来；DNS的一笔误操作，影响是全网的，修复时间是以小时计的。

所以我现在给自己定了几条规矩：第一，生产环境的DNS变更永远走变更流程，哪怕只是加一条TXT验证记录也要记录在案；第二，不直接在生产区域上做测试，测试记录先放到独立区域里验证；第三，变更结束后主动用多个公共DNS递归器验证结果，不要只盯着本机的解析输出。这几条规矩看着朴素，但它们是保证DNS配置不翻车的底线。

如果你刚接触Azure DNS，建议先从一个小域名或者一个测试子域练手，把记录集、别名记录、TTL、导入导出这些概念都亲手过一遍，再去碰生产环境。这篇东西讲到的命令和排查思路，都是我自己在真实项目里反复用过、踩过坑之后沉淀下来的，你可以直接拿去当操作手册。真遇到问题，按照我上面写的排查顺序一步一步来，大概率能自己解决掉八成的解析故障。