域名解析

一、域名解析失败

 1、看是局部还是全部，还是公网？

2、一般要么是dns端口不通，dns没有解析。或者机器conntrack表满了。

3、或者到客户家里换个dns地址试试

4、公网欧洲，就别解析到国内了。添加一些欧洲的运营商，就近解析。

域名选择： 粗暴认为域名有几个点，就是几级域名。

　　域名多一级，dns就要多递归一次，耗时就会增加。层级最多不能超过5层。

二、nslookup

nslookup example.com

nslookup example.com 8.8.8.8   #指定DNS服务器

nslookup ：超时(网络问题)还是无解析(域名解析问题)

三、DNS服务器地址

DNS服务器地址，例如8.8.8.8 和 8.8.4.4（Google DNS）或1.1.1.1 和 1.0.0.1（Cloudflare DNS）。

知名的 DNS 有 Google 的“8.8.8.8”，Microsoft 的“4.2.2.1”，还有 CloudFlare 的“1.1.1.1”等等。

工具:

Best NetTools

阿里和听云的拨测工具

 四、域名解析

DNS 的核心系统是一个三层的树状、分布式服务，基本对应域名的结构：

1、根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的 IP 地址；

2、顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，比如 com 顶级域名服务器可以返回 apple.com 域名服务器的 IP 地址；

3、权威域名服务器（Authoritative DNS Server）：管理自己域名下主机的 IP 地址，比如 apple.com 权威域名服务器可以返回 www.apple.com 的 IP 地址。

在这里根域名服务器是关键，它必须是众所周知的，否则下面的各级服务器就无从谈起了。目前全世界共有 13 组根域名服务器，又有数百台的镜像，保证一定能够被访问到。

有了这个系统以后，任何一个域名都可以在这个树形结构里从顶至下进行查询，就好像是把域名从右到左顺序走了一遍，最终就获得了域名对应的 IP 地址。

例如，你要访问“www.apple.com”，就要进行下面的三次查询：1、访问根域名服务器，它会告诉你“com”顶级域名服务器的地址；2、访问“com”顶级域名服务器，它再告诉你“apple.com”域名服务器的地址；3、最后访问“apple.com”域名服务器，就得到了“www.apple.com”的地址。

在核心 DNS 系统之外，还有两种手段用来减轻域名解析的压力，并且能够更快地获取结果，基本思路就是“缓存”。

首先，许多大公司、网络运行商都会建立自己的 DNS 服务器，作为用户 DNS 查询的代理，代替用户访问核心 DNS 系统。这些“野生”服务器被称为“非权威域名服务器”，可以缓存之前的查询结果，如果已经有了记录，就无需再向根服务器发起查询，直接返回对应的 IP 地址。

这些 DNS 服务器的数量要比核心系统的服务器多很多，而且大多部署在离用户很近的地方。比较知名的 DNS 有 Google 的“8.8.8.8”，Microsoft 的“4.2.2.1”，还有 CloudFlare 的“1.1.1.1”等等。

其次，操作系统里也会对 DNS 解析结果做缓存，如果你之前访问过“www.apple.com”，那么下一次在浏览器里再输入这个网址的时候就不会再跑到 DNS 那里去问了，直接在操作系统里就可以拿到 IP 地址。

另外，操作系统里还有一个特殊的“主机映射”文件，通常是一个可编辑的文本，在 Linux 里是“/etc/hosts”，在 Windows 里是“C:\WINDOWS\system32\drivers\etc\hosts”，如果操作系统在缓存里找不到 DNS 记录，就会找这个文件。

有了上面的“野生”DNS 服务器、操作系统缓存和 hosts 文件后，很多域名解析的工作就都不用“跋山涉水”了，直接在本地或本机就能解决，不仅方便了用户，也减轻了各级 DNS 服务器的压力，效率就大大提升了。下面的这张图比较完整地表示了现在的 DNS 架构。

在 Nginx 里有这么一条配置指令“resolver”，它就是用来配置 DNS 服务器的，如果没有它，那么 Nginx 就无法查询域名对应的 IP，也就无法反向代理到外部的网站。 

resolver 8.8.8.8 valid=30s;  #指定Google的DNS，缓存30秒 

五、域名配置

站点域名根据全球化部署的需求，使用vivien.vtech.com/*进行地区指向，将会需要根据每个部署地区购买单独的域名指向服务产生额外的费用，并需要运维在各部署地区进行域名解析的维护，且不同地区进行访问时，会造成先通过当前地区进行解析，再进行指向地区跳转，导致站内资源访问路径加长，出现访问延迟或超时的问题。

为保证站点用户服务高效性，域名方案调整为*.vivien.vtech.com（*为地区英文缩写）

方案一：vivien.vtech.com/* 

 1、证书配置：

　　vivien.vtech.com/* 属于路径级别部署，实际域名证书需要针对主域名申请。

　　即，只需要购买为vivien.vtech.com 主域名申请一个证书（如泛域名证书 *.vtech.com），即可覆盖所有路径（如 /us、/eu）。

2、但所有用户访问同一个域名 vivien.vtech.com，需通过 全局负载均衡（GSLB） 或 基于路径的CDN规则 动态分配流量到不同地区的服务器。

➜ 技术依赖：

• 需购买支持多地区路由的GSLB服务（按地区节点收费，如AWS Route 53、Cloudflare Load Balancer）

• 或为每个地区单独配置CDN服务（如美国CDN、欧洲CDN），按地区实例计费

• 每次新增地区需更新全局路由策略，运维复杂度高

3、访问路径

用户访问 vivien.vtech.com/*us 的完整链路：
1. 用户DNS查询 -> 本地DNS递归解析 -> 根域名服务器 -> 权威DNS返回vivien.vtech.com的IP（GSLB地址）
2. 用户请求到达GSLB -> GSLB根据用户IP判断地区 -> 返回目标地区CDN的IP（如美国CDN）
3. 用户重定向到美国CDN -> 最终访问资源

问题：

• 多次跳转：GSLB判断和CDN重定向增加200-500ms延迟

• 单点瓶颈：GSLB故障会导致全球服务中断

• 跨地区回源：若CDN未缓存资源，可能需从其他地区回源，进一步增加延迟

方案二：*.vivien.vtech.com

1、证书配置：若使用通配符证书 *.vivien.vtech.com，该证书可自动覆盖所有地区子域名（如us.vivien.vtech.com），无需为每个地区单独购买证书。 

2、地区化子域名 + 本地化解析

• 地区化子域名 + 本地化解析
  用户直接访问 us.vivien.vtech.com（美国）、eu.vivien.vtech.com（欧洲）等子域名，通过 DNS分权解析 实现：

  • 每个子域名可独立配置DNS记录，指向本地CDN或服务器

  • 无需依赖全局GSLB，各地区DNS解析自治
    ➜ 成本优化：

  • 无需购买全局GSLB服务，直接使用本地DNS（如地区性DNS服务商）

  • CDN可按地区独立选择低成本服务商（如美国用Cloudfront、欧洲用BunnyCDN）

3、访问路径

用户访问 us.vivien.vtech.com 的链路：
1. 用户DNS查询 -> 本地DNS直接解析 us.vivien.vtech.com 的IP（指向美国CDN）
2. 用户直连美国CDN -> 获取资源

优化效果：

• 减少GSLB跳转环节，路径缩短50%以上

• DNS解析结果缓存于本地，后续访问时延趋近于0

区别：

旧访问链路：
用户 -> 本地DNS -> 全球GSLB -> 目标区域CDN（平均增加200ms）

新访问链路：
用户 -> 地区专属DNS -> 本地CDN（平均时延降低至50ms内）

六、域名新玩法

有了域名，又有了可以稳定工作的解析系统，于是我们就可以实现比 IP 地址更多的“新玩法”了。

第一种，也是最简单的，“重定向”。

因为域名代替了 IP 地址，所以可以让对外服务的域名不变，而主机的 IP 地址任意变动。当主机有情况需要下线、迁移时，可以更改 DNS 记录，让域名指向其他的机器。

比如，你有一台“vivien.tech”的服务器要临时停机维护，那你就可以通知 DNS 服务器：“我这个vivien.tech域名的地址变了啊，原先是 1.2.3.4，现在是 5.6.7.8，麻烦你改一下。”DNS 于是就修改内部的 IP 地址映射关系，之后再有访问vivien.tech 的请求就不走 1.2.3.4 这台主机，改由 5.6.7.8 来处理，这样就可以保证业务服务不中断。

第二种，因为域名是一个名字空间，所以可以使用 bind9 等开源软件搭建一个在内部使用的 DNS，作为名字服务器。

这样我们开发的各种内部服务就都用域名来标记，比如数据库服务都用域名“mysql.inner.app”，商品服务都用“goods.inner.app”，发起网络通信时也就不必再使用写死的 IP 地址了，可以直接用域名，而且这种方式也兼具了第一种“玩法”的优势。

第三种“玩法”包含了前两种，也就是基于域名实现的负载均衡。

1、因为域名解析可以返回多个 IP 地址，所以一个域名可以对应多台主机，客户端收到多个 IP 地址后，就可以自己使用轮询算法依次向服务器发起请求，实现负载均衡。

2、域名解析可以配置内部的策略，返回离客户端最近的主机，或者返回当前服务质量最好的主机，这样在 DNS 端把请求分发到不同的服务器，实现负载均衡。

前面我们说的都是可信的 DNS，如果有一些不怀好意的 DNS，那么它也可以在域名这方面“做手脚”，弄一些比较“恶意”的“玩法”，举两个例子：“域名屏蔽”，对域名直接不解析，返回错误，让你无法拿到 IP 地址，也就无法访问网站；“域名劫持”，也叫“域名污染”，你要访问 A 网站，但 DNS 给了你 B 网站。

 

总结：

1、域名使用字符串来代替 IP 地址，方便用户记忆，本质上一个名字空间系统；

2、DNS 就像是我们现实世界里的电话本、查号台，统管着互联网世界里的所有网站，是一个“超级大管家”；

3、DNS 是一个树状的分布式查询系统，但为了提高查询效率，外围有多级的缓存；

4、使用 DNS 可以实现基于域名的负载均衡，既可以在内网，也可以在外网。

 

七、俄罗斯

阿里/腾讯/华为/google/亚马逊 都不支持俄罗斯的的市场；

现在只有金山支持俄罗斯环境，但是金山需要确认是否有充足的服务器资源

 

俄罗斯服务商：yandex

 

八、Tips

1、浏览器地址栏里随便输入一个不存在的域名，比如就叫“www. 不存在.com”，试着解释一下它的 DNS 解析过程。

浏览器缓存->操作系统缓存->hosts->dns

dns：1、先本地网卡被分配的 dns server ip 来进行解析（dns server ip 一般是“非官方”的ip，比如谷歌的“8.8.8.8”，本身它也会对查找的域名解析结果进行缓存）

        2、先去顶级域名服务器“com”去查找“不存在.com”的域名服务器ip，结果发现不存在，于是直接返回告诉浏览器域名解析错误（当然这两次查找过程是基于udp协议 ）

 

2、DNS失效或者出错：Failed host lookup

 

3、早期的域名系统只支持使用英文，而且顶级域名仅限制在3个字符以内。但随着互联网的发展，现在已经解除了这些限制。

可以使用中文做域名，而且新增了“asia”、“media”、“museum”等许多新类别的顶级域名

 

域名是大小写无关的，但通常都是用小写的形式。

 

4、过长的域名或者过多的层次关系也会导致与IP地址同样难于记忆的问题，所以常见的域名大多是两级或三级，四级以上的很少见。

 

5、域名总长度限制在253个字符以内，而每一级域名长度不能超过63个字符

 

6、你有一个网站要上线，你在域名注册商那里申请了abc.com,那么你的域名A记录就保存在这个域名注册商的DNS服务器上，该DNS服务器称为权威域名服务器。

当客户端访问abc.com时，先查找浏览器DNS缓存，没有则查找操作系统DNS缓存，在这一阶段是操作系统dnscache clinet 服务进行DNS缓存的

（你在任务管理器里面可以看到一个dns客户端进程，就是这玩意实现缓存的）。

如果还是没有则查找hosts文件中的域名记录。然后依然没有的话则访问电脑上设置的DNS服务器IP，比如三大营运商的dns服务器或者谷歌的8.8.8.8，此时这一层的DNS服务器称为“野生DNS缓存服务器”，也就是非权威域名服务器。

如果还是没有则非权威域名服务器会去查找 根域名服务器-顶级域名服务器-二级域名服务器-权威域名服务器 ，这样客户端就在权威域名服务器上找到了abc.com对应的IP了。

这个IP可以是多个，每次客户端请求的时候域名服务器会根据负载均衡算法分配一个IP给你。当DNS缓存失效了，则重新开始新一轮的域名请求。

总结如下： 浏览器缓存->操作系统dnscache ->hosts文件->非权威域名服务器->根域名服务器->顶级域名服务器->二级域名服务器->权威域名服务器。

其中非权威域名服务器还包括LDNS（企业内网DNS服务器），三大营运商DNS，谷歌公开的DNS，微软公开的DNS等。

另外DNS请求有两种方式：递归查询和迭代查询。

LDNS往后面查询一般是递归查询，因为公司内网是有防火墙的，全部请求通过LDNS来递归查询然后把结果给内网用户。