一、为什么设为127.0.0.1会出现DNS解析失败？ #

首先得明确：127.0.0.1是本地回环地址，当resolv.conf指向它时，系统会尝试调用本地运行的DNS服务（比如systemd-resolved、dnsmasq、BIND这类）来完成域名解析。如果你的本地VM上根本没启动这类DNS服务，或者服务运行异常（比如配置错误、端口被占用），那就会出现你遇到的NXDOMAIN错误、dig无输出这类解析失败的情况。

从你描述的现象来看：当手动指定Google（8.8.4.4）、CloudFlare这类外部DNS服务器时解析成功，说明你的域名在Route53的A记录配置是完全正常的，问题就出在本地的DNS服务上——要么没跑起来，要么没法正常转发请求到上游DNS。

至于为什么Comodo的8.26.56.26也不行，大概率是办公室网络的防火墙策略拦截了对这个DNS服务器的UDP 53端口访问，和resolv.conf指向127.0.0.1本身无关。

二、resolv.conf一般会在哪些场景下被修改？ #

日常运维中，resolv.conf的变更通常来自以下几种情况：

• DHCP自动配置：如果你的VM是通过DHCP获取IP地址，DHCP服务器会自动推送DNS地址到你的系统，覆盖resolv.conf内容。比如dhclient、NetworkManager这类工具都会自动处理这个过程。
• 网络管理工具自动更新：像NetworkManager、systemd-networkd这类主流网络管理服务，会根据你当前的网络配置（比如切换有线/无线、连接不同VPN）自动更新resolv.conf，确保DNS配置和当前网络环境匹配。
• 本地DNS服务的自动配置：如果你的系统安装了systemd-resolved、dnsmasq这类本地DNS转发服务，它们启动时通常会自动把resolv.conf指向127.0.0.1，同时自己负责把解析请求转发到上游DNS。如果这类服务意外停止，就会导致解析失败。
• VPN连接/断开：大部分VPN客户端在连接时会修改resolv.conf，把DNS指向VPN服务器提供的地址；断开时有些客户端会自动恢复原配置，但也有部分可能残留错误配置。
• 容器/虚拟化工具影响：比如Docker、KVM这类工具，在创建容器或虚拟机时，可能会修改主机的resolv.conf来适配虚拟网络环境。
• 手动或脚本修改：管理员手动编辑resolv.conf，或者自动化脚本（比如部署脚本、监控脚本）修改配置。

三、给你的排查建议 #

1. 先检查本地DNS服务状态：比如用systemctl status systemd-resolved或者service dnsmasq status看看服务是否正常运行，有没有报错日志。
2. 确认resolv.conf的管理来源：有些系统（比如Ubuntu）的resolv.conf是软链接到systemd-resolved的配置文件，你可以用ls -l /etc/resolv.conf查看链接指向，确定是哪个服务在管理它。
3. 检查DHCP配置：如果你的VM用DHCP获取IP，查看DHCP服务器推送的DNS地址是否正确——有没有错误推送了127.0.0.1但本地没运行DNS服务？
4. 排查网络策略：针对Comodo DNS无法使用的情况，可以用telnet 8.26.56.26 53或者nc -zv 8.26.56.26 53测试端口是否能通，确认是不是办公室防火墙拦截了。

备注：内容来源于stack exchange，提问作者user93916