How do you verify a DNS spoof is working from the victim side? What command and output proves it?

Run nslookup mycampus.hslu.ch — if the output shows the attacker's IP instead of the real one, the spoof is succeeding.

The verification:

$ nslookup mycampus.hslu.ch

Server:         192.168.1.1       ← whatever DNS server you're configured for
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   mycampus.hslu.ch
Address: 192.168.1.99             ← attacker's IP! Spoof is working.

Compare to expected:

# What it should resolve to (using a different DNS, e.g., Google's):
$ nslookup mycampus.hslu.ch 8.8.8.8

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   mycampus.hslu.ch
Address: 147.88.196.50            ← the real IP

Equivalent tools:

host mycampus.hslu.ch         # Shorter output
dig mycampus.hslu.ch           # More detail (TTL, flags, full answer section)
ping mycampus.hslu.ch          # Implicitly shows resolved IP

Why dig is the pro tool:

dig mycampus.hslu.ch

;; ANSWER SECTION:
mycampus.hslu.ch.    300    IN    A    192.168.1.99
;; AUTHORITY SECTION:
;; Query time: 5 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

You see TTL, the actual server that answered, query time. Useful for diagnosing.

The MitM-aware victim:

A clued-in user comparing nslookup results from different sources:

nslookup mycampus.hslu.ch              # may be spoofed
nslookup mycampus.hslu.ch 8.8.8.8      # external — bypasses local spoof

Mismatched answers = spoof detected. (But this requires the user to actively check, which most don't.)

Tip: Always test the spoof's success before moving on. Building the fake login page and finding the spoof failed wastes hours. nslookup is the cheapest sanity check.

Go deeper:

• nslookup (Wikipedia) — the query tool the card uses to read back the resolved IP.
• dig (Wikipedia) — the richer alternative showing TTL, answering server and query time.