-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have determined how my Windows 2000 DNS cache got poisoned, resulting in non-existent domains resolving instead to the bigred.com website. There are two registered hosts, NS1.REFRACT.COM (66.34.52.240) and NS2.REFRACT.COM (66.34.52.241) that are authoritative for some 543 domains under the generic TLDs. The list of domains is in the attached text file, for those who are interested (thanks to Joseph McDonald <joe@vpop.net> for grepping his copies of the gTLD zone files at my request). The addresses given are the ones in the glue from the gTLD servers. REFRACT.COM is registered through OpenSRS with NS[1-4].MYDOMAIN.COM as nameservers. Mydomain.com's servers give different addresses for NS[12].REFRACT.COM, 65.194.192.211 and 65.194.192.212, respectively. In practice, modern DNS software ignores the glue from the delegated-to nameservers, preferring to cache the glue from the parents, in this case, the gTLD servers. But even so, nameservers are in fact running on the addresses given in the REFRACT.COM zone by the Mydomain.com servers, and they behave the same way as described here. A DNS cache, following delegations from the roots, and the gTLD servers, for one of these domains, will encounter bogus glue in the responses to _iterative_ queries made to one of these poison servers. The bogus glue assigns false address records to [a-m].gtld-servers.net, assigning 66.34.52.224 to all of them. Depending on the state of the already-cached records for the gTLD server addresses, a naive DNS cache, such as Windows 2000 DNS server in its default setup, or very old BIND servers prior to ~4.9.1, may become poisoned by caching this bogus data. When that happens, future queries for gTLD domains will be directed to the server at 66.34.52.224. This bogus gTLD server at 66.34.52.224 is the one that responds to any _iterative_ query with the IP address of the bigred.com search engine website. It's rather simple to get a client of a vulnerable cache to make a query for one of the domains registered with the REFRACT.COM nameservers. HTML spam will do the trick. I emphasize _iterative_ query, because all these servers - all four NS[12].REFRACT.COM servers and 66.34.52.224 - are lame for any domain when given a recursive query. They simply give a referral back to the roots, with correct glue. A poor schmuck (like me) who is trying to track down the source of his Win2K cache poison, would encounter the bogus gTLD glue in his cache's answers, and would naturally query the server at the bogus address to see what is going on. But the common query tools perform recursive queries unless told otherwise. Caches use iterative queries to resolve domains for their clients. That these poison servers respond with bogus glue only to iterative queries is slightly clever, and provides a little cover while DNS caches continue to be poisoned. It confused me for a while in any case! I couldn't have done it better myself, even if I were Eugene Kashpureff. For Windows 2000 DNS, the solution is to click on the "Advanced" tab on the Properties screen of the DNS server control panel, and check the box labelled "Secure cache against pollution". Duh. Why this is not on by default ... ah why bother: it's Microsoft, just be glad it's there, for gods' sakes. Once your Win2K cache is a little less naive, you can flush the cache in the same control panel, and your DNS resolution should return to normal. No more bigred.com when you'd expect a "Cannot find server or DNS Error" page, no more replies to ping from hosts that don't exist, etc. Older BIND software simply must be replaced with a modern version that has some kind of poison protection. D. J. Bernstein's dnscache was never vulnerable, since it always tosses out-of-zone glue. I hope this proves useful to someone. I searched all over many search engines, and found a handful of references to the problem in various (sometimes funny) contexts, but no solution or explanation. Hopefully this message will be archived and easily found on Google, and the next poor schmuck that tries to solve this problem will find this post and save himself a few days' hair-pulling. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO1TfGUksS4VV8BvHEQIJXQCgoGXUsOBZ+PjgPbbwdMe39Pj/3hMAoK8p NJB5lesgwY1HyBnl4PUsuvYK =geCR -----END PGP SIGNATURE-----