dns相关工作生活

DNS梳理

2019-07-04  本文已影响0人  大富帅

dns解析两个命令,一个nslookup ,一个dig

[/tmp]$ nslookup mumu-apk.fp.ps.netease.com
Server:     127.0.1.1
Address:    127.0.1.1#53

Non-authoritative answer:
mumu-apk.fp.ps.netease.com  canonical name = mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com.
Name:   mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com
Address: 36.250.146.35
Name:   mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com
Address: 61.240.203.75

dig 的解析

[/tmp]$ dig mumu-apk.fp.ps.netease.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> mumu-apk.fp.ps.netease.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13807
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 7, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mumu-apk.fp.ps.netease.com.    IN  A

;; ANSWER SECTION:
mumu-apk.fp.ps.netease.com. 1127 IN CNAME   mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com.
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 61.240.203.75
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 36.250.146.36
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 36.250.146.39
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 36.250.146.47
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 36.250.146.34
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 36.250.146.35
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 36.250.146.46
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 61.240.203.68
mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com. 112 IN A 61.240.203.69

;; AUTHORITY SECTION:
dlcloud.fastcdn.com.    4453    IN  NS  dns2.dlcloud.fastcdn.com.
dlcloud.fastcdn.com.    4453    IN  NS  dns4.dlcloud.fastcdn.com.
dlcloud.fastcdn.com.    4453    IN  NS  dns3.dlcloud.fastcdn.com.
dlcloud.fastcdn.com.    4453    IN  NS  h101.flxdns.com.
dlcloud.fastcdn.com.    4453    IN  NS  dns6.dlcloud.fastcdn.com.
dlcloud.fastcdn.com.    4453    IN  NS  dns7.dlcloud.fastcdn.com.
dlcloud.fastcdn.com.    4453    IN  NS  dns1.dlcloud.fastcdn.com.

;; ADDITIONAL SECTION:
dns1.dlcloud.fastcdn.com. 4460  IN  A   122.11.46.90
dns7.dlcloud.fastcdn.com. 4460  IN  A   221.233.135.63
dns2.dlcloud.fastcdn.com. 4460  IN  A   1.82.132.128
dns4.dlcloud.fastcdn.com. 4460  IN  A   58.216.101.252
dns6.dlcloud.fastcdn.com. 4460  IN  A   119.147.248.114
dns3.dlcloud.fastcdn.com. 4460  IN  A   111.161.19.42

;; Query time: 3 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Jul 04 11:04:34 CST 2019
;; MSG SIZE  rcvd: 492

关于DNS服务器

nslookup的server 都是指本地的DNS服务器IP
本地服务器IP是相当于客户端一样,像远端的DNS服务器请求结果

递归.png

关于NS记录

我在DNSPod网站注册了个域名 88zfp.xyz,有个域名后,我需要解析它,让它落地到某个IP,不然这个域名就没意义了。
所以DNSPod就是专门做这个解析工作的。
注册了这个域名,dnspod会自动生成两条 NS 记录


image.png

解析的记录类型有几个比如常见的A, CNAME, NS , MX 记录
这里的NS记录说明这个域名 88zfp.xyz 的DNS解析服务交给 f1g1ns1.dnspod.net 负责。
有了这个前提,就是说可以让这个服务器来解析其他记录,比如A记录,CNAME记录,MX记录。

我们来dig www.88zfp.xyz

image.png

这个截图可以看到了 88zfp.xyz 这个域名确实是就给了f1g1ns1.dnspod.net ,f1g1ns2.dnspod.net 这两个服务器来解析。
所以我在后台定义的主机记录:www -> 123.58.165.252 就是把记录写到了这两个服务器的分布式数据库里面,以后来请求的时候,它就会查自己的DB,找出映射关系

所以如果我想再解析bb.88zfp.xyz 这个域名的A记录,CNAME记录或者其他记录,都会出错,因为这个域名,包括它的子域名*.bb.88zfp.xyz都是要由 dns1.fastcdn.com 来解析,这里的默认DNS已经没权限解析


image.png

CDN相关

我们想要mumu-apk.fp.ps.netease.com 这个域名接入CDN, 就要让这个域名cname 到CDN提供的域名


image.png

当然了要CNAME记录也是基于这个域名本来设置了NS记录的,委托了某个服务器作为DNS,然后再记录CNAME记录到他的数据库里面。
执行dig mumu-apk.fp.ps.netease.com +trace 可以看到这个域名netease.com NS记录是ns3.nease.net

image.png

说话来,CNAME到CDN给的域名有什么作用呢,作用就是CNAME到CDN的域名后,这个域名就交给了CDN指定的NS记录来解析,这就相当于我们可以使用上CDN的智能DNS了,不然我们自己的默认的域名DNS一定是没有人家CDN提供的强大。

我们在来 dig mumu-apk.fp.ps.netease.com

image.png

看截图访问我们自己域名转嫁到访问 CDNAME 目标 mumu-apk.fp.ps.netease.com.dlcloud.fastcdn.com.
而这个域名 fastcdn.com的NS记录 dns1.fastcdn.com. dns7.fastcdn.com. 等几个DNS服务器。
从数量上看就比自己的DNS服务器多。

那么问题来了,DNS的服务器有这么多,能只能选择DNS吗?

DNS运营商决定返回的IP

image.png
# 使用googleDNS返回了国外的IP 3.3.3.3
dig @8.8.8.8 www.88zfp.xyz
www.88zfp.xyz.      9   IN  A   3.3.3.3

# 使用了电信的DNS IP, 返回了定义的电信IP 5.5.5.5
dig @202.102.213.68 www.88zfp.xyz
www.88zfp.xyz.      600 IN  A   5.5.5.5

# 默认DNS是联通的,所以返回了联通线路的IP 4.4.4.4
dig  www.88zfp.xyz
www.88zfp.xyz.      10  IN  A   4.4.4.4

当然,有专门的网站做这个

image.png
https://tools.ipip.net/dns.php

充分说明了返回什么IP,是根据LDNS的IP来决定的,也就是本地设置的dns IP 访问到权威DNS服务器的时候,权威DNS根据这个请求的LDNS IP来查找最近线路的IP

所谓权威DNS服务器就是 AUTHORITY SECTION 这部分,之所以是权威,因为我们设置了这个域名88zfp.xyz的NS记录是这两个DNS服务器解析,也就是说他们两个才有权威的资格去解析,所以叫权威服务器

;; AUTHORITY SECTION:
88zfp.xyz.      2299    IN  NS  f1g1ns1.dnspod.net.
88zfp.xyz.      2299    IN  NS  f1g1ns2.dnspod.net.

多个NS记录

要知道最后解析的是权威DNS服务器,也就是NS记录,而这个NS记录是上一级的DNS服务器返回的

.  NS ->  b.root-servers.net 
返回
xyz.  NS ->  z.nic.xyz.  
返回
88zfp.xyz.      3600    IN  NS  f1g1ns1.dnspod.net.
88zfp.xyz.      3600    IN  NS  f1g1ns2.dnspod.net.

所以我之前的问题, 域名指定了多个NS记录,会选哪个来解析,这个问题不是ns记录来选的,而是交给客户端来选,因为上一级DNS就告诉我,这个域名有两个NS记录, 那我请求的时候,只能客户端根据自己的宣发来决定请求哪个。或随机,或取第一个! 不同客户端不同算法

子域名级别 && 泛解析级别

DNS可以解析子域名级别,套餐越高,解析的级数越多。
.com .net .cn 这些都是一级域名 或者 顶级域名
baidu.com qq.com 这些都是二级域名
www.baidu.com, music.qq.com 这些都是三级域名 依次类推

DNS可以解析的 泛解析级别, 是指.88zfp.xyz 这样的解析最多可以到多少级,跟子域名级别一样
比如我们的igor, 新的项目每个都会生成一个域名,都project1.xx.com, project2.xx.com, project3.xx.com
这就是应用了泛域名,注册的时候,增加了
.xx.com的记录 ,然后*的域名就可以随便了

dnspod 子域名级别 这里的含义是指最多可以a.b.c.xx.com 这样3级的解析a.b.c
dnspod 泛解析级别 这里的含义是指最多可以.v.xx.com 这样3级的解析.v
https://buy.cloud.tencent.com/cns?orderStamp=1562815413064

dnspod 不让改 ns 记录

问题:dnspod面板是不可以修改ns记录的,我的88zfp.xyz 域名想换成由www.dns.com提供的NS,怎么办呢?
回答:dnspod 的价值就在于它负责 ns,88zfp.xyz指定了dnspod提供的ns f1g1ns1.dnspod.net ,才有后台的事情,就是让dnspod来解析各种A, CNAME记录,你想在dnspod那里改了这个NS, 那么就是不给dnspod解析呗,那就意义了,所以dnspod肯定不会给你改的。 要怎么改? 就到你注册域名的那个注册商改,那里才是指定NS记录的,指定给谁去解析。所以注册了一个域名,你想给dnspod或者dns.com解析,就是域名注册商修改的,填入你想用的解析商,dnspod 或者 dns.com。
而我的域名是腾讯云那里注册的,所以到那里确实可以修改 https://console.cloud.tencent.com/domain/mydomain

但是在dnspod里面可以,修改3级域名的NS, 比如music.88zfp.xyz 可以在DNSPOD里面设置NS记录到www.dns.com提供的NS服务器。为什么?因为就像层级一样,88zfp.xyz 指向了DNSPOD的基础下,那么它的下面的记录都由它来管理,自然它的DNS数据库就可以存一条记录 music.88zfp.xyz -> dns.com 然后转交给 dns.com解析继续下一层的解析记录。跟DNS解析的一层一层下来,是一个道理

image.png

https://www.v2ex.com/t/360613

dnspod 的价值就在于它负责 ns
你改这个东西不是要人家老命么 (来自一位网友,言简意赅,而且很幽默)

关于DNS 的TTL

这个TTL是指LocalDNS 本地DNS的缓存,当请求解析时,LDNS会向NS请求解析,然后NS会返回TTL给LDNS,告诉它,这个记录你缓存到本地多久,过期前LDNS就都不会再想NS请求解析。所以当修改了DNS解析时,确认各地的 DNS 已经更新完成后,才能确定是生效,因为每个地方缓存结束时间不一样!

记住,这一切都能起作用的前提,是那些 DNS 服务器完全遵守这些标准和规范,NS的TTL配置才能真正起到效果,不然LDNS都不遵循标准,哪怕NS告诉它要TTL 60秒,它擅作主张TTL 2000 就没意义了。当然了,大部分的LDNS都是正常的,遵守规范的
https://jaminzhang.github.io/dns/DNS-TTL-Understanding-and-Config/

指定两个 NS 记录, 一个国外,一个国内,能加速吗?

目前来说,哪怕你指定了,多个NS,要看客户端怎么选择,有的客户端是随机挑NS来访问,有的是第一个请求失败,才会去请求第二个,那这样就没什么意义了。 那怎么解决了?待查证

递归和迭代再认识

递归查询:A --> B --> C --> B --> A
迭代查询:A --> B A --> C --> A
将递归查询和迭代查询的方式放到查询流程中,就如下图所示。(未标出Client指向的DNS服务器)


image.png

也就是说,递归的意思是找了谁谁就一定要给出答案。那么允许递归的意思就是帮忙去找位置,如A对B允许递归,那么B询问A时,A就去帮忙找答案,如果A不允许对B递归,那么A就会告诉B的下一层域的地址让B自己去找。
可以想象,如果整个域系统都使用递归查询,那些公共的根域和顶级域会忙到死,因此更好的方案就是把这些压力分散到每个个人定制的DNS服务器。
所以DNS的解析流程才会如下图。并且在客户端到DNS服务器端的这一阶段是递归查询,从DNS服务器之后的是迭代查询。也就是说,顶级域和根域出于性能的考虑,是不允许给其他任何机器递归的。

image.png

为什么客户端到DNS服务器阶段是递归查询?因为客户端本身不是DNS服务器,它自己是找不到互联网上的域名地址的,所以只能询问DNS服务器,最后一定由DNS服务器来返回答案,所以DNS服务器需要对这个客户端允许递归。因此,dns解析器(nslookup、host、dig等)所发出的查询都是递归查询。

这个网页写得DNS最全
https://www.cnblogs.com/f-ck-need-u/p/7367503.html#auto_id_0

DNS节点分布

包括美国和香港? 这个怎么使用上

如果公共 DNS 和域名所在 NS 如果支持 edns-client-subnet 就可以

DNSPOD 能抗攻击

公共DNS的问题

https://blog.skk.moe/post/which-public-dns-to-use/
https://ephen.me/2017/PublicDns_2/

httpdns

dnspod 提供的httpdns
https://www.dnspod.cn/httpdns/demo

Anycast DNS

查一下,好像国内海外的IP

上一篇下一篇

猜你喜欢

热点阅读