如何解决域名解析不生效问题？
域名解析不生效产生的原因很多，除了网络不可用， 域名劫持()等因素之外， 按照排查链路先后顺序列举如下：
1.1 域名状态是否正常
先检查域名的状态，可以查看注册服务商提供的 whois 域名信息，如果域名状态为 clienthold 或 serverhold 状态，说明域名是被禁止解析的。这种状态下，即使设置了域名解析，也无法生效，域名无法被访问到，需要联系域名注册商取消这个状态。
1.2 权威修改是否已经修改生效
请确认权威DNS的域名解析记录已修改成功。
1.3 递归DNS缓存记录是否已更新
修改域名解析后，还取决于各运营商递归DNS的缓存是否生效。
1.4 客户端DNS缓存记录是否已更新
客户端在老的解析记录TTL过期前无法更新。
其中1.3，1.4是常见不生效原因，长时间无法生效大多由于1.3导致。
二、域名解析不生效解决办法
2.1 通过递归DNS解决
2.1.1 方法一：使用
HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务器，从而绕过运营商的Local DNS，能够解决Local DNS造成的、、三方面问题，并且能够提升域名解析效率。
HTTPDNS与传统的域名解析流程对比如下图所示。
HTTPDNS与传统DNS对比图
(3) 如何使用
(4)使用有什么限制？
HTTPDNS需要修改应用的DNS解析过程，因此主要适用于C/S架构的场景。
对于无法修改域名解析过程的场景，如PC浏览器访问、微信H5页面访问都无法使用HTTPDNS。
2.1.2 方法二：使用公共DNS
上面提到，由于ISP提供的递归域名服务器质量参差不齐，导致比较容易出现解析失败、解析不生效等问题，因此部分厂商提供了公共DNS解决这个问题。
常见的公共dns有：
DNS 服务器 IP
提供方名称
提供方国家
114.114.114.114
114.114.115.115
2.1.3 两种方法优劣对比
实现简便程度
备注：满分10分，分数越高说明方法优势越大
对上面对比做一个说明：
（1）HTTPDNS使用时需要开发者修改DNS解析流程，因此只适用于C/S架构的应用，对于PC浏览器、微信H5等场景不适用，程序编写也有一定的工作量，好在国内的HTTPDNS厂商都提供了封装好的SDK和示例代码供开发者使用和参考，大大降低了实现难度。
（2）使用public dns的方法通用性很低，因为需要每个客户都对自己终端的DNS服务器配置进行修改，由于需要面向庞大的、水平参差不齐的终端用户，这种方式对于开发者而言实施难度非常大。
2.2 通过客户端自身解决
对于客户端缓存结果不能更新的问题，可以通过强制刷新系统DNS缓存来删除老的解析结果。以windows系统为例，方法如下：
打开windows命令行,执行ipconfig/flushdns命令清空DNS缓存
图二 Windows系统情况DNS缓存方法示意图
三、悲催的域名解析不生效问题
尽管权威DNS系统属于变更相对较少的一个底层服务，但系统管理员可能还会在以下几种情况下变更DNS服务器的域名解析记录：
（1）域名对应IP变更（替换、增加、减少等情况）
（2）接入CDN系统，增加域名的CNAME记录
（3）系统受到攻击时切换IP躲避攻击！！！
（4）其他需要变更的情形
修改解析记录后常见难题是：**不生效**
域名解析不生效示意图
下面首先看看域名解析的流程。
四、域名解析过程分析
以常见的递归解析方式为例，说明解析流程
域名解析流程示意图
上图是相对完整的域名解析流程（假设各个环节的缓存没有命中）：
1） 用户终端发起域名解析请求
2）本地递归域名服务器向根域名服务器(.)请求并得到.com域名服务器的IP地址
3）本地递归域名服务器向.com域名服务器请求并得到权威域名服务器的地址
4）本地递归域名服务器向发出的解析请求并得到返回结果
5）用户终端从本地递归域名服务器得到最终的解析结果
五、域名解析不生效根源
5.1 域名结果缓存环节分析
域名解析不生效（生效慢）是由于域名解析结果被缓存住，并且缓存结果短时间无法更新导致的。
域名解析可能在访问终端系统、本地递归域名解析服务器两个环节被缓存住，如下图所示。
图五 域名解析结果缓存环节分析示意图
5.2 终端缓存特征
终端的缓存是由终端应用（如PC浏览器）控制的，一般情况下会遵循域名解析结果的TTL规范，也就是在域名有效期过期后会自动重新请求，因此这个时间是可预期的，也是可控的（通过修改权威TTL）。
5.3 递归域名服务器缓存特征
本地递归域名服务器一般由提供服务的ISP设置，服务器自身也是由ISP维护，公网上存在大量的递归域名服务器不遵循权威的TTL，导致我们的域名解析修改不生效（全球生效时间最长可能有72小时之久）。
由上面的分析可以知道，域名解析不生效最重要的诱因是递归域名服务器不能及时更新解析结果。
耐心看到这里的读者必须予以奖励，这里提供几个域名解析的几个TIPS。
6.1 域名解析从入门到中级
看完这篇就欧了。
6.2 无线场景下的域名服务器设置
Android/iOS在wifi接入场景下可以通过在系统的设置中找到修改DNS服务器的入口，但非wifi的网络制式接入（如2/3/4G网络）无法修改DNS服务器配置，因此当ISP为我们配置的默认递归域名服务器不合理时，就会碰到调度精确性的问题，这个问题可以参考
6.3 黑科技：解析实时生效方法
上面通过改进递归DNS设置（使用HTTPDNS或者配置公共DNS），可以确保域名解析结果在TTL过期后生效，但如果TTL设置时间较长（如10分钟），这时候我们仍然需要等待比较久的时间才能看到解析结果生效。
有没有更好的办法？ 从第五节的分析来看，域名解析不生效的关键环节之一是递归DNS服务器缓存的域名解析结果需要等待TTL过期才会去权威更新，这个等待时间能否消除掉？
答案是肯定的。如果权威解析记录修改后，能够同步更新递归DNS的缓存记录，就可以实现解析记录的实时生效。
这种特性只能通过递归DNS和权威DNS配合才能实现，阿里云云解析即将发布支持解析记录修改实时生效的版本，敬请期待。个人认为这个基本不可能。根据HTTP协议来说：
用户-&输入网站域名-&DNS（找到域名对应的IP）-&客户端-&DNS查到的对应域名的IP-&网站可以看出来，只能获得客户端的IP地址，DNS解析的过程中网站服务器根本不会参与也没产生交互，所以无法获取。个人理解，如有更高明的方法请告之，3x。
附近的朋友等待您的帮助
包打听移动版妙用DNS解析实现防火墙客户的重定向
我的图书馆
妙用DNS解析实现防火墙客户的重定向
前言：现在很多公司都使用微软的活动目录对网络进行管理，其中内部DNS服务器是不可或缺的一个组成部分。我们知道，对于ISA的防火墙客户端通过ISA访问网络资源时，其DNS解析由ISA服务器帮助完成，你是否有想过，通过的内部DNS服务器和防火墙客户端结合，能够巧妙的解决很多实际问题。
这篇文章里，我将通过两个CASE，讲述使用两者结合的方法解决两个实际问题。
声明：这两个CASE都是我近期遇到的问题，其中解决第一个CASE的是我的一个同事，他为我提供了一种新的思路；第二个CASE则是我沿用这种思路，解决新的问题。
问题描述：Contoso公司的网络环境如下图所示：
该公司使用ISA 2004作为代理服务器。
公司内部网络采用单林单域模式，内部DNS名为，在Internet上注册的域名亦为。公司有50多台服务器，包括邮件服务器、数据库服务器、OA服务器、FTP服务器与Web服务器等，其中邮件服务器、OA服务器均为双网卡，而FTP服务器与Web服务器均只有外网卡，数据库服务器只有内网卡。有外网卡的服务器均直接与外线交换机相连，且在Internet上注册有合法的DNS名。
公司内部客户机的TCP/IP配置中，将DNS指向内部的DNS服务器，有访问互联网权限的客户机均使用FWC方式访问Internet。现公司为了提高访问OA服务器和邮件服务器的速度，要求客户机通过服务器的内部网卡进行访问邮件服务器和OA服务器。
分析存在的问题：OA服务器和邮件服务器数量总和大约在30台，如果一台一台在ISA控制台上设置“访问不通过代理服务器”，工作量较大，且将来添加新服务器时，需要在ISA上添加相应的纪录；另一方面，如果在ISA上直接设置Bypass *.，那么会造成安装有防火墙客户端用户无法访问和（因为这几台Server没有内网卡）。
解决方案：其实解决的方案有很多，但下面这种最简单的不知道你想到没有：
在ISA Server上对*.进行Bypass，然后在内部DNS为和分别新建两条A纪录，指向各自的外网IP。
我们以为例，来考虑一下现在的客户机访问过程：
1、用户通过IE访问，通过防火墙客户端向ISA Server发送请求，要求进行解析；
2、ISA判定访问此web站点不需要经过ISA Server；
3、客户端向内网DNS查询的地址，内部DNS返回这台服务器的外网IP；
4、客户端判定IP地址在外网，向ISA发送访问此IP的请求；
5、代理服务器通过策略处理，响应请求，连接建立。
正如上述过程所描述的，防火墙客户端模式的客户机通过使用内部DNS服务器的解析，实现了对外部资源的访问。
请仔细体会一下其中的过程，然后接着看CASE2。
背景描述：BlueEye公司位于上海，是总部位于深圳的Contoso收购的一家公司。Contoso收购Blueeye后，未对BlueEye的AD架构进行更改，而保持了其原有的内部DNS名：，只是将其电子邮件名统一为，且要求其通过使用总部的邮件服务器进行邮件的发送与接受，便于邮件的监控。
两家公司的网络结构图简单表示如下所示：
点击查看大图
BlueEye内部有收发邮件的客户机均安装了防火墙客户端软件，使用Outlook EXPress收发邮件，且总部指定其使用的POP3服务器为，SMTP服务器为。Contoso公司另有一台供另一家分公司使用。
某日，Contoso通知BlueEye其突然Down机，正在进行抢修，要求BlueEye的IT部门通知BlueEye的内部用户（1000多人）更改OE的设置，使用作为临时的SMTP服务器。
分析：如果通知所有用户修改OE设置，等原先的SMTP服务器修复后还需要再更改回来，必定会造成用户的不满；同时，总部的 服务器供另一家分公司使用，暂时不会考虑去ISP的DNS注册别名。那么如何才能够快速解决此问题呢？
解决方案：如果你看过CASE1，应该会有一个思路：能不能让用户的客户机将解析为的IP，然后再向ISA发送访问请求呢？
自然是可以的，方法如下：
（1）在的内部DNS上新建一个主区域(不需要选择与AD集成)，命名为
（2）在中新建一条A纪录，将指向61.0.0.2
（3）在ISA Server上中将添加到标签Domains中；
（4）客户机刷新防火墙策略后，即可成功接收和发送邮件。待smtp服务器修复后，删除所作的更改即可恢复原来的状态，而不需要在客户端进行任何的修改。
上述两个CASE，没有用到什么高深的知识，只是通过思路的转变，就解决了两个比较棘手的问题。希望这篇文章能够给你提供一种新的解决问题的思路。
TA的最新馆藏[转]&[转]&
喜欢该文的人也喜欢