Table of Contents

A Complete Guide for Security & DevOps Professionals

The Domain Name System (DNS) is one of the most fundamental building blocks of the modern internet — yet it’s also one of the most misunderstood areas, even among experienced developers and IT professionals. Whether you’re trying to understand how attackers discover the real server IP behind Cloudflare, setting up a subdomain on a different host, or migrating a website without breaking email services, DNS plays a central role.

What This Guide Covers

Why DNS records matter
How shared hosting works
How web servers know which domain to serve on a shared IP
How attackers uncover real server IPs even behind Cloudflare
The role of TXT records in domain verification
How to correctly set up subdomains
How to migrate hosting safely without breaking MX (email) records

1. The Core DNS Records and What They Do

Before diving into advanced scenarios, let’s quickly recap the most important DNS record types and their jobs:

A Record

Maps a domain or subdomain → an IPv4 address.
Example:

text

example.com A 203.1.2.3

CNAME Record

An alias pointing one domain to another.
Example:

text

blog.example.com CNAME myblog.hosting.com

MX Record

Controls where email for your domain is delivered.
Example:

text

example.com MX 10 mail.protonmail.com

NS Record

Points to the authoritative nameservers responsible for your DNS.
Example:

text

example.com NS ns1.synergywholesale.com.au

TXT Record

Stores text data used for:

Domain verification (Google, Repl.it, AWS, etc.)
SPF/DKIM/DMARC email authentication
Service configuration

Important: TXT records do not route traffic — they store metadata.

2. Why You Cannot Combine A Records and NS Records

A very common question is: “Why can’t I mix A and NS records for the same host?”

Answer:

A Record = where traffic goes
NS Record = who controls DNS for this domain

These two have completely different jobs. If a domain has an NS record, DNS resolvers must delegate authority to that nameserver.

Therefore:

❌ You cannot set an A record at the exact same label where an NS record delegates authority
✔ But you can have A records at your root domain even though your root domain has NS records

3. Why Many Domains Share the Same IP (Shared Hosting)

You may have noticed dozens — even hundreds — of unrelated domains pointing to the same server IP. This is perfectly normal and called Name-Based Virtual Hosting.

How does the server know which website to show?
Because every HTTP request contains a Host Header:

http

GET / HTTP/1.1
Host: ahsan.au

The web server (e.g., Apache, Nginx, Caddy, IIS) reads the Host header and selects the correct virtual host configuration.

4. How Attackers Discover Real Server IPs (Even Behind Cloudflare/WAF)

Most companies protect their origin server IP using services like Cloudflare, AWS CloudFront, or other WAFs, but attackers can still uncover the real origin.

A) Historical DNS Lookups

Tools like SecurityTrails, ViewDNS, and Shodan store historical DNS records. If your site was ever exposed before protection was added, these sites still have the original IP.

B) Exposed Subdomains

Typical mistake:

text

www.example.com → Cloudflare (protected)
api.example.com → direct A record (exposed)
dev.example.com → direct A record (exposed)

One forgotten A record leaks the entire hosting environment.

C) Email Services Leaking Origin

If your mail server and web server are the same machine, an MX lookup may reveal the origin.

D) Direct-IP Fingerprinting

If the origin server is misconfigured and responds to direct IP requests, attackers can detect server banners and TLS certificates.

E) Webhooks or Outbound Calls

If your application makes outbound requests, the origin IP appears in logs at third-party systems.

5. How webhook.site Helps in DNS/Web Application Testing

Webhook.site doesn’t receive DNS traffic — it receives HTTP requests. It is useful for:

Testing if external systems can make callbacks
Inspecting headers (X-Forwarded-For, origin IPs, user-agent)
Testing webhooks, API notifications, or SSRF pathways

Steps:

Generate a unique URL on webhook.site
Configure your app to call that URL
Trigger the event
Inspect the incoming request

6. Understanding TXT Records for Subdomain Verification

TXT records are frequently required in two cases:

(1) Domain Ownership Verification

Services like Repl.it, AWS, and Google require a TXT record like:

text

_subdomain.example.com TXT "verification=abc123"

(2) Email Security

TXT records are used for SPF, DKIM, and DMARC to protect against email spoofing.

Important: TXT records do not point your subdomain anywhere. To route traffic, you must use A or CNAME records.

7. Hosting Repl.it on a Subdomain While Main Site Runs on Synergy

Scenario:

Root domain (example.au) hosted on Synergy Wholesale
You want app.example.au to point to Repl.it

Steps:

Add TXT record for verification (no routing effect)
Add either:
- An A record if Repl.it gives you an IP
- Or a CNAME if they give you a hostname

Example:

text

app.example.au A 45.56.88.12

This routes only the subdomain — NO conflict with your main site.

8. Can You Have More Than One CNAME Record?

Short answer: Not for the same subdomain.

You can only have one CNAME per hostname, but you can have different records for different subdomains.

Valid Example:

text

example.au A 203.1.2.3
app.example.au A 45.22.33.11
dev.example.au CNAME app.example.au

Invalid Example:

text

app.example.au CNAME repl.it
app.example.au CNAME other.host.com  <- conflict

9. How to Migrate Hosting Without Breaking Email (MX Records)

This is crucial for business clients. Follow this exact process:

Step-by-Step Migration:

Export all DNS records from old host
Recreate all DNS records at the new DNS host
Only change the A record(s) – website moves, email stays untouched
If changing nameservers, recreate DNS zone before switching
Test before cutting over using nslookup, dig, or MXToolbox

DNS Security Best Practices Table

Risk Area	Vulnerability	Protection
Exposed Subdomains	IP leakage through forgotten A records	Regular DNS audits
Historical Data	Archived IPs in historical databases	Proactive protection from day one
Email Configuration	MX records revealing infrastructure	Separate web and mail servers
DNS Misconfiguration	Conflicting records causing downtime	DNS validation tools

Final Thoughts

DNS is powerful, flexible, and foundational — but mistakes in DNS architecture can expose your real server IP, break email services, open security gaps, or cause downtime. Understanding the difference between TXT, A, CNAME, and NS records, knowing how subdomains and shared IPs work, and properly structuring hosting migrations are essential skills for every security engineer, DevOps engineer, and penetration tester.

With proper DNS hygiene, Cloudflare/WAF protection, and a clear understanding of how traffic flows, you can secure your web infrastructure while smoothly routing your domains, subdomains, and hosted services.