V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
loganwuhan111
V2EX  ›  DNS

困惑于 DNS 解析的完整过程

  •  
  •   loganwuhan111 · 2021-08-03 19:02:45 +08:00 · 3904 次点击
    这是一个创建于 1212 天前的主题,其中的信息可能已经有所发展或是发生改变。

    尝试用 dig +trace www.gov.cn 这条命令来了解 DNS 解析的完整过程。实验机器为 Ubuntu 18.04 。用 wireshark 抓包。本机地址 192.168.0.97

    首先是把 /etc/resolv.conf 改成了自己本地路由器自带的 DNS 地址 192.168.0.1,否则各种 dns 请求都去到了 127.0.0.53 。

    wireshark 显示本机先向 192.168.0.1 发送 DNS query,查询 root 的服务器。192.168.0.1 返回了 13 个根服务器的域名和地址。虽然根服务器的地址已经被包含在 192.168.0.1 的回复里,本机依然向 192.168.0.1 分别发送了 13 个根服务器域名的解析查询,并收到了回复。 问题一

    随后本机在 13 个根服务器的地址中选取了 192.5.5.241 ( F 根服务器),发送了 www.gov.cn 的 query 。192.5.5.241 返回了 a.dns.cn, b.dns.cn .... g.dns.cn 以及 ns.cernet.net 。没有附加对应的地址。 问题二

    于是本机又向 192.168.0.1 分别发送了多个 query,查询以上返回的 a.dns.cn 等域名对应的地址,并收到对应的回复。最后一个来自 192.168.0.1 的回复是:ns.cernet.net 的地址 是 103.137.60.44 。问题三

    到这一步,算是找到了 .cn 的 DNS 服务器了。

    然后本机向 103.137.60.44 发送 DNS query,查询 www.gov.cn 的地址。103.137.60.44 返回了另外三个 DNS 服务器,ns1.cdns.cnns2.cdns.cnns3.cdns.cn 。没有附加对应的地址。 同问题二

    于是本机向 192.168.0.1 分别发送三个 query,查询以上返回的 ns1.cdns.cn 等域名对应的地址,并收到对应的回复。最后一个来自 192.168.0.1 的回复是:ns2.cnds.cn 的地址 是 125.208.46.1 。 同问题三

    到这一步,算是找到了 gov.cn 的 DNS 服务器了。

    最后,本机向 125.208.46.1 发送 query,查询 www.gov.cn 的地址,并收到一个 CNAME 回复。

    问题一:为什么 192.168.0.1 已经返回了根服务器的地址,本机依旧要重新查询呢

    问题二:这里为什么只返回域名,不返回地址呢?

    问题三:这里 192.168.0.1 好像处于上帝视角。问题二通过 192.168.0.1 解决,可能是因为路由器去查询了 ISP 提供的 DNS 服务器。但是在没有上帝视角的情况下,问题二该怎么解决呢?

    问题有点长,感谢阅读。如果需要提供抓包文件,可以商量一下怎么发送过去。

    第 1 条附言  ·  2021-08-03 22:59:51 +08:00
    纠错一下,根服务器其实有一并返回.cn 服务器的地址。但是.cn 服务器确实没有一并返回 gov.cn 服务器的地址。
    15 条回复    2021-08-11 13:13:38 +08:00
    Tianao
        1
    Tianao  
       2021-08-03 19:18:04 +08:00 via iPhone
    我比较困惑的是,如果希望使用迭代查询,就不应该向 192.168.0.1 请求任何查询,因为具有迭代查询能力的主机都是写死根服务器 IP 的。

    如果希望向 192.168.0.1 这种服务器请求查询,则应该直接请求 www.gov.cn 的 A+AAAA 查询,然后坐等上游帮你返回递归解析结果。
    loganwuhan111
        2
    loganwuhan111  
    OP
       2021-08-03 19:37:47 +08:00 via Android
    @Tianao 确实。但我不知道怎么设置。而且其实 dig 也向根服务器进行了查询。
    xiaopc
        3
    xiaopc  
       2021-08-03 20:00:19 +08:00   ❤️ 2
    问题 1,要加 +additional 才使用 glue records

    问题 2,这个需要目标域名的权威 DNS 有配置,比如 qq[.]com 就有
    可以使用 dig ns qq[.]com @g.gtld-servers.net. 测试

    问题 3,再去根服务器查询 .cn 顶级域的 DNS 服务器 IP 啊

    1 楼的问题,ISC 知识库 aa-00208 是这样说的:

    dig may still send queries to the servers listed in /etc/resolv.conf when using +trace

    When following delegation iteratively as specified with the +trace option, dig will begin by requesting the NS records for the servers authoritative for root ("."). These may or may not be supplied with glue - that is A and AAAA records that can be used for the next queries dig has to send. When there is no glue provided, either on the initial query for the root nameservers, or later on when following delegation, dig will revert to recursively querying the servers listed in /etc/resolv.conf to obtain the needed A/AAAA RRsets.
    loganwuhan111
        4
    loganwuhan111  
    OP
       2021-08-03 22:59:00 +08:00
    @xiaopc 谢谢回答。自己又用 dig 做了一些实验,感觉大概理解了。还有一个问题想请教。

    gov.cn 的管理者在 a.dns.cn 那里可以设置是否与 ns1.cdns.cn 一并返回 ns1.cdns.cn 的地址是吗?是否做此设置的考虑因素是什么呢?
    mytsing520
        5
    mytsing520  
       2021-08-04 00:46:38 +08:00   ❤️ 1
    www.gov.cn 为一主域名,其域名为 www,后缀为 gov.cn

    DNS 查询过程为:
    递归 DNS 中存有全球 13 个根服务器的地址,并向其发起 www.gov.cn 的请求。根服务器检索自身只发现了 cn 顶级域的委派记录,并向递归 DNS 返回该信息,里面包含了 cn 的权威 DNS 地址。
    递归 DNS 继续向获得的 cn 的权威 DNS 服务器请求 www.gov.cn 的记录,在 cn 的权威 DNS 中发现了 www.gov.cn 域名的委派记录,并向递归 DNS 返回该信息,里面包含了 www.gov.cn 的权威 DNS 地址。
    递归 DNS 继续向获得的 www.gov.cn 的权威 DNS 服务器请求 www.gov.cn 的记录,在 www.gov.cn 的权威 DNS 中发现了 www.gov.cn 的实际解析记录,向递归 DNS 返回该信息。由于本次请求里面没有发现进一步的委派信息,DNS 请求结束。

    根服务器地址为(a-m).root-servers.net
    CN 顶级域的权威 DNS 地址为(a-g).dns.cn
    www.gov.cn 的权威 DNS 地址为 ns(1-3).cdns.cn
    由于 gov.cn 后缀与 cn 后缀为相同顶级域,因此不再单独查询 gov.cn 的权威 DNS 信息,虽然这个信息确实存在。
    xiaopc
        6
    xiaopc  
       2021-08-04 06:34:01 +08:00
    @loganwuhan111
    必须设置 glue record 的情况:qq[.]com 的 NS 记录是 ns(1-4).qq.com ,如果不为 ns(1-4) 设置解析的话,就存在循环解析的问题了
    其他情况下不是必须的,为了解析速度等因素也可以设置。比如 microsoft[.]com 的 NS 记录是 ns1-205.azure-dns.(com/net/org/info),只为 ns1-205.azure-dns[.]com 做了 glue record
    loganwuhan111
        7
    loganwuhan111  
    OP
       2021-08-04 08:25:47 +08:00 via Android
    @xiaopc 感谢大佬。
    huangmingyou
        8
    huangmingyou  
       2021-08-04 09:33:31 +08:00
    https://datatracker.ietf.org/doc/html/rfc1035 可以读一下这个 rfc 以及其他相关 rfc.
    Kasumi20
        9
    Kasumi20  
       2021-08-04 09:49:23 +08:00
    有这么复杂吗?为什么我写这个 DNS 代理的时候不用考虑这么多?

    https://github.com/develon2015/dnsd
    loganwuhan111
        10
    loganwuhan111  
    OP
       2021-08-04 10:01:34 +08:00
    @Kasumi20 不太了解你这个。如果你是做迭代的查询就会这样复杂吧。我猜你是直接把 DNS 查询转发到类似 8.8.8.8 这样的服务器去了?
    xinghen57
        11
    xinghen57  
       2021-08-04 10:41:24 +08:00 via iPhone
    @Kasumi20 请问如果 dns 查询国内外分流,是在哪个环节实现的?

    比如国内外设置了不同的 dns 查询服务器。
    某网站是.com 后缀,dns 查询时,在那个环节选 dns 服务器?又是依据什么区分国内外 dns 查询服务器的?
    1423
        12
    1423  
       2021-08-04 22:32:16 +08:00
    不应该依赖 dig 吧,dig 的 trace 我理解是调试或者演示用,不是真实的递归 dns 服务器工作流程。
    装一个递归 dns 服务器试一下才能得出正确结论
    xiaooloong
        13
    xiaooloong  
       2021-08-06 11:12:00 +08:00   ❤️ 1
    @xinghen57 递归服务器在做递归时,域名请求被发送到了权威 dns,权威 dns 根据请求者的 ip 判断返回结果。这个递归 dns 一般是省级运营商会有一个。如果你自己去做递归,权威服务器就会根据你的 ip 返回结果。

    比如你是河北联通,你平时用的就是河北联通的 dns,b 站这种带 cdn 的解析出来就是河北的节点。如果你把你电脑上的 dns 服务器改成广州电信的 dns,那解析出来就是广州的 cdn 节点。
    mytsing520
        14
    mytsing520  
       2021-08-08 08:07:35 +08:00   ❤️ 1
    @xinghen57
    在权威 DNS 服务器。
    如果预设了“分流”措施,当权威 DNS 收到请求后,根据请求发起者的 IP 地址(一般为运营商的 IP 地址,如省出口),来匹配“分流”措施中定义的规则,并返回对应的解析结果。
    hermanzeng
        15
    hermanzeng  
       2021-08-11 13:13:38 +08:00
    首先 dig +trace 的过程只是一个展现方式,模拟展现出从根到 tld 到域名权威最后到域名的过程;整个过程是去本地的 Localdns 拿到根的配置,然后在去解析根的域名拿到 IP,在一层层的塞进去去解析,同实际的解析过程略有差异;
    可以根据 https://dns-lookup.jvns.ca/trace.html#baidu.com 这个链接去理解整个解析的过程。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5954 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 41ms · UTC 02:48 · PVG 10:48 · LAX 18:48 · JFK 21:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.