From: loser_313 at yahoo.com (Dave Yingling)
Subject: Question for DNS pros

This might not be exactly what you want, but you can register with
verisign and download the root zone file that contains the com and net
TLD's.  I think the org TLD is done by someone else.  Anyway, there are
some weird restrictions, such as IP access lists and what not, but if
you get the zone file you could grep for it. :)  If that doesn't work a
perl or shell script might work.  But I doubt you want to write the
script for something that might not even work.  It's just an idea you
could maybe try.

The verisign link:
http://www.verisign.com/nds/naming/tld/
then just click around till you find it.

Dave




--- Nick FitzGerald <nick@...us-l.demon.co.uk> wrote:
> Paul Schmehl wrote:
> 
> > Well, no, because that wouldn't solve the problem.
> > 
> > A host on our network is being queried quite regularly on udp/53 by
> other 
> > hosts. A review of the packets reveals that these other hosts
> believe that 
> > our host is a dns server.  (AAMOF the IP address isn't even in use
> at the 
> > present time.)
> 
> OK, given this extra information, I see you are making one huge 
> assumption...
> 
> > Now, if you do a reverse lookup for that IP, *our* DNS servers,
> which are 
> > authoritative for our network will tell you what the hostname is. 
> But that 
> > isn't what I want to know.  Obviously, a simple dig -x IP will tell
> me that.
> > 
> > What I want to know is *why* do these "foreign" hosts think an IP
> on my 
> > network is serving DNS when there's not even a host at that
> address.
> 
> I think you're assuming that a remote host should only consider this
> IP 
> of yours as a DNS server _if_ that information is _in the DNS, 
> somewhere_, hence your query -- you're trying to work out how to find
> 
> out what part of the DNS thinks this IP of yours is a DNS server.
> 
> > I can think of two possibilities:
> > 
> > 1) At some time in the past, a host *was* serving DNS at that
> address and 
> > some "foreign" hosts have cached the address.
> > 2) Someone somewhere has registered a domain and used our IP
> address for 
> > one of their "nameservers" in the registration.
> > 
> > (If anyone can think of other explanations, please let me know.)
> 
> I can think of another...
> 
> Several recent malwares (mostly mass-mailing viruses, but some others
> 
> too) have hard-coded lists of various servers to fall back on if
> local 
> (i.e. local to the compromised/victim host) fails.  When we first 
> started to see this tactic (several years ago) it tended to be SMTP 
> servers running open relays (or at least, the largest internal-to- 
> external-relaying SMTP servers at the largest ISPs).  Usually these 
> lists were used if MX lookup for a target address failed or other 
> transmission difficulties presented themselves (outgoing connections
> on 
> port 25 failed because of firewall rules, etc), or (particularly
> before 
> the mass-mailers did MX) if simply guessing "smtp.<domain>", 
> "mail.<domain>", etc as the likely MX of a target domain failed. 
> More 
> recently, as proper MX resolution has become more common in these 
> malwares' mailing engines, so has inclusion of lists of "known 
> promiscuous" DNS servers, presumably in the expectation that MX for 
> more target domains will be resolved than simply relying on the 
> victim's default DNS.
> 
> If your IP was in one of these lists (perhaps because of a typo or
> its 
> nefarious inclusion in some commonly distributed list of promiscuous 
> DNS servers) you could see requests from all over the place asking
> for 
> all manner of target hosts (assuming that the malware writers
> actually 
> get their DNS querying code right!).  If the malware in question were
> 
> doing this for MX reasons (by far the most common use to date) you 
> would, of course, expect to see whatever DNS query or sequence of 
> queries is normal for getting MX information, but now we are getting 
> out of area fo expertise.  Of course, all manner of other nefarious 
> malware-related purposes besides self-mailing could be tied into such
> 
> behaviour, so not seeing MX requests does not mean that this type of 
> explanation is incorrect...
> 
> 
> -- 
> Nick FitzGerald
> Computer Virus Consulting Ltd.
> Ph/FAX: +64 3 3529854
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Powered by blists - more mailing lists