2019-09-08 20:27:35

域名是如何解析的,解析的过程介绍


域名是如何解析的,解析的过程介绍

前几天我增加了一个小工具:Dig+trace域名查询工具,可用于域名解析诊断,今天顺便同大家分享一下域名解析的过程,一起探究一下域名解析的原理,什么是域名我相信各位看官已经不用介绍了,我们直接从域名解析过程开始。

首先,计算机拿到用户输入的域名以后会去查询一个服务器,那就是咱们电脑中设置的DNS服务器,DNS是指 Domain Name System,每个运营商都会提供一个DNS服务器来供用户解析域名,本文不讲DNS的原理,只讲域名的解析过程,所以直接看解析的过程。

以 www.renfei.net 为例,以英文点“.”为界限,会被分为以下几个部分:

.:根
net.:顶级域名
renfei.net.;一级域名
www.renfei.net.:二级域名

解析过程:

; <<>> DiG 9.10.6 <<>> www.renfei.net +trace
;; global options: +cmd
.			1454	IN	NS	a.root-servers.net.
.			1454	IN	NS	b.root-servers.net.
.			1454	IN	NS	c.root-servers.net.
.			1454	IN	NS	d.root-servers.net.
.			1454	IN	NS	e.root-servers.net.
.			1454	IN	NS	f.root-servers.net.
.			1454	IN	NS	g.root-servers.net.
.			1454	IN	NS	h.root-servers.net.
.			1454	IN	NS	i.root-servers.net.
.			1454	IN	NS	j.root-servers.net.
.			1454	IN	NS	k.root-servers.net.
.			1454	IN	NS	l.root-servers.net.
.			1454	IN	NS	m.root-servers.net.
;; Received 239 bytes from 192.168.3.1#53(192.168.3.1) in 2181 ms

net.			172800	IN	NS	j.gtld-servers.net.
net.			172800	IN	NS	k.gtld-servers.net.
net.			172800	IN	NS	f.gtld-servers.net.
net.			172800	IN	NS	a.gtld-servers.net.
net.			172800	IN	NS	i.gtld-servers.net.
net.			172800	IN	NS	g.gtld-servers.net.
net.			172800	IN	NS	h.gtld-servers.net.
net.			172800	IN	NS	l.gtld-servers.net.
net.			172800	IN	NS	m.gtld-servers.net.
net.			172800	IN	NS	d.gtld-servers.net.
net.			172800	IN	NS	c.gtld-servers.net.
net.			172800	IN	NS	e.gtld-servers.net.
net.			172800	IN	NS	b.gtld-servers.net.
net.			86400	IN	DS	35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
net.			86400	IN	RRSIG	DS 8 1 86400 20190921050000 20190908040000 59944 . U67D4A1ac4cMhMsLOfaOVPYUOXvFr0++r1oYMt1o2m+j/XV3pXktCOGG tH+eBNlbMsiSGmD9mKeJ+2Rp87gVm4vLO6tDMiqS9YRp7Z5IsojcdqUL C6MnXYoQGSv9QuJhKG2mJKaJiYqK4REjZRqWo+UbnpTw200UZrLHw2pe 8/S8LsxWLOR/g9vAma22hj36McHjakbBIIRUE3CMkOwn9tIfYVwBqpnO ssETDNElvF0ZqM1NDzi9ryA5ftmZDWvBMvog6xWsAAFGikEIyTpiGV83 HV9CyLyIouDD1dpVKzh7bK4AdkHfQ5BNNR01FNnAfQWw6DwKGnXHwV1Q SMLB4A==
;; Received 1171 bytes from 192.5.5.241#53(f.root-servers.net) in 5 ms

renfei.net.		172800	IN	NS	elsa.ns.cloudflare.com.
renfei.net.		172800	IN	NS	ian.ns.cloudflare.com.
renfei.net.		172800	IN	NS	jack.ns.cloudflare.com.
renfei.net.		172800	IN	NS	kim.ns.cloudflare.com.
renfei.net.		172800	IN	NS	lee.ns.cloudflare.com.
renfei.net.		172800	IN	NS	todd.ns.cloudflare.com.
renfei.net.		172800	IN	NS	tom.ns.cloudflare.com.
renfei.net.		172800	IN	NS	will.ns.cloudflare.com.
renfei.net.		172800	IN	NS	coco.ns.cloudflare.com.
renfei.net.		172800	IN	NS	mary.ns.cloudflare.com.
renfei.net.		172800	IN	NS	albert.ns.cloudflare.com.
renfei.net.		172800	IN	NS	peyton.ns.cloudflare.com.
renfei.net.		172800	IN	NS	robin.ns.cloudflare.com.
renfei.net.		86400	IN	DS	2371 13 2 AB869C32F05DF68F733BC57F2B5993A5CD00566A6C4CAD102A9CD36C 3F9A2F9A
renfei.net.		86400	IN	RRSIG	DS 8 2 86400 20190912095909 20190905084909 59540 net. E5YYPNXrbiCLEj/yQY1BjylrPMdhKj2r60GM6xExVjpyBGMA6cshXhZT wHsEtgEHMoXRCLw9zMREM37vzeDIGUP2VkiIQkM57BzPQutoOyqB/Eyf 32DNnT956MD+De7sFZB8qcpHDNTYNf7qr0pN2w3f4pl8RSzjEW0iNe+s ffsJ4iVUJ1LQ++q1kDlucghh7sab54VduGjaE5LWyEQPAA==
;; Received 551 bytes from 2001:502:1ca1::30#53(e.gtld-servers.net) in 201 ms

www.renfei.net.		43200	IN	A	104.18.60.69
www.renfei.net.		43200	IN	RRSIG	A 13 3 43200 20190909122105 20190907102105 34505 renfei.net. yAj+eHswgX/Ltevl3iHhYZTD5jKG742yVltIoX3KilobjWz2mHjY/dPw iWGPt381JqwGWXuG+Yo/70n4MpsZ/A==
;; Received 191 bytes from 173.245.59.118#53(ian.ns.cloudflare.com) in 199 ms

解析过程一:寻找根解析服务器

我们根据 Dig+trace 的解析跟踪会看到,先查询了 . 根的 NS 记录,NS 就是 NameServer,根域名服务器是规定死的,一共13台服务器,分别是a、b、c、d、e、f、g、h、i、j、k、l、m,由于早期的 DNS 查询结果是一个512字节的 UDP 数据包。这个包最多可以容纳13个服务器的地址,因此就规定全世界有13个根域名服务器,编号从a.root-servers.net一直到m.root-servers.net。

在获得13个根服务器后,随机挑选一个

解析过程二:寻找 net.解析服务器

上面的过程拿到根域名服务器地址以后,就会去询问根服务器,net. 的 NS 记录是什么?这时候我们看到 f.root-servers.net 进行了应答,耗时 5ms,又拿到了 从a.gtld-servers.net一直到m.gtld-servers.net 的服务器

解析过程三:寻找 renfei.net.解析服务器

上面的过程拿到net.域名服务器地址以后,就会去询问net.服务器,renfei.net. 的 NS 记录是什么?这时候我们看到 e.gtld-servers.net 进行了应答,耗时 201ms,拿到了一组 NS 服务器,因为到 renfei.net. 这一级,已经是用户注册的域名了,所以我们可以自定义自己的 NS 服务器

解析过程四:寻找 www.renfei.net.的解析记录

上面的过程拿到renfei.net.域名服务器地址以后,就会去询问renfei.net.服务器,www.renfei.net. 的解析记录是什么?这时候我们看到 ian.ns.cloudflare.com 进行了应答,回复了一条 A 记录,值是 104.18.60.69,这样我们就拿到了最终的 IP 地址,解析过程结束


题外话,肯定有同学问根服务器这么重要,都在谁手里管理呢?

这13台根域名服务器中名字分别为“A”至“M”,其中10台设置在美国,另外各有一台设置于英国、瑞典和日本。

1个为主根服务器,放置在美国。其余12个均为辅根服务器,其中9个放置在美国,欧洲2个,位于英国和瑞典,亚洲1个,位于日本。

所有根服务器均由美国政府授权的互联网域名与号码分配机构ICANN统一管理,负责全球互联网域名根服务器、域名体系和IP地址等的管理。

2010年3月16日前,中国大陆有F、I、J这3个根域DNS镜像,但因为某些不和谐原因,中国大陆境内的I根域镜像曾被撤销路由通告。现今,中国大陆境内共有F、I、J、L这4个根域的6台DNS镜像(L有三台镜像)在提供服务。


商业用途请联系作者获得授权。
版权声明:本文为博主「任霏」原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://www.renfei.net/posts/1003287
评论与留言
以下内容均由网友提交发布,版权与真实性无法查证,请自行辨别。

本站有缓存策略,时间约2小时后能看到您的评论。本站使用自动审核机制,如果您的内容包含广告/谩骂/恐怖/暴力/涉政等不和谐内容将无法展示!


本站有缓存策略,时间约2小时后能看到您的评论。本站使用自动审核机制,如果您的内容包含广告/谩骂/恐怖/暴力/涉政等不和谐内容将无法展示!

关注任霏博客
扫码关注「任霏博客」微信订阅号
微博:任霏博客网
Twitter:@renfeii
Facebook:任霏
最新留言 优先级低的并不代表一定要等到优先级高的运行完才能运行,只是cpu分配的资源少了而已。 /lib64/ld-linux-x86-64.so.2: No such file or directory 报了这个错误,怎么解决呢 对于一个布道 DevOps 多年的选手来讲,看到这个报告,还是想继续布道布道。虽然是各种对比哈,但是我感觉与 DevOps 太像了(可能是职业病犯了哈)。首先声明本人不是GitLab 用户(因为不免费,没法薅羊毛啊),本人是 GitHub 忠实用户。 首先,你这是田忌赛马的对比,中文对比一事,着实有点可笑 1 土生土长和外来户能立马拉到同一个起跑线上吗? 2 一个真正的开发者应该去提升自己的英语能力,而不是拿全部是中文文档说事。大家都知道现在开源非常热,开发者是开源的主力军,如果要贡献优秀的开源项目(诸如Linux 内核,Kubernetes),英语就是个硬门槛。如果我是你,我倒希望公司内部的系统是英文的,最起码能让我锻炼英语,在看开源项目文档的时候不至于看不懂,提 PR 的时候不至于提交代码的内容描述不清楚而没法被 Merge。 其次,阿里云效、Coding 大家都知道背后站的是谁,很容易造成厂商绑定,现在很多企业都希望不要被厂商绑定。 再者,有一个点需要明白,GitLab 是一个 DevOps 平台,什么叫做 DevOps 平台(DevOps 走到现在,确切的说应该叫做 DevSecOps)?就是覆盖了软件开发生命周期全阶段的,从项目管理到代码托管到安全再到日志监控、甚至包含现在的云原生能力。不仅仅是说一个 CI/CD 就能概括的了的。这一点是 DevOps 布道的真正误区,我见过太多了,我在这儿再布道一哈,CI/CD 不等于 DevOps,他只是 DevOps 落地实践的核心能力。仅凭借一个 CI/CD 能有现成模版就判断出哪个好坏,过于牵强了吧。相信大家真正到项目用的时候,模版是满足不了要求的吧,毕竟大家都很特性化。 最后,还是一个很热的话题,开源,open source。GitLab 是开源的,Coding 和 云效这方面我没看到相关的开源内容(可能是我孤陋寡闻)。大家可以看看国内有多少用 GitLb 的,GitLab 的 CE 版,然后私有化部署,就是很多公司的代码托管 + DevOps 解决方案。 个人愚见,做一些对比报告的时候,还是先需要明白这个产品的定位,去深入挖掘一些真正有意义的对比,这样的对比报告才能有意义。作为一个常年写博客、文章的人来说。你写的每个字、每篇文章,你要想到你的思想会影响到别人。有可能因为你的片面之词,让别人错失一些学习的好机会。 docker run 那一长串后,出来一个字符串,然后去 docker containers 下面看 显示 exited(1);logs 下就一行错误 initdb failed 感谢🙏,第一个问题是空格的问题应该,我逐字敲完后可以构建了.第二个问题是我docker环境的问题,docker更新为最新版后需要重置配置文件.现已经正常使用,再次感谢您的分享和您的细心解答,期待下次相遇😄 还有一个问题可以请教下吗?就是我在容器里建文件夹没有权限,su root后密码不知道是多少,sudo mkdir xxx 提示我,没有sudo命令,请问有好的解决方法吗?谢谢解答 -v 后面可以指定文件吗 我的也是报错,还有。我执行了这个:@localhost kingbase-es-v8-r3-docker % docker run -d --name kingbase -p 54321:54321 -e SYSTEM_PWD=SYSTEM -v /opt/kingbase/data:/opt/kingbase/data -v /opt/kingbase:/opt/kingbase/Server/bin kingbase:v8r3 docker: 'run -d --name kingbase -p 54321:54321 -e SYSTEM_PWD=SYSTEM -v /opt/kingbase/data:/opt/kingbase/data -v /opt/kingbase:/opt/kingbase/Server/bin kingbase:v8r3' is not a docker command. See 'docker --help' 麻烦帮忙看下,是不是我写的命令有问题,还是版本问题,谢谢啦 请问我build的时候一直报错,是资源没了吗?failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head "https://reg-mirror.qiniu.com/v2/library/centos/manifests/7?ns=docker.io": Moved Permanently 能不能在代码那里详细解释一下啊,没完全懂呀 en 按照路径上的来操作的,但是启动时一直报:zsh: no such file or directory: docker run -d --name kingbase -p 54321:54321 -e SYSTEM_PWD=SYSTEM -v /Volumes/installation/opt/kingbase/data:/opt/kingbase/data -v /Volumes/installation/opt/kingbase/bin/license.dat:/opt/kingbase/Server/bin/license.dat kingbase:v8r3 错误