full-disclosure - Question for DNS pros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20040724100204.GC19833@freesbee.wheel.dk>
From: ssch at wheel.dk (Steffen Schumacher)
Subject: Question for DNS pros

On 23.07.2004 17:11:10 +0000, Paul Schmehl wrote:
> --On Friday, July 23, 2004 09:50:44 PM +0200 Oliver@...yhat.de wrote:
> >
> >hm... you could also try reverse lookups for all existing ip-adresses in
> >the world :)
> >
> 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.)
> 
> 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 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.
> 

DHCP telling the hosts to use that DNS server? 
Do you use DHCP? If so, check the config, if it is in the clear, there may be 
a rouge DHCP server popping up once in a while. To check for this you should 
check your DHCP logs.

Just a suggestion..

/Steffen 

> (If anyone can think of other explanations, please let me know.)
> 
> Now how is a reverse lookup going to help you with that?  It would be 
> trivial to write a perl script that did reverse lookups for every IP on the 
> Internet and wrote the responses to a comma delimited file, but the 
> resulting file would be useless to solve the problem that I'm trying to 
> solve.
> 
> And for those who were thinking "just do a tcpdump", here's what *that* 
> looks like - no domain info there -
> 
> 17:01:44.646943 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  48072 NS? . 
> (17)
> 17:01:45.386919 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  48073 NS? . 
> (17)
> 17:01:46.153402 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  48074 NS? . 
> (17)
> 17:01:47.657898 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  1084 PTR? 
> 63.37.110.129.in-addr.arpa. (44)
> 17:01:48.399150 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  1085 PTR? 
> 63.37.110.129.in-addr.arpa. (44)
> 17:01:49.144398 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain:  1086 PTR? 
> 63.37.110.129.in-addr.arpa. (44)
> 
> The best suggestion yet has been to set up a name server at that address 
> with verbose logging.  That's probably what I will do next week.
> 
> Paul Schmehl (pauls@...allas.edu)
> Adjunct Information Security Officer
> The University of Texas at Dallas
> AVIEN Founding Member
> http://www.utdallas.edu/ir/security/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html