Composer不支持DNSSEC验证，其DNS解析依赖系统或PHP运行时，DNSSEC校验由系统级DNS服务决定；防劫持主防线是secure-http:true强制HTTPS和security.signature:true启用签名验证。
Composer本身不支持DNSSEC验证
Composer没有内置DNSSEC解析能力，也不参与域名系统层级的签名验证。它依赖PHP底层的cURL或stream函数发起HTTP(S)请求，而DNS解析完全交给操作系统或PHP运行时的resolver（如getaddrinfo），DNSSEC校验由系统级DNS服务（如systemd-resolved、dnsmasq）或上游DNS服务器决定，Composer对此无控制权。
真正起作用的是系统DNS配置，不是composer config
想让Composer请求免受DNS劫持，关键不在Composer命令，而在你运行它的环境是否使用了支持DNSSEC的DNS服务。常见有效路径：
- 把系统DNS设为支持DNSSEC的公共解析器，例如Cloudflare
1.1.1.1或 Google8.8.8.8（注意：Google DNS不验证DNSSEC，仅转发；Cloudflare默认启用并强制验证） - Linux下启用
systemd-resolved并开启DNSSEC：sudo systemctl edit systemd-resolved→ 加入[Resolve] DNSSEC=required - macOS可通过
scutil --dns确认当前resolver是否报告dnssec: enabled；若无，需换用支持DNSSEC的DNS配置（如使用dnscrypt-proxy） - 群晖NAS等嵌入式系统通常默认关闭DNSSEC，需在「控制面板 → 网络 → 网络界面 → 编辑 → DNS服务器」中手动填入
1.1.1.1，并在SSH中运行resolvectl dns eth0 1.1.1.1 && resolvectl dnssec eth0 yes
HTTPS + 签名验证才是Composer的防劫持主防线
DNS劫持只是中间一环，Composer真正的防护靠两层叠加：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
-
secure-http: true（默认开启）→ 强制所有源必须走HTTPS，防止HTTP明文响应被篡改 -
security.signature: true→ 启用packagist.org官方签名验证，确保packages.json元数据未被镜像或中间节点篡改 - 即使DNS被劫持到假IP，只要该IP无法提供有效的TLS证书（或证书域名不匹配），cURL会直接报错中断；即使证书伪造成功，signature字段缺失或校验失败也会导致
composer install拒绝写入vendor/
镜像源配置错误会直接废掉DNSSEC和签名保护
很多人以为换镜像=防劫持，实际恰恰相反：
- 执行
composer config -g repo.packagist composer http://xxx→ 触发secure-http拒绝，或降级为HTTP，DNS劫持+响应篡改一步到位 - 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/→ 镜像不提供signature字段，Composer自动跳过包完整性校验 - 正确做法是只配
repos.packagist（复数），类型为composer，URL为带尾斜杠的HTTPS镜像，同时保留官方源的签名能力——这点极易被忽略，但决定了你拉下来的代码到底信不信得过
别指望Composer自己做DNSSEC。它连DNS查询都不亲手发。真正要动的是你的/etc/resolv.conf、systemd-resolved配置，或者路由器DNS设置。而Composer能做的，是用HTTPS锁住传输层，用signature锁住内容层——这两道锁，缺一不可，且必须按规范配。
