TL;DR

正常环境下三层交换机没有配置 ipv6 出口，不应该对 AAAA 的请求有响应。

因为错误配置三层交换机的一个 VLANIP 为 DHCP ，导致三层上的 DNS Server 多了一个 STATIC 的 DNS SERVER ，会尝试走这个出口解析 AAAA ，导致超时。

每次请求的时候都会尝试解析一次之前没有正常解析的 AAAA ，然后就一直超时

下掉这个 DHCP 的 VLANIP 之后一切恢复正常。

正确的处理思路

在业务代码 curl 侧诊断，定位速度慢的瓶颈（ dns 解析）
抓 dns 的包，发现第一次请求新域名会同时返回 A 和 AAAA 结果，AAAA 较慢且超时
看交换机的上游 DNS （见最后），DNSv6 的解析结果列表出现了域名对应的 v6 地址，不符合预期
下掉不合适的三层网关，问题解决

网络拓扑

从外向内看：

光猫
Openwrt(192.168.0.20/24, 出口, DNS)
三层交换机(192.168.0.50/24, DHCP(GW=三层，DNS=三层), DNS Proxy)
服务器(192.168.0.178/24), 走 dhcp ，网关是 50,ubuntu 22.04

抓包

root@port:/etc/ipsec.d/certs# tcpdump -nn port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:39:21.024461 IP 192.168.0.167.44834 > 192.168.0.50.53: 25756+ A? xyzw.example.com. (32)
10:39:21.024583 IP 192.168.0.167.36106 > 192.168.0.50.53: 26490+ AAAA? xyzw.example.com. (32)
10:39:21.026904 IP 192.168.0.50.53 > 192.168.0.167.36106: 26490 ServFail- 0/0/0 (32)
10:39:21.051091 IP 192.168.0.50.53 > 192.168.0.167.44834: 25756 1/0/0 A 120.25.87.140 (48)

很明显，机器发起请求的时候，都会同时请求 A 解析和 AAAA 解析，AAAA 解析延迟也会造成这样的效果。

机器的 ip 的结果

user@web:/opt$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 68:f7:28:2a:59:4d brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.178/24 brd 192.168.0.255 scope global dynamic enp0s25
       valid_lft 74054sec preferred_lft 74054sec
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether e8:b1:fc:ad:03:90 brd ff:ff:ff:ff:ff:ff
user@web:/opt$ ip r
default via 192.168.0.50 dev enp0s25 proto dhcp src 192.168.0.178 metric 100
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.178
192.168.0.50 dev enp0s25 proto dhcp scope link src 192.168.0.178 metric 100

在机器上基于 php/curl 请求

curl 请求正常发，curl_getinfo诊断显示：

    [total_time] => 4.252037
    [namelookup_time] => 4.114418
    [connect_time] => 4.168542
    [pretransfer_time] => 4.222082

也即在 dns 上花费了较多时间

加上这句之后 dns 解析时间正常

curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);

也即强制不解析 ipv6 就好

在机器上 dig 的结果

dig -4

dig -4 baidu.com
秒回
dns 走的是 127.0.0.53#53, resolvd
dig -4 @192.168.0.50 baidu.com
秒回
dig -4 @192.168.0.20 baidu.com
秒回

dig -6

dig -6 baidu.com
15s 后超时
dig -6 @192.168.0.50 baidu.com
秒回
显示的 dns 服务器是
;; SERVER: ::ffff:192.168.0.50#53(::ffff:192.168.0.50)
0.20 同理，不赘述

traceroute 的结果

ygs@port:~$ traceroute baidu.com
traceroute to baidu.com (110.242.68.66), 30 hops max, 60 byte packets
 1  _gateway (192.168.0.50)  0.800 ms  1.084 ms  1.458 ms
 2  bogon (192.168.0.20)  17.737 ms  0.200 ms  17.719 ms
 3  bogon (10.119.0.1)  27.133 ms  27.209 ms  27.127 ms
 4  211.136.62.225 (211.136.62.225)  25.922 ms  25.888 ms  17.708 ms
 ...
 ...

这里出现了最近出现的一个问题：我的 mac 和内网其他机器有时候都会显示为 bogon ，不知道为啥

原因

回到开头，网关上面有一台机器错误的返回了我的子网的 dns 反向解析，当然不认识了，返回 bogon

H3C 交换机诊断结果

已解析 IP

ipv6 部分出现了已解析的 ip ，很明显我的 op 是不可能响应 AAAA 的

DNS 列表

web 侧只看到了 op 的地址，但是深挖一下

[H3C]display dns server
Type:
  D: Dynamic    S: Static

No. Type  IP address
1   S     192.168.0.21
2   D     192.168.100.1

##### 去掉三层接口之后
[H3C]display dns server
Type:
  D: Dynamic    S: Static

No. Type  IP address
1   S

恢复正常

maybeonly

2023-03-14 11:53:05 +08:00

emmmmmm
怎么说
给不给回 AAAA 记录和你用 v4 还是 v6 解析是完全无关的才对
虽然有一些有 bug 或者配置的 dns 服务器没能正确处理 AAAA 记录，但是和他本身有没有 v6 也没有关系才对
回 servfail 虽然不好，但是也不是完全不能接受的
至于 dig 的-6 参数，是指其应当通过 v4 还是 v6 解析……man 里边是这么写的
```
If no server argument is provided, dig consults /etc/resolv.conf; if an address is found there, it queries the name server at that address. If either of
the -4 or -6 options are in use, then only addresses for the corresponding transport will be tried. If no usable addresses are found, dig will send the
query to the local host. The reply from the name server that responds is displayed.
```
而且 dns 这东西是可以被缓存的，连续来同样的查询的话后续可能就是缓存命中而已（没命中的话就要向转发的 dns 查询或者自己做递归）
还有 traceroute 之类的不想让他反向解析的话加上-n 就好了，内网 ip 反解变成 bogon 并没有错。
最后……192.168.100.1 哪儿来的？不管用不用三层交换，建议还是直接下发可靠的 dns ，这个结论上倒是没有错。个人理解不直接使用运营商的 dns 的原因，一来是客户到运营商可能有些 rtt （特别是在 cpe 接入的场合），另一方面会在出口上产生大量的 dns 的 nat 。至于自家的三层交换这俩都不存在，那直接用可靠的内网 dns 就好了。

记录一次 DNS 故障：三层做网关，机器总是请求三层网关的 AAAA DNS 然后超时