Master DNS: From Domain Registration to Detecting Hijacks

In the theoretical part we covered DNS protocol basics, and now we answer common questions about domain names, registration, binding, and troubleshooting.

Why are the domains I want to register already taken?

Why do DNS domains need to be filed?

How to bind a newly registered domain to my website?

How can I see the name servers that resolve my domain?

Is it true that a single file can access many non‑existent sites?

What are trusted name servers and can they act maliciously?

How to know if my current name server is misbehaving?

Everyone can register a domain. Usually you want a top‑level domain (e.g., selfboot.cn, google.com). Free TLDs like .tk exist, but most domains require yearly payment. Choose a reputable registrar (e.g., DNSpod in China, GoDaddy abroad). Once you have a domain, avoid changing it frequently because the cost is high, and avoid free domains as they may disappear.

Domain Registration and Binding

After registering, bind the domain to your site by adding DNS records with the registrar. Most registrars provide free DNS resolution services.

For example, GitHub Pages allows custom domains via a CNAME file. If your blog is reachable at username.github.io, add a CNAME containing your domain (e.g., selfboot.cn) and create the corresponding DNS record at the registrar.

When visiting selfboot.cn, DNSpod resolves the request to GitHub’s IP, which then serves the blog associated with the CNAME.

Domain Name Resolution

Two common DNS diagnostic tools are dig and nslookup .

Example: query the A record of selfboot.cn with a short output:

$ dig selfboot.cn -t A +short 192.30.252.153 192.30.252.154

Reverse lookup (IP to domain):

$ dig -x 192.30.252.153 +short pages.github.com.

nslookup works on almost all platforms and provides similar information.

Trace Path Query

Use dig +trace to see the chain of name servers from the root to the target domain.

dig selfboot.cn +trace @8.8.8.8 ... (output truncated for brevity) ... selfboot.cn. 14400 IN A 192.30.252.153 selfboot.cn. 14400 IN A 192.30.252.154

The output shows root servers, the cn TLD servers, and finally DNSpod’s authoritative servers for selfboot.cn.

Online tools like dnsgraph can visualize this path.

DNS Flaws

Domain Squatting

Some TLDs have no registration restrictions, while others (e.g., .pro) limit who can register. Squatting occurs when registrars bulk‑register valuable names and resell them at high prices, making it hard to find a suitable domain.

DNS Hijacking

Malicious name servers can return false records, redirecting users to unwanted sites or ads. To test your resolver, run:

nslookup google.com

If the returned IP is incorrect, switch to a trusted resolver such as Google’s 8.8.8.8 and verify again.

$ nslookup www.google.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.google.com Address: 216.58.221.68

DNS Spoofing

Unlike hijacking, spoofing cannot be bypassed by simply changing resolvers. Attackers forge DNS responses with matching transaction IDs, causing the victim to accept false IP addresses.

Example of consistent (but fake) responses for facebook.com from a compromised resolver:

$ nslookup facebook.com Server: 10.8.4.4 Address: 10.8.4.4#53 Non-authoritative answer: Name: facebook.com Address: 159.106.121.75 $ nslookup facebook.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: facebook.com Address: 159.106.121.75

These IPs do not belong to Facebook; they are results of DNS spoofing. The attack relies on sending a forged response with the correct sequence number before the legitimate one arrives.

Using hosts files can mitigate some attacks locally, but sophisticated attackers can still bypass such defenses.