SSRF漏洞验证有个痛点：目标内网IP常常不可达，配合或者出网端口被限制。可验你没法直接确认漏洞是配合否真实存在。这时候dnslog派上用场了——把探测请求变成一次DNS解析，可验只要目标机器发出请求，配合你的可验dnslog服务器立刻收到记录。

原理一点都不玄乎。配合SSRF的可验本质是服务端替你去请求一个地址。如果你让服务端去请求一个你控制的配合域名，比如 test123.your-dnslog.cn，可验那它一旦发起请求，配合必然先做一次DNS解析。可验这个解析记录会出现在你的配合dnslog后台。有记录，可验说明服务端真的配合发起了请求，漏洞实锤。

具体操作分三步。第一步，去dnslog平台申请一个子域名。第二步，把漏洞URL里的参数改成这个子域名，比如 ?url=http://test123.your-dnslog.cn。第三步，刷新dnslog后台，看有没有解析记录。

我在一次渗透测试里遇到过这种情况。目标系统有个图片裁剪功能，可以传入图片地址。我试了内网IP，没反应；试了公网IP，也没反应。后来换成dnslog，直接把地址改成我的子域名。过了两秒，后台跳出两条记录——一条IPv4解析，一条IPv6解析。这说明服务器不仅发起了请求，还同时尝试了两种协议。漏洞确认得清清楚楚。

有个细节值得注意。有些SSRF会限制协议，只允许http或https。这种情况下dnslog照样适用，因为http请求的第一步就是解析域名。还有的会限制端口，但DNS解析走的是53端口，跟应用层端口无关。只要服务端能解析外部域名，dnslog就有效。

反过来讲，如果dnslog后台迟迟没有动静，也别急着下结论。先确认目标服务器是不是本身就不出网，或者有内部DNS劫持。我碰到过一次，目标服务器把请求发出来了，但内网DNS服务器缓存了那个域名，导致dnslog平台没收到记录。这种情况换个不常见的子域名就能解决。

用dnslog验证SSRF还有个额外好处——能判断漏洞的影响范围。比如你给不同的参数位置都配上不同的子域名，通过看哪个域名被解析，就能定位出哪些参数真正可控。这比盲打盲试高效得多。我习惯把每个参数位都分配独立的子域名前缀，一次请求就能把所有可疑点都测一遍。

最后说个实战技巧。dnslog平台尽量选支持通配符解析的，这样你可以自己拼接任意子域名，不用每次申请。配合脚本自动化测试，效率能提升好几倍。当然，前提是你得确保测试过程合法合规，别拿dnslog去干坏事。