NextDNS CLI设备名称缺失问题的分析与解决方案

问题现象描述

在家庭网络环境中，当用户通过FritzBox等路由器部署NextDNS CLI服务时，可能会遇到一个典型现象：DNS查询日志中所有请求都显示为来自路由器本身，而局域网内的其他设备名称无法正确显示。尽管通过nextdns discovered命令可以识别到mDNS服务发现的设备，但这些信息并未反映在实际查询日志中。

技术背景分析

这种现象本质上是由DNS查询路径决定的。当路由器作为DHCP服务器时，默认会将自己设置为客户端的第一DNS服务器。此时网络中的数据流向表现为：

1. 终端设备向路由器发起DNS查询 2.路由器将查询转发给实际配置的DNS服务器（如运行NextDNS CLI的Synology NAS）
2. 最终DNS服务器只能看到路由器的IP地址

根本原因定位

问题核心在于DNS查询的"跳数"：

• 单跳架构：设备→NextDNS服务器（可获取真实客户端信息）
• 双跳架构：设备→路由器→NextDNS服务器（丢失原始客户端信息）

当采用第二种架构时，NextDNS服务端只能记录到作为中间节点的路由器IP，无法获取原始请求设备的标识信息。

解决方案实施

对于FritzBox路由器

1. 进入"家庭网络→网络→网络设置"
2. 在IPv4地址部分修改DNS服务器设置
3. 在IPv6地址部分同样指定NextDNS服务器地址
4. 确保DHCP服务下发的DNS设置同步更新

通用解决步骤

1. 登录路由器管理界面
2. 定位DHCP服务器配置区域
3. 将下发给客户端的DNS服务器地址修改为：
   • IPv4：指向运行NextDNS CLI的设备地址
   • IPv6：同样指向NextDNS服务地址
4. 保存配置并重启DHCP服务

注意事项

1. 某些路由器（如FritzBox）存在多个DNS相关配置项，需全部检查
2. IPv4和IPv6需要分别配置
3. 修改后建议：
   • 重启客户端设备以获取新DHCP配置
   • 在NextDNS CLI端执行缓存清除操作
4. 对于无法设置多DNS服务器的情况，可考虑：
   • 使用IPv4和IPv6分别指向不同备用服务器
   • 部署本地DNS缓存服务作为中间层

效果验证

配置生效后，可通过以下方式验证：

1. 在客户端执行nslookup检查使用的DNS服务器
2. 观察NextDNS控制台日志中的客户端标识
3. 使用nextdns log命令查看实时查询记录

正确配置后，日志应能显示各个终端设备的真实主机名或网络标识，而非统一显示为路由器地址。对于部分显示为代码的设备，可通过检查DHCP保留设置或mDNS配置进一步优化识别精度。

进阶建议

1. 对于大型网络，建议部署专业的本地DNS服务
2. 考虑结合mDNS和LLMNR协议增强本地名称解析
3. 定期检查DHCP租约信息与DNS日志的对应关系
4. 在路由器支持的情况下，启用DNS代理日志功能辅助排查