就是要你懂DNS--一文搞懂域名解析相关问题 | plantegg

标签: | 发表时间:2023-01-19 13:49 | 作者:
出处:https://plantegg.github.io

一文搞懂域名解析DNS相关问题

本文希望通过一篇文章解决所有域名解析中相关的问题

最后会通过实际工作中碰到的不同场景下几个DNS问题的分析过程来理解DNS

这几个Case描述如下:

  1. 一批ECS nslookup 域名结果正确,但是 ping 域名 返回 unknown host
  2. Docker容器中的域名解析过程和原理
  3. 中间件的VipClient服务在centos7上域名解析失败
  4. 在公司网下,我的windows7笔记本的wifi总是报dns域名异常无法上网(通过IP地址可以上网)

因为这些问题都不一样,但是都跟DNS服务相关所以打算分四篇文章挨个介绍,希望看完后能加深对DNS原理的理解并独立解决任何DNS问题。

下面我们就先开始介绍下DNS解析原理和流程。

Linux下域名解析流程

  • DNS域名解析的时候先根据 /etc/host.conf、/etc/nsswitch.conf 配置的顺序进行dns解析(name service switch),一般是这样配置:hosts: files dns 【files代表 /etc/hosts ; dns 代表 /etc/resolv.conf】( ping是这个流程,但是nslookup和dig不是)
  • 如果本地有DNS Client Cache,先走Cache查询,所以有时候看不到DNS网络包。Linux下nscd可以做这个cache,Windows下有 ipconfig /displaydns ipconfig /flushdns
  • 如果 /etc/resolv.conf 中配置了多个nameserver,默认使用第一个,只有第一个失败【如53端口不响应、查不到域名后再用后面的nameserver顶上】

image.png

上述描述主要是阐述的图中 stub resolver部分的详细流程。这部分流程出问题才是程序员实际中更多碰到的场景

所以默认的nsswitch流程是

image.png

以下是一个 /etc/nsswitch.conf

            
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
            
# cat /etc/nsswitch.conf |grep -v "^#" |grep -v "^$"
passwd: files sss
shadow: files sss
group: files sss
hosts: files dns myhostname <<<<< 重点是这一行三个值的顺序
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
netgroup: nisplus sss
publickey: nisplus
automount: files nisplus sss
aliases: files nisplus

这个配置中的解析顺序是:files->dns->myhostname, 这个顺序可以调整和配置。

Linux下域名解析流程需要注意的地方

Linux下域名解析诊断工具

  • ping
  • nslookup (nslookup domain @dns-server-ip)
  • dig(dig +trace domain)
  • tcpdump (tcpdump -i eth0 host server-ip and port 53 and udp)
  • strace

img

案例

向 /etc/hosts 中添加了一条test.unknow.host, 无法解析到,但是test.localhost可以解析?

      [[email protected] 08:50 /home/ren]
$head -2 /etc/hosts
127.0.0.1  test.unknow.host
127.0.0.1   test.localhost

[[email protected] 08:50 /home/ren]
$ping test.unknow.host
ping: unknown host test.unknow.host

[[email protected] 08:50 /home/ren]
$ping -c 1 test.localhost
PING test.localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from test.localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.016 ms

--- test.localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.016/0.016/0.016/0.000 ms

为什么 test.unknow.host 没法解析到?
可能有哪些因素导致这种现象?

尝试 ping -c 1 test.localhost 的目的是做什么?

看完前面的理论我的猜测是两种可能导致这种情况:

  • /etc/hosts 没有启用
  • 有本地缓存记录了一个unknow host记录

验证

      strace -e trace=open -f ping -c 1 test.localhost

可以通,说明 /etc/hosts 是在起作用的,所以最好验证 /etc/hosts 在起作用的方法是往其中添加一条新纪录,然后验证一下

那接下来只能看本地有没有启动 nscd 这样的缓存了,见后发现也没有,这个时候就可以上 strace 追踪ping的流程了

undefined

从上图可以清晰地看到读取了 /etc/host.conf, 然后读了 /etc/hosts, 再然后读取到我们添加的那条记录,似乎没问题,仔细看这应该是 ip地址后面带的是一个中文字符的空格,这就是问题所在。

到这里可能的情况要追加第三种了:

  • /etc/hosts 中添加的记录没生效(比如中文符号)

dhcp

如果启用了dhcp,那么dhclient会更新在Network Manager启动的时候更新 /etc/resolv.conf

dnsmasq

一般会在127.0.0.1:53上启动dns server服务,配置文件对应在:/run/dnsmasq/resolv.conf。集团内部的vipclient就是类似这个原理。

微服务下的域名解析、负载均衡

微服务中多个服务之间一般都是通过一个vip或者域名之类的来做服务发现和负载均衡、弹性伸缩,所以这里也需要域名解析(一个微服务申请一个域名)

域名解析通过jar、lib包

基本与上面的逻辑没什么关系,jar包会去通过特定的协议联系server,解析出域名对应的多个ip、机房、权重等

域名解析通过dns server

跟前面介绍逻辑一致,一般是/etc/resolv.conf中配置的第一个nameserver负责解析微服务的域名,解析不到的(如baidu.com)再转发给上一级通用的dns server,解析到了说明是微服务自定义的域名,就可以返回来了

如果这种情况下/etc/resolv.conf中配置的第一个nameserver是127.0.0.1,意味着本地跑了一个dns server, 这个服务使用dns协议监听本地udp 53端口

验证方式: nslookup 域名 @127.0.0.1 看看能否解析到你想要的地址

kubernetes 和 docker中的域名解析

一般是通过iptables配置转发规则来实现,这种用iptables和tcpdump基本都可以看清楚。如果是集群内部的话可以通过CoreDNS来实现,通过K8S动态向CoreDNS增删域名,增删ip,所以这种域名肯定只能在k8s集群内部使用

nginx 中的域名解析

nginx可以自定义resolver,也可以通过读取 /etc/resolv.conf转换而来,要注意对 /etc/resolv.conf中 注释的 兼容

https://github.com/blacklabelops-legacy/nginx/issues/36可能是nginx读取 /etc/resolv.conf没有处理好 # 注释的问题

进一步的Case学习:

  1. 一批ECS nslookup 域名结果正确,但是 ping 域名 返回 unknown host
  2. Docker容器中的域名解析过程和原理
  3. 中间件的VipClient服务在centos7上域名解析失败
  4. 在公司网下,我的windows7笔记本的wifi总是报dns域名异常无法上网(通过IP地址可以上网)

参考文章:

GO DNS 原理解析

Linux 系统如何处理名称解析

Anatomy of a Linux DNS Lookup – Part I

相关 [dns 域名解析 相关] 推荐:

就是要你懂DNS--一文搞懂域名解析相关问题 | plantegg

- -
一文搞懂域名解析DNS相关问题. 本文希望通过一篇文章解决所有域名解析中相关的问题. 最后会通过实际工作中碰到的不同场景下几个DNS问题的分析过程来理解DNS. 一批ECS nslookup 域名结果正确,但是 ping 域名 返回 unknown host. Docker容器中的域名解析过程和原理.

修改windows XP 的 VPN域名解析DNS优先级

- 桔子 - iGFW
XP包括之前的系统拨入VPN后,会发现VPN接口配置的DNS的优先级不够而无法对内部主机进行解析. 导致虽然已经连上了vpn但是但是无法打开youtube、twitter等网站,因为系统默认的DNS还是原来的本地连接的DNS,依旧被劫持中. 而通过修改注册表值即可解决这个问题. 1.    点击开始, 点击运行, 键入REGEDIT, 然后按确定.

备用的dns

- - 互联网 - ITeye博客
下载软件 百度找出来了 居然被解析到了本地. cr173 被指向到了 127.0.0.1. 找遍了hosts 和路由器 最后才发现是万恶的联通. 阿里dns 速度和质量都不错. 百度dns 评测说较慢 备胎. 114DNS安全版 (114.114.114.119, 114.114.115.119).

Public DNS Tool-DNS切换工具

- - 无名小卒
Public DNS Tool v9.1下载: dbank| kuaipan| 官方. 无名小卒(Digital Fingerprint: b98c67913fef00419d415179421ab42f) Related Posts. Webluker-免费CDN、DNS解析和网站监控服务.

DNS解析过程及DNS TTL值

- - IT技术博客大学习
标签:   DNS   TTL.    经常说DNS劫持,也常常说域名解析不正确. 在阅读《HTTP权威指南》缓存一章时,提到缓存文档过期采用“生存时间技术”与DNS类似. 所以抽空学习了解了一下DNS的解析过程,以及DNS TTL值的概念. 根域名服务器(root-servers.org)是互联网域名解析系统(DNS)中最高级别的域名服务器,全球仅有13台根服务器.

新网DNS故障

- - 月光微博客
  新网的DNS服务今天出现长时间故障,包括新网自身在内的大量域名都无法解析,导致网站无法打开,例如使用新网服务的jiathis等网站域名都无法解析.   做为一个域名服务商,DNS发生如此长时间的故障,并且导致客户的域名无法解析,实在太不应该了.   建议新网的客户对新网进行集体诉讼,或者干脆把域名转走算了.

DNS服务-详解

- - 操作系统 - ITeye博客
DNS(Domain Name System)域名系统,在TCP/IP网络中有非常重要的地位,能够提供域名与IP地址的解析服务. <1> 客户机提交域名解析请求,并将该请求发送给本地的域名服务器. <2> 当本地的域名服务器收到请求后,就先查询本地的缓存. 如果有查询的DNS信息记录,则直接返回查询的结果.

免费域名解析服务

- - 月光博客
  一般域名使用注册商提供的域名解析服务虽然方便,但功能大多有限,特别是目前国内还会针对某些DNS服务器进行屏蔽,造成网站无法解析的情况出现,因此,使用第三方域名解析服务也是中国网站的必要选择,这里就介绍一些常见的免费域名解析服务.    域名注册商提供的免费服务.    Godaddy:不在Godaddy注册域名,也可以使用Godaddy的域名解析服务,使用方法很简单,登录Godaddy网站后,点击“Add Off-site DNS”即可添加用户的域名,之后将用户域名的DNS设置为Godaddy指定的地址,域名DNS生效后,即可点击添加的域名进行DNS解析设置.

域名解析服务器 – OpenerDNS

- - FreeBuf.COM
OpenerDNS是面向国内普通互联网用户开放的“高速 安全 免费”的域名解析服务器. 还在使用Google DNS或者Opendns吗. 现在就切换到:OpenerDNS地址: 42.120.21.30. 为什么使用OpenerDNS:. 安全:我们保证解析数据的真实性,域名不被污染. 现在就切换到42.120.21.30,所有域名都准确解析了.

域名遭遇DNS污染

- - 望月的博客
费劲九牛二虎之力,终于将在 万网注册的wangyueblog.com这个域名转移到godaddy,然而舒心的日子没有几天,麻烦又来了,由于日益严重的 DNS污染,域名常常出现解析错误,真是屋漏偏逢连夜雨,不过,blogging还得继续,所以还是得想办法,在这里将想法和办法分享,仅供参考. 某些网络运营商为了某些目的,对DNS进行了某些操作,导致使用ISP的正常上网设置无法通过域名取得正确的IP地址.