DNS详解：它究竟控制什么

大多数企业主一辈子只会碰到DNS两次：一次是网站或邮箱刚设置的时候，另一次通常是有点慌张的时候——改了点什么之后，某样东西突然不工作了，却没人记得当初动了什么。这是运营网站中最不显眼的一部分，直到它把事情搞砸为止。本文将说明DNS到底控制什么、从输入域名到页面加载之间幕后实际发生了什么、哪些记录对小企业真正重要、到底该去哪里修改它们，以及几乎所有DNS相关故障背后的那几个常见错误。

DNS到底是做什么的

互联网上的每一台设备，真正的定位方式其实是一串数字地址，而不是一个名字。DNS就是把人们实际输入——或从搜索结果里点击——的域名，映射到这串背后的地址的系统，就像电话簿把一个人的名字映射到他的电话号码一样。当有人访问yourdomain.com时，浏览器会向DNS询问”这个域名指向哪里？”，在一瞬间得到答案，然后从那里加载网站。您网站的具体内容并不存放在DNS里——它纯粹是一本把访客带到正确地方的地址簿，而每当邮件服务器需要向您的域名投递邮件时，同样的查询也会单独再发生一次。

一次DNS查询是如何一步步完成的

访问一个网站会触发一条短短的查询链，大多数人从未见过它，但每一步都会在下一步被问之前先被检查：

• 浏览器与设备缓存。浏览器和操作系统首先检查是否最近访问过而已经知道答案，如果有，就直接加载页面。
• 递归解析器。如果没有缓存，请求会发给解析器——通常由访客的互联网服务商或某个公共服务运行——由它代替访客去真正查找答案。
• 根服务器与顶级域服务器。解析器先向互联网的根服务器询问哪些服务器负责该域名的后缀（.com、.my等），再向该后缀的注册局询问哪些域名服务器负责这个具体域名。
• 权威域名服务器。解析器接着向该域名自己的域名服务器——即注册商处设置的那些——查询实际记录，例如指向网站服务器的A记录。
• 返回答案并缓存。解析器把答案交回浏览器，浏览器连接到该服务器地址，同时这个答案会被缓存下来，供下次使用，缓存时长由TTL决定。

这一切通常在不到一秒内完成。只有当链条中的某一步返回了错误答案时，它才会变得显眼——通常是因为记录刚被修改，而链条中某处仍在提供更早、已缓存的旧答案。

小企业实际会用到的DNS记录

大多数域名在实际操作中只需要少数几种记录类型。A记录将一个域名——或域名的某个特定部分，比如子域名——直接指向托管您网站的服务器IP地址；正是这条记录让yourdomain.com加载出您的网站。CNAME记录将一个域名指向另一个域名，而不是指向IP地址，最常见的用法是让www.yourdomain.com解析到与yourdomain.com相同的地方。MX记录告诉互联网哪台邮件服务器负责处理您域名的邮件，让发送到您@yourdomain.com的邮件真正送达您的收件箱。TXT记录保存的是文本类设置，而不负责任何路由——如今最常见的用途是SPF、DKIM和DMARC，下文会详细说明，它们帮助接收方邮件服务器确认一封自称来自您域名的邮件是真实的，而不是伪造的。NS记录与其他记录略有不同：它保存在注册局那一层，用来声明哪些域名服务器对该域名拥有权威管理权。

DNS记录类型一览

您的DNS到底在哪里管理

这一点比DNS的其他任何部分都更容易让人搞混：DNS并不会自动跟域名的注册地绑定在一起。真正起决定作用的是域名当前指向的域名服务器（nameserver）。如果域名仍在使用注册商的默认域名服务器，DNS就在注册商的控制面板中管理。如果它已改为指向主机服务商的域名服务器——当域名和主机是同一家公司，或者经历过一次迁移后很常见——DNS就改由主机账户管理，而注册商自己的DNS设置实际上会被忽略。在改动任何内容之前，先确认域名当前使用的是哪套域名服务器，是很值得做的一步，任何注册商或主机的控制面板都能查到。

域名服务器与DNS记录：谁管什么

这两层很容易被混为一谈，因为它们都挂在”DNS”这个词下面。域名服务器是在注册局这一层，通过域名注册商一次性设置好的——它决定了哪家公司的服务器对该域名拥有权威管理权。记录——A、CNAME、MX、TXT等等——则存放在那些域名服务器自己的区域文件（zone file）里，日常的改动都发生在这一层。把域名指向新的域名服务器，相当于把整个区域文件搬到别处；而修改单条记录，只是在当前生效的那个区域文件里改一行。

为什么DNS修改不会立刻生效

每条DNS记录都带有一个TTL（存活时间）——一个时长，告诉互联网上的每一台其他服务器，在重新查询之前应该沿用已有答案多久。TTL短，比如300秒（5分钟），意味着修改可能很快就能生效；TTL较长，比如86,400秒（24小时），常见于不太会经常改动的记录，可能需要长达24到48小时才能在各处完全可见，因为世界各地不同的网络会按各自的节奏而非同时刷新本地缓存。在计划好的改动之前——例如网站迁移、更换邮件服务商——提前一两天把TTL调低，是个不错的做法，能让最终的切换一旦完成就传播得更快。

如何规划一次不中断服务的DNS变更

大多数DNS相关的故障，都是因为变更发生时，它所依赖的那一头还没准备好。按以下顺序操作可以避免这种情况：

• 先调低TTL。在计划变更前一两天，把要改动的记录的TTL调低，这样一旦真正切换，生效速度会更快，而不是被卡在很长的缓存窗口后面。
• 先让目的地就绪，再把流量指过去。在修改任何记录之前，先确认新服务器已经能正常提供网站服务，或者新的邮件服务商已经能正常收信——顺序不能反过来。
• 一次只改一条记录。修改一条记录后，用DNS查询工具确认它解析正确，再去改下一条，而不是一口气批量编辑好几条记录。
• 保留旧的服务一段缓冲期。不要立刻关停旧服务器或旧邮箱——部分访客和邮件服务器在一段时间内仍会使用缓存中较旧的答案。
• 情况稳定后把TTL调回去。短TTL在迁移期间很有用；如果长期保持过短，只会增加不必要的负担，却没有持续的好处。

DNS与邮件送达率：SPF、DKIM和DMARC

除了负责路由收件邮件的MX记录外，另有三条基于TXT的记录，正日益决定您发出的邮件是进入收件箱还是垃圾箱。SPF记录列出了哪些邮件服务器被允许代表该域名发送邮件，这样接收方服务器就能拒绝那些自称来自该域名、实际却是从别处发出的邮件。DKIM会为发出的邮件附上一个加密签名，证明邮件在传输过程中没有被篡改，且确实来自获授权的服务器。DMARC建立在这两者之上，告诉接收方邮件服务器该如何处理未通过这些验证的邮件——隔离、拒收，或仅仅上报。网站运行本身并不需要这三者，但主流邮箱服务商正越来越倾向于把没有配置它们的域名视为更可能发送垃圾邮件，这对任何用自己域名发送发票、报价单或营销邮件的企业来说都很重要。

常见错误

• 不小心改动或删除了MX记录。这是企业悄悄失去收件邮件最常见的方式——没有任何错误提示，因为邮件只是不再送达，而不是被退回。
• 在新服务器就绪之前就把A记录指过去。在迁移过程中，趁新服务器实际上还没准备好承载网站就切换过去，会让正在运行的网站无端下线。
• 更换邮件服务商后忘记更新SPF。没有列出新服务商服务器的旧SPF记录，可能导致合法邮件被标记为垃圾邮件甚至直接被拒收。
• 临近计划中的迁移时TTL仍然很长。切换当天才设置的长TTL，意味着新记录生效后，旧答案仍可能被继续提供长达24到48小时。
• 一口气编辑多条记录，中间不做任何核对。一批修改里的一个拼写错误，往往要等到某样东西——通常是邮件——已经坏了好几个小时才会被发现。
• 以为DNS必然绑定在注册商那里。域名其实已经指向了主机商的域名服务器，却在注册商面板里找记录，不仅浪费时间，还可能让人误改了一个根本不生效的区域文件。

Gotka Technologies 在其中的角色

无论域名还是主机是否与Gotka合作，DNS记录都在同一个客户中心管理——就是您已经用来处理账单和支持的那个，无需另外的登录或工具。Gotka的域名注册标配域名锁定与WHOIS隐私保护，云主机套餐——Go AI Lite 36个月方案低至RM17.80/月起——则包含免费迁移，因此在搬迁网站的过程中，DNS会作为其中一环被正确处理，而不是留给网站所有者自己去理清楚。至于注册本身，我们这篇关于如何在.my和.com域名之间做选择的文章，讲的是在DNS都还没涉及之前，需要先决定的事。

本文用到的关键术语

• DNS（域名系统）：把域名转换为计算机实际用来查找服务器的地址的全球性系统。
• 域名服务器（nameserver）：在注册商处设置的、对某个域名拥有权威管理权并保存其记录区域文件的服务器。
• 区域文件（zone file）：域名当前的域名服务器所保存的一整套DNS记录——A、MX、TXT等等。
• A记录：将域名或子域名直接指向服务器的IP地址。
• CNAME记录：将一个域名指向另一个域名，而不是指向IP地址。
• MX记录：告诉互联网哪台邮件服务器负责处理该域名的收件邮件。
• TTL（存活时间）：其他服务器在重新查询之前，应缓存一个DNS答案多久。
• 传播（propagation）：一次DNS变更在全球不同网络中逐步变得可见的过程，由TTL决定快慢。
• SPF / DKIM / DMARC：基于TXT的记录，让接收方邮件服务器能够验证一封邮件是否真的来自其所声称的域名。