Alright, now we're getting into something you use constantly without even thinking about it.

You probably don't type an IP address every time you want to visit a website. You type something like:

reddit[.]com

or:

github[.]com

Your computer can't just magically know where that name lives. Somewhere between you typing a domain and the website appearing, that name has to be translated into an IP address.

That's one of the main jobs of DNS — the Domain Name System.

Think of DNS like a massive distributed phone book for the internet. You know the name you want, DNS helps your computer figure out the address associated with it.

And yes, I'm defanging the domains/IPs with [.] because Reddit apparently thinks networking lessons are trying to send everybody to random fucking websites.

What Actually Happens?

Let's say you enter:

example[.]com

Your computer needs an address before it can communicate with the server.

But it doesn't necessarily immediately fire a request halfway across the internet asking, “YO, WHERE THE FUCK IS EXAMPLE?”

There are multiple places that answer might already exist.

Your browser may have cached it. Your operating system may have cached it. Your machine may also have a local hosts file that can provide a mapping.

If it still doesn't have an answer, your system typically asks its configured DNS resolver.

That resolver might be provided by your router, ISP, company, VPN, or a public DNS service.

The resolver does the heavy lifting of finding the answer.

Conceptually:

YOU | | "Where is example[.]com?" v DNS RESOLVER | | figures that shit out v ANSWER | v YOU 

The actual DNS hierarchy gets more interesting.

Root → TLD → Authoritative

Imagine the resolver doesn't already have the answer cached.

It can work through a hierarchy.

At the top are root DNS servers.

The root doesn't need to know the final IP for every website on Earth. Instead, it can point the resolver toward the servers responsible for a particular top-level domain.

For:

something[.]com

the relevant TLD is:

.com

The .com TLD infrastructure can then direct the resolver toward the authoritative name servers responsible for that particular domain.

The authoritative server can provide the requested DNS record.

Very simplified:

Resolver: "Where is example[.]com?" Root: "Ask .com" .com: "Ask the authoritative server for example[.]com" Authoritative server: "Here's the answer." 

Now the resolver can return that information to your computer.

DNS Records

DNS does a hell of a lot more than simply map a name to an IPv4 address.

DNS contains different record types, and you're going to encounter these constantly once we get deeper into reconnaissance.

An A record maps a hostname to an IPv4 address.

example[.]com -> IPv4 address 

An AAAA record does something similar for IPv6.

A CNAME creates an alias pointing one hostname toward another hostname.

An MX record tells you about the mail servers responsible for receiving email for a domain.

An NS record identifies authoritative name servers.

A TXT record stores text information. You'll eventually see TXT records used for things like domain verification and email-security mechanisms.

There's more, but those are enough to start building the mental model.

Stop Reading. Open a Terminal.

On Linux, try:

dig example.com 

You're not attacking anything. example.com exists specifically for documentation/examples.

Look through the output.

You'll see sections such as:

QUESTION SECTION ANSWER SECTION 

Don't worry about understanding every number yet.

Find the ANSWER SECTION.

You're looking at information returned through DNS.

Now try:

dig example.com A 

You're explicitly asking for an A record.

Try:

dig example.com AAAA 

Now you're asking about IPv6.

And:

dig example.com NS 

Now you're asking about its name servers.

You're starting to ask DNS specific questions instead of just letting your browser do everything for you.

Try nslookup

You can also use:

nslookup example.com 

Windows users can run this directly from Command Prompt or PowerShell.

Again, pay attention to what you're actually seeing rather than just whether the command “worked.”

Which DNS server answered you?

What addresses came back?

Did you receive IPv4, IPv6, or both?

Those questions matter more than memorizing the command.

DNS Caching

Now imagine every computer on Earth had to walk the entire DNS hierarchy every single time somebody requested a domain.

That would be fucking ridiculous.

DNS answers can therefore be cached.

Records contain a value called TTL — Time To Live.

TTL helps determine how long a DNS response may be cached before it should be considered stale and refreshed.

This is why changing a DNS record doesn't necessarily appear everywhere instantaneously.

Someone may still have the previous answer cached.

So DNS isn't simply:

NAME -> ADDRESS 

It's closer to:

NAME ↓ CHECK WHAT WE ALREADY KNOW ↓ ASK RESOLVER ↓ RESOLVE THROUGH DNS IF NECESSARY ↓ RETURN RECORD ↓ CACHE IT 

Why Does a Hacker Give a Shit?

Because DNS can reveal information about infrastructure.

In an authorized lab or a domain you own, DNS records can help you understand how an organization has structured its public-facing systems.

You might discover that a domain has separate hostnames associated with things like:

www mail api dev vpn 

That doesn't mean any of them are vulnerable.

It means you've learned something about the attack surface.

And that's an important distinction.

Reconnaissance isn't:

“I found something, therefore I can hack it.”

Reconnaissance is:

“I found something. What exactly is it?”

Later we'll start connecting these concepts.

DNS gives you a hostname.

The hostname resolves to an IP.

The IP represents a network location.

That host exposes services through ports.

Those ports speak protocols.

Those services have software behind them.

Now you can probably see where we're going with this.

Your Turn

Using example.com, run:

dig example.com A dig example.com AAAA dig example.com NS 

Then:

nslookup example.com 

Now explain, in your own words, what happened between typing example[.]com and receiving an address.

Don't tell me:

That's technically useful, but I want more.

Tell me what the resolver does.

Tell me what root, TLD, and authoritative servers are doing.

Tell me what an A record represents.

Tell me why caching and TTL exist.

If you can explain that without copying this lesson, you're actually learning the shit.

Next: Lesson 8 — Subnets, CIDR & Why /24 Isn't Some Weird Shit After an IP Address

That's where addresses like:

192[.]168[.]1[.]25/24

finally start making sense.

And we're gonna do it without turning the lesson into 45 minutes of incomprehensible binary math.

DaemonCore Academy // BASIX 007

LEARN // HACK // BUILD // SHARE

https://academy.daemoncore.app