DNS cache poisoning report.
For background you may wish to review this report  http://isc.sans.org/presentations/dnspoisoning.php
and this issue about BIND 4 or 8 not being suitable as forwarders http://isc.sans.org/diary.php?date=2005-04-28

Next, a request. PLEASE review your dns servers logs and cache for 65.23.154.2 If you find it listed as authoritative for .com please send us an email with a dump of the dns cache. Directions for dumping, cleaning and protecting your cache are available in the write-up above.

Serverhome.com (65.23.154.2) is being reported for Kashpureff-style cache poisoning for the .com TLD.

This report shows there are about 16k domains hosted on this server.
http://www.ipwalk.com/webhost/total_domains/webhost_name/serverhome.com

Be careful if you look up one of those domains there is a good chance you will see extra RR records including ones that claim they are authoritative for .com.

Sample packet showing the cache poisoning in action. Note the extra .com servers.
No.     Time        Source                Destination           Protocol Info
19 12.201047   65.23.154.2           192.168.0.3           DNS      Standard query response A 65.23.154.2
Frame 19 (542 bytes on wire, 542 bytes captured)
Ethernet II, Src: Actionte_58:9d:0a (00:0f:b3:58:9d:0a), Dst: HonHaiPr_1d:cc:b4 (00:14:a4:1d:cc:b4)
Internet Protocol, Src: 65.23.154.2 (65.23.154.2), Dst: 192.168.0.3 (192.168.0.3)
User Datagram Protocol, Src Port: domain (53), Dst Port: 3918 (3918)
Domain Name System (response)
    Transaction ID: 0x0029
    Flags: 0x8580 (Standard query response, No error)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 15
    Additional RRs: 10
    Queries
        www.ibm.com: type A, class IN
    Answers
        www.ibm.com: type A, class IN, addr 65.23.154.2
            Name: www.ibm.com
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 4
            Addr: 65.23.154.2
    Authoritative nameservers
        com: type NS, class IN, ns a.gtld-servers.net
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 20
            Name server: a.gtld-servers.net
<SNIP b-m gtld-server list >
com: type NS, class IN, ns ns1.serverhome.com
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 17
            Name server: ns1.serverhome.com
        com: type NS, class IN, ns ns2.serverhome.com
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 6
            Name server: ns2.serverhome.com
    Additional records
        a.gtld-servers.net: type A, class IN, addr 192.5.6.30
            Name: a.gtld-servers.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
            Data length: 4
            Addr: 192.5.6.30

        <SNIP b-gtld ? g-gtld>

        h.gtld-servers.net: type A, class IN, addr 192.54.112.30
            Name: h.gtld-servers.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
            Data length: 4
            Addr: 192.54.112.30

I provided this information to the hosting provider Rackmounted.Com. They stated that
"Returning unexpected answers to queries that will never occur in the wild is not abuse"

So I did a dig for serverhome.com a domain they own.
dig @65.23.154.2 serverhome.com
; <<>> DiG 9.2.1 <<>> @65.23.154.2 serverhome.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8745
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15,
ADDITIONAL: 2
;; QUESTION SECTION:
;serverhome.com. IN A
;; ANSWER SECTION:
serverhome.com. 86400 IN A 65.23.154.2
;; AUTHORITY SECTION:
com. 86400 IN NS i.gtld-servers.net.
com. 86400 IN NS j.gtld-servers.net.
com. 86400 IN NS k.gtld-servers.net.
com. 86400 IN NS l.gtld-servers.net.
com. 86400 IN NS m.gtld-servers.net.
com. 86400 IN NS ns1.serverhome.com.
com. 86400 IN NS ns2.serverhome.com.
com. 86400 IN NS a.gtld-servers.net.
com. 86400 IN NS b.gtld-servers.net.
com. 86400 IN NS c.gtld-servers.net.
com. 86400 IN NS d.gtld-servers.net.
com. 86400 IN NS e.gtld-servers.net.
com. 86400 IN NS f.gtld-servers.net.
com. 86400 IN NS g.gtld-servers.net.
com. 86400 IN NS h.gtld-servers.net.
;; ADDITIONAL SECTION:
ns1.serverhome.com. 86400 IN A 65.23.154.2
ns2.serverhome.com. 86400 IN A 65.23.154.2


Highlights from the original Email thread reportng a DNS cache poisoning event.

"I have been investigating a DNS problem my company experienced late
last week. Users were reporting that no matter what site they attempted to access they would receive a page indicating that the domain was for sale.

I did some basic troubleshooting and found that all requests that were resolved against our internal DNS server were answered with the same address 65.23.154.2. I began digging in the DNS logs and found that NS record for the "com." zone had been inserted at what seemed to be a higher priority then the common TLD servers in the "com." domain.

After the cache became corrupted it caused our internal name servers to query 65.23.154.2 as a name server for the "com." zone. It would reply with the 65.23.154.2 address to any request that was requested.

I was out of town at the time of the event and without understanding what it was I was
dealing with I blocked access to 65.23.154.2 at our firewall, cleared the cache on all internal DNS servers and cleared the cache on our proxy.

I then contacted the ISP and left word that I thought they may have
a misconfigured host on their network but I did not receive a response.

Today, I was able to find the time to confirm these findings in a VM environment that I placed on our external network. The server is a MS Windows 2003 with SP1 installed and the "secure cache against pollution" check box was enabled.

I contacted MY_ISP yesterday and inquired as to what version of DNS they
were running on our forwarders. They would only admit that they had
version(8.something) and seem quite defensive about the notion that they
had forwarded corrupt cache info that caused my company so much trouble
late last week. It seemed as if they were insistent on saying that
their cache was not corrupted. I tried to explain that I didn't think
that it was only that poisoned authority records had been passed to us
from them as a result of an authoritative response from a malicious
server.

I am going to recommend that my company install its own DNS cache servers in our DMZ running the latest version of BIND and to NOT allow internal DNS servers to conduct recursive lookups."

Additional DNS information.

There are a lot of other systems that are currently setup to do dns cache poisoning.
http://dns.measurement-factory.com/surveys/200603-poison.txt
Cornell did a dns survey their report is available here:
http://www.cs.cornell.edu/People/egs/beehive/dnssurvey.html
ISC.com's DNS survey results
http://www.isc.org/index.pl?/ops/ds/