MySQL默认会触发反向DNS查询以匹配权限表中的主机名，攻击者可通过伪造PTR记录绕过IP限制；应强制启用skip_name_resolve=ON并改用IP/CIDR格式授权。
MySQL 本身不执行 DNS 反向解析（rDNS）来验证客户端身份，除非你显式启用了 skip_name_resolve=OFF（默认是 OFF），且客户端连接时使用的是主机名而非 IP。真正暴露风险的，是 MySQL 在用户权限匹配阶段对主机名做 gethostbyaddr() 调用——这个调用由操作系统发起，不受 MySQL 控制，且极易被伪造的 rDNS 记录干扰。
为什么 MySQL 会触发反向 DNS 查询
当 MySQL 启动时未设置 skip_name_resolve=ON，且用户账号的 Host 字段包含域名（如 'appuser'@'web01.internal' 或通配符 'appuser'@'%.company.com'），那么每次新连接建立时，MySQL 会：① 获取客户端 IP；② 调用系统级 gethostbyaddr() 查该 IP 对应的 hostname；③ 再用这个 hostname 去匹配权限表中的 Host 值。
这个过程完全依赖本地 resolver 和上游 DNS（包括 rDNS 的 PTR 记录），攻击者只要能控制目标 IP 的 PTR 记录（例如租用某云厂商 VPS 并自助配置 rDNS），就可能让 192.0.2.42 解析出 db-admin.prod.company.com，从而绕过本应只允许内网 IP 段的权限限制。
常见错误现象包括：
- 应用在测试环境连得上，上线后偶发“Access denied”——实际是因生产 DNS 缓存了被污染的 rDNS 结果
- 同一 IP 的连接有时成功、有时失败——rDNS 解析超时或返回不同结果导致权限匹配不稳定
- 启用
host_cache表后发现大量HOST_BLOCKED_PERMANENTLY状态——因反复失败的 rDNS 查询触发了 MySQL 的防爆破机制
必须关闭 skip_name_resolve=OFF 的默认行为
这是最直接有效的缓解措施：强制 MySQL 仅基于客户端 IP 地址做权限匹配，跳过所有 hostname 解析环节。它不是“可选优化”，而是面向生产环境的硬性要求。
操作步骤：
- 编辑 MySQL 配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]段下添加：skip_name_resolve = ON
- 重启 MySQL 服务（
systemctl restart mysql） - 确认生效：
SELECT @@skip_name_resolve;应返回1
注意：启用后，所有用户账号的 Host 值必须改用 IP 或 CIDR 格式（如 'appuser'@'10.10.20.0/24'），不能再用域名；否则该账号将永远无法匹配成功。
清理并锁定现有用户 Host 字段
即使设置了 skip_name_resolve=ON，残留的域名型 Host 条目仍可能误导运维判断，甚至在配置误关时造成权限失控。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
建议立即执行：
- 查出所有含域名的用户：
SELECT User, Host FROM mysql.user WHERE Host NOT REGEXP '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}(/.*)?$' AND Host NOT IN ('localhost', '%'); - 逐个改为等效 IP 段（如把
'admin'@'ci-runner.example.com'改为'admin'@'172.20.10.0/28'） - 删除无明确来源 IP 范围的宽泛条目，例如
'devuser'@'%'—— 它等同于允许任意 IP 连接，与 rDNS 漏洞无关，但本身就是高危配置
改完务必执行 FLUSH PRIVILEGES;，且需同步更新应用连接字符串中的 host 参数（不能继续填域名，否则连接会因 DNS 解析失败而超时）。
监控 host_cache 表与连接延迟异常
即便已启用 skip_name_resolve=ON，若某天被临时关闭或配置未生效，host_cache 表就是第一道预警哨兵。
关键检查项：
- 查询缓存中失败记录：
SELECT * FROM performance_schema.host_cache WHERE HOST IS NULL OR HOST LIKE '%error%'; - 关注
HOST_VALIDATED列是否长期为NO，这表示 rDNS 解析持续失败 - 对比
CONNECTED_TIME和LAST_SEEN时间差，若连接建立耗时 >500ms 且集中在某几个 IP，大概率是 rDNS 轮询超时所致
这个表不会自动清空，一旦发现异常模式，应立刻回溯 MySQL 错误日志中类似 Host 'x.x.x.x' is not allowed to connect 或 Could not resolve hostname 的报错行——它们往往藏在看似无关的连接拒绝日志里。
真正危险的不是 rDNS 本身，而是把它和权限控制耦合在一起的设计惯性。很多团队花大力气加固 SSL、审计日志，却让一个系统级的 gethostbyaddr() 调用成为整个访问控制链上最不可信的一环。
