Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] DNS question about DNSENUM.PL



That statement is not accurate. We have separate zone files for different domains: blu.org, heli-vets.org, Abreau.net, etc., but blu.org is a single zone file for all three BLU servers plus our various CNAMES, MX records, etc.



On Mar 26, 2013, at 10:53 AM, Jerry Feldman <gaf at blu.org> wrote:

> For your local hostnames, you would need to set up a DNS server inside of your VPN so those host names are only visible after someone has established the VPN. While we do not do a VPN for BLU.org, we do have separate zone files for each host.
> 
> On 03/26/2013 10:21 AM, Chris O'Connell wrote:
>> Tom,
>> 
>> Thanks for taking the time to explain all of that.  What I've found is that
>> most of the address I can find are A, MX .  As a result, when I run a
>> DNSENUM against my domain externally most A records that point to our IP
>> addresses.  Obviously I would like to hide these (especially ones like
>> remote.blah.org and vpn.blah.org).
>> 
>> The explanation about the file system is making sense... you can view the
>> file if you can guess the name.  My next question is, what's the mechanism
>> that allows me to view the file if I guess the name?  Followed by how do I
>> control it?  Is this tied by binding an internal DNS server on our local
>> domain to the external DNS server?
>> 
>> Thanks again everyone.
>> 
>> Chris
>> 
>> 
>> On Mon, Mar 25, 2013 at 6:24 PM, Tom Metro <tmetro+blu at gmail.com> wrote:
>> 
>>> Chris O'Connell wrote:
>>>> I've been using DNSENUM.PL via BackTrack to do some information
>>> gathering
>>>> on my work's network.
>>> Never heard of it, but looks like Dnsenum is documented here:
>>> http://code.google.com/p/dnsenum/
>>>   The purpose of Dnsenum is to gather as much information as possible
>>>   about a domain. The program currently performs the following
>>>   operations:
>>> 
>>>   1) Get the host's addresse (A record).
>>>   2) Get the namservers.
>>>   3) Get the MX record.
>>>   4) Perform axfr queries on nameservers and get BIND versions...
>>>   5) Get extra names and subdomains via google scraping
>>>      (google query = "allinurl: -www site:domain").
>>>   6) Brute force subdomains from file, can also perform recursion on
>>>      subdomain that have NS records.
>>>   7) Calculate C class domain network ranges and perform whois queries
>>>      on them.
>>>   8) Perform reverse lookups on netranges...
>>>   9) Write to domain_ips.txt file ip-blocks.
>>> 
>>> 
>>>> So, not all of my DNS sub domains show up in a simple scan.
>>> (Lets set aside the "subdomain" terminology discussion. In my experience
>>> the term is often used even for domains that aren't delegated, which is
>>> likely a misuse of the term.)
>>> 
>>> My guess would be that Dnsenum is getting its initial list by looking at
>>> names returned as a side effect of other queries. While zone transfers
>>> used to be readily accessible, as Rich said they've been largely
>>> disabled for security reasons (and at one time to avoid security holes
>>> in BIND). However, that restriction might be IP sensitive, and you might
>>> be allowed to do a zone transfer from your own LAN's IP range. You can
>>> try playing around with a tool like 'dig' to explore this further yourself.
>>> 
>>> DNS is like a file system directory where you don't have permission to
>>> list the directory contents, but if you know the file name you can
>>> access the file contents. I'm assuming their brute force option simply
>>> goes through a list of common names, looking to see if each exists.
>>> 
>>> But as implied by items #1 through #3 above, DNS intentionally reveals
>>> some information in order to make it useful.
>>> 
>>> Disabling zone transfers is an attempts to hide the particulars within a
>>> zone, but it is imperfect at best, as this information often leaks out
>>> through other means (mail headers, for example). One possibility is to
>>> scan through the range of IP addresses used by your target and do
>>> reverse (PTR) queries on each IP (#8 above). Of course lots of DNS
>>> entries lack corresponding PTR records, so that may not turn up much.
>>> 
>>> The source for Dnsenum can be viewed here:
>>> http://code.google.com/p/dnsenum/source/browse/trunk/dnsenum.pl?r=2
>>> 
>>> and it looks like if you run it in verbose mode it'll tell you a bit
>>> more about what queries it is performing.
>>> 
>>> The best way to answer this question would be to obtain your zone file
>>> from whoever maintains your DNS and look at how the records vary between
>>> the ones that Dnsenum finds and the ones it can't.
>>> 
>>>  -Tom
>>> 
>>> --
>>> Tom Metro
>>> Venture Logic, Newton, MA, USA
>>> "Enterprise solutions through open source."
>>> Professional Profile: http://tmetro.venturelogic.com/
>>> 
>> 
>> 
> 
> 
> -- 
> Jerry Feldman <gaf at blu.org>
> Boston Linux and Unix
> PGP key id:3BC1EB90
> PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org