Course 46 - CompTIA Cybersecurity Analyst | Episode 9: Domain Names, IP Ranges, and Zone Transfers
Episode OverviewThis episode explores the fundamentals of DNS reconnaissance and network footprinting, examining how security professionals can use Internet addressing information and DNS infrastructure to build a clearer picture of an organization's external network.The discussion begins with the relationship between human-readable domain names and IP addresses, then moves into global IP address allocation, WHOIS-based information gathering, and DNS zone transfers. It concludes with alternative subdomain enumeration techniques and defensive measures designed to prevent unauthorized DNS information disclosure.Key Topics Covered1. Domain Names, IP Addresses, and Internet AllocationThe episode begins with the foundations of Internet addressing and name resolution.It examines how domain names provide human-readable identifiers that can be resolved to IP addresses, while domain registries and registrars support the management of top-level domains (TLDs), including generic TLDs such as .com and country-code TLDs.The discussion also introduces the organizations responsible for coordinating regional Internet number resources, including:
- ARIN — American Registry for Internet Numbers
- RIPE NCC — serving Europe, the Middle East, and Central Asia
- APNIC — Asia Pacific Network Information Centre
- LACNIC — Latin America and the Caribbean
- AFRINIC — African Network Information Centre
- Hostnames and subdomains
- Internal or external network addresses
- Mail servers
- Application infrastructure
- Other DNS records describing the organization's environment
Speaker 1: Back in the fall of 2021, one of the absolutely
biggest social media networks on the planet just completely vanished
from the Internet.
Speaker 2: Yeah, that was a wild day. And the crazy thing
is the physical servers were totally fine. Right.
Speaker 1: The data centers had power. The internal network was humming
along perfectly. But for like six straight hours, nobody could
access their apps or websites. It wasn't some physical disaster
at all.
Speaker 2: No, it was. Well, it was basically just the map,
the invisible map that tells the rest of the Internet
where those servers are located. was accidentally erased.
Speaker 1: Which is just a terrifying realization for any organization. We
tend to think of the internet as, you know, physical
cables and metal boxes.
Speaker 2: Right, but everything really depends on this highly vulnerable, constantly
shifting layer of invisible directions. And if you understand how
to read those directions, I mean, you hold the keys
to the entire global network.
Speaker 1: So today we are taking a deep dive into that
exact map. We're going to break down the mechanics of
DNS harvesting. And we're going to frame this whole conversation
around a hypothetical scenario, like a high stakes red team engagement.
Speaker 2: I love this framing. It's the best way to learn it.
Speaker 1: Exactly. So imagine you are a cybersecurity professional and you're
tasked with mapping out a target organization's entire network infrastructure.
Speaker 2: You need to find their critical servers, their perimeters, their
email portals, all of it.
Speaker 1: But here's the massive catch. You have to do this
without ever once touching the company's internal systems or, you know,
Tripping a single security alarm.
Speaker 2: Which sounds like a paradox, right? How do you draw
a detailed floor plan of a super secure facility if
you aren't allowed to step foot inside the perimeter or
even touch the front gate?
Speaker 1: Exactly. It seems impossible.
Speaker 2: But the structural blueprint of a network isn't locked in
some vault. By its very nature, a huge portion of
that intelligence just has to be broadcast publicly. It's just
out there, waiting for someone who understands the underlying mechanics
to put the pieces together.
Speaker 1: Okay, so let's start the clock on our heist. I've
got the target company's name, and I want to find
out where they live digitally. My first instinct would be
to just fire up a port scanner and start pinging
their main website to see what responds.
Speaker 2: Which would immediately get your IP address flagged.
Speaker 1: Yeah.
Speaker 2: And then blocked by their firewall.
Speaker 1: Oh, really? That fast?
Speaker 2: Oh, yeah. That is way too noisy for the reconnaissance phase.
You don't interact with their hardware at all yet. You
start with Passive reconnaissance.
Speaker 1: Right. Just reading the metadata, they are legally obligated to
publish to the world. So like a simple who is
query on their domain name is usually the first move.
Speaker 2: Exactly. Because it's not just returning an IP address.
Speaker 1: Yeah. When I run a who search, it drops an
administrative goldmine. I mean, I'm seeing the physical mailing address
of the registrant, the phone numbers for their IT department.
even the direct email addresses of their network administrator.
Speaker 2: And that administrative data is basically the foundation of any
good social engineering campaign. But as a network mapper, you
are really looking for the underlying host names.
Speaker 1: The actual structure of the subdomains themselves. Right.
Speaker 2: Because IT administrators have to manage thousands of machines at scale.
They rely on logical naming conventions to keep things organized.
Speaker 1: So they aren't naming their servers after Lord of the
Rings characters anymore.
Speaker 2: Rarely. I mean, maybe in a small startup, but at
an enterprise scale, logic strictly dictates the names.
Speaker 1: Makes sense.
Speaker 2: So let's say in your passive search of their public records,
you uncover a server named dc1. targetcompany. com. If you understand enterprise architecture,
DC almost universally stands for domain controller.
Speaker 1: Oh, wow. Which is the central authority for a Windows network, right?
Managing passwords and user permissions.
Speaker 2: Exactly. Exactly. So by spotting DC1, you haven't just found
a server. You've identified the absolute crown jewels of their network.
Speaker 1: And I haven't even sent a single packet to it yet.
Speaker 2: Not one. Or consider finding something like X01. That strongly
suggests a Microsoft Exchange server handling their corporate email.
Speaker 1: So as an attacker or a penetration tester, this intelligence
dictates your entire strategy going forward.
Speaker 2: 100%. Yeah. Because you know X01 is likely an exchange server.
You don't need to waste any time trying Linux exploits
or web application attacks on it.
Speaker 1: Right. You just pull the specific zero-day exploits for Microsoft
Exchange straight out of your toolkit. You've drastically narrowed your
attack surface without making a single sound.
Speaker 2: And this is why companies fight so hard over their
top-level domains now. You've got the classic. com,. net,. org,
and the country codes like. co,. uk, or. it.
Speaker 1: But global organizations will spend absolute fortunes acquiring a clean.
com domain, regardless of where their physical headquarters actually is.
Speaker 2: Yeah, because search engine algorithms tend to favor the. com space,
which forces companies to centralize their global public footprint under
one highly visible, easily scannable namespace.
Speaker 1: It totally consolidates their exposure. Okay, let's escalate our heist
scenario a bit. Say I've used a WhoSearch to map
out their domain names, but I hit a roadblock.
Speaker 2: Let me guess. A privacy protection proxy.
Speaker 1: Exactly. All the physical addresses and administrative contacts are hitting
behind some third-party shell. The names aren't giving me the
physical location anymore. How do I track down where these
servers actually reside in the real world?
Speaker 2: Well, that is when you stop looking at the names
and you start looking at the underlying numbers, the IP addresses. Okay.
Speaker 1: How does that help?
Speaker 2: To trace an IP address to a physical location, you
have to understand the geography of the Internet's routing tables.
The globe is actually carved up into five distinct areas.
Physical territories. Oh, right.
Speaker 1: Managed by regional internet registries, or RIRs.
Speaker 2: Exactly.
Speaker 1: But wait, why carve it up at all? I mean,
why not just have one giant global database for every
single IP address on the planet?
Speaker 2: It really just comes down to the physical limitations of
internet routers. If every major backbone router in the world
had to memorize the specific individual location of all four
billion individual IPv4 addresses.
Speaker 1: It would just instantly overload.
Speaker 2: Totally. Their memory and processing power would fry, and the
internet would grind to a halt. So instead, IP addresses
are handed out in massive, contiguous blocks based purely on geography.
Speaker 1: Meaning a router in New York doesn't need to know
the exact path to a specific server in Tokyo. It
just looks at the first part of the IP address,
realizes it belongs to the Asian block, and just fires
the data across the Pacific.
Speaker 2: Right. It lets the local routers in Asia... figure out
the specific directions once it gets there.
Speaker 1: That is so efficient. So those massive blocks are distributed
by the five regional authorities. You have ARIN handling the U.S., Canada,
and Antarctica, where IPE covers Europe, Russia, and the Middle East.
Speaker 2: AP & I handles Asia and Australia. LA ARIN I
distributes to Latin America. And AAREA manages the entire continent
of Africa.
Speaker 1: So if I want to find out who owns a
specific block of IP addresses, say I see some strange
traffic hitting my network and I want to trace it,
Can I just query any of these five databases?
Speaker 2: No, they don't cross-reference their assignments like that. If you
query the African Authority, ARNI, trying to identify the IP
address 8.8.8.8, the query just drops. It returns completely blank.
Speaker 1: Oh, because you have to understand that 8.8.8.8 is part
of a North American block and query ARIN directly.
Speaker 2: Exactly. And once you hit the correct regional authority, they
reveal not only that Google owns that specific IP, but
they will dump the entire block of neighboring IP addresses
registered to that organization.
Speaker 1: Okay, so now we have the names and we have
the regional IP blocks. Step three of our engagement, we
need to start actively investigating. querying their specific servers to
see how traffic is actually routed.
Speaker 2: Right, time to start poking.
Speaker 1: Do we need to start deploying specialized, you know, hacker
tools for this?
Speaker 2: Actually, you already have the most powerful tool for this
built directly into your own operating system.
Speaker 1: Wait, really?
Speaker 2: Yeah, it's called nslookup or nameserver lookup. Whether you are
on Mac, Linux, or Windows, you literally just open a terminal,
type nslookup, followed by the target domain, and you are
directly asking the domain name system to hand over its
routing cards.
Speaker 1: So let's dive into those routing cards for a second,
the DNS records. It's not just translating a name to
a number. There are different types of records that tell
TRACIC where to go.
Speaker 2: Yeah, it's kind of like an air traffic control tower
sorting different types of planes to entirely different runways.
Speaker 1: I like that visualization. So the most basic one is
the A record, right? The address record. Right.
Speaker 2: Its only job is to map a human-readable host name,
like www.targetcompany.com, to its specific IPv4 address. But if you
are routing an email, your computer doesn't use the A
record at all.
Speaker 1: It specifically queries for an MX record, the mail exchange.
Speaker 2: Exactly, which directs all those inbound messages to that X01
exchange server we found earlier.
Speaker 1: Okay, what about the other types?
Speaker 2: Well, then you have pointer records, or PTRs, which basically
do the reverse. They take an IP address and resolve
it back to a host name. Those are often used
in security logs to verify who is actually connecting to you.
Speaker 1: And finally, CNA records, or canonical names. These act as aliases,
pointing one domain name to another domain name instead of
to an IP address.
Speaker 2: Right, and CNMEs can actually be pretty dangerous if they
aren't managed properly.
Speaker 1: Oh, yeah. I was reading about a massive vulnerability involving
CNME records recently. Basically, a company set up a promotional
blog using a third-party hosting service, and they created a
CNME record-pointing blog.targetcompany.com to that external host.
Speaker 2: Happens all the time for marketing campaigns.
Speaker 1: Right, but eventually the campaign ended. They stopped paying the
third-party host, and the external blog was deleted.
Speaker 2: But they forgot to delete the internal CNAME record pointing
to it.
Speaker 1: Exactly. So an attacker noticed this, went to that third-party
hosting service, and simply registered the abandoned namespace the company
used to use. Wow. Yeah. Suddenly, because the target company's
CNAME was still active, the attacker had total control over blog.targetcompany.com.
They achieved a complete subdomain takeover without hacking a single
It is crazy how often that happens. Yeah. It is
a perfect example of why mapping these records is so critical.
Speaker 2: Because misconfigurations in the map itself actually become the vulnerabilities.
Speaker 1: Okay, so ANSI lookup gives us the destination, but it
doesn't really show us the journey. If I want to
see the actual physical path my data takes to reach
their perimeter, I'm going to use traceroute.
Speaker 2: Yes, and traceroute is fascinating because it exploits a built-in
safety mechanism of the internet called time-to-live, or TTL.
Speaker 1: Break that mechanism down for us. Because when I run
a traceroute, it just lists out every single router my
data bounces through, millisecond by millisecond. How does my computer
actually know the IP addresses of all those random intermediate
routers sitting in different states or even countries?
Speaker 2: Well, when you send a packet of data across the Internet,
there is a serious risk it could get stuck in
an infinite loop, just bouncing between two confused routers forever.
Speaker 1: Like a digital ghost?
Speaker 2: Right, exactly. So to prevent the Internet from clogging up
with these looping ghosts, every single packet is assigned a TTL.
It's a maximum number of hops it is allowed to make.
Every time it hits a router, that number decreases by one.
Speaker 1: And when it hits zero?
Speaker 2: The router drops the packet entirely and sends an error
message back to the original sender saying, you know, time exceeded.
Speaker 1: Oh, that is incredibly clever. So Traceroute just sends out
a packet with a TTL of one. It hits the
very first router in your own house. The counter drops
to zero. And the router sends that error message back.
Speaker 2: Yep. Now you know the IP of your own router.
Speaker 1: Then it sends a packet with a TTL of two.
It passes your router. hits your internet service provider's router,
drops to zero, and that ISP router sends an error back.
Now you know the second hub.
Speaker 2: You've got it. It just repeats this process, incrementally increasing
the time to live by one each time. It forces
every single router along the path to reveal its IP
address by sending an error message.
Speaker 1: You can literally watch your keystroke leave your building, hit
a fiber optic hub in your city... bounce to an
ISP halfway across the country, and finally land at the
target's perimeter. But sometimes you'll see a line that just says,
request timeout.
Speaker 2: Right, and that usually means your packet hit a firewall. See,
many corporate firewalls are intentionally configured to silently drop expired
packets without sending that error message back.
Speaker 1: Specifically to hide their internal routing from tools exactly like traceroute.
Speaker 2: Exactly.
Speaker 1: But even the silence is data, right? I mean, a
timeout tells the red team exactly where the external perimeter
defenses actually begin.
Speaker 2: It perfectly visualizes the attack surface.
Speaker 1: Okay, let's push into the final phase of our heist.
Doing this one domain at a time, querying an A record,
running a trace route, it's slow. What if we want
the entire master map of the organization, every internal server,
every IP address, all at once?
Speaker 2: To pull that off, we target a mechanism called a
DNS zone transfer. Again, to understand the exploit, you really
have to understand the engineering requirement behind it.
Speaker 1: Okay, let's hear it.
Speaker 2: A single DNS server. is a massive single point of failure.
If an enterprise hosts their own DNS and that server crashes,
their entire digital footprint basically ceases to exist to the
outside world. Emails bounce, websites disappear, applications fail.
Speaker 1: So they absolutely have to maintain backup servers.
Speaker 2: Right. But to keep all those backup servers perfectly synchronized,
the primary DNS server performs what's called a zone transfer.
It literally packages up its entire database, every single canna.
a record, MX record, CNAME, and internal IP address.
Speaker 1: And just ships it in bulk to the secondary servers.
It's the equivalent of a massive corporation accidentally publishing its
internal HR directory, complete with employee home addresses, private phone numbers,
and security clearance levels directly to the public internet.
Speaker 2: It is the ultimate jackpot for reconnaissance. The vulnerability occurs
when an IT administrator configures the primary DNS server but
fails to restrict which IP addresses are actually allowed to
request that sync.
Speaker 1: So if it's left open, an attacker just uses a
command line tool, usually DIG, and requests the full transfer themselves.
Speaker 2: Yep. The command is simply DIG AX4R, followed by the
target DNS server. That AX4R flag marks the request for
a full zone transfer.
Speaker 1: And if the door is unlocked, the server doesn't even
verify who is asking. It just obediently drops a massive spreadsheet.
containing the complete network topology right onto the attacker's screen.
Speaker 2: Which is wild. And for those of you who want
to see the mechanics of this safely, there is actually
an educational environment set up specifically for this.
Speaker 1: Right, the website DigiNinja. They host intentionally vulnerable servers just
for learning. You can fire up a terminal, point that
DigXR at command at nsztm1. digi. ninja, and just watch a real
raw zone transfer pour down your screen totally legally.
Speaker 2: But in reality, most modern enterprise networks have caught on
to this trick by now. They configure their systems to
explicitly deny zone transfer requests from unauthenticated random IP addresses.
Speaker 1: So the door is locked. Do we just pack up
the red team and go home?
Speaker 2: Far from it. If we can't request the master copy politely,
we resort to DNS brute forcing.
Speaker 1: How does that work?
Speaker 2: We write a script, typically in Python, that automates the
guessing process. We feed the script a massive dictionary of
common server names like test, dev, admin, mail, squel, backup.
Speaker 1: And the script just fires those queries at the target
DNS server at thousands of requests a second. Like, do
you have a server named admin? Do you have a
server named backup? Do you have a server named test?
Speaker 2: Exactly. When the target server replies with an IP address,
the script logs the hit. When it says not found,
it instantly moves to the next guess. You are basically
automating the passive recon at a terrifying speed.
Speaker 1: But wait, the target server's public-facing, right? It has to
answer legitimate DNS requests to function. So how does the
defense tell the difference between a normal customer looking for
the website and our Python script firing 10,000 dictionary words
a second?
Speaker 2: Good question. This relies on intrusion prevention systems, or IPS,
implementing what's called rate limiting. The IPS monitors the volume
of queries originating from a single IP address.
Speaker 1: Okay, so when it sees an unnatural spike, like thousands
of queries in a few seconds, it blocks the IP.
Speaker 2: Not necessarily, because blocking often just prompts the attacker script
to automatically rotate to a new proxy IP and resume
the attack.
Speaker 1: Oh, interesting. So it throttles them instead.
Speaker 2: Exactly. It turns time into a physical barrier. The IPS
might step in and restrict that specific connection to answering
only one query per minute.
Speaker 1: Wow. The math on that is devastating for an attacker.
I mean, if I have a dictionary of 10,000 common
subdomains to guess... At 100 queries a second, I have
the entire map in a minute and a half. But
if the IPS slows me down to one query a minute.
Speaker 2: That 90-second automated hack suddenly becomes a seven-day agonizing crawl.
And in cybersecurity, time is your most valuable resource.
Speaker 1: Hackers are inherently looking for the path of least resistance.
Speaker 2: Right. So by turning a quick script into a week-long chore,
the defender frustrates the attacker. They'll almost always just kill
the script, abandon the target... and move on to a
network without an IPS in place.
Speaker 1: It's an incredible psychological defense mechanism. It doesn't rely on
being an impenetrable brick wall. It just acts as a
completely exhausting speed bump. Okay, let's pull back and look
at the whole heist we just pulled off.
Speaker 2: Yeah, we walked through the complete life cycle of mapping
a network from the outside. Starting with passive intelligence gathering,
understanding how top-level domains and host names basically reveal the
purpose of a machine.
Speaker 1: Right, and then we navigated the physical geography of the internet.
understanding how the five regional internet registries dictate where massive
blocks of IPs are physically routed.
Speaker 2: Then we moved to active querying, using built-in tools like
Inns Lookup to pull specific routing records and using the
clever time-to-live mechanics of Traceroute to physically map out the
perimeter defenses.
Speaker 1: And finally, we attempted the high-stakes data heist of a
full zone transfer, resorting to the sheer mathematical force of
rate-limited brute forcing when we found the front doors locked.
Speaker 2: And we did all of it without ever triggering an
internal alarm on the target's core servers.
Speaker 1: Amazing. So let's do a quick review exercise for you
to cement these mechanics. Think back to our discussion on
host names and the specific records that direct traffic.
Speaker 2: Right, the air traffic control labels.
Speaker 1: Yeah. So if you are running a reconnaissance script against
a target domain and you uncover an active server designated
as X01, what specific type of server is that highly
likely to be? And.
Speaker 2: Which specific DNS record type is absolutely critical for routing
the correct traffic to it? Take a second to process
the architecture.
Speaker 1: Got it. Okay, so an X01 host name strongly indicates
an exchange server. Because its primary function is handling corporate email,
it relies entirely on MX or mail exchange records to
route that communication past the perimeter.
Speaker 2: Spotting that combination immediately tells you exactly where the organization's
communications bottleneck is located. It's all about seeing the logic
behind the labels.
Speaker 1: Exactly. So we want to leave you with a final
provocative thought. Throughout this deep dive, we've focused on massive
enterprise networks. We talked about how billion-dollar companies struggle to
hide their digital footprints while navigating the public requirements of
the Internet's routing map.
Speaker 2: But I want you to scale that concept all the
way down to the room you are sitting in right now.
Speaker 1: Yeah, look at the router blinking in your living room.
think about the smartphone in your pocket. As you move
through the world, your devices are constantly querying the local DNS,
searching for known Wi-Fi networks, requesting IPs, pulling data just
to sync your background apps.
Speaker 2: If multinational corporations with dedicated security teams continuously leak structural
intelligence just by participating in the internet.
Speaker 1: Consider the sheer volume of metadata your own personal devices
are continuously broadcasting to the world, entirely invisibly just to
keep you connected.
Speaker 2: It's definitely something to think about.
Speaker 1: The map of the internet isn't static. You know, it
is always being drawn in real time by everything we
plug into it. The only real question is who is
sitting quietly on the outside watching the traffic and reading
the map. Keep exploring those invisible structures, and we'll see
you on the next deep dive.