What's the purpose of that in terms of security / hacking?
The hostname(s) of resources can provide valuable information to narrow the scope of an attacker's task by providing information about available machines and resources. The underlying space of network (IP) addresses is sparsely populated (and
IP:port combinations even more so), so narrowing down the addresses at which the organization hosts machines significantly reduces the preparatory work necessary to locate machines, map the topology, and launch an attack.
For example, the presence of a name
ssh.company.com in the DNS provides hints of machines which probably host an SSH daemon. In the first instance, it is reasonable to suppose that daemon runs on its default port, significantly reducing attack overhead and advancing to the stage of probing for vulnerabilities. By contrast, scanning the large IP ranges of an organization (if known a priori) is slower, more time consuming, and more likely to trigger early alerts in firewalls and IDS devices of port scan attempts.
Is there any way to do that other than by brute-force with a dictionary of the most popular subdomain names?
Yes, there are alternative methods, which might be available depending upon the degree of (mis-)configuration of the relevant infrastructure. Here is a list of common methods:
A dictionary attack operates passively by sending standard DNS queries for common hostnames. By definition, it cannot guarantee to provide a full enumeration of a zone, but it will always find any resources with common hostnames. This attack vector cannot be mitigated without impeding the proper functioning of the DNS.
A brute-force attack also operates passively, but generates all possible combinations of hostnames. Such an attack can be exhaustive, as RFC 1035 limits the maximum permissible length of a DNS label and the overall length of an FQDN (§2.3.4). However, this would be extremely time-consuming, especially given the sparse population of the DNS namespace.
A zone transfer attack attempts to request a zone transfer from an authoritative DNS nameserver for a given domain. A zone transfers represents a dump of the entire zone contents, which is typically used by slave servers to update their locally cached copy of a zone. A successful zone transfer provides an enumeration of an entire zone.
Most sysadmins provide some security-by-obscurity by restricting the source IP addresses which may submit zone transfer requests. Hence, this attack can only succeed if: a server has an open zone transfer policy (anybody may submit a zone transfer), the attacking party can observe a zone transfer in progress, or the attacking party gains the ability to issue packets from one of the trusted IP addresses, perhaps by traffic interception in the network.
NSEC walking attack can enumerate DNSSEC-signed zones. DNSSEC must assert the non-existence of records in a zone to prevent attackers spoofing
NXDOMAIN responses in an attempt at denial-of-service. The provision of a denial-of-existence proof is commonly achieved by sorting the zone records and linking them in a chain of
NSEC records (each signed). It follows that the intervening namespace between each
NSEC record contains no valid resource records.
However, this technique necessarily allows the
NSEC space to be trivially walked to enumerate a DNS zone.
Various alternative mechanisms for minimizing this risk are proposed:
Online signing, in which the
NXDOMAIN responses are generated ad-hoc and iteratively restrict a smaller and smaller subset of the namespace (e.g. restricting
aaa.domain.com). However, this approach requires a signing key to be distributed to slave servers, which spreads keying material further than perhaps desired.
NSEC3 records introduce hashes into the denial-of-existence proofs. The hashes are signed statically, obviating the need for slave servers to be provided with a copy of the signing key. As the hostnames are hashed, walking the chain of
NSEC3 records is no longer trivial and attracts significantly greater overhead, although some claims exist that this is still not sufficient.
Wikipedia has a good view on the whole issue.
How to protect my domain?
Protecting against the above attacks should be your first line of defense, through properly configured nameservers and carefully considering any deployment of DNSSEC. However, you cannot fully eliminate the threat of a dictionary or brute-force attack without breaking proper DNS functionality.
You should remain cognizant of the fact the DNS is public information; although it is perhaps good practice not to give up your zonefile to anybody who requests it, this is just security-by-obscurity. Defense-in-depth security techniques should still be adopted through appropriate security precautions in your network topology, training your system users against social attacks, properly tightening any public-facing daemons you might operate, and whatever else your written security policy dictates.
Zone transfer testing
It is easy to test (or experiment) with DNS zone transfers using the
dig(1) utility under your favorite *nix environment. Finding a zone which allows you to transfer it is another matter, but digi.ninja provides the
zonetransfer.me example for this purpose. The following command should demonstrate a successful zone transfer against the
zonetransfer.me zone, which will provide you with a full enumeration of this demonstration zone:
dig @nsztm1.digi.ninja zonetransfer.me AXFR
You can test your own zones by replacing the relevant fields in the command. A failed attempt should elicit the response
; Transfer failed