[Discuss] DNS question about DNSENUM.PL

Tue Mar 26 13:53:17 EDT 2013

Clearly the fact that you must use brute forcing to guess some records (or
hosts) but not others indicates that there is a way to obscure and hide
things to some extent.  I don't know if this is using a zone transfer, or
whatever Jerry is using.  Jerry, can you tell us more about what exactly
you're doing?

As always, I'm happy to learn more.  RIch, is this is the book you
recommend?  http://www.amazon.com/DNS-BIND-5th-Cricket-Liu/dp/0596100574

On Tue, Mar 26, 2013 at 1:38 PM, Jerry Feldman <gaf at blu.org> wrote:

> Not entirely accurate either. My home systems has a separate zone file.
> That way, if Comcast renumbers my host, all I need to do is to change my
> zone file. I've had this set up for at least 5 years. The point I was
> making is that you can have separ4ate zone files for hosts.
>
>
> On 03/26/2013 12:07 PM, John Abreau wrote:
>
>> 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/<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<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/<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<http://lists.blu.org/mailman/listinfo/discuss>
>

-- 
Chris O'Connell
http://outlookoutbox.blogspot.com