Articles

Metasploit Framework Windows Tutorial
Remote Desktop Connection
Windows Processes That May Be Dangerous
How-To use NetCat a Tutorial
Common Linux Commands
Common Ports
Netcat Commands
HTTP Response Codes
War-Google Hack Terms
Wardriving
Avoiding Social Engineering and Phishing Attacks
Intrusion Detection on Linux
Linux Intrusion Detection
Penetration Testing Guide
Penetration Testing Tools
Social Engineering Fundamentals, Part I: Hacker Tactics
Social engineering (computer security)
The Psychology of Social Engineering

The Archives

General GSO
GovernmentSecurity.org News & Suggestions
In The News
Open Topic
General Security Information
Trash Can
Exploit & Vulnerability Mailing List Archives
Trial Member Forum
Product and Program Reviews GSO Tutorials
System Security
Windows Systems
Beginners Section
Linux & Unix Systems
File Downloads
Exploit Research & Discussion Trojan & Virus Errata
Networking Security / Firewall / IDS / VPN / Routers
System Hardening
E-Mail Security
Wifi Security
Trial Member Uploads
Upload discovered Trojans & Mal ware
GSO Programming Section
C , C++ , VC++
Visual Basic.NET
Perl /CGI
Java/Javascript
PHP/XML/ASP/HTML
Assembly + Other
The Cork Board
Network Security Consultant Directory
Network Security Jobs
The Archives
Encryption Information
General Network Security
Internet Anonymity
HTTP Protocol Security
Linux Security
MS IIS Information
Exploit Articles
Programming / Tool Design
GSO Software Projects
Public Downloads
Microsoft Security Questions and Papers

Full Version: Dns Zone Transfers
myth
Just a quick little note on DNS Zone Transfers, well, not officailly a zone transfer, but receiving all the known records.

Because of the way DNS servers are treated, they often get over looked with 'securing'. However, as my a local DNS server has just found out, I was able to dump their whole DNS change, 75,260 IP records, to my computer.... PTR A MX all records the DNS server holds.

I assume that they allowed just a subnet and I was included. (It was safe to do so - legally that is). That was not the major security issue though, because of the situation of the DNS server, i also got the ip's of their private subnets, including the security centre, office's, projectors, helpdesk machines and more.

It was a simple nix command host with the -l option

CODE
host -l <domain> >> <filename>


And it dumps the output to the file, or stdout, or however you choose to process the information.

I wrote this to remind people that DNS servers also contain important information, and shouldnt be overlooked, as my buddy has found out...
packet
A very good example of why you A: need to lock down the ability to do a DNS zone transfer and B: practice split-DNS seperate internal and external DNS systems. They can even reside on the same DNS server and just be accessable via differnet interfaces or IPs but thats not normally a very smart idea either (unless it is a Sidewinder).

Good info, this is one way I do security audits on companies, internal DNS records can hold some very juicy information.

--P>G>>
Warlord_David
i'm guessing your talking about the host.exe program that comes with dig. Well I tested out the command line you gave, and i got the error below:

CODE

errno2result.c:61: unable to convert errno to isc_result: 10057: Socket is not connected.


Anyone have a solution?
myth
a follow up is @ http://www.governmentsecurity.org/forum/in...showtopic=15264

Using dig instead, but all you need to do is send an AXFR Record Query Request for that domain name.

http://www.infosyssec.com/infosyssec/ipsectools.htm (scroll down to Dig It)<- you can do the same thing online, but the dns server will get a query from a completely unknown IP, to your own ISP they may have only allowed the IP's they control, however, because your one of them - you may get an insider advantage.

But yeah, continue any further discussion in the other thread, cheers

(oh, btw, the answer your question, sounds like an OS problem or the client may need to be told which network interface to use, all of my previous and next examples are using linux)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2005 Invision Power Services, Inc.