本帖最后由 沧海 于 2018-1-26 15:39 编辑从dig www.jszhdc.cn +trace @221.131.143.69　抓包分析dig的报文 转载网上文章-作者 wujunfeng DNS报文大小分析9712在UDP数据报中的用户数据长度显示为37字节：12字节为固定长度的报文首部，21字节为查询名字，以及用于查询类型和查询类的4个字节。在DNS报文中无需填充数据。 9714 查询结果中的U DP数据长度： 69字节。为说明这些字节需要知道以下两点：1) 在返回的结果中包含查询问题。2) 在返回的结果中会有许多重复的域名，因此使用压缩方式。在这个例子中，域名 gemini.tuc.noao.edu出现了三次。压缩方法：当一个域名中的标识符是压缩的，它的单计数字节（范围由0～6 3）中的最高两位将被设置为11。这表示它是一个16 bit指针而不再是8 bit的计数字节。指针中的剩下14 bit说明在该D N S报文中标识符所在的位置（起始位置由标识字段的第一字节起算）。只要一个标识符是压缩的，就可以使用这种指针，而不一定非要一个完整的域名压缩时才能使用。因为一个指针可能指向一个完整的域名，也可能只指向域名的结尾部分（这是因为给定域名的结尾标识符是相同的）。 显示了在问题部分的域名中各标识符的计数字节。在这个例子中，每个回答中的指针值为12，表示从DNS首部开始的偏移量。 ====================================================C:\Users\wjf>dig www.jszhdc.cn +[email]trace@221.131.143.69[/email] ; > DiG 9.3.2> www.jszhdc.cn +trace @221.131.143.69; (1 server found);; global options: printcmd. 498578 IN NS b.root-servers.net.. 498578 IN NS m.root-servers.net.. 498578 IN NS f.root-servers.net.. 498578 IN NS l.root-servers.net.. 498578 IN NS d.root-servers.net.. 498578 IN NS k.root-servers.net.. 498578 IN NS e.root-servers.net.. 498578 IN NS h.root-servers.net.. 498578 IN NS c.root-servers.net.. 498578 IN NS g.root-servers.net.. 498578 IN NS i.root-servers.net.. 498578 IN NS a.root-servers.net.. 498578 IN NS j.root-servers.net.. 514216 IN RRSIG NS 8 0 51840020140713000000 20140705230000 8230 .jgMKRM9a9AWVdIMwO7RR0qmXT++dGgvIv9lDt0bFEAMsM6tzSyHpwv80 QyQO5141EwQxPSjsuQ+P6e3XcozCLxx/kZP2M4iQ9LsaZlWKoYfAqQshVmdorU8ZRANfOS9167vgW8K7eCkKaF82SC0LAwM0vpVmuE0yzPvj715r zqU=;; Received 913 bytes from 221.131.143.69#53(221.131.143.69)in 70 ms cn. 172800 IN NS e.dns.cn.cn. 172800 IN NS a.dns.cn.cn. 172800 IN NS c.dns.cn.cn. 172800 IN NS d.dns.cn.cn. 172800 IN NS b.dns.cn.cn. 172800 IN NS ns.cernet.net.;; Received 294 bytes from192.228.79.201#53(b.root-servers.net) in 230 ms jszhdc.cn. 86400 IN NS dns2.jiangsumobile.com.jszhdc.cn. 86400 IN NS dns1.jiangsumobile.com.;; Received 86 bytes from203.119.29.1#53(e.dns.cn) in 240 ms www.jszhdc.cn. 43200 IN A 221.178.251.141jszhdc.cn. 43200 IN NS dns1.jiangsumobile.com.jszhdc.cn. 43200 IN NS dns2.jiangsumobile.com.;; Received 134 bytes from211.103.13.101#53(dns2.jiangsumobile.com) in 130 ms 9715 经过分析发现，dig +trace，是客户端直接与各个DNS进行报文交互的（并不是通过221.131.143.69与各个DNS交互），同时会调用本地DNS使用dig +trace　@221.131.143.69中的@221.131.143.6只是为了从221.131.143.69获取到13个根DNS的域名，如下是抓包分析192.168.0.115是客户端电脑的IP 9716 如下是dig +trace的第1个请求报文（向dig @指定IP 发起请求）9718如下是dig +trace的第2个响应报文9720注意在answers中有14条纪录，　b.root-servers.net.　排在第一个，additional有25条纪录　 9721 而additional有25条纪录，有的根DNS除了返回A纪录，另外还多返回一条AAAA纪录9725 如下是dig +trace的第3个请求报文(向本地DNS 发起请求) 当前本地DNS为192.168.0.1，正好与网关地址一样，如果本地DNS为114.114.114.114，则目地DNS会变为114.114.114.114 9726 如下是dig +trace的第4个响应报文(本地DNS 响应)9728如下是dig +trace的第5个请求报文（向b.root-servers.net请求） 9730 如下是dig +trace的第6个响应报文 (b.root-servers.net响应)9731 如下是dig +trace的第7个请求报文(向本地DNS 发起请求) 9732 9733如下是dig +trace的第8个响应报文(本地DNS 响应) 9734 如下是dig +trace的第9个请求报文(发给e.dns.cn) 9737 如下是dig +trace的第10个响应报文(e.dns.cn响应) 9739 后面的报文省略 9740 9741　 ====================================DNS UDP or TCP当名字解析器发出一个查询请求，并且返回响应中的TC（删减标志）比特被设置为1时，它就意味着响应的长度超过了512个字节，而仅返回前512个字节。在遇到这种情况时，域名解析器通常使用TCP重发原来的查询请求，它将允许返回的响应超过512个字节。 9743 9744 97469747 客户端转为TCP 53请求97499751 抓包的原始报文参考附件

GSLB也称全局负载均衡，作用是实现互联网上不同地域服务器间的流量调配，保证用户访问最佳(最近，性能最好)的服务器来提供服务，从而确保访问质量。 实现GSLB有很多种办法，可以网上搜索，这里主要说一下DNS实现GSLB： 1 通过运营商线路调度：这个主要是指国内，由于特殊原因国内不同运营商互联互通存在很大问题，比如联通用户访问电信机房服务器延迟很大，甚至有可能无法访问的情况。假如您的业务部署在不同运营商机房，可以通过运营商线路解析来实现调度，联通线路用户域名解析到联通机房IP，电信线路用户域名解析电信机房IP，这样保证不同用户访问最佳的服务器。 2 通过地域线路调度： 1）我们都知道，网站服务器越近，访问速度越快，比如天津用户访问北京服务器会比广州服务器快很多。假如您的业务部署在华北，华南两个Region，可以通过地域线路解析，设置华北，东北，西北，华中用户访问域名解析到北京服务器IP，华东，华南，西南用户访问域名解析到广州服务器IP，这样用户访问离自己最近的服务器可以提升访问体验。 2）假如您的业务是面向全球的，国内部署有业务，海外也部署有业务，可以选择中国用户访问域名解析到国内服务器，海外用户访问域名解析到海外服务器。当然海外的还可以细分，比如选择亚太--新加坡的用户等，可以具体到洲，国家。 3 权重轮询：比如一个域名解析到多个IP，可以根据不同IP服务器的配置，业务情况设置解析比重，比如2:1或者1:1等等。 4 健康检查，故障转移：可以创建监控任务实时监控后端服务器IP的健康状态，如果发现后端服务器异常，可以把解析流量切换到其他正常的服务器或者备用服务器，保证业务不会中断。 当然GSLB有很多调度策略，国内主要的是上面几种，除了上面还有其他诉求吗？欢迎楼下讨论

本帖最后由 antcloud 于 2018-1-16 11:39 编辑DNS解析共有16中返回结果，目前用到的有10个如下： 0 NOERROR /* No error condition */ 1 FORMAT ERROR /* Format error */ 2 SERVFAIL /* Server failure */ 3 NXDOMAIN /* Name Error */ 4 NOT IMPL /* Not implemented */ 5 REFUSED /* Refused */ 6 YXDOMAIN /* name should not exist */ 7 YXRRSET /* rrset should not exist */ 8 NXRRSET /* rrset does not exist */ 9 NOTAUTH /* server not authoritative */ 10 NOTZONE /* name not inside zone */ 11-15 /* reserved for future use */

1、通过解析量可以区分不同区域网民上网习惯，青睐哪些网站； 2、可以分析出不同省份基于具体网站的访问流量； 。。。。大家可以补充。。。。

本帖最后由 antcloud 于 2017-12-25 22:48 编辑【摘要】 ***。转自[网络安全] 【华安解密之DDoS攻防】01 DNS原理篇“暴风”事件解密 到DDoS攻击，就让人不由得想起7年前那场触目惊心的“519暴风断网”事件。这场灾难仿佛一阵飓风，瞬间席卷了中国互联网。暴风事件带来的巨大破坏性，不仅仅是在短短两个小时内让天津、北京、上海、河北、山西、内蒙古、辽宁、吉林、江苏、黑龙江、浙江、安徽、湖北、广西、广东等地区的DNS服务陆续瘫痪，导致用户不能正常上网... 转自[网络安全] 【华安解密之DDoS攻防】01 DNS原理篇“暴风”事件解密 到DDoS攻击 说到DDoS攻击，就让人不由得想起7年前那场触目惊心的“519暴风断网”事件。这场灾难仿佛一阵飓风，瞬间席卷了中国互联网。暴风事件带来的巨大破坏性，不仅仅是在短短两个小时内让天津、北京、上海、河北、山西、内蒙古、辽宁、吉林、江苏、黑龙江、浙江、安徽、湖北、广西、广东等地区的DNS服务陆续瘫痪，导致用户不能正常上网，更为重要的是，众多黑客灵光一闪，开启了一种新的攻击模式。那次互联网灾难之后，DDoS攻击的编年史中出现了两个时代：一个是前暴风时代，一个是后暴风时代。 今天就和大家一起回顾一下“519暴风断网”事件。 事件回顾 失了一颗铁钉，亡了一个国家。一个馒头，引发一场血案。很多很多大事件，都是从微不足道的小事开始的。这一次，小人物再次改变了历史。 “暴风”这件事儿的起因是两个游戏私服互相竞争，来回发动DDoS攻击。在达不到预期效果的情况下，干脆直接向对方的域名服务器下手了。 5月18日开始，DNS服务提供商DNSPod的6台服务器开始受到攻击。 18日晚20点33分，在史无前例的大流量攻击下，DNSPod的6台服务器开始陆续失效，大量网站开始间歇性无法访问。第一波攻击的流量在21点30分左右达到高峰，流量超过了10Gbps。要知道那可是2009年，奥运会才开过一年，北京的房价还是可以接受的，一个电信核心机房的带宽最多也只有几十G。 18日当晚，由于DNSPod耗尽了整个机房近乎三分之一的带宽资源，为了不影响机房其他用户，DNSPod服务器被运营商下线。 如果事情到此为止，其实也不会造成多大的影响。可是发动攻击的黑客忘了，运营商的管理员也忘了，DNSPod并不仅仅为这个被攻击的网游私服提供域名解析服务，还支持数十万其他的网站，这其中就包括大名鼎鼎的暴风影音。普通用户遇到上网失败，试几次就放弃了；暴风影音软件的设计，使它在请求失败后持续不断地重新发起请求。再考虑到暴风影音巨大的装机量，悲剧发生了。 19日晚，由于DNSPod网络服务被中断，致使其无法为包括baofeng.com在内的域名提供域名解析服务，诸多采用DNSPod服务的网站无法访问，DNS请求涌向了本地DNS缓存服务器，DNS缓存服务终于顶不住了，发生了大面积的堵塞。 19日晚21点左右，浙江电信DNS缓存服务开始瘫痪，之后的两个小时内天津、北京、上海、河北、山西、内蒙古、辽宁、吉林、江苏、黑龙江、浙江、安徽、湖北、广西、广东等地区的DNS缓存服务器也陆续瘫痪。全国各省市出现大面积断网。 事件中涉及的几个关键角色 DNSPod DNSPod是国内最大的一家免费DNS解析服务提供商，暴风影音和前面恶性竞争的游戏私服都是DNSPod的客户。 运营商 由于中国特色的运营商市场，导致DNSPod这样的网络基础服务提供商无法独立承建数据中心，只能租用运营商IDC的机房和服务器资源。 暴风影音 影音软件起家，后来向媒体提供商转型。暴风影音软件中，有一项强制随机启动的名为stormliv.exe的进程，只要用户安装了暴风影音，该进程就会自动运行，并不断连接暴风影音网站，下载广告或升级。 私服与黑客 这个就很容易理解了，一个是为了一己私欲，策划这场攻击事件的背后指示者；一个是为了牟取暴利的攻击事件执行者。 从事件整个过程来看，一共有几个关键点： 1、游戏私服攻击竞争对手DNS服务，打蛇打七寸，间接攻击了整个DNSPod的业务。 2、运营商对DNSPod流量进行了阻断，粗暴的对流量进行了黑洞处理。 3、几亿安装了暴风影音客户端的PC充当“肉鸡”，导致运营商DNS缓存服务器无法提供服务，进而导致大面积断网。 如果把这次事件看成是“多米诺骨牌”效应，那被推倒的第一张“骨牌”是DNSPod服务器；第二张“骨牌”毫无疑问就是暴风影音充当“肉鸡”导致服务耗尽的运营商DNS缓存服务器；而第三张“骨牌”就是全国范围瘫痪的网络了。如果想深入理解这次互联网灾难，我们要先从DNS的基础知识讲起。 DNS服务器在网络中充当什么角色？ 大家都知道，当我们在上网的时候，通常输入的是网址，其实这就是一个域名，比如www.vmall.com。这个域名就好比是餐馆的招牌，通常我们想要找一个餐馆，一般都会输入餐馆名称进行查找，而不是直接找XX街XX号。大家很难记住这个门牌号，而餐馆名称却很容易记住。 网络上的计算机彼此之间只能用IP地址才能相互识别，但是IP地址是一串数字，很难记忆，所有就有了域名。域名很容易被人们记住，我们上网的时候可以直接输入域名，计算机需要通过域名找到对应的IP地址，这就是域名解析的过程。 域名解析要由专门的域名解析系统（Domain Name System，简称DNS）来完成。在DNS系统中，涉及以下几种类型的服务器： 根服务器主要用来管理互联网的主目录，全世界只有13个根逻辑服务器节点。这13个节点其中10个设置在美国，另外各有一个设置于英国、瑞典和日本。虽然网络是无国界的，但服务器还是有国界的。所有根服务器均由美国政府授权的互联网域名与号码分配机构ICANN统一管理。 顶级域名服务器一般用于存储.com、.edu、.cn等顶级域名。 递归服务器也可理解为存储着官方域名解析授权的授权服务器，一般存储着这个网络中域名和IP地址的解析关系，也就是DNSPod充当的角色。试想一下，如果每个上网用户在上网的时候都向授权服务器发送请求，那授权服务器必然承受不住，所以就有了缓存服务器存在的必要。 缓存服务器就相当于是授权服务器的一个代理，可以缓解授权服务器的压力。我们每次上网的时候，域名解析的请求都是发给缓存服务器的，缓存服务器第一次收到用户请求的时候，会向授权服务器请求域名和IP地址的解析表，然后储存在本地，等后续再有用户请求相同的域名时，就会直接答复，不再请求。毕竟一个网站的IP地址不是经常变换的。当然，这个解析表是有一定的有效期的，等有效期到了，这个解析表就会自动老化，等下次有用户请求时重新向授权服务器询问。这个定期老化机制，可以保证缓存服务器上域名解析的定期更新。 1、 DNS客户端查询通常采用递归方式，缓存服务器首先会判断本地是否有这个域名的解析缓存。 2、 如果本地没有缓存，就会把域名发送到根服务器。根服务器收到www.vmall.com请求后，会判断.com是谁授权管理，并返回.com所在的顶级域名服务器IP地址。 3、 缓存服务器继续向顶级域名服务器发送www.vmall.com解析请求，顶级域名服务器收到请求后，会返回下一级.vmall.com的递归服务器IP地址。 4、 缓存服务器继续向递归服务器发送www.vmall.com解析请求，递归服务器收到请求后，返回www.vmall.com的解析地址。如果域名层级较多，则递归服务器也会存在多级。 5、 缓存服务器得到www.vmall.com的解析IP地址后，将IP地址发送给客户端，同时在本地缓存。 6、 后续一段时间内，当有客户端再次请求www.vmall.com这个域名解析时，缓存服务器直接回应解析的IP地址，不再重复询问。 针对关键环节解决方案思路： 我们继续回到暴风影音这件事上。运营商对DNSPod采用的是粗暴式的黑洞处理，显然这种方式是不行的，直接影响了其他域名的解析业务。 1、DNS递归（授权）服务缺少有效的保护，运营商IDC和SP缺少应用层清洗能力，可以针对应用层流量进行攻击流量的识别和针对性清洗。 2、DNS缓存服务缺少有效的保护，DNS缓存服务缺少对于特定域名的限速，以及异常流量中有针对性的清洗攻击流量，转发正常流量的能力。 华为专业Anti-DDoS解决方案怎么做？ 华为Anti-DDoS专业防御系统支持对DNS服务器提供精细化的防御。精细化的意思就是针对不同的DNS服务器、不同的攻击类型、不同的应用场景，提供不同的防御手段。华为Anti-DDoS针对这次事件可以从两方面进行部署。 授权服务器防护 DNSPod服务器的防护可以作为第一道防线。对于DNSPod服务器，由于它所遭受的攻击其实都是僵尸主机发送的DNS query，属于虚假源攻击，所以可以采用重定向方式进行防御。 缓存服务器防护 如果DNSPod服务器不幸沦陷了，那还可以通过保护DNS缓存服务器，作为阻止事件继续恶化的第二道防线。 DNS缓存服务器和DNSPod服务器所遭受的攻击不同，毕竟暴风影音用户都是真实存在的源，属于真实源攻击，源认证防御方式对这种真实源无效， 所以可以这么做： 1、 首先，Anti-DDoS支持针对DNS服务的TopN统计，并提供报表。从报表中，可以获知访问最多的Top N域名，在这么大的访问量下，暴风影音一定是名列前茅的。 2、 然后，针对被攻击域名进行指定域名限速，即对暴风影音的域名进行限速。 这样就可以避免其他域名服务受影响，也不会导致DNS缓存服务器瘫痪。 域名作为广大民众访问互联网的起点和入口，是全球互联网通信的基础。域名解析系统作为承载全球亿万域名正常使用的系统，是互联网的基础设施。而域名系统又是一种公开服务，很容易被黑客作为攻击的对象。域名系统的故障会导致互联网陷入瘫痪，所以保护域名系统也变得至关重要。 “暴风影音”事件的第二阶段，也就是DNS缓存服务器拒绝服务，导致大面积Internet接入瘫痪，才是本次攻击的威力点。这个结果虽然不是攻击者的本意，但是一连串的连锁反应，使它成为DDoS史上具有里程碑意义的关键事件。它给了DDoS攻击者新的方向，如何利用庞大的网络基础设施架构产生更大、更真实的DDoS攻击。后面的NTP反射攻击，搜狐视频签名嵌入式攻击等都是源于这个思路，它开启了DDoS攻击的新**。

进行域名解析时，常常有以下几种返回： 1、NOERROR 你的域名存在，且业务正常运行，使用dig命令@{公网提供的地址} 你要解析的域名，返回noerror，如： dig @{公网提供的地址} huawei.com ; > DiG 9.9.4-RedHat-9.9.4-18.el7 > @ huawei.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 15439 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;huawei.com. IN A 2、NXDOMAIN 如果你要解析的三级域名不存在，但存在相应的二级域名，则返回nxdomain，如： dig @{公网提供的地址} 234214.huawei.com ; > DiG 9.9.4-RedHat-9.9.4-18.el7 > @ 234214.huawei.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER- opcode: QUERY, status: NXDOMAIN, id: 15243 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;234214.huawei.com. IN A 3、REFUSED 如果你要解析的域名不存在，则返回REFUSED，如： dig @{公网提供的地址} 234214.com ; > DiG 9.9.4-RedHat-9.9.4-18.el7 > @ 234214.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER- opcode: QUERY, status: REFUSED, id: 58405 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;234214.com. IN A 4、serve**il 当然还存在域名有问题导致返回serve**il。 其他等等。。。若有不妥之处，请指正。

DNS （Domain Name Server）域名解析服务，使用TCP&UDP的53号端口(主从DNS之间用TCP，客户端查询使用UDP)。它可以完成域名与IP地址的互换，可以通过IP地址解析到域名；也可以通过域名解析到IP地址。 DNS的层次 [*]根域：根域位于层次化结构的最顶部并用点“.”表示全球有十三个根服务器。一个主根服务器，十二个辅助根服务器。 [*]顶级域：顶级域是按照组织类别或地理位置来划分的，如下： [table=98%,white] .gov政府组织.com商业组织.net网络中心.org非**性组织.edu教育部门. cn .uk .us国家国别的代码，cn表示中国，uk表示英国，us表示美国.com.cn国内商业机构.net.cn国内互联网机构.org.cn国内非**性组织注： [*] .com &.net由internic国际组织管理，而以.cn结尾的是由cnnic中国互联网中心管理的。 [*]二级域：有国际域名组织为互联网中的个人或部门制定和登记的二级域(如：baidu.com) 所以根据这些概念：华为云可以支持几级域名？这方面有什么特殊的限制吗？

本帖最后由 antcloud 于 2017-11-28 11:29 编辑【摘要】 DNS负载均衡的优点是简单易行，而且实现代价小。它在DNS服务器中为同一个域名配置多个IP地址（即为一个主机名设置多条A资源记录），在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的计算机上去，从而达到负载均衡的目的。 下面是一个实现web服务器负载平衡的配置片段（在区域数据文件中）。 DNS负载均衡的优点是简单易行，而且实现代价小。它在DNS服务器中为同一个域名配置多个IP地址（即为一个主机名设置多条A资源记录），在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的计算机上去，从而达到负载均衡的目的。 下面是一个实现web服务器负载平衡的配置片段（在区域数据文件中）。 www.antcloud.com IN A 20.20.3.1 IN A 20.20.3.2 IN A 20.20.3.3 在以上配置中，当客户端查询www服务器IP地址时，Bind将根据rrset-order语句定义的次序把配置中设定的3条A记录都发送给客户端，客户端可以使用自己规定的算法从3条记录中挑选一条。rrset-order语句是主配置文件中options主语句的一条子语句，可以定义固定、随机和轮询的次序，Bind9默认返回的顺序是随机。 合法的排序值是： fixed:记录以它们在域文件中的顺序 random:记录以随机顺序被返回 cyclic:记录以环顺序被返回 例如： rrset-order { class IN type A name "www.antcloud.com" order random; order cyclic; }; 将会使得任何处于IN类中的A类记录的响应以随机顺序返回，IN 类以"host.example.com"为后缀。其他的记录以循环记录被返回。如果多重rrset-order语句出现，它们并不组合在一起，只适用于最后一个条。但是rrset-order语句不被BIND9支持，BIND9目前只支持"random-cyclic"排序，服务器随机选择RRset集中的开始点，有顺序返回在那个点开始的记录。 可以通过配置全局配置 dns 轮询配置options来实现轮询。 options { rrset-order { order cyclic; }; ..... }; fixed在默认编译的时候是关闭的，需要在编译的时候打开： Allow ´fixed´ rrset-order (--enable-fixed-rrset) ./configure --enable-largefile --enable-threads --disable-openssl-version-check --enable-fixed-rrset --prefix=/home/slim/bind9.9.7 --with-libtool 注意：rrset-order为全局配置，该配置在Bind中会配置在每一个view中。每个域名请求都要遍历该规则列表，配置该配置会影响到Bind的解析性能。

本帖最后由 潘冬子 于 2017-11-28 15:39 编辑 Linux环境下有些文件的配置正确与否关系到DNS实际解析效果，本文就对这几个文件简要小科普一下： /etc/nsswitch.conf文件 该规定通过哪些途径以及按照什么顺序去查找特定类型的信息，还可以指定某个方法奏效或失效时系统将采取什么动作。Nsswitch.conf中的每一行配置都指明了如何搜索信息，每行配置的格式如下： Info: method [[action]] [method [[action]] ...] 其中，info指定该行所描述的信息的类型，method为用来查找该信息的方法，action是对前面的method返回状态的响应。action要放在方括号里。 #cat /etc/nsswitch.conf（示例范本） #主机名称：先查/etc/hosts，查不出结果时才查DNS hosts: files dns 在上述示例中，hosts指的就是名称数据库，关键字files表示数据来源是本地主机上的文件/etc/hosts，关键字DNS表示数据来源是DNS server。 默认情况下，排列在后面的数据来源只有在优先级的数据不提供明确结果时，才会被查询到。然而，你可以是下面语法来改变解析条件： 【 【！】status = action … 】 将上述语法列在数据来源之后，表示在status成立或不成立时，进行action所描述的动作。例如以下范本： #cat / etc/nsswitch.conf Hosts: dns【!UNAVAIL=return】files 在上述举例中，当解析器要查询主机名称时，会优先向DNS server查询，但是当DNS server不可用时（Unavailable），则直接返回（return），而不是继续查询/etc/hosts。换句话说，只有在DNS Server有作用但查不出结果时，/etc/**s才会被查询到。 关于status还有更多的赋值，如success、notfound、unavalil、tryagain等。 /etc/hosts文件 该文件可以配置主机IP及其对应的主机名。在局域网或者是internet上，每台主机都由一个IP地址，它区分每台主机，并可以根据IP进行通讯。但IP地址不方便记忆，所有又有了域名。在一个局域网中，每台机器都有一个主机名，用于区分主机，便于相互访问。 # cat /etc/hosts 127.0.0.1 localhost.localdomain 127.0.0.1 localhost.localdomain 192.168.1.100 panda100 test100 另外，linux下通过hostname 这个kernel变量来设置主机名只是临时的，并不会保存到/etc/hosts文件中，下次重启系统时，此主机名将不会存在。 /etc/resolv.conf文件 该文件用于设置DNS服务器的IP地址及DNS域名，还包含了主机的域名搜索顺序。该文件是由域名解析器使用的配置文件。它的格式很简单，每行以一个关键字开头，后接一个或多个由空格隔开的参数。 resolv.conf的关键字主要有四个，分别是： nameserver //定义DNS服务器的IP地址 domain //定义本地域名 search //定义域名的搜索列表 sortlist //对返回的域名进行排序 /etc/resolv.conf的示例： domain huaweicloud.com nameserver 10.72.255.100 nameserver 114.114.114.114 nameserver 8.8.8.8 nameserver表示解析域名时使用该地址指定的主机为域名服务器。其中域名服务器是按照文件中出现的顺序来查询的,且只有当第一个nameserver没有反应时才查询下面的nameserver。同时，nameserver可以配置多个，但是linux系统默认只会使用前三个nameserver。 Domain:声明主机的域名。很多程序用到它，如邮件系统；当为没有域名的主机进行DNS查询时，也要用到。如果没有域名，主机名将被使用，删除所有在第一个点( .)前面的内容。 Search:它的多个参数指明域名查询顺序。当要查询没有域名的主机，主机将在由search声明的域中分别查找。 domain和search不能共存；如果同时存在，后面出现的将会被使用。 Sortlist:允许将得到域名结果进行特定的排序。它的参数为网络/掩码对，允许任意的排列顺序。此外，resolv.conf还提供一些功能可以实现对查询超时、查询重试次数、DNS轮询查询等场景的定制，比如如果希望上面设置的三个DNS服务器都能轮询使用，可以在文件中配置如下： options rotate timeout:3 attempts:1 #默认查询超时为5秒，重试次数为2# domain huaweicloud.com nameserver 10.72.255.100 nameserver 114.114.114.114 nameserver 8.8.8.8

本帖最后由 知足常乐 于 2017-11-25 13:02 编辑DNS 的查询过程有两种类型：递归查询和迭代查询。 递归查询用于主机向本地域名服务器的查询。主机向本地域名服务器发出请求时，如果本地域名无法给出查询域名的 IP 地址，那么它会替代主机，以客户端的身份向其他的根域名服务器发出查询请求。主机则处于等待状态，等待本地域名服务器向其返回查询结果。 本地域名服务器与根域名服务器之间的查询属于迭代查询。本地域名服务器向根域名服务器发出查询请求时，如果根域名能够给出要查询域名的 IP 地址，则返回给本地服务器 IP 地址，否则，则会反馈给本地服务器下一步要查询的服务器，然后让本地服务器进行后续的查询。 以查询域名 www.hitwh.edu.cn 为例，介绍 DNS 的解析过程。具体的工作流程如图 所示。 5464 （1）主机向本地域名服务器发送域名为 www.hitwh.edu.cn 的查询请求。 （2）假设本地域名服务器没有缓存，则本地域名服务器向根域名服务器发送查询请求。 （3）根域名服务器把.cn 顶级域名服务器的地址返回给本地域名服务器。 （4）本地域名服务器接收到根域名服务器返回的地址后，向.cn 顶级域名服务器发送查询请求。 （5）.cn 顶级域名服务器收到请求后，把 edu.cn 权威域名服务器的地址返回给.cn 顶级域名服务器。 （6）本地域名服务器根据.cn 顶级域名服务器返回的地址，向edu.cn 权威域名服务器发送查询请求。 （7）edu.cn 权威域名服务器把 hitwh.edu.cn 权威域名服务器的地址反馈给本地域名服务器。 （8） 本地 域 名 服 务 器 根 据 edu.cn 权 威 域 名 服务 器 返 回 的 地 址 ，向hitwh.edu.cn 权威域名服务器发送查询请求。 （9）hitwh.edu.cn 权威域名服务器收到请求后，把 www.hitwh.edu.cn 的 IP地址返回给本地域名服务器。 （10）本地域名服务器收到 www.hitwh.edu.cn 的 IP 地址后，把地址返回给主机。

本帖最后由 知足常乐 于 2017-11-25 13:03 编辑如果有幸你能知道有个东西叫DNSSEC，那么恭喜，你又发现一个重大安全隐患。简单来说这个东西就是一部分解决你的DNS查询中的DNS的欺骗和缓存污染问题。除了DNSSEC区域签名以外，云计算服务供应商们还必须在客户用于名称解决方案的递归解析程序中打开DNSSEC验证。

本帖最后由 antcloud 于 2017-12-25 22:43 编辑【摘要】 DNS按功能（角色）的分类： 1.权威DNS： 权威DNS是经过上一级授权对域名进行解析的服务器，同时它可以把解析授权转授给其他人，如COM顶级服务器可以授权**.COM的权威服务器为NS.**.COM，同时NS.**.COM还可以把授权转授给NS.DDD.COM，这样NS.DDD.COM就成了**.COM实际上的权威服务器了。平时我们解析域名的结果都源自权威DNS。 DNS按功能（角色）的分类：1.权威DNS：权威DNS是经过上一级授权对域名进行解析的服务器，同时它可以把解析授权转授给其他人，如COM顶级服务器可以授权**.COM的权威服务器为NS.**.COM，同时NS.**.COM还可以把授权转授给NS.DDD.COM，这样NS.DDD.COM就成了**.COM实际上的权威服务器了。平时我们解析域名的结果都源自权威DNS。 2.递归DNS:负责接受用户对任意域名查询，并返回结果给用户。递归DNS可以缓存结果以避免重复向上查询。我们平时使用最多的就是这类DNS，他对公众开放服务，一般由网络运营商提供，大家都自己可以架递归DNS提供服务。递归DNS一定要有可靠的互联网连接方可使用。 3.转发DNS:负责接受用户查询，并返回结果给用户。但这个结果不是按标准的域名解析过程得到的，而是直接把递归DNS的结果转发给用户。它也具备缓存功能。他主要使用在没有直接的互联网连接，但可以连接到一个递归DNS那里，这时使用转发DNS就比较合适。其缺陷是：直接受递归DNS的影响，服务品质较差。 4、HTTPDNSDNS服务用于在网络请求时，将域名转为IP地址。传统的基于UDP协议的公共DNS服务极易发生DNS劫持，从而造成安全问题。HttpDns服务则是基于HTTP协议自建DNS服务，或者选择更加可靠的DNS服务提供商来完成DNS服务，以降低发生安全问题的风险。HttpDns还可以为精准调度提供支持。因而在当前网络环境中得到了越来越多的应用。

本帖最后由 潘冬子 于 2017-11-28 15:41 编辑 Local DNS在平时上网中扮演重要角色，如果设置不当的话，可能会导致网速慢、网站劫持、网页打不开等一系列问题。随着当前互联网的发展，除了运营商提供的递归服务外，越来越多的企业推出公共LocalDNS产品和服务。今天我们就来梳理一些市面上常用的第三方公共DNS服务。一、国内篇DNSPod DNS+：国内第一家支持ECS的公共DNS，是DNSPod推出的公共域名解析服务，可以为全网用户提供域名的公共递归解析服务！ 服务地址：119.29.29.29 114DNS：国内用户量巨大的DNS，访问速度快，各省都有节点，同时满足电信、联通、移动各运营商用户，可以有效预防劫持。 服务地址：114.114.114.114、114.114.115.115、114.114.114.119、114.114.115.119、114.114.114.110、114.114.115.110阿里 AliDNS：阿里巴巴集团推出的DNS递归解析系统，目标是成为国内互联网基础设施的组成部分，面向互联网用户提供“快速”、“稳定”、“智能”的免费DNS递归解析服务。 服务地址：223.5.5.5、223.6.6.6百度Baid**S：百度DNS旗下云解析服务,依托百度一流基础设施和强大技术实力,为用户提供免费的、超越竞品的服务体验。没有套餐区分,安全,稳定,高效 DNS 服务器 IP 地址： 服务地址：180.76.76.76 CNNIC SDNS：由中国互联网络**(CNNIC)正式推出的免费的公共云解析服务(SecureDNS,简称SDNS)。该服务可为广大网民提供安全、智能、高速的上网接入解析服务。 服务地址：1.2.4.8、210.2.4.8 二、国外篇OpenDNS：免费的域名解析服务提供商（DNS）。创建于2006年，长期以来致力于为广大个人用户以及商务企业用户和公共领域提供免费的域名解析服务。 服务地址：208.67.222.222、208.67.220.220 Google DNS：谷歌公共域名解析服务（GooglePublic DNS）是由谷歌公司于2009年发布的一项新的DNS服务。主要为了替代ISPs或其他公司提供的DNS服务。 DNS 服务器 IP 地址： 服务地址：8.8.8.8、8.8.4.4、2001:4860:4860::8888、2001:4860:4860::8844 IBM DNS：IBM 、Global Cyber Alliance 和 PacketClearing House 合作推出了免费的 Quad9 公共 DNS 服务（9.9.9.9），它将会屏蔽对僵尸网络、钓鱼攻击和其它恶意主机相关联的域名查询。Quad9的工作与其它免费的公共 DNS 相似，但不会返回已识别为恶意的域名解析。服务地址：9.9.9.9 9.9.9.10OpenNic DNS：OpenNic是一个社区化的非营利组织，主张DNS中立、免费服务、用户决议、自由开放、保护隐私、拒绝劫持。访问官网，会自动向你推荐最适合你所在区域的DNS。服务地址：128.199.248.105、106.186.17.181 最后，想知道更多的公共DNS服务地址，可以去查看http://www.ip.cn/dns.html?qivqbk=okqht3

IP Anycast＋BGP方式是DNS领域常用的多点部署架构和技术方案，采用这种方式不需要额外采购如F5等负载均衡设备，部署灵活可扩展。本文就简单介绍一下IPAnycast＋BGP技术在DNS领域的最佳实践。 Anycast技术原理Anycast即IP地址任播技术。根据RFC1546定义，它建议从IP地址空间分配出一块独立的地址空间作为任播地址，一般为一个C段地址。从IP网络上来看，任播技术通过一个Anycast地址标识一组提供特定服务的集群，如DNS解析服务。同时，服务访问方并不关心提供服务的具体是哪一台主机，访问该地址的请求报文可以被IP网络路由到这一组目标中的任何一台主机上，它提供的是一种无状态的、尽力而为的服务。 Anycast技术优势全局负载均衡。不同客户端将访问不同目的主机，此过程对客户端透明，从而实现了目的主机的负载均衡。提升解析效率。Anycast利用路由度量到“最近”的目的主机，提高了客户端响应速度。服务冗余高可用。当任意目的主机接入的网络出现故障时，导致该目的主机路由不可达，客户端请求可以在无人为干预的情况下自动被路由到其他可达的最近目的主机，在一定程度上确保了服务的高可用。 Anycast最佳应用实践Anycast实质上是一种网络技术，它借助于网络中动态路由协议实现服务的负载均衡和冗余。实际应用时，IPAnycast＋BGP的部署必须使用能够运行BGP的设备与其他自治域进行路由交换，通常使用的设备是路由器或三层交换机。然后将目标主机直接接入路由器或通过负载均衡设备将多台主机接入路由器，路由器向上联自治域广播目标主机共享的单播地址。路由器可以从上联自治域接收全路由表，也可以将默认路由的下一跳指向上联自治域的路由器接口。目前，IPAnycast＋BGP在DNS系统部署中得到了广泛应用，如华为云公网DNS、谷歌Public DNS等。此外，由于实际各公司拥有的IP地址段数量有多有少，在采用IPanycast任播时有的会使用专门的C段地址，而有的只能使用\32地址。

欢迎来到DNS服务吐槽贴，在这里您可以畅所欲为，无所不谈。 文档，界面，功能，凡是您使用不爽的都可以吐槽给我们，我们会快速响应您的诉求。 希望华为云能给您带来极致的上云体验！