Tianao

Tianao

🏢  网络攻城狮
V2EX 第 122244 号会员,加入于 2015-06-14 13:55:32 +08:00
10 G 24 S 73 B
20231119 午夜俱乐部
天黑以后  •  Tianao  •  148 天前  •  最后回复来自 wweerrgtc
4
iOS 16 锁屏界面的播放控制太容易误触了
Apple  •  Tianao  •  2022-09-18 10:46:28 AM  •  最后回复来自 hucheng518
6
[充电头网]证书过期啦
全球工单系统  •  Tianao  •  2022-02-08 14:09:32 PM  •  最后回复来自 yu1u
3
Dirty 咖啡用牛奶推荐
咖啡  •  Tianao  •  2022-03-01 08:19:00 AM  •  最后回复来自 svaeric
5
[IETF] www.ietf.org 挂了
全球工单系统  •  Tianao  •  2021-10-24 22:09:24 PM  •  最后回复来自 Kinnice
1
Supermicro 官网挂了
全球工单系统  •  Tianao  •  2021-10-21 11:04:00 AM
充电头网 www.chongdiantou.com 挂啦
  •  1   
    全球工单系统  •  Tianao  •  2021-08-27 17:19:44 PM  •  最后回复来自 gesse
    8
    Tianao 最近回复了
    6 天前
    回复了 Moyyyyyyyyyyye 创建的主题 全球工单系统 似乎腾讯云挂了
    @solos #16 堆叠的可靠性和业务连续性能力不能满足数据中心需求是业界共识,就算不上全路由,vPC/M-LAG/MC-LAG + FHRP 也是基础,青云 2015 年因为 H3C 堆叠故障出过大事故。
    6 天前
    回复了 Moyyyyyyyyyyye 创建的主题 全球工单系统 似乎腾讯云挂了
    @solos #14 青云……就是那个数据中心“汇聚层交换机”用堆叠的厂商。
    8 天前
    回复了 DinoStray 创建的主题 职场话题 关于远程办公, 办公地点的一些讨论
    看着成双成对的小情侣卿卿我我。
    8 天前
    回复了 DinoStray 创建的主题 职场话题 关于远程办公, 办公地点的一些讨论
    可以去中学门口的奶茶店,看着小情侣们,就回忆起自己的青春,当时候的我也是这样,
    11 天前
    回复了 Philippa 创建的主题 MacBook Air Macbook Air M3 拓展坞选择
    DisplayLink 和雷雳 4 扩展坞都不便宜,体验也未必有预期的那么好,不如再买个 C 口显示器。ThinkVision T 系列和 P 系列我都搭配过 MacBook, 连接性体验方面没有任何问题。
    国内电话拨打 12308

    如您的中国籍亲属在国外下落不 明,领事官员可以向您提供当地报警方式 及其他获取救助的渠道。所在国警方立案 的,可以敦促所在国警方及时妥善处理。
    ——中华人民共和国外交部领事保护中心《中国领事保护与协助指南》(2023 年 9 月)
    14 天前
    回复了 BridgeCham 创建的主题 咖啡 2024 年有什么咖啡值得推荐或者回购呢
    性价比:肯德基 K 咖啡,咖啡包月卡 5 元/杯。
    @CharonVIII #2 我测试下来,是 Windows 上的 nslookup 实现在通过 UDP 收到 Truncated 置位的应答、转而使用 TCP 并完成 TCP 的 3-way 握手后,会紧接着(也就是在这个 TCP 连接的第 4 个包)发送一个带有 PSH 置位的、仅有 2 bytes 的 TCP payload 的 TCP segment, 我不知道这个 2-byte 载荷的意义是什么(但猜测是用作一个什么出于性能或可用性目的的什么前导?),然后紧接着就收到了来自 223.5.5.5 的 TCP RST (我也不知道 223.5.5.5 为什么要 reset, 但是我猜测是 223.5.5.5 收到了这个不明所以的 TCP 分段,出于节省资源开销/防攻击的目的主动 reset 掉了这个 TCP 连接),然而按照 Windows nslookup 的预期(这一「预期」我使用了其他使用 Windows nslookup 可以正常解析的 DNS 服务器进行了验证),这第 5 个包本应是来自服务端的正常 ACK, 然后 nslookup 再紧接着发送可以和第 4 个包进行 TCP segment reassemble 从而组成一个完整 DNS 请求的 TCP 分段,但是此时 TCP 连接已经被 223.5.5.5 给 reset 掉了。

    目前的判断:Windows 的 nslookup 实现和 223.5.5.5 的某些策略性表现在 TCP 解析时存在兼容性问题。

    目前的建议:在 Windows 上,在 PowerShell 中使用 Resolve-DnsName 能够获得比 nslookup 更接近 Windows DNS 客户端真实表现的测试结果。换言之,在 Windows 上,仅是 nslookup 失败不代表浏览器等真实用户访问行为调用的 DNS 解析也会失败。

    「照理说 A 记录太多的网站肯定不止这一家...」
    对于一般 web 服务的 GSLB, 国内一般都是地理+运营商分区解析,每个分区最终的 A/AAAA 记录真的远没这么多;对于国际化服务,虽然会使用 anycast, 但是 ADNS 会控制每次返回给 recursive DNS 的权威结果数量,也不会一次性返回好几十个 anycast 地址的 A 记录。
    权威解析给这个 CNAME 配的 A 记录太多了,dig 在请求的时候携带了 UDP payload size (比如我的 macOS 的默认是 4096), 所以 223.5.5.5 会直接使用 UDP 返回这个八百多字节的递归解析结果; nslookup 默认没有在请求里携带 UDP payload size 信息,223.5.5.5 默认按 512 对待,返回了 Truncated flag 置位,让客户端去用 TCP 再请求一次。

    至于楼主的 nslookup 为什么没有成功通过 TCP 解析,就要检查 nslookup 的实现、DNS 客户端的配置和 TCP 的联通性了(比如 telnet 223.5.5.5 53 )。我的 macOS 的 nslookup 是会在这样输出之后正确显示最终的 A 记录的:
    nslookup www.ai2moe.org 223.5.5.5
    ;; Truncated, retrying in TCP mode.

    至于为什么阿里的 DoH 没问题,因为 DoH 和使用 53 端口的 DNS 是两个完全不同的协议,不存在这个默认最大 512 字节的限制。

    至于为什么 119.29.29.29 和 114.114.114.114 和运营商 DNS 使用相同的 nslookup 和相同的 DNS 协议也没问题,因为它们直接无视了来自 DNS 客户端的 DNS 请求中携带的 UDP payload size, 偷偷把超长递归解析结果裁剪到不超过 512 字节(在本例中,是通过随机丢弃 A 记录的方式)通过 UDP 直接返回了。
    30 天前
    回复了 zhuantouer 创建的主题 云修电脑 安装 Windows11,识别不了硬盘
    确认下是 GUID 分区表 (GPT) 的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5598 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 06:42 · PVG 14:42 · LAX 23:42 · JFK 02:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.