[Discuss] DNS question about DNSENUM.PL

Wed Mar 27 11:51:14 EDT 2013

The issue here is that you can have zone files set up for public 
display, and zone files used for hosts inside of the VPN.

On 03/27/2013 03:47 AM, John Abreau wrote:
> Technically, gaf.blu.org is a sub zone that in principal could contain multiple hosts, e.g. foo.gaf.blu.org, bar.gaf.blu.org, etc., but it only contains a single A record for "@", which gets mapped to the value of $ORIGIN.
>
> Hallowed are the Ori!  :-)
>
>
> On 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/
>>>>>>    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

-- 
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