分类目录归档:dns

fredzeng与你一起对dns,dns地址,电信dns地址,联通dns地址,dns服务器未响应,dns怎么设置,dns是什么,dns服务器学习相关知识及探讨!这里可以找到综合性的DNS相关文章。

OkHttp3应用[HTTP DNS的实现]

1. HTTP DNS 的介绍

HTTP DNS通过将域名查询请求放入http中的一种域名解析方式,而不用系统自带的libc库去查询运营商的DNS服务器,有更大的自由度。目前微信,qq邮箱、等业务均使用了HTTP DNS,详见这里

主要优点

  • 能够准确地将站点解析到离用户最近的CDN站点,方便进行流量调度
  • 解决部分运营商DNS无法解析国外站点的问题
  • TCP在一定程度可以防止UDP无校验导致的DNS欺诈(比如墙,运营商广告,404导航站),当然基于HTTP的话本质还是不安全的。

2. HTTP DNS 与 native DNS 的流程对比

使用http与native的区别主要在:

  • 需要实现native 自带的 LRU缓存(DNS默认是600s,原生的缓存在JNI内存中,而OkHttp缓存在硬盘中)
  • Socket请求拼装环节在java层,而不是在libc库中(当然有的项目非要做成JNI,也没办法)
  • 需要维护一个单独的HttpClient进行DNS查询

在进行实现前,我们先看下原生情况的查询方法的strace

2.1. Android下native DNS查询过程

//JDK层调用 InetAddress.lookupHostByName()(InetAddress.java); Libcore.os.android_getaddrinfo(InetAddress.java) //framework下调用 libcore.io.ForwardingOs.getaddrinfo(ForwardingOs.java) //framework层 libcore.io.Posix.getaddrinfo(Posix.java) //JNI层,此方法为java的代理 Posix_android_getaddrinfo(Posic.cpp) //调用BIONIC的libc标准库 android_getaddrinfofornet(getaddinfo.c) android_getaddrinfofornetcontext(getaddinfo.c)
...

发送socket包...

2.2. HTTP DNS流程

//拼装HTTP请求(OkHttp) client.newCall //JDK层,进行socket请求 Socket.connect(socket.java) //framework层 libcore.io.IoBridge.connect //进行tcp连接(JNI/C) ....

3. HTTP DNS的实现

在OkHttp中,提供了DNS的接口(这个接口基本没人知道,甚至网上都没有讨论),方便用户自己实现lookup方法。下文实现了两个OkHttpClient单例,一个负责dns,一个负责业务。

关于OkHttp,可以看以前的文章

经过考察第三方DNS服务,看起来只有腾讯系的DNSPod还是不错的,它直接返回一个ip地址,不需要解析json等乱七八糟的东西,文档在这里

DNSPod在返回的Header中,没有设置缓存,并主动断开了Socket连接,这样的话每次进行lookup时都会进行一个GET请求,相比以前原生多了40ms。我们都知道DNS默认的TTL时间一般是600s,因此我们可以通过复用OkHttp中的cache,在返回的response中加入Cache-Control的Header就可以实现再第二次lookup时避免再次访问网络。

static public synchronized OkHttpClient getHTTPDnsClient() { if (httpDnsclient == null) { final File cacheDir = GlobalContext.getInstance().getExternalCacheDir();
    httpDnsclient = new OkHttpClient.Builder() //消费者工作线程池 .dispatcher(getDispatcher()) //Logger拦截器  .addNetworkInterceptor(getLogger())
        .addNetworkInterceptor(new Interceptor() { @Override public Response intercept(Chain chain) throws IOException {
            Response originalResponse = chain.proceed(chain.request()); return originalResponse.newBuilder() //在返回header中加入缓存消息 //下次将不再发送请求 .header("Cache-Control", "max-age=600").build();
          }
        }) //5MB的文件缓存 .cache(new Cache(new File(cacheDir, "httpdns"), 5 * 1024 * 1024))
        .build();
  } return httpDnsclient;
}

max-age表示可以续600s;如果缓存命中将返回数据,反之抛出IOException。

通过测试,HTTP DNS工作效果如下:

  1. 在600s内,无论是否联网,都不会进行请求
  2. 在600s外,没联网时会抛出IOException,反之会进行HTTP请求

接着,我们实现了DNS查询接口,值得注意的一点就是第三方服务器可能会挂,所以一定要注意所有异常并留出后路。

static Dns HTTP_DNS = new Dns(){
  @Override public List<InetAddress> lookup(String hostname) throws UnknownHostException { //防御代码 if (hostname == null) throw new UnknownHostException("hostname == null"); //dnspod提供的dns服务 HttpUrl httpUrl = new HttpUrl.Builder().scheme("http")
        .host("119.29.29.29")
        .addPathSegment("d")
        .addQueryParameter("dn", hostname)
        .build();
    Request dnsRequest = new Request.Builder().url(httpUrl).get().build(); try { String s = getHTTPDnsClient().newCall(dnsRequest).execute().body().string(); //避免服务器挂了却无法查询DNS if (!s.matches("\\b(?:\\d{1,3}\\.){3}\\d{1,3}\\b")) { return Dns.SYSTEM.lookup(hostname);
      } return Arrays.asList(InetAddress.getAllByName(s));
    } catch (IOException e) { return Dns.SYSTEM.lookup(hostname);
    }
  }
};

在真正的业务请求时,构建OkHttpClient时对DNS进行配置就ok了

//真正的调用客户端,供Retrofit与Picasso使用 static public synchronized OkHttpClient getClient() { if (client == null) { final File cacheDir = GlobalContext.getInstance().getExternalCacheDir(); client = new OkHttpClient.Builder().addNetworkInterceptor(getLogger())
        .cache(new Cache(new File(cacheDir, "okhttp"), 60 * 1024 * 1024))
        .dispatcher(getDispatcher()) //配置DNS查询实现 .dns(HTTP_DNS)
        .build();
  } return client;
}

4. 例子

Fork me on Github,有更多交流可以与我微信沟通,在深圳的开发者可以与我面基。

巧用域名发散,缓解域名发散限制

说到优化,其实机会不多,费力不讨好,但需求不少,而且往往是刚需。一般来说针对请求优化的思路都是“收敛”,但是在这篇文章中,我们剑走偏锋,反其道行之,利用域名发散的方式缓解并发请求的限制。

最近后端前辈的带领下做一件“大事儿”,将原有的基于页面的广告请求改为行业内比较先进的单广告位请求。随之带来了好多未知的坑。过去一个页面只发出一个异步请求,现在要发出1*广告位数的请求,这一个页面50-110的请求数无论对于后台能否承接高并发还是前端对大量异步回调的处理,都是挑战。但是单广告位有事只能投放的先提条件,身为广告人,怎能不迈出这一步呢。

这次我们就先看看其中一个坑。我的一个页面中有100 多个广告位,要在页面刚加载的时候,并发100个异步请求。首先服务端的压力就不小,前端同时并发这么多的请求也会有一系列的问题:

1、大量的异步请求所带来的大量的回调,注意这些回调并不是按请求的顺序返回的;

2、浏览器并发限制,浏览器针对同一个域名可并发的请求数量是有限的,平均下来是6个。很明显我这100多个广告位请求要分好多批出发啊?

为什么要这么多的请求?

一开始的时候我也在问这个问题,毕竟在做单广告位之前,我好不容易写了一个基于页面的广告展示代码(一个页面只有一个请求,包含这个页面所有需要展示的广告数据)。那时候风和日丽、岁月静好、大错不出、小错不少。后台仅仅提供有数据的广告位,我将他们按照业务逻辑展示。但是后端前辈的鸡汤太好喝加之确实这段时间一直有一些问题解决不了,就是我们的广告后台只是将广告定位到了页面,而没有定位到具体的广告位;广告后台需要针对具体的广告位进行智能投放;后台需要对页面上的所有广告数据进行一次打包,就不得不在广告后台加入页面的概念,这完全是为了应对现有的模式,理想中广告投放后台应该专注于用户画像和针对资源(广告位)的服务,而前端也不该直接对广告位进行处理。这样两端都去掉页面这一层才是更好的选择,同时这也是业内普遍公认的处理办法——“单广告位请求”(智能广告的基石)。

出问题了——异步回调,啥时候干活

我们的广告逻辑要求一部分广告马上显示,这部分还好,回调就渲染;另一部分要求分好几批次展示,这我就要等这部分“贵族广告”都回来了在启动渲染。但是单广告位请求就不得不面临一个问题——丢包。如果发100个,回来99个,那我的99个还不展示了?这问题不难,相信你心中肯定有答案了,不就是设定一个“截至时间”吗,但是和下面问题混在一起就要多考虑一点了。

又出问题了——并发请求

既然没有选择原地踏步,而是勇敢前行,就要踩坑。第一个问题就是太慢,100多个好几批要很长时间才回来,我后续的广告渲染要等多久?时间长了,能保证都回来,但用户体验太差;时间太短,体验好了,但是100多个请求来不及回来。看来这个“截止时间”不好定。

最终业务方选择了用户体验,毕竟广告本就是异步渲染,在等要等多久啊!这样我就只有一条路了——“提速”,优化请求的耗时,能在截至时间内那会所有的请求。那么我们来看一下耗时由那些部分组成:

从上面来,网络不是我们能控制的、服务端也已经加上了两级缓存,看好像没有前端能优化的部分哈,但是这里仅仅是一个请求的耗时,100个旧不是这样了。100个请求并不是一口气都发出去,而是被浏览器限制住了。浏览器为了方式同一个域名下的并发请求过多,从而做了安全限制,一般允许同一域名同时发出6个请求,如果每一个请求的耗时固定,并且网络带宽正常,总的耗时应该取决于最后一个请求发出的时间:

50个

100个

通过demo我们可以看出50个请求总耗时391ms减去dom ready ,50个请求耗时 = 391 - 155 = 236ms;100个请求耗时 = 850 - 214 = 636ms

单一请求,我优化不了,但我可以减少最后一个请求的等待时间。那么等待时间是由什么决定的呢?等待时间是由同域并发请求限制造成的。虽然域名收敛时后续请求可以利用长链接来减少开销,感觉会“快一点”,但是浏览器限制了并发请求数。如果我们走另一条路(域名发散)呢?经过我的测试发散后单广告位的并发请求数又明显提高,50个广告位2个域名,总耗时=259 – 157 = 102ms 节约了134ms 减少56.7%。100个域名3个域名总耗时 = 428 - 256 = 172ms 节约了464ms 减少72.9%。当然这是理想环境下,优化率较高。观察上线效果,总耗时减少在30%-50%这个范围内。

50个

100个

怎么(利用域名发散)做的?

其实很简单,我们对同一个服务申请多个域名。换个名字,浏览器就分别限制了,两个域名不就并发12个了嘛!这样并发的多了,等待的就少了,自然最后一个请求的等待时间,就大幅减少。总耗时也就可控在用户体验上可接受的范围。

开发和测试的时候我们通过绑hosts的方式让服务器IP 有好几个“外号”,当然上线的时候还是要麻烦运维同事部署到公网环境。

是不是域名越发散(越多)越好?

当然不是的,我们刚才提到域名收敛有一个最大的好处就是:后续的请求可以利用第一次建立好的长链接来减小网络开销,从而“提速”。当我100个请求,10个域名,就要建立10次链接。开销也不小。我们在域名收敛和域名发散之间需要折中一下。当然我在实际开发中发现50个请求时4个域名就已经比3个的耗时长了,而且3个域名的总耗时不是很稳定。我最终决定根据广告位数量来判断使用几个域名。30个请求以下使用1个域名;70个请求以下使用2个域名;120以下使用3个域名。

总结:

实际工作中网站优化的机会不多,优化过静态请求的同学一定都知道合并静态资源。其背后正是“域名收敛”的思想。但是一般网站合并静态资源后,刨除内容图片资源懒加载的数量,往往js、css、精灵图的总量往往不会太多而且通过按需加载,往往不会产生如此大的并发请求。像单广告位请求这高并发的应用场景还是不多见,我们利用域名收敛、发散这样的一些基础理论却解决复杂棘手的问题。想来无论外界对前端价值褒贬不一,做前端开发还是挺有意思的。

全局精确流量调度新思路-HttpDNS服务详解

小编:对于互联网,域名是访问的第一跳,而这一跳很多时候会“失足”,导致访问错误内容,失败连接等,让我们在互联网上畅游的爽快瞬间消失,而对于这关键的第一跳,鹅厂也在持续深入研究和思考对策,今天小编就邀请了我们负责这块域名解析的好伙伴—廖伟健同学跟我们做一个分享。同时,今天小编也非常希望了解大伙对这块内容的感受,所以今天文中加入了投票功能,希望您投上神圣的一票哦。事不延迟,我们启程 !

但凡使用域名来给用户提供服务的互联网企业,都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。那么对于腾讯这样的域名数量在10万级别的互联网公司来讲,域名解析异常的情况到底有多严重呢?每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS进行探测,腾讯域名在全国各地的日解析异常量是已经超过了80万条。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通,但是由于各种原因,处理效率及效果均不能达到腾讯各业务部门的需求。除了和运营商进行沟通,有没有一种技术上的方案,能从根源上解决域名解析异常及用户访问跨网的问题呢?

一、问题根源:

要解决问题,我们得先得了解下现在国内各ISP的LocalDNS的基本情况。国内运营商LocalDNS造成的用户访问异常可以归为下三类:

1、域名缓存:

域名缓存很好理解,就是LocalDNS缓存了腾讯的域名的解析结果,不向腾讯权威DNS发起递归,示意图如下:

022251G8O.jpg

022251G8O.jpg

022251G8O.jpg

为何LocalDNS要把域名解析结果进行缓存呢?原因有以下几个:

(1)保证用户访问流量在本网内消化:国内的各互联网接入运营商的带宽资源、网间结算费用、IDC机房分布、网内ICP资源分布等存在较大差异。为了保证网内用户的访问质量,同时减少跨网结算,运营商在网内搭建了内容缓存服务器,通过把域名强行指向内容缓存服务器的IP地址,就实现了把本地本网流量完全留在了本地的目的。

(2)推送广告:有部分LocalDNS会把部分域名解析结果的所指向的内容缓存,并替换成第三方广告联盟的广告。

这种类型的行为就是我们常说的域名缓存,域名缓存会导致用户产生以下的访问异常:

A、仅对80端口的http服务做了缓存,如果域名是通过https协议或其它端口提供服务的,用户访问就会出现失败。比如支付服务、游戏通过指定端口连接connect server服务等。

B、缓存服务器的运维水平参差不齐,时有出现缓存服务器故障导致用户访问异常的问题。

2、解析转发:

除了域名缓存以外,运营商的LocalDNS还存在解析转发的现象。解析转发是指运营商自身不进行域名递归解析,而是把域名解析请求转发到其它运营商的递归DNS上的行为。正常的LocalDNS递归解析过程是这样的:

而部分小运营商为了节省资源,就直接将解析请求转发到了其它运营的递归LocalDNS上去了:

这样的直接后果就是腾讯权威DNS收到的域名解析请求的来源IP就成了其它运营商的IP,最终导致用户流量被导向了错误的IDC,用户访问变慢。

3、LocalDNS递归出口NAT:

LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归,但是因为在网络上存在多出口且配置了目标路由NAT,结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址:

这样的直接后果就是GSLB DNS收到的域名解析请求的来源IP还是成了其它运营商的IP,最终导致用户流量被导向了错误的IDC,用户访问变慢。

二、现有的解决方案及存在的问题:

运营商的LocalDNS解析域名异常,给对用户访问腾讯业务的体验造成了非常大的损害。那么我们是如何处理这些域名解析异常的问题的呢?

1、实时监控+商务推动:

这种方案是目前腾讯的运营团队一直在使用的方案。这种方案就是周期比较长,毕竟通过行政手段来推动运营商来解决这个问题是比较耗时的。另外我们通过大数据分析,得出的结论是Top 3的问题用户均为移动互联网用户。对于这部分用户,我们有什么技术手段可以解决以上的问题呢?

2、绕过自动分配DNS,使用114dns或Google public DNS:

这个方案看上去很美好,114dns是国内最大的中立缓存DNS,而Google又是秉承不作恶理念的互联网工程帝国巨鳄,而且腾讯的权威DNS又支持edns-client-subnet功能,能直接识别使用Google publicDNS解析腾讯域名的用户的IP地址,不会出现流量调度失效。但是问题来了:

(1)如何在用户侧构造域名请求:对于PC端的客户端来说,构造一个标准的DNS请求包并不算什么难事。但在移动端要向一个指定的LocalDNS上发送标准的DNS请求包,而且要兼容各种iOS和android的版本的话,技术上是可行的,只是兼容的成本会很高。

(2)推动用户修改配置极高:如果要推动用户手动修改PC的DNS配置的话,在PC端和手机客户端的WiFI下面还算勉强可行。但是要用户修改在移动互联网环境下的DNS配置,其难度不言而喻。

3、完全抛弃域名,自建connectcenter进行流量调度:

如果要采用这种这种方案的话,首先你就得要拿到一份准确的IP地址库来判断用户的归属,然后再制定个协议搭个connect center来做调度,然后再对接入层做调度改造。这种方案和2种方案一样,不是不能做,只是成本会比较高,尤其对于腾讯这种业务规模如此庞大的公司而言。

三、利用HttpDNS解决用户域名解析异常:

既然上面的方案都存在那么多的问题,那有没有一种调度精准、成本低廉、配置方便的基于域名的流量调度系统呢?答案是肯定的。腾讯公司的GSLB 团队推出了一种全新的域名解析调度系统:HttpDNS。HttpDNS是为移动客户端量身定做的基于Http协议和域名解析的流量调度解决方案,专治LocalDNS解析异常以及流量调度不准。详细介绍如下:

(1)HttpDNS基本原理:

HttpDNS的原理非常简单,主要有两步:

A、客户端直接访问HttpDNS接口,获取业务在域名配置管理系统上配置的访问延迟最优的IP。(基于容灾考虑,还是保留次选使用运营商LocalDNS解析域名的方式)

B、客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例,通过在header中指定host字段,向HttpDNS返回的IP发送标准的Http请求即可。

(2)HttpDNS优势:

从原理上来讲,HttpDNS只是将域名解析的协议由DNS协议换成了Http协议,并不复杂。但是这一微小的转换,却带来了无数的收益:

A、根治域名解析异常:由于绕过了运营商的LocalDNS,用户解析域名的请求通过Http协议直接透传到了腾讯的HttpDNS服务器IP上,用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。

B、调度精准:HttpDNS能直接获取到用户IP,通过结合腾讯自有专利技术生成的IP地址库以及测速系统,可以保证将用户引导的访问最快的IDC节点上。

C、实现成本低廉:接入HttpDNS的业务仅需要对客户端接入层做少量改造,无需用户手机进行root或越狱;而且由于Http协议请求构造非常简单,兼容各版本的移动操作系统更不成问题;另外HttpDNS的后端配置完全复用现有权威DNS配置,管理成本也非常低。总而言之,就是以最小的改造成本,解决了业务遭受域名解析异常的问题,并满足业务精确流量调度的需求。

D、扩展性强:HttpDNS提供可靠的域名解析服务,业务可将自有调度逻辑与HttpDNS返回结果结合,实现更精细化的流量调度。比如指定版本的客户端连接请求的IP地址,指定网络类型的用户连接指定的IP地址等。

当然各位可能会问:用户将首选的域名解析方式切换到了HttpDNS,那么HttpDNS的高可用又是如何保证的呢?另外不同运营商的用户访问到同一个HttpDNS的服务IP,用户的访问延迟如何保证?

为了保证高可用及提升用户体验,HttpDNS通过接入了腾讯公网交换平台的BGP Anycast网络,与全国多个主流运营商建立了BGP互联,保证了这些运营商的用户能够快速地访问到HttpDNS服务;另外HttpDNS在多个数据中心进行了部署,任意一个节点发生故障时均能无缝切换到备份节点,保证用户解析正常。

四、接入效果及未来展望:

当前HttpDNS已在腾讯内部接入了多个业务,覆盖数亿用户,并已持续稳定运行超过一年时间。而接入了HttpDNS的业务在用户访问体验方面都有了非常大的提升。以某个接入HttpDNS的业务为例,该业务仅通过接入HttpDNS,在未做任何其它优化的情况下,用户平均访问延迟下降超过10%,访问失败率下降了超过五分之一,用户访问体验的效果提升非常显著。另外腾讯的HttpDNS服务除了在腾讯内部被广泛使用以外,也受到了业务同行的肯定。国内最大的publicDNS服务商114dns在受到腾讯DNS的启发下,也推出了HttpDNS服务。

在未来的日子里,腾讯GSLB团队将会在腾讯内部进一步推广HttpDNS服务,并将在实际业务的需求下对HttpDNS服务进行升级,如提供更为通用、安全、简单的接入协议,进一步提升接入用户的网络访问体验等等。希望HttpDNS能为各位在解决域名解析异常及全局流量调度失效方面提供一个简单、可行的思路,也欢迎各位业界同行与腾讯一起,就如何进行更精准的全局流量调度方面进行更为深入的讨论!

http://119.29.29.29/

接入文档
https://www.dnspod.cn/httpdns/guide

DEMO
https://www.dnspod.cn/httpdns/demo

腾讯DNSPod公共DNS 119.29.29.29 体验报告

腾讯DNSPod推出新Open DNS服务,公共DNS是119.29.29.29

114DNS、Dnspod DNS、阿里DNS、百度DNS、360DNS、Google DNS公共DNS评测体验报告

114DNS、腾讯dnspod DNS、阿里DNS、百度DNS、360DNS、Google DNS公共DNS评测体验报告从ping及dig返回时间对比测试,国内DNS普遍很快,而阿里DNS最快,次之腾讯dnspod DNS,然后114DNS,百度及360DNS中规中矩,而Google DNS还是很慢,我们还是拥抱国产DNS吧,推荐腾讯DNSPOD DNS 119.29.29.29 阿里DNS 223.6.6.6、223.5.5.5

[root@localhost ~]# ping 114.114.114.114 -c 4;ping 119.29.29.29 -c 4;ping 223.6.6.6 -c 4;ping 180.76.76.76 -c 4;ping 101.226.4.6 -c 4;ping 8.8.8.8 -c 4

PING 114.114.114.114 (114.114.114.114) 56(84) bytes of data.
64 bytes from 114.114.114.114: icmp_seq=1 ttl=77 time=24.9 ms
64 bytes from 114.114.114.114: icmp_seq=2 ttl=95 time=26.5 ms
64 bytes from 114.114.114.114: icmp_seq=3 ttl=65 time=26.0 ms
64 bytes from 114.114.114.114: icmp_seq=4 ttl=76 time=26.4 ms

— 114.114.114.114 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3031ms
rtt min/avg/max/mdev = 24.919/25.990/26.536/0.671 ms
PING 119.29.29.29 (119.29.29.29) 56(84) bytes of data.
64 bytes from 119.29.29.29: icmp_seq=1 ttl=53 time=10.2 ms
64 bytes from 119.29.29.29: icmp_seq=2 ttl=53 time=15.3 ms
64 bytes from 119.29.29.29: icmp_seq=3 ttl=53 time=10.0 ms
64 bytes from 119.29.29.29: icmp_seq=4 ttl=53 time=9.68 ms

— 119.29.29.29 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3014ms
rtt min/avg/max/mdev = 9.684/11.345/15.391/2.345 ms
PING 223.6.6.6 (223.6.6.6) 56(84) bytes of data.
64 bytes from 223.6.6.6: icmp_seq=1 ttl=53 time=7.56 ms
64 bytes from 223.6.6.6: icmp_seq=2 ttl=53 time=8.45 ms
64 bytes from 223.6.6.6: icmp_seq=3 ttl=53 time=7.08 ms
64 bytes from 223.6.6.6: icmp_seq=4 ttl=53 time=6.69 ms

— 223.6.6.6 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 6.698/7.450/8.453/0.661 ms
PING 180.76.76.76 (180.76.76.76) 56(84) bytes of data.
64 bytes from 180.76.76.76: icmp_seq=1 ttl=54 time=36.7 ms
64 bytes from 180.76.76.76: icmp_seq=2 ttl=54 time=37.3 ms
64 bytes from 180.76.76.76: icmp_seq=3 ttl=54 time=36.5 ms
64 bytes from 180.76.76.76: icmp_seq=4 ttl=54 time=36.1 ms

— 180.76.76.76 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3041ms
rtt min/avg/max/mdev = 36.136/36.675/37.327/0.432 ms
PING 101.226.4.6 (101.226.4.6) 56(84) bytes of data.
64 bytes from 101.226.4.6: icmp_seq=1 ttl=55 time=30.5 ms
64 bytes from 101.226.4.6: icmp_seq=2 ttl=55 time=30.7 ms
64 bytes from 101.226.4.6: icmp_seq=3 ttl=55 time=28.4 ms
64 bytes from 101.226.4.6: icmp_seq=4 ttl=55 time=30.6 ms

— 101.226.4.6 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3035ms
rtt min/avg/max/mdev = 28.478/30.091/30.722/0.934 ms
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=39.6 ms

— 8.8.8.8 ping statistics —
4 packets transmitted, 1 received, 75% packet loss, time 4000ms
rtt min/avg/max/mdev = 39.617/39.617/39.617/0.000 ms
[root@localhost ~]# traceroute -n 114.114.114.114;traceroute -n 119.29.29.29;traceroute -n 223.6.6.6;traceroute -n 180.76.76.76;traceroute -n 101.226.4.6;traceroute -n 8.8.8.8
traceroute to 114.114.114.114 (114.114.114.114), 30 hops max, 60 byte packets
 1  192.168.1.100  0.470 ms  0.670 ms  0.886 ms
 2  100.64.0.1  6.717 ms  6.723 ms  10.996 ms
 3  183.56.68.41  6.734 ms  6.794 ms  6.844 ms
 4  183.56.64.161  7.278 ms  7.200 ms  7.313 ms
 5  183.56.65.38  10.736 ms  10.794 ms  10.733 ms
 6  202.97.64.77  33.088 ms  32.746 ms  32.487 ms
 7  218.2.134.2  32.125 ms  26.167 ms  26.070 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
traceroute to 119.29.29.29 (119.29.29.29), 30 hops max, 60 byte packets
 1  192.168.1.100  0.448 ms  0.654 ms  0.871 ms
 2  100.64.0.1  131.462 ms  131.469 ms  131.562 ms
 3  183.56.68.97  6.767 ms  6.779 ms  6.778 ms
 4  183.56.64.113  6.848 ms  6.902 ms  6.999 ms
 5  183.56.65.14  10.389 ms  10.449 ms  10.617 ms
 6  61.140.0.37  10.306 ms  10.130 ms  11.986 ms
 7  61.140.1.10  16.669 ms  10.706 ms  10.718 ms
 8  183.61.145.194  9.224 ms  10.416 ms  10.001 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
traceroute to 223.6.6.6 (223.6.6.6), 30 hops max, 60 byte packets
 1  192.168.1.100  0.462 ms  0.669 ms  0.890 ms
 2  14.127.64.1  13.381 ms  13.834 ms  14.015 ms
 3  113.106.43.229  7.094 ms  7.107 ms  7.198 ms
 4  119.136.12.158  7.109 ms  7.232 ms  7.284 ms
 5  183.56.66.2  10.394 ms 183.56.65.62  13.996 ms 183.56.65.74  8.326 ms
 6  119.147.221.10  7.730 ms 119.147.223.106  9.083 ms 119.147.221.130  11.309 ms
 7  119.147.220.238  12.315 ms  7.492 ms  7.509 ms
 8  * * 14.215.137.50  9.989 ms
 9  * 42.120.242.234  10.362 ms  10.063 ms
10  42.120.242.214  14.005 ms *  14.055 ms
11  42.120.253.10  6.657 ms * 42.120.253.2  8.375 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
traceroute to 180.76.76.76 (180.76.76.76), 30 hops max, 60 byte packets
 1  192.168.1.100  0.378 ms  0.581 ms  0.797 ms
 2  14.127.64.1  7.265 ms  7.344 ms  7.409 ms
 3  113.106.43.229  7.197 ms  7.313 ms  7.432 ms
 4  59.40.49.110  7.507 ms  7.563 ms  7.590 ms
 5  * * *
 6  202.97.65.101  42.138 ms  42.004 ms *
 7  * * *
 8  220.181.17.118  38.775 ms *  39.623 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
traceroute to 101.226.4.6 (101.226.4.6), 30 hops max, 60 byte packets
 1  192.168.1.100  0.495 ms  0.723 ms  0.882 ms
 2  100.64.0.1  6.797 ms  6.844 ms  6.984 ms
 3  183.56.68.41  6.885 ms  7.006 ms  7.060 ms
 4  183.56.64.153  7.126 ms  7.187 ms  7.235 ms
 5  183.56.65.2  11.666 ms  11.620 ms  11.698 ms
 6  61.152.86.209  34.800 ms  38.168 ms  34.288 ms
 7  * * *
 8  124.74.233.134  31.913 ms  31.789 ms  33.247 ms
 9  101.226.0.30  34.916 ms  33.804 ms  33.766 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.100  0.433 ms  0.649 ms  0.859 ms
 2  14.127.64.1  6.670 ms  6.890 ms  8.232 ms
 3  113.106.43.233  6.648 ms  8.238 ms  8.758 ms
 4  119.136.12.142  7.658 ms  8.177 ms  8.247 ms
 5  183.56.65.62  14.300 ms 183.56.65.54  10.677 ms 183.56.65.62  14.295 ms
 6  202.97.35.210  15.390 ms  15.077 ms  15.025 ms
 7  202.97.60.70  11.663 ms 202.97.91.178  10.466 ms 202.97.60.70  10.198 ms
 8  202.97.61.22  11.875 ms  14.665 ms  14.108 ms
 9  202.97.62.214  11.413 ms  11.453 ms  12.505 ms
10  209.85.241.58  15.582 ms  13.576 ms 209.85.241.56  23.106 ms
11  216.239.40.13  11.598 ms 216.239.40.11  13.685 ms  12.834 ms
12  209.85.253.89  38.926 ms  38.903 ms  37.668 ms
13  64.233.175.205  44.340 ms 209.85.250.103  39.732 ms  39.431 ms
14  * * *
15  8.8.8.8  40.948 ms  41.787 ms  41.446 ms

腾讯DNSPod公共DNS 119.29.29.29 体验报告

上周看到DNSPod官网正式推出了公共DNS服务,并且号称是国内第一家支持ECS协议的公共DNS,于是抓紧时间体验了下。(其实很久之前就听闻DNSPod有搞公共DNS的动作,不知道为什么一直没有正式对外推广,后来看了服务介绍,个人猜测可能就是为了等Google的ECS协议才拖到现在发布吧。)Anyway,随着代表腾讯的DNSPod加入,现在BAT三家的公共DNS服务算是全部集齐!

DNSPod的公共DNS服务(又称“Public DNS+”)IP是119.29.29.29,和他家之前推出的移动解析“D+”是一样的,目测后端应该是同一套架构。(再吐个槽,怎么现在都喜欢在名字后面搞个+号呢?DNSPod之前出了httpdns叫D+,现在搞公共DNS,又叫Public DNS+,是为了响应“互联网+”号召么?)

言归正传!我特意找了国内外几家知名的公共DNS对比测试,它们是:

114dns: 114.114.114.114

阿里: 223.5.5.5.5

百度: 180.76.76.76

360: 101.226.4.6

Google: 8.8.8.8

从宣传资料来看,各家卖点都差不多,基本都是快速、准确、稳定、无劫持等等。下面就以这些方面做考量,用实际数据说话吧。

1、快速

关于DNS的持续测试工具,我简单选用ping测试。通过测试ping来测试延时,也可以反映DNS的解析延时。

1-1 从全国各地的3大运营商进行ping测试,测试结果如下:


MLUIX6PJUQIA.jpg

如上图,可以清晰地看到Google的公共DNS平均时延极高,达到了174.495ms。果然从大陆访问Google远在台湾的服务器,速度还是太慢了!

1-2 以下是去掉Google后,国内几家公共DNS的延时表现:


XK20PE1RG217.jpg

DNSPod的公共DNS延时最低,为35ms;其次是百度的38.503ms和114的40.195ms;阿里的公共DNS延时最高,达到了41.246ms,仍需努力呀!

【结论】 在国内,本土4家公共DNS的速度远远快于国外的Google。其中DNSPod最快,但与国内其他公共DNS差距不算大。至于360,连Anycast都没有,直接懒测out!

2、准确

如果运营商没有各种劫持和NAT的话,毫无疑问运营商的递归DNS应该是最准确的,但事实往往事与愿违,也是因为这样,我们不得不使用公共DNS,因此公共DNS的准确度,是重要的考虑因素。

理论来讲,如果公共DNS能支持Google的ECS协议,直接把用户的IP信息透传到授权DNS,授权DNS根据用户的IP而不是递归的IP来进行智能解析,这样就可以保证解析的准确度了。但是据了解,目前除了国外的Google和Open DNS支持ECS以外,国内之前的公共DNS都没有支持,DNSPod算是第一家。

个人认为主要原因应该是支持ECS的技术难度太高:需要每个域名、每个线路、每个IP段单独缓存,缓存量实在是太大了,而如果不缓存速度又太慢。技术投入大,而实际收益不高,应该是国内其他公共DNS对ECS望而却步的原因。

2.1 各家公共DNS对ECS协议的支持情况:


0Z95VQ26D7CZ.jpg

经过实际测试发现,DNSPod的公共DNS确实如它宣传的一致,是支持了ECS的!并且支持程度和Google一样,在接入端和后端都支持ECS。这确实是个惊喜!以后终于可以用着国内的公共DNS,享受快速解析的同时也不牺牲解析准确度了。

另外,国内其他4家中,只有阿里的公共DNS在接入端是支持ECS。但说实话,单单在接入端支持ECS对用户解析准确度的提升并没有实质性的帮助,还是和使用用户实际IP一样依赖后端递归DNS的分布情况,只是可以方便用户对解析准确度进行测试而已。所以像Open DNS的接入端都没有支持ECS,只是后端支持。

又有问题来了,当用户解析域名的授权DNS不支持ECS时,只有公共DNS支持ECS也没用啊。这时候怎么办呢?那就只有靠公共DNS的后端节点部署情况来提升解析准确度了。

在更多省份的运营商部署更多的递归DNS节点,就可以根据用户DNS请求中的IP分配到对应的节点去。当某个省份运营商没有递归DNS节点时,只能将请求分配到邻近省份同运营商的递归节点上,解析准确度会受到一定影响。简单来讲,就是“节点越多,解析越准确!”。

从各家公共DNS的官网上看了下后端递归DNS节点的部署情况,发现DNSPod的节点部署竟然也是最多的!

2.1 各家公共DNS节点情况:


71WJQ5SSS03E.jpg

如上,在国内几家公共DNS中,DNSPod的公共DNS无论是总结点数还是国外节点数,都比其他家高得多。(百度的节点数没公布,不知道有多少个。Google没有国内节点,测试了下国内用户的DNS查询请求,是路由到了台湾的解析服务器。)

【结论】DNSPod的公共DNS在接入端和后端都支持ECS协议,准确度等同Google,速度又比Google快。另外DNSPod密集的节点部署,进一步保证了解析准确度,Public DNS+确实值得推荐!为良心产品点赞!

3、稳定

因为无法知道各家公共DNS的具体架构,所以我用dig测试和ping测试丢包率来看下各家公共DNS服务的稳定性(未测试360)。

dig测试来看,BAT和114都部署了多个国内接入节点,且每个接入节点都是多台服务器组成的集群,都用同一个IP使用BGP Anycast接入,不管是单服务器故障还是单节点故障,都可以快速切换,稳定性上应该是都有保障的。Google的话,因为国内没有服务器且经常受到防护墙的干扰,稳定性欠佳。

3-1 ping测试的丢包率,各家公共DNS结果如下:


49SR5WM72GVP.jpg

从ping测试的丢包率来看,国内各家公共DNS丢包率都差不多,DNSPod、阿里、114的丢包率都在1%左右,百度丢包略高为2.286%。

Google的结果就惨多了,半夜之后好点在30%左右,白天和上半夜在70%左右,整体丢包率为50%左右,纵是真爱也真心不敢推荐使用。

【结论】 DNSPod、阿里、114和百度4家的公共DNS服务,在稳定性没有看出明显差别,大家都可以放心使用。

4、无劫持

所有公共DNS都宣称自己无劫持,这个功能不太好测试,但是实际使用中确实没发现明显的恶意劫持,就算都过关吧。

以上就是我对市场上几家主流公共DNS服务进行的实际体验报告。最终发现新出的“Public DNS+”(腾讯DNSPod的公共DNS)确实不错,无论速度、准确度、稳定性都可圈可点,与其他家相比都不逊色甚至略强。感兴趣的不妨把DNS改为119.29.29.29试试吧。

腾讯DNSPod推出新Open DNS服务,公共DNS是119.29.29.29

9月7日消息,近日,腾讯旗下DNSPod正式推出了类似google open dns服务,公共域名解析服务Public DNS+,使用同一个服务IP 119.29.29.29,号称安全零劫持。

DNS劫持是一种通过改变指定域名在运营商侧DNS配置的正确解析指向,将该域名的解析结果重定向到劫持IP的劫持行为。DNS劫持类型可大致分为运营商缓存,广告,恶意劫持等类别。

DNSPod推出的Public DNS+服务号称有安全零劫持、准确不丢包、快速无等待、稳定多容灾的优势。

DNSPod建立于2006年3月份,是中国第一大DNS解析服务提供商、第一大域名托管商,2011年8月8日被腾讯收购,收购完成后,DNSPod保持独立运营。

国内外几家知名的公共DNS:

114dns: 114.114.114.114

阿里: 223.5.5.5.5

百度: 180.76.76.76

360: 101.226.4.6

Google: 8.8.8.8

我们就测试一下这些dns dig的速度如何:

360DNS 101.226.4.6 dig测试
# dig @101.226.4.6 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @101.226.4.6 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23722
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com.                      IN      A
;; ANSWER SECTION:
v.qq.com.               331     IN      CNAME   v.tc.qq.com.
v.tc.qq.com.            3165    IN      CNAME   v.tcdn.qq.com.
v.tcdn.qq.com.          60      IN      CNAME   p21.tcdn.qq.com.
p21.tcdn.qq.com.        161     IN      A       119.147.253.22
p21.tcdn.qq.com.        161     IN      A       119.147.33.32
p21.tcdn.qq.com.        161     IN      A       119.147.253.21
p21.tcdn.qq.com.        161     IN      A       119.147.33.28
p21.tcdn.qq.com.        161     IN      A       119.147.253.20
p21.tcdn.qq.com.        161     IN      A       113.107.238.22
p21.tcdn.qq.com.        161     IN      A       119.147.33.29
p21.tcdn.qq.com.        161     IN      A       119.147.33.31
p21.tcdn.qq.com.        161     IN      A       119.147.33.30
p21.tcdn.qq.com.        161     IN      A       59.57.18.147
;; Query time: 31 msec
;; SERVER: 101.226.4.6#53(101.226.4.6)
;; WHEN: Wed Dec  2 11:50:05 2015
;; MSG SIZE  rcvd: 244

百度DNSdig测试180.76.76.76
# dig @180.76.76.76 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @180.76.76.76 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54787
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com.                      IN      A
;; ANSWER SECTION:
v.qq.com.               488     IN      CNAME   v.tc.qq.com.
v.tc.qq.com.            856     IN      CNAME   v.tcdn.qq.com.
v.tcdn.qq.com.          315     IN      CNAME   p21.tcdn.qq.com.
p21.tcdn.qq.com.        319     IN      A       119.147.33.30
p21.tcdn.qq.com.        319     IN      A       119.147.253.21
p21.tcdn.qq.com.        319     IN      A       119.147.33.29
p21.tcdn.qq.com.        319     IN      A       119.147.33.28
p21.tcdn.qq.com.        319     IN      A       119.147.33.31
p21.tcdn.qq.com.        319     IN      A       119.147.253.22
p21.tcdn.qq.com.        319     IN      A       59.57.18.147
p21.tcdn.qq.com.        319     IN      A       119.147.253.20
p21.tcdn.qq.com.        319     IN      A       113.107.238.22
p21.tcdn.qq.com.        319     IN      A       119.147.33.32
;; Query time: 38 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)
;; WHEN: Wed Dec  2 11:49:34 2015
;; MSG SIZE  rcvd: 244

阿里Open DNS公共DNSdig测试: 223.5.5.5.5
# dig @223.6.6.6 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @223.6.6.6 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55386
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com.                      IN      A
;; ANSWER SECTION:
v.qq.com.               235     IN      CNAME   v.tc.qq.com.
v.tc.qq.com.            235     IN      CNAME   v.tcdn.qq.com.
v.tcdn.qq.com.          235     IN      CNAME   p21.tcdn.qq.com.
p21.tcdn.qq.com.        235     IN      A       119.147.253.20
p21.tcdn.qq.com.        235     IN      A       113.107.238.22
p21.tcdn.qq.com.        235     IN      A       119.147.33.30
p21.tcdn.qq.com.        235     IN      A       59.57.18.147
p21.tcdn.qq.com.        235     IN      A       119.147.33.32
p21.tcdn.qq.com.        235     IN      A       119.147.33.28
p21.tcdn.qq.com.        235     IN      A       119.147.33.29
p21.tcdn.qq.com.        235     IN      A       119.147.253.22
p21.tcdn.qq.com.        235     IN      A       119.147.253.21
p21.tcdn.qq.com.        235     IN      A       119.147.33.31
;; Query time: 5 msec
;; SERVER: 223.6.6.6#53(223.6.6.6)
;; WHEN: Wed Dec  2 11:48:56 2015
;; MSG SIZE  rcvd: 244

腾讯Dnspod openDNS 公共DNS dig测试 119.29.29.29
# dig @119.29.29.29 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @119.29.29.29 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63125
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com.                      IN      A
;; ANSWER SECTION:
v.qq.com.               169     IN      CNAME   v.tc.qq.com.
v.tc.qq.com.            3169    IN      CNAME   v.tcdn.qq.com.
v.tcdn.qq.com.          169     IN      CNAME   p21.tcdn.qq.com.
p21.tcdn.qq.com.        169     IN      A       119.147.33.32
p21.tcdn.qq.com.        169     IN      A       119.147.253.21
p21.tcdn.qq.com.        169     IN      A       113.107.238.22
p21.tcdn.qq.com.        169     IN      A       119.147.33.30
p21.tcdn.qq.com.        169     IN      A       119.147.33.29
p21.tcdn.qq.com.        169     IN      A       59.57.18.147
p21.tcdn.qq.com.        169     IN      A       119.147.33.31
p21.tcdn.qq.com.        169     IN      A       119.147.33.28
p21.tcdn.qq.com.        169     IN      A       119.147.253.20
p21.tcdn.qq.com.        169     IN      A       119.147.253.22
;; Query time: 12 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Wed Dec  2 11:47:43 2015
;; MSG SIZE  rcvd: 244

114dns公共DNS dig测试: 114.114.114.114
# dig @114.114.114.114 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @114.114.114.114 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35456
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com.                      IN      A
;; ANSWER SECTION:
v.qq.com.               172     IN      CNAME   v.tc.qq.com.
v.tc.qq.com.            2611    IN      CNAME   v.tcdn.qq.com.
v.tcdn.qq.com.          539     IN      CNAME   p21.tcdn.qq.com.
p21.tcdn.qq.com.        262     IN      A       113.107.238.22
p21.tcdn.qq.com.        262     IN      A       119.147.33.30
p21.tcdn.qq.com.        262     IN      A       119.147.33.29
p21.tcdn.qq.com.        262     IN      A       119.147.33.31
p21.tcdn.qq.com.        262     IN      A       119.147.33.32
p21.tcdn.qq.com.        262     IN      A       119.147.253.20
p21.tcdn.qq.com.        262     IN      A       119.147.33.28
p21.tcdn.qq.com.        262     IN      A       119.147.253.22
p21.tcdn.qq.com.        262     IN      A       119.147.253.21
p21.tcdn.qq.com.        262     IN      A       59.57.18.147
;; Query time: 27 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Wed Dec  2 11:48:44 2015
;; MSG SIZE  rcvd: 244

使用国外 DNS 造成国内网站访问慢的解决方法

你是否是一个使用国外 DNS 的中国网民?你是否发现使用国外 DNS 之后访问某些国内网站奇慢无比?这不是 DNS 慢,而是电信到联通的线路太慢。如果你愿意小小地折腾一下,那么跟随本文,你可以解决这一问题。

一、为什么要用国外 DNS

由于众所周知的问题,国内 DNS 服务器解析国外网站会遭到 DNS 污染和投毒,使之解析到完全虚构的 IP 上,造成「开了 VPN 也没法访问 Twitter 或 Facebook」等问题。以下是一个例子:

	
  1. wzyboy@vermilion:~$ dig twitter.com @8.8.8.8 +short

  2. 199.59.148.82

  3. 199.59.149.230

  4. 199.59.148.10

  5. wzyboy@vermilion:~$ dig twitter.com @221.228.255.1 +short

  6. 93.46.8.89

Twitter 正确的 IP 地址应该是 199.59.148.0/24 里的那几个,但是如果用 221.228.255.1 这台中国电信的 DNS 服务器查询,查到的就是不知道什么鬼地址了,地理信息是在意大利,乱七八糟的。正是因为这样的 DNS 解析不正确的情况出现,不少人转而使用了国外的 DNS 服务器,如老牌的 OpenDNS 以及这几年新崛起的好记又好用的 Google Pulic DNS 即 8.8.8.8 和 8.8.4.4。使用它们进行查询,再配合以 VPN 或者浏览器的远程 DNS 解析,便可避免 DNS 污染的情况出现,从而解析出正确的地址。

此外,拒绝使用电信的 DNS 服务器,还可以避免烦人的「114 上网导航」页面……

二、为什么使用国外 DNS 会「慢」

我是在「慢」上加了引号的,因为这其实不是国外 DNS 慢,而是你要访问的网站的 CDN 分配错误,慢。由于国内各大运营商之间的主干线路带宽太窄,所以导致「最远的距离是从电信到联通」,电信用户访问联通的服务器非常慢,联通用户访问电信的服务器也非常慢,相信这都是大家有体验的。因此,国内不少网站都用了双线 CDN,在电信的机房里放点服务器,再在联通的机房里放点服务器。运用智能 DNS 技术,当你访问网站的时候,DNS 根据你的来源 IP 判断你是电信用户还是联通用户,然后再返回相应的 IP 地址,这样你会访问到就近的、同运营商的服务器,访问速度就大大提升了。而如果使用国外的 DNS 的话,你的查询来源来自国外,国内网站的 DNS 无法判断你是电信用户还是联通用户,就胡乱分配你一个服务器。比如我是一个江苏电信的用户,但当我访问淘宝网的时候,淘宝的 DNS 把我解析到青岛联通的服务器上,奇慢无比。所以:

很多人认为 Google Public DNS, OpenDNS 等「慢」,主要不是查询慢,而是电信到联通之间太慢。

当然了,如果硬要比较查询的话,倒也是会慢很少一点的:

	
  1. ;; 使用 8.8.8.8 解析 www.google.com 耗时 79 毫秒

  2. ;; Query time: 79 msec

  3. ;; SERVER: 8.8.8.8#53(8.8.8.8)

  4. ;; WHEN: Thu Sep 6 17:20:37 2012

  5. ;; MSG SIZE rcvd: 143

  6. ;; 使用中国电信 221.228.255.1 服务器解析 www.google.com 耗时 6 毫秒

  7. ;; Query time: 6 msec

  8. ;; SERVER: 221.228.255.1#53(221.228.255.1)

  9. ;; WHEN: Thu Sep 6 17:20:44 2012

  10. ;; MSG SIZE rcvd: 284

别看 6 毫秒和 79 毫秒差别很大的样子,但是人类是很难感觉出来的,而且,这只是查询时间,与实际的访问速度无关,就算你一整天都在刷 www.google.com,也就每小时慢个几百毫秒的样子,根本感觉不出来。真正慢的原因,还是上文所说的「电信到联通」的问题。

三、问题的解决思路

现在问题明确了:使用国外 DNS 之后,查询来源变成国外的 IP,使用了 CDN 加速的国内网站的 DNS 会无法判断你的来源,胡乱给你分配一个地址,如果不是同一个运营商的,访问速度便会很慢。

那解决方案也就出现了:让国内网站的 DNS 服务器知晓你的来源,从而给你分配正确的服务器 IP。于是 Google 起草了一个专有协议,叫 EDNS,在 DNS 查询请求中包含源地址,这样淘宝就知道查询来源不是 Google 服务器,而是电信的某用户,就不会把你扔到联通服务器上了 。听起来很美好是吧?不过这个协议不开放,目前几乎没有人用,所以,问题丝毫没有解决。

新思路是:访问那些会因 CDN 加速解析错误而极其缓慢国内网站的时候,直接向国内的服务器发送请求,让 DNS 知晓你的来源,给你分配个正确的 IP。访问其他网站的时候,再通过国外的 DNS 查询。

听起来很简单的样子,实现起来也不难:用 dnsmasq 在本地搭个 DNS 缓存服务器,规定哪些域名用哪个服务器查就好了。

四、安装及配置 dnsmasq

安装 dnsmasq

dnsmasq 是一个非常轻量的 DNS 缓存及 DHCP 服务器,在我的 Arch Linux 上只占用了 368 KiB 的磁盘空间,相比功能极其强大的 BIND9 来说小多了(BIND9 的安装体积是 6.23 MiB)。不光是体积小,它的功能也很专一,配置起来也是十分方便的,五分钟就可以搞定。

Ubuntu 12.04 及之后的版本应该自带了 dnsmasq。如果没有,可以使用 sudo apt-get install dnsmasq 安装。Arch Linux 直接 sudo pacman -S dnsmasq 即可。我的笔记本电脑需要给手机 DHCP 及 IP 转发用,因此早就安装了 dnsmasq,但是直到今天才想起这么用它……

配置 dnsmasq

dnsmasq 的各参数可以通过 man dnsmasq 查看,配置文件中也有许多清晰明了的注释。默认的配置文件位于 /etc/dnsmasq.conf,打开它,可以更改这几个地方:

	
  1. no-resolv

  2. no-poll

  3. server=8.8.8.8

  4. server=8.8.4.4

  5. server=/cn/114.114.114.114

  6. server=/taobao.com/114.114.114.114

  7. server=/taobaocdn.com/114.114.114.114

  8. server=/tbcache.com/114.114.114.114

  9. server=/tdimg.com/114.114.114.114

第一行的 no-resolv 和第二行的 no-pull 让 dnsmasq 不要通过 /etc/resolv.conf 确定上游服务器,也不要检测 /etc/resolv.conf 的变化(因为我们就是要拿本机当服务器嘛),接下来两行指定 dnsmasq 默认查询的上游服务器,此处以 Google Public DNS 为例,喜欢用 OpenDNS 的也可以改 OpenDNS。接下来就是规定一张名单了,把一些国内网站的域名写在这里即可。比如server=/cn/114.114.114.114 便是把所有 .cn 的域名全部通过 114.114.114.114 这台国内 DNS 服务器来解析,你也可以改成其他的国内 DNS 比如你的运营商提供的 DNS。接下来四行是淘宝的几个域名,让它们也通过国内的 DNS 服务器解析。

这样分流操作之后,默认所有域名都通过 8.8.8.8 和 8.8.4.4 解析,但是所有的 .cn 域名以及淘宝的域名通过 114.114.114.114 这台国内 DNS 服务器解析。当然,除了淘宝网,你也可以添加更多的域名,根据自己的喜好,把经常访问,但是使用国外服务器解析到很慢的服务器上的网站域名都可以添加进去,不过:如果这个网站本身就只能一台服务器,没有 CDN 加速,那再怎么添加也是无济于事的,得让网站管理员去买双线机房……另外,在写这篇文章的时候,发现 @felixonmars 维护了一张国内常用的、但是通过国外 DNS 会解析错误的网站域名的列表,据他所说,这是他在公司里部署这一套东西之后,公司里其他人报怨「慢」的网站域名收集来的,应该囊括了绝大多数有此问题的网站,值得依赖,欢迎选用。如果觉得直接把这么多域名加在 /etc/dnsmasq.conf 里不爽的话,可以在 dnsmasq.conf 里把 conf-dir=/etc/dnsmasq.d 这一行取消注释,然后把在 /etc/dnsmasq.d 里弄点列表。比如我就是把 @felixonmars 维护的列表放在/etc/dnsmasq.d/server.china.conf 里。

配置好之后,保存,Ubuntu 可用 sudo service dnsmasq restart,Arch Linux 可用 sudo rc.d restart dnsmasq 重启 dnsmasq。如果没有错误的话,这时本地的 dnsmasq 已经跑起来了。

测试 dnsmasq

测试一下:

	
  1. wzyboy@vermilion:~$ dig www.taobao.com @8.8.8.8 +short

  2. www.gslb.taobao.com.danuoyi.tbcache.com.

  3. scorpio.danuoyi.tbcache.com.

  4. 119.167.195.251 → 这是淘宝的青岛联通的服务器,我用江苏电信连奇慢无比

  5. 119.167.195.241 → 这也是青岛联通

  6. wzyboy@vermilion:~$ dig www.taobao.com @127.0.0.1 +short

  7. www.gslb.taobao.com.danuoyi.tbcache.com.

  8. scorpio.danuoyi.tbcache.com.

  9. 222.186.49.251 → 解析到常州电信了,快!

  10. 61.155.221.241 → 这是上海电信

  11. wzyboy@vermilion:~$ dig twitter.com @127.0.0.1 +short

  12. 199.59.150.7 → Twitter 还是用 8.8.8.8 解析的,所以解析出来是未经污染的正确地址

  13. 199.59.148.82

  14. 199.59.149.230

效果很明显,这时可以把本地的 DNS 设为 127.0.0.1 了。大部分 Linux 用户直接更改 /etc/resolv.conf 的内容为:

	
  1. nameserver 127.0.0.1

即可。Ubuntu 12.04 及以后的用户,可能需要对 resolv.conf 做一些手脚,具体参考这里。如果不愿意改的话,可能每次联网都要手工改一次 resolv.conf,或者在 NetworkManager 中手工指定 127.0.0.1 为 DNS。DHCP 用户的话,可以通过 /etc/resolv.conf.head 之类的文件来保证 127.0.0.1 在第一行。

这样配置完之后,如果你没有在 dnsmasq 里限定查询 IP,那么你的家人、朋友们也是可以把你的电脑作为 DNS 服务器的。如果你本地是 VPN 全局翻墙的话,需要把你选择的国内 DNS 服务器通过路由表加入直连的范围内。当然,已经使用 chnroutes 的就不需要了。

DNS攻击原理及防范方法

随着网络的逐步普及,网络安全已成为INTERNET路上事实上的焦点,它关系着INTERNET的进一步发展和普及,甚至关系着INTERNET的生存。可喜的是我们那些互联网专家们并没有令广大INTERNET用户失望,网络安全技术也不断出现,使广大网民和企业有了更多的放心,下面就网络安全中的主要技术作一简介,希望能为网民和企业在网络安全方面提供一个网络安全方案参考。

DNS的工作原理

DNS分为Client和Server,Client扮演发问的角色,也就是问Server一个Domain Name,而Server必须要回答此Domain Name的真正IP地址。而当地的DNS先会查自己的资料库。如果自己的资料库没有,则会往该DNS上所设的的DNS询问,依此得到答案之后,将收到的答案存起来,并回答客户。

DNS服务器会根据不同的授权区(Zone),记录所属该网域下的各名称资料,这个资料包括网域下的次网域名称及主机名称。

在每一个名称服务器中都有一个快取缓存区(<a href=”http://www.it892.com/baike/wiki/%E9%AB%98%E9%80%9F%E7%BC%93%E5%86%B2%3Ca%20href=” http:=”” www.it892.com=”” baike=”” wiki=”” 存储器’=”” target=”_blank” style=”color: rgb(0, 96, 192); text-decoration: none;”>存储器’ target=’_blank’>Cache),这个快取缓存区的主要目的是将该名称服务器所查询出来的名称及相对的IP地址记录在快取缓存区中,这样当下一次还有另外一个客户端到次服务器上去查询相同的名称 时,服务器就不用在到别台主机上去寻找,而直接可以从缓存区中找到该笔名称记录资料,传回给客户端,加速客户端对名称查询的速度。例如:

当DNS客户端向指定的DNS服务器查询网际网路上的某一台主机名称 DNS服务器会在该资料库中找寻用户所指定的名称 如果没有,该服务器会先在自己的快取缓存区中查询有无该笔纪录,如果找到该笔名称记录后,会从DNS服务器直接将所对应到的IP地址传回给客户端 ,如果名称服务器在资料记录查不到且快取缓存区中也没有时,服务器首先会才会向别的名称服务器查询所要的名称。例如:

DNS客户端向指定的DNS服务器查询网际网路上某台主机名称,当DNS服务器在该资料记录找不到用户所指定的名称时,会转向该服务器的快取缓存区找寻是否有该资料 ,当快取缓存区也找不到时,会向最接近的名称服务器去要求帮忙找寻该名称的IP地址 ,在另一台服务器上也有相同的动作的查询,当查询到后会回复原本要求查询的服务器,该DNS服务器在接收到另一台DNS服务器查询的结果后,先将所查询到的主机名称及对应IP地址记录到快取缓存区中 ,最后在将所查询到的结果回复给客户端



常见的DNS攻击包括:

1) 域名劫持

通过采用黑客手段控制了域名管理密码和域名管理邮箱,然后将该域名的NS纪录指向到黑客可以控制的DNS服务器,然后通过在该DNS服务器上添加相应域名纪录,从而使网民访问该域名时,进入了黑客所指向的内容。

这显然是DNS服务提供商的责任,用户束手无策。

2) 缓存投毒

利用控制DNS缓存服务器,把原本准备访问某网站的用户在不知不觉中带到黑客指向的其他网站上。其实现方式有多种,比如可以通过利用网民ISP端的DNS缓存服务器的漏洞进行攻击或控制,从而改变该ISP内的用户访问域名的响应结果;或者,黑客通过利用用户权威域名服务器上的漏洞,如当用户权威域名服务器同时可以被当作缓存服务器使用,黑客可以实现缓存投毒,将错误的域名纪录存入缓存中,从而使所有使用该缓存服务器的用户得到错误的DNS解析结果。

最近发现的DNS重大缺陷,就是这种方式的。只所以说是“重大”缺陷,据报道是因为是协议自身的设计实现问题造成的,几乎所有的DNS软件都存在这样的问题。

3)DDOS攻击

一种攻击针对DNS服务器软件本身,通常利用BIND软件程序中的漏洞,导致DNS服务器崩溃或拒绝服务;另一种攻击的目标不是DNS服务器,而是利用DNS服务器作为中间的“攻击放大器”,去攻击其它互联网上的主机,导致被攻击主机拒绝服务。

4) DNS欺骗

DNS欺骗就是攻击者冒充域名服务器的一种欺骗行为。

原理:如果可以冒充域名服务器,然后把查询的IP地址设为攻击者的IP地址,这样的话,用户上网就只能看到攻击者的主页,而不是用户想要取得的网站的主页了,这就是DNS欺骗的基本原理。DNS欺骗其实并不是真的“黑掉”了对方的网站,而是冒名顶替、招摇撞骗罢了。

现在的Internet上存在的DNS服务器有绝大多数都是用bind来架设的,使用的bind版本主要为bind 4.9.5+P1以前版本和bind 8.2.2-P5以前版本.这些bind有个共同的特点,就是BIND会缓存(Cache)所有已经查询过的结果,这个问题就引起了下面的几个问题的存在.

DNS欺骗

在DNS的缓存还没有过期之前,如果在DNS的缓存中已经存在的记录,一旦有客户查询,DNS服务器将会直接返回缓存中的记录

防止DNS被攻击的若干防范性措施

互联网上的DNS放大攻击(DNS amplification attacks)急剧增长。这种攻击是一种数据包的大量变体能够产生针对一个目标的大量的虚假的通讯。这种虚假通讯的数量有多大?每秒钟达数GB,足以阻止任何人进入互联网。

与老式的“smurf attacks”攻击非常相似,DNS放大攻击使用针对无辜的第三方的欺骗性的数据包来放大通讯量,其目的是耗尽受害者的全部带宽。但是,“smurf attacks”攻击是向一个网络广播地址发送数据包以达到放大通讯的目的。DNS放大攻击不包括广播地址。相反,这种攻击向互联网上的一系列无辜的第三方DNS服务器发送小的和欺骗性的询问信息。这些DNS服务器随后将向表面上是提出查询的那台服务器发回大量的回复,导致通讯量的放大并且最终把攻击目标淹没。因为DNS是以无状态的UDP数据包为基础的,采取这种欺骗方式是司空见惯的。

这种攻击主要依靠对DNS实施60个字节左右的查询,回复最多可达512个字节,从而使通讯量放大8.5倍。这对于攻击者来说是不错的,但是,仍没有达到攻击者希望得到了淹没的水平。最近,攻击者采用了一些更新的技术把目前的DNS放大攻击提高了好几倍。

当前许多DNS服务器支持EDNS。EDNS是DNS的一套扩大机制,RFC 2671对次有介绍。一些选择能够让DNS回复超过512字节并且仍然使用UDP,如果要求者指出它能够处理这样大的DNS查询的话。攻击者已经利用这种方法产生了大量的通讯。通过发送一个60个字节的查询来获取一个大约4000个字节的记录,攻击者能够把通讯量放大66倍。一些这种性质的攻击已经产生了每秒钟许多GB的通讯量,对于某些目标的攻击甚至超过了每秒钟10GB的通讯量。

要实现这种攻击,攻击者首先要找到几台代表互联网上的某个人实施循环查询工作的第三方DNS服务器(大多数DNS服务器都有这种设置)。由于支持循环查询,攻击者可以向一台DNS服务器发送一个查询,这台DNS服务器随后把这个查询(以循环的方式)发送给攻击者选择的一台DNS服务器。接下来,攻击者向这些服务器发送一个DNS记录查询,这个记录是攻击者在自己的DNS服务器上控制的。由于这些服务器被设置为循环查询,这些第三方服务器就向攻击者发回这些请求。攻击者在DNS服务器上存储了一个4000个字节的文本用于进行这种DNS放大攻击。

现在,由于攻击者已经向第三方DNS服务器的缓存中加入了大量的记录,攻击者接下来向这些服务器发送DNS查询信息(带有启用大量回复的EDNS选项),并采取欺骗手段让那些DNS服务器认为这个查询信息是从攻击者希望攻击的那个IP地址发出来的。这些第三方DNS服务器于是就用这个4000个字节的文本记录进行回复,用大量的UDP数据包淹没受害者。攻击者向第三方DNS服务器发出数百万小的和欺骗性的查询信息,这些DNS服务器将用大量的DNS回复数据包淹没那个受害者。

如何防御这种大规模攻击呢?首先,保证你拥有足够的带宽承受小规模的洪水般的攻击。一个单一的T1线路对于重要的互联网连接是不够的,因为任何恶意的脚本少年都可以消耗掉你的带宽。如果你的连接不是执行重要任务的,一条T1线路就够了。否则,你就需要更多的带宽以便承受小规模的洪水般的攻击。不过,几乎任何人都无法承受每秒钟数GB的DNS放大攻击。

因此,你要保证手边有能够与你的ISP随时取得联系的应急电话号码。这样,一旦发生这种攻击,你可以马上与ISP联系,让他们在上游过滤掉这种攻击。要识别这种攻击,你要查看包含DNS回复的大量通讯(源UDP端口53),特别是要查看那些拥有大量DNS记录的端口。一些ISP已经在其整个网络上部署了传感器以便检测各种类型的早期大量通讯。这样,你的ISP很可能在你发现这种攻击之前就发现和避免了这种攻击。你要问一下你的ISP是否拥有这个能力。

最后,为了帮助阻止恶意人员使用你的DNS服务器作为一个实施这种DNS放大攻击的代理,你要保证你的可以从外部访问的DNS服务器仅为你自己的网络执行循环查询,不为任何互联网上的地址进行这种查询。大多数主要DNS服务器拥有限制循环查询的能力,因此,它们仅接受某些网络的查询,比如你自己的网络。通过阻止利用循环查询装载大型有害的DNS记录,你就可以防止你的DNS服务器成为这个问题的一部分.

结束语:网络攻击越来越猖獗,对网络安全造成了很大的威胁。对于任何黑客的恶意攻击,都有办法来防御,只要了解了他们的攻击手段,具有丰富的网络知识,就可以抵御黑客们的疯狂攻击。一些初学网络的朋友也不必担心,因为目前市场上也已推出许多网络安全方案,以及各式防火墙,相信在不久的将来,网络一定会是一个安全的信息传输媒体。特别需要强调的是,在任何时候都应将网络安全教育放在整个安全体系的首位,努力提高所有网络用户的安全意识和基本防范技术。这对提高整个网络的安全性有着十分重要的意义

什么是DNS劫持和DNS污染,公共DNS是最好的解决办法

我们知道,某些网络运营商为了某些目的,对 DNS 进行了某些操作,导致使用 ISP 的正常上网设置无法通过域名取得正确的 IP 地址。常用的手段有:DNS劫持DNS污染。DNS劫持 和 DNS污染 在天朝是非常常见的现象。一般情况下输入一个错误或不存在的 URL 后,本应该出现404页面,而我们看到的却都是电信、联通等运营商的网址导航页面,正常访问网站时出现电信的小广告,使用了代理却依然无法正常访问某些境外网站,以及最近 Google 几乎被彻底封杀、微软 OneDrive 打不开,这些都和 DNS 有一定关系。

DNS劫持

DNS劫持 就是通过劫持了 DNS 服务器,通过某些手段取得某域名的解析记录控制权,进而修改此域名的解析结果,导致对该域名的访问由原 IP 地址转入到修改后的指定 IP,其结果就是对特定的网址不能访问或访问的是假网址,从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持 通过篡改 DNS 服务器上的数据返回给用户一个错误的查询结果来实现的。

DNS劫持 症状:某些地区的用户在成功连接宽带后,首次打开任何页面都指向 ISP 提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是曾经出现过用户访问 Google 域名的时候出现了百度的网站。这些都属于 DNS劫持。

DNS污染

DNS污染 是一种让一般用户由于得到虚假目标主机 IP 而不能与其通信的方法,是一种 DNS 缓存投毒攻击(DNS cache poisoning)。其工作方式是:由于通常的 DNS 查询没有任何认证机制,而且 DNS 查询通常基于的 UDP 是无连接不可靠的协议,因此 DNS 的查询非常容易被篡改,通过对 UDP 端口 53 上的 DNS 查询进行入侵检测,一经发现与关键词相匹配的请求则立即伪装成目标域名的解析服务器(NS,Name Server)给查询者返回虚假结果

DNS污染 症状:目前一些在天朝被禁止访问的网站基本都是通过 DNS污染 来实现的,例如 YouTube、Facebook 等网站。

解决方法

对于 DNS劫持,可以通过手动更换 DNS 服务器为 公共DNS 解决。

对于 DNS污染,可以说,个人用户很难单单靠设置解决,通常可以使用 VPN 或者域名远程解析的方法解决,但这大多需要购买付费的 VPN 或 SSH 等,也可以通过修改 Hosts 的方法,手动设置域名正确的 IP 地址。

公共DNS

公共DNS 是一种面向大众免费的 DNS 互联网基础服务。我们知道要上网,就必须要 DNS 解析服务,尽管大多数电脑用户都很少会去手动设置 DNS 服务器地址,而是采用默认自动获取网络商 DNS 地址的方式,不过对于一些小型网络服务商而言,可能全球或者全国 DNS 节点比较少,这样就容易导致打开网页偏慢等现象。

更换 DNS 服务器地址为 公共DNS 后,可以在一定程度上加快域名解析速度防止 DNS劫持加强上网安全,还可以屏蔽大部分运营商的广告。下面列出几个目前常用的 公共DNS 服务器地址:

名称 DNS 服务器 IP 地址
OpenerDNS 42.120.21.30
阿里 AliDNS 223.5.5.5 223.6.6.6
V2EX DNS 199.91.73.222 178.79.131.110
CNNIC SDNS 1.2.4.8 210.2.4.8
114 DNS 114.114.114.114 114.114.115.115
Google DNS 8.8.8.8 8.8.4.4
OpenDNS 208.67.222.222 208.67.220.220

给出了这么多,说一下选择吧,如果是国内用户,没有洁癖的,可以考虑 114DNS阿里DNS,如果有洁癖,国内可以选择 V2EX DNSOpenerDNS,国外的可以选择很多,优选 Google 的,虽然有延迟,但还能接受,其他的看自己的网络情况了。

手动更换DNS

1. 打开“网络和共享中心”;

2. 点击正在使用的网络打开“状态”;

【天敏讲坛】关于DNS服务器影响网络在线播放的流畅性问题解决方案

导读

DNS 是域名系统 (Domain Name System) 的缩写,是因特网的一项核心服务,它作为可以将域名和IP地址相互映射的一个分布式数据库,能够使人更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。

现在 DNS一般有路由器的设置完成,在智能网络机顶盒通过DHCP拿到 IP地址后,DNS地址就就自动分配下来了。

路由器的厂家很多,在DNS的处理上也是各有不通过,具体这里无法一一说清楚,这里小编指出,如果你遇到以下问题,可以排查一下你的智能网络机顶盒是否拿到了正确的DNS地址。

1情况1

进入直播电视,切换频道很慢,(正常情况,电视盒子的电视直播很多台,切换1s左右)长达5、6秒,甚至更长,但是最后能够播放,一旦播放了,又很流畅。多数频道存在 这个问题的时候,可能就是路由器分配的DNS地址不对。

原因解析:每次切换频道的时候,比如是sohu的播放源,glsb.tv.sohu.com/****xx, 切台开始的时候,需要将域名解析成 IP,DNS服务器的好与坏,这个解析时间可长可短。

2情况2

进入首页后,某个站点的电影海报页面,翻页的时候图片下载很慢,10个图片需要很久才出来,但是播放开始后,无论是高清、超清都很流畅。

原因分析:可能也是DNS地址解析 过慢导致。

3情况3

部分站点播放卡顿, 但是 部分站点的 超清、高清都很流畅,这个问题情况很复杂,不能断定说是DNS的问题。

这里可能和DNS有关系的话,是因为很多站点的视频播放都采用了负载均衡技术和就近选取服务器的策略,那么有一部分站点,他就是依赖各地 的DNS来决定,用哪个服务器去响应你的点播请求。所以你用的DNS不是当地电信或联通的DNS的话,可能出现的情况。

a)明明你是电信的网络,结果响应你的是联通的服务器;

b)明明你在广东,结果响应你的,可能不是离你最近的服务器,可能跑到北方,或者某个角落的服务器

全能解决办法:检查路由器分配的DNS是否可以用,可以更换114.114.114.114、223.6.6.6、8.8.8.8等opendns