文章目录
相关概念
NS:Name Server 完成域名到IP的转换
每台服务器可以将请求转发给其他名称服务器或把它们负责的子域名的子集委派给其他名称服务器。
Zonefile: 区域文件 包含域名到IP的映射
是当用户请求某个域名时,DNS 系统最终找出 IP 关联记录的地方。Zonefile放置在名称服务器中,通常定义了特定域名下可用的资源,或者可以去获取该信息的位置。
Zonefile 是 Name Server存储其所知道的域名信息记录的文件,一个Zonefile配置一个域,该域下包含多条 RR 记录,定义了该域下资源的位置。名称服务器具有的zonefile越多,他能够权威回答的请求数量就越多。
Zonefile文件的 O R I G I N 表 示 该 区 域 最 高 等 级 的 权 威 , 如 果 一 个 区 域 文 件 被 配 置 为 “ e x a m p l e . c o m ” 域 , 则 ORIGIN 表示该区域最高等级的权威,如果一个区域文件被配置为 “example.com” 域,则 ORIGIN表示该区域最高等级的权威,如果一个区域文件被配置为“example.com”域,则ORIGIN被设置为example.com
RR: Resource Record
在zonefile中,保存着记录。其中最简单的记录形式是,是资源和名称之间的单独映射。它们可以将域名映射到 IP 地址,定义域名的名称服务器,定义域名的邮件服务器
RR记录
格式 name [TTL] IN rr_type value
TTL(Time To Live)可以从全局继承,即在文件首行放一个类似 $TTL 1D 的全局字段,表示生存时间为一天。
@ 用于表明当前区域的名字,属于省略写法
rr_type主要有以下类型
SOA记录(Start Of Authority record):起始授权记录
这种记录是所有Zonefile的强制性记录,必须是Zonefile中的第一个记录( O R I G I N 和 ORIGIN和 ORIGIN和TTL在他之前指定)。
domain.com. IN SOA ns1.domain.com. admin.domain.com.(
12083; zonefile的序列号,每次编辑时增加,slave检查master的序列号是否大于它所在系统的序列号,如果主>从,则更新从,否则不变
3h; zone刷新间隔,从服务器向主服务器轮询检查zonefile是否变更的时间
30m; 区域重试间隔,从服务器slave向再结束刷新时无法联系到master时,等待这么多时间,再次轮询
3w; 到期时间,slave在此时间内无法与master联系,则它不再作为此域的权威来源返回响应,并停止对外服务。
1h; 名称服务器在此文件中找不到所请求的名称时缓存找不到结果的时间
);
- domain.com: 该区域的根,表明该Zonefile用于domain.com域名,可以用@占位符代替,表示前面 $ORIGIN 的内容
- IN SOA: IN(internet) 可以省略不写 SOA 起始授权记录
- ns1.domain.com: 该域的主名称服务器
- admin.domain.com: 该域的文件管理员的邮箱地址,其中的 @ 用 . 代替
A 和 AAAA记录:IPV4和IPV6
格式 host IN A IPv4_address
host IN AAAA IPv6_address
SOA记录指出,主服务器为 ns1.domain.com,ns1.domain.com 也是domain.com 的zonefile定义的,因此需要为其指定地址
ns1 IN A 111.222.111.222
可以不必提供全名 ns1.domain.com, $ORIGIN 会补全其余部分
CNAME 记录(Canonical Name record):域名映射到别名
有一个A记录定义了server1主机,然后使用www作为此主机的别名
server1 IN A 111.111.111.111
www IN CNAME server1
MX记录(Mail eXchange):邮件交换
邮件记录通常不会讲主机映射到某些内容,因为他们适用于整个域,因此MX记录通常没有主机名
IN MX 10 mail.domain.com
如果定义了多个邮件服务器,数字可以昂朱计算机决定发送邮件的服务器的首选项号。数字越低优先级越高。
IN MX 10 mail1.domain.com.
IN MX 20 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
NS记录(Name Server):名称服务器记录
在Zonefile中定义NS记录是因为该Zonefile可能是另外一个Name Server的缓存副本
表明这个域的权威DNS服务器
IN NS ns1.domain.com
IN NS ns2.domain.com
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
每个Zonefile中至少应该定义两个NS服务器,以便一个服务器出问题时DNS可以正确运行,如果只有一个NS记录,大多数DNS服务软件会认为Zonefile无效
PTR(PoinTer)记录:定义域IP相关联的名称,可以认为是A/4A 的逆记录
PTR记录是惟一的,因为他们以.arpa根开始被委派给IP地址所有者,区域互联网注册管理机构管理指派IP地址到组织和服务提供商
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com
一次完整的网络请求的过程 以 http://www.news.google.com 为例
域名解析 --> TCP/IP三次握手 --> client发起http请求 --> server响应http请求 --> 浏览器解析html代码并请求相应资源(js,css,img,video等) --> 浏览器渲染呈现
域名解析
- chrome会首先搜索 浏览器自身的DNS缓存(可以使用 chrome://net-internals/#dns 来进行查看),浏览器自身的DNS缓存有效期比较短,且容纳有限,大概是1000条。如果自身的缓存中存在www.google.com 对应的IP地址并且没有过期,则解析成功。
- 如果(1)中未找到,那么Chrome会搜索 操作系统自身的DNS缓存(可以在命令行下使用 ipconfig /displaydns 查看)。如果找到且没有过期则成功。
- 如果(2)中未找到,那么尝试读取位于C:\Windows\System32\drivers\etc下的 hosts文件,如果找到对应的IP地址则解析成功。
- 如果(3)中未找到,浏览器首先会找TCP/IP参数中设置的 本地DNS服务器,如果要查询的域名包含在本地配置的zonefile中,则完成权威域名解析;如果要查询的域名,不由本地DNS服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个IP地址映射,完成域名解析,此解析不具有权威性。
- 如果(4)中未找到(本地zonefile与缓存解析都失效),则本地DNS服务器根据设置(是否设置转发器)进行查询。
- 若没有设置转发,LDNS会把请求发至 根服务器root, 根服务器收到请求后返回负责这个域名(.com)的名称服务器的一个IP。
- 本地DNS服务器通过该IP请求 .com域的名称服务器,负责 .com 域的服务器收到请求后,自己仍然无法解析,会返回 .com的下一级域名服务器(google.com)的IP,以此类推,直至找到可以解析该域名的名称服务器。
- 在google.com的名称服务器中,找到news.google.com对应的zonefile,在该zonefile中中找到 www.news.google.com 对应的RR记录,即可找到提供服务的服务器IP。
- 若LDNS设置了转发器,则会从第6步开始的把请求转发至上一级DNS服务器,由上一级服务器进行解析,上一级服务器如果不能解析,或找根DNS或把转请求转至上上级,以此循环,最终将解析结果返回给LDNS,由LDNS返回给用户解析结果。
由权威域名服务器返回的DNS解析结果,称为权威应答
而由递归服务器(即本地DNS服务器)返回的解析结果,称为非权威应答,因为递归服务器是通过缓存权威服务器的解析结果来进行应答的,可能存在不同步的问题。从client端来看,client端值发起请求,不管中间如何进行操作,只是在最后获得结果,是一个递归的过程;从LDNS端来看,是一个迭代的过程,LDNS分别依次向root-.com-xxx.com域发起请求并利用响应发起下一波请求,最后将结果返回client。
所谓 递归查询过程 就是 “查询的递交者” 更替, 而 迭代查询过程 则是 “查询的递交者”不变。
TCP的三次握手建立连接
向上文查到的服务器的IP发送http请求
服务器响应http请求
浏览器解析html代码
浏览器渲染呈现
智能调度
在中国大陆,运营商一般是 全省共用 2 组递归 DNS 服务,用的人越多缓存数据越多,用户体验就越好,但是又不能太远,因此通常是省级为单位。所以我们在做智能解析的时候,面对中国大陆这一情况,只能精确到省级进行调度。针对无法市级或者更精确的调度这一问题,在业务配合的情况下可以使用 HTTPDNS 进行更精确的 CDN 调度
edns-client-subnet:LDNS在查询时增加访客的实际IP,来实现权威服务器精准调度
Google 在提供公共递归 DNS 8.8.8.8/8.8.4.4 的时候,虽然可以做到全球任播来尽量将自己的出口 IP 靠近真实访客,但是一个个地区部署节点成本还是非常惊人,而且调度效果并不好。因此 Google 设计了一个协议 EDNS0(edns-client-subnet),允许递归服务器在查询包中加上访客的实际 IP 地址供权威服务器精准调度。
单播,组播(多播),广播以及任播
- 单播 unicast: 目的地址唯一,基于TCP的协议均为单播。每次只有两个实体相互通信,发送端和接收端都是唯一确定的。 在IPv4网络中,0.0.0.0到223.255.255.255属于单播地址。
- 组播 multicast: 把信息同时传递给一组目的地址。它使用策略是最高效的,因为消息在每条网络链路上只需传递一次,而且只有在链路分叉的时候,消息才会被复制。组播报文的目的地址使用D类IP地址, D类地址不能出现在IP报文的源IP地址字段。
- 广播 broadcast: 是指封包在计算机网络中传输时,目的地址为网络中所有设备的一种传输方式。实际上,这里所说的“所有设备”也是限定在一个范围之中,称为“广播域”。广播都是限制在局域网中的,比如以太网或令牌环网络。因为广播在局域网中造成的影响远比在广域网中小得多。以太网和 IPv4网都用全1的地址表示广播,分别是ff:ff:ff:ff:ff:ff和255.255.255.255。令牌环网络使用IEEE 802.2控制域中的一个特殊值来表示广播。
- 任播 anycast: 网络寻址和路由的策略,使得资料可以根据路由拓朴来决定送到“最近”或“最好”的目的地。在网络位址和网络节点之间存在一对多的关系:每一个位址对应一群接收节点, 但在任何给定时间,只有其中之一可以接收到传送端来的资讯。在互联网中,通常使用边界网关协议来实现任播。作为老板,你在公司大喊一声“开发组的过来一个人”, 总会有一个人灰溜溜去响应。
httpDNS 更精确 CDN 调度
httpDNS相关以及进一步切合调度302,实现精准调度
https://blog.csdn.net/sheldon761642718/article/details/64129679
原理
-
客户端直接访问HttpDNS接口,获取业务在域名配置管理系统上配置的访问延迟最优的IP。(基于容灾考虑,还是保留次选使用运营商LocalDNS解析域名的方式)
-
客户端向获取到IP后,就直接往此IP发送业务协议请求。以Http请求为例,通过在header中指定host字段,向HttpDNS返回的IP发送标准的Http请求即可。
发起一个 HTTP 请求到一个线路非常好的节点(例如 BGP 线路),这个节点通过 HTTP 协议拿到访客实际 IP 之后,通过返回 302 重定向 HTTP 状态码,或者在 body 返回一个实际的 URL。
上面提到的 URL 格式通常是 http://IP/ 这样的,直接解析出 IP 地址而不是域名。这样就可以确保访客访问到最合适的节点上实现 IP 级调度,甚至根据用户账号资料(是否 VIP 等)进行更加丰富的调度。当然根据需求也可以解析成 https://节点名.域名/ 这种格式,配合泛域名证书就可以实现 HTTPS 兼容。
dig: domain information groper
https://blog.csdn.net/qq_32907349/article/details/75219548
dig test1.wgw.com @172.28.27.16 +subnet=172.28.21.209
test1.wgw.com: 需要dig的域名 @172.28.27.16 服务器ip
+subnet=172.28.21.209:源ip
本机相当于LDNS,收到subnet请求 test1.wgw.com,采用edns将源ip(即subnet=172.28.21.209)附带在dns解析请求后边,发送给域名解析服务器,服务器根据源ip进行更精确的调度
格式: dig @server name type
@server: the name or IP address of the name server to query.
name: is the name of the resource record that is to be looked up.
type: indicates what type of query is required --- ANY, A, MX, SIG, etc.
选项:
-b<ip地址>:当主机具有多个IP地址,指定使用本机的哪个IP地址向域名服务器发送域名查询请求;
-f<文件名称>:指定dig以批处理的方式运行,指定的文件中保存着需要批处理查询的DNS任务信息;
-P:指定域名服务器所使用端口号;
-t<类型>:指定要查询的DNS数据类型;
-x<IP地址>:执行逆向域名查询;
-4:使用IPv4;
-6:使用IPv6;
-h:显示指令帮助信息。
查询选项:
+trace: 全路径
+tcp: 默认是使用UDP进行查询,强制使用TCP
etc
bind中的配置
DNS & bind从基础到深入 https://www.cnblogs.com/f-ck-need-u/p/7367503.html
下文将以longshuai.com域以及这个域中的主机的定义来说明相关配置方法。
named.conf是named默认加载的配置文件,该配置文件中只能有一个options,在这里面用于配置全局项。其中下例中的directory指令定义区域数据文件的存放目录。
options {
directory "/var/named";
};
除了option,还必需有区域的配置。zone关键字后面接的是域和类,域是自定义的域名,IN是internet的简称,是bind 9中的默认类,所以可以省略。 **type定义该域的类型是"master(主) | slave(从) | stub(子域) | hint(根) | forward(转发)"**中的哪种,file定义该域的区域数据文件(区域数据文件的说明见下文),因为这里是相对路径db.longshuai.com,它的相对路径是相对于/var/named的,也可以指定绝对路径/var/named/db.longshuai.com。
zone "longshuai.com" IN{
type master;
file "db.longshuai.com"
};
除此外,在每个named.conf中还应该配置几个必须的区域。
- 根域名"."的区域配置。
zone "." IN {
type hint;
file named.ca;
}
type hint表示该区域"."类型为hint。dns服务器如何知道根域名服务器在哪里?这就是hint类型的作用,它提示dns服务器根据其区域数据文件named.ca中的内容去获取根域名地址,并将这些数据缓存起来,下次需要根域名地址时直接查找缓存即可。
DNS中的IXFR和AXFR:区域传输使用TCP协议 其他情况使用UDP协议
https://blog.csdn.net/homedesk/article/details/77989241
DNS在进行区域传输的时候使用TCP协议,其它时候则使用UDP协议;TCP协议传输过程中没有长度限制,UDP最长512字节
DNS的规范规定了2种类型的DNS服务器,一个叫主DNS服务器,一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息,而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时,它需要与主DNS服务器通信,并加载数据信息,这就叫做区传送(zone transfer)
完成主从DNS服务器的配置解析文件的同步,来进行容灾。
在较早的DNS实现中,更新区域数据的任何请求都需要通过使用完全区域传输(Full Zone Transfer,AXFR)查询来完全传送整个区域数据库。在Windows 2000以后的DNS系统中,允许进行增量区域传输(Incremental Zone Transfer,IXFR)
区域传输可能会发生在以下任何情况中:
- 当区域的刷新间隔到期时
- 当其主服务器主动向辅助服务器通知区域更改(也就是发出DNS通知notify)时
- 当启动区域的辅助服务器时(辅助DNS服务器只能向主要DNS服务器复制记录)
- 在区域的辅助服务器使用DNS控制台以便手动启动(通过执行“刷新”菜单操作)来自其主服务器的传送时
ref:
DNS完全解读: http://www.cnblogs.com/momenglin/p/8555964.html
完整网络请求:https://blog.csdn.net/seu_calvin/article/details/53304406
DNS原理及实战配置指南:http://blog.51cto.com/zhang789/1858610
90创新学院CDN:https://www.90.cx/init-website/