<div dir="ltr"><span style="font-size:12.8px">Robert Edmonds wrote:</span><br style="font-size:12.8px"><span style="font-size:12.8px">> 'dig @</span><a href="http://8.8.8.8/" target="_blank" style="font-size:12.8px">8.8.8.8</a><span style="font-size:12.8px"> -t TXT </span><a href="http://test.dns.google.com/" target="_blank" style="font-size:12.8px">test.dns.google.com</a><span style="font-size:12.8px">' will return the TXT record</span><br style="font-size:12.8px"><span style="font-size:12.8px">> "Thanks for using Google Public DNS."</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Note that you may get that reply even when your DNS traffic is being hijacked. I once had an unusual experience on a hotel Internet connection where even after authenticating, the captive portal DNS interception remained active, although the response replacement was disabled.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I was getting responses from authoritative servers without AA, which was puzzling. When I checked and saw this was happening with several root and TLD name servers as well, I realized the hotel network was (still) hijacking the traffic and responding from a recursive resolver. I was then quite amused to see the following:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">$ dig +short TXT <a href="http://test.dns.google.com/" target="_blank">test.dns.google.com</a>. @<a href="http://resolver1.opendns.com/" target="_blank">resolver1.opendns.com</a></div><div style="font-size:12.8px">"Thanks for using Google Public DNS."<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Apparently, the captive portal's recursive server was forwarding to 8.8.8.8. The TXT record just tells you that the resolution of the name (at some point, possibly in the previous few seconds) passed through Google Public DNS. It never tells you who might have handled it on the way.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Rather than using CHAOS class queries, the best way to detect hijacking is through the EDNS nameserver ID (as mentioned recently on this list). Unfortunately, Google Public DNS doesn't (yet?) support those either, but right now you can use the following command to detect most indiscriminate DNS hijacking:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div>$ dig +norec +noall +comment +nsid SOA @<a href="http://l.root-servers.net/" target="_blank">l.root-servers.net</a></div><div>;; Got answer:</div><div>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59195</div><div>;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27</div><div><br></div><div>;; OPT PSEUDOSECTION:</div><div>; EDNS: version: 0, flags:; udp: 4096</div><div>; NSID: 6c 61 78 35 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f 72 67 ("<a href="http://lax51.l.root-servers.org/" target="_blank">lax51.l.root-servers.org</a>")</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">@alex</div><div style="font-size:12.8px"><br></div></div>