DNS Admin Course — Lab Environment

Lesson 1

Resolution, Caching & Resolvers

Practice Objective

Observe the difference between a recursive resolver's cached answer and an authoritative answer, and measure TTL decay in real time against your own domain.

Why It's Important

Almost every "DNS isn't working" support ticket is actually a caching misunderstanding — a change was made correctly but a resolver (the student's ISP, a public resolver, or their own OS) is still serving a stale cached answer. Knowing how to prove where the stale answer lives is the single most-used diagnostic skill in this course.

Commands to Run / Settings to Verify

# Query your own domain against your ISP/default resolver, note the TTL
dig yourdomain.com A

# Query the same record directly against a public resolver, compare TTL
dig @1.1.1.1 yourdomain.com A
dig @8.8.8.8 yourdomain.com A

# Query the authoritative nameserver directly (bypasses all caching)
dig @ns1.yourdnsprovider.com yourdomain.com A +norecurse

# Watch TTL count down: re-run the same query every 10s and compare the TTL field
watch -n 10 "dig @1.1.1.1 yourdomain.com A | grep -A1 ANSWER"

Change the A record's IP in your dashboard, then re-run the recursive query before and after the TTL expires — confirm you see the OLD value until TTL hits 0, then the NEW value.

Additional Notes (Role-Specific)

Sysadmin: you'll also want systemd-resolve --flush-caches (or dscacheutil -flushcache on macOS) to prove local OS-level caching is a separate layer from the resolver's cache — two caches, two flush points, commonly conflated.
DevOps: in containerized/k8s environments, CoreDNS's own cache TTL (separate from upstream TTL) is the layer that actually bites you — kubectl logs on the CoreDNS pod plus dig from inside a pod is the equivalent exercise.
Security-adjacent: this is also where to introduce DoH/DoT — repeat the dig @1.1.1.1 query using kdig +tls @1.1.1.1 yourdomain.com (if knot-dnsutils is installed) or curl against https://cloudflare-dns.com/dns-query and compare — same answer, different transport, different privacy exposure.

← Back to Lesson 1

Lesson 2

Delegation, Glue & Redundancy

Practice Objective

Trace your domain's full delegation chain from the root down, confirm glue records are correct, and detect lame delegation.

Why It's Important

A misconfigured or lame delegation is invisible until it isn't — some resolvers cache the working path and mask the problem for weeks until a cache expires and users suddenly can't resolve your domain at all. This is the #1 root cause NODA's own CAT-INFRA category checks for.

Commands to Run / Settings to Verify

# Walk the delegation chain manually, root -> TLD -> your NS
dig +trace yourdomain.com

# Confirm what the PARENT zone says your nameservers are
dig yourdomain.com NS @a.root-servers.net    # (or the relevant TLD server from +trace output)

# Confirm what YOUR nameservers say about themselves (should match)
dig yourdomain.com NS @ns1.yourdnsprovider.com

# Check glue: does the parent hand back A/AAAA for your NS without a second lookup?
dig yourdomain.com NS +additional

# Detect lame delegation: query each listed NS directly, all must answer authoritatively
for ns in $(dig +short yourdomain.com NS); do echo "== $ns =="; dig @$ns yourdomain.com SOA +norecurse; done

A mismatch between parent-side NS and your-side NS, or any nameserver that doesn't answer authoritatively, is the lame-delegation signature to watch for.

Additional Notes (Role-Specific)

Sysadmin: if you run BIND yourself, named-checkzone catches many of these before they go live — run it as a pre-flight, not just a post-mortem.
DevOps: multi-provider DNS (e.g. Route53 + Cloudflare as secondary) needs the NS set to be byte-identical on both sides — a CI check comparing dig NS output across providers before a deploy catches drift before customers do.
Security-adjacent: an attacker who can register a currently-unclaimed nameserver hostname from a stale/removed NS record can hijack delegated traffic — this is why NODA flags orphaned/removed-but-still-delegated NS entries as Critical, not cosmetic.

← Back to Lesson 2

Lesson 3

Zone Mechanics

Practice Objective

Understand SOA serial semantics, force and verify a zone transfer (AXFR), and confirm secondaries stay in sync.

Why It's Important

A stale or non-incrementing serial silently breaks secondary sync — secondaries think nothing changed and serve outdated data indefinitely. This is a quiet, hard-to-notice failure mode until an audit (or an angry customer) surfaces it.

Commands to Run / Settings to Verify

# Read the current SOA serial + timers
dig yourdomain.com SOA +short

# Compare serial across primary and every secondary — must match after any change
for ns in $(dig +short yourdomain.com NS); do echo "== $ns =="; dig @$ns yourdomain.com SOA +short; done

# Attempt a zone transfer (should SUCCEED only from an authorized secondary IP, FAIL from elsewhere)
dig axfr yourdomain.com @ns1.yourdnsprovider.com

# From your lab box (should be refused if AXFR is properly locked down):
dig axfr yourdomain.com @ns1.yourdnsprovider.com

Make one small record change, bump the serial per your provider's convention (YYYYMMDDnn is the common one), and re-run the secondary comparison above until all secondaries match.

Additional Notes (Role-Specific)

Sysadmin: an AXFR that succeeds from an arbitrary IP is a real, common misconfiguration — treat a successful transfer from your lab box as a finding to fix, not a convenience.
DevOps: if zone data is managed as code (Terraform/IaC), the serial bump should be automated as part of the pipeline — a human-maintained serial WILL eventually get forgotten.
Security-adjacent: this is the exact check behind NODA's "AXFR / Zone Transfer" Check (CAT-SEC) — an open zone transfer hands an attacker your entire DNS footprint in one query, including internal-looking hostnames useful for reconnaissance.

← Back to Lesson 3

Lesson 4

Record Types Beyond the Basics

Practice Objective

Correctly construct and verify A/AAAA, CNAME-restriction edge cases, MX, TXT, SRV, and CAA records.

Why It's Important

Most admins know A/MX/TXT; CAA and CNAME-coexistence rules are where "masters level" actually starts — CAA in particular is the newest widely-relevant record type and controls who is allowed to issue a TLS cert for your domain at all.

Commands to Run / Settings to Verify

# Basic address records
dig yourdomain.com A
dig yourdomain.com AAAA

# CNAME coexistence rule check — a CNAME must be the ONLY record at that name
dig www.yourdomain.com CNAME
dig www.yourdomain.com ANY    # should show nothing else at this name

# MX
dig yourdomain.com MX +short

# SRV (example: a service advertising itself via DNS)
dig _sip._tcp.yourdomain.com SRV

# CAA — who is authorized to issue certs for this domain
dig yourdomain.com CAA +short

Add a CAA record restricting issuance to one CA (e.g. 0 issue "letsencrypt.org"), then confirm via dig it's visible before relying on it — and note that CAA is checked by the CA at issuance time, not by browsers at connection time.

Additional Notes (Role-Specific)

Sysadmin: a CNAME accidentally coexisting with another record type at the same name is a classic misconfiguration in control-panel DNS editors that don't enforce the RFC rule client-side — always verify with dig ANY after adding a CNAME.
DevOps: SRV records matter more in service-discovery-heavy environments (SIP, XMPP, some Kubernetes ingress patterns) — if your stack doesn't use service discovery via DNS, this record type may simply not apply; don't force an exercise where there's no real use.
Security-adjacent: CAA with no iodef tag means you won't get notified of unauthorized issuance attempts — add one (0 iodef "mailto:security@yourdomain.com") as the more complete configuration.

← Back to Lesson 4

Lesson 5

DNSSEC I: Chain of Trust

Practice Objective

Sign a zone, observe the DS record appear at the parent, and validate the resulting chain of trust end to end.

Why It's Important

This is the single most-cited "best practice gap" in the entire industry (see NODA's own research articles) — most operators either never enable it or enable it once and never verify the chain actually validates. Watching your own DS record populate is the best teaching moment in the course.

Commands to Run / Settings to Verify

# Before signing: confirm no DNSKEY exists yet
dig yourdomain.com DNSKEY +short

# Enable DNSSEC via your provider's dashboard (one-click on Cloudflare/Route53/most modern hosts), then:
dig yourdomain.com DNSKEY +short
dig yourdomain.com DS +short          # queried from the PARENT

# Full chain validation (requires a validating resolver)
delv yourdomain.com A                 # delv reports "fully validated" or shows exactly where the chain breaks

# Confirm a validating public resolver agrees
dig @1.1.1.1 yourdomain.com A +dnssec +cd    # AD flag present = validated

delv (ships with BIND) is the most direct tool for this — it walks the actual trust chain, not just "is DNSSEC on."

Additional Notes (Role-Specific)

Sysadmin: if self-hosting BIND, named-checkzone plus dnssec-verify should run as a pre-publish gate, not a post-hoc check.
DevOps: DS record publication at the parent is usually a manual or semi-manual registrar step even when zone signing itself is automated — this is the one part of the pipeline that resists full automation on most registrars; document it explicitly in runbooks.
Security-adjacent: an AD flag from a public resolver is necessary but not sufficient — always cross-check with delv or a second independent validator (e.g. dnsviz.net) before considering the chain trustworthy, since a misconfigured resolver can falsely report validation.

← Back to Lesson 5

Lesson 6

DNSSEC II: Operations & Failure Modes

Practice Objective

Perform a key rollover and deliberately break DNSSEC to recognize its real-world failure signatures.

Why It's Important

DNSSEC deployments fail almost exclusively at operational moments — key rollovers, algorithm changes — not at initial setup. This is the gap between "I turned it on" and "I can operate it," and it's where most real-world DNSSEC outages actually happen.

Commands to Run / Settings to Verify

# Baseline: confirm current validation is clean
delv yourdomain.com A

# Initiate a key rollover via your provider's dashboard, then monitor the transition:
dig yourdomain.com DNSKEY +short      # watch for two keys present during rollover overlap
dig yourdomain.com DS +short          # confirm DS updates at parent AFTER new DNSKEY is live, not before

# Deliberately break it (lab domain only — never on a production zone):
# e.g. let the DS record go stale relative to a rolled key, or truncate a signature manually if your provider allows raw record edit
dig yourdomain.com A +dnssec          # observe SERVFAIL and the exact error against a validating resolver
delv yourdomain.com A                 # delv will show precisely which link in the chain failed

The goal is recognizing the SERVFAIL pattern from a validating resolver (typically what end users report as "domain X doesn't work") and tracing it back to the specific broken link via delv, rather than guessing.

Additional Notes (Role-Specific)

Sysadmin: know your provider's rollover automation (Cloudflare/Route53 auto-rotate on a schedule) vs. manual rollover — manual rollover is where the DS-before-DNSKEY ordering mistake actually happens in production.
DevOps: if DS records are managed as code, a rollover MUST be a two-step deploy (publish new DNSKEY, wait for propagation + old TTL expiry, THEN update DS) — a single atomic IaC apply that does both at once is the most common self-inflicted DNSSEC outage.
Security-adjacent: RFC 8624 governs algorithm selection — if testing an algorithm change (not just key rollover), confirm your registrar/parent actually supports the new algorithm in DS records before cutting over; not all do.

← Back to Lesson 6

Lesson 7

DNS as Attack Surface

Practice Objective

Test your own infrastructure for open resolver behavior and cache-poisoning-adjacent misconfigurations.

Why It's Important

An open resolver on infrastructure you control can be silently weaponized in a reflection/amplification DDoS attack against a third party — you become an unwitting participant, and it's entirely preventable with one configuration check.

Commands to Run / Settings to Verify

# Test whether YOUR nameserver answers recursive queries from arbitrary requesters (it should NOT, for an authoritative-only server)
dig @your-lab-box-ip google.com A         # from a machine OTHER than the server itself

# Confirm recursion is disabled on an authoritative-only server (BIND example)
grep -i recursion /etc/bind/named.conf.options    # should show "recursion no;"

# Check your domain isn't itself vulnerable to being used as a reflection amplifier via ANY queries
dig yourdomain.com ANY @ns1.yourdnsprovider.com +norecurse

# Basic response-size check — larger responses = larger amplification factor if abused
dig yourdomain.com ANY +norecurse | wc -c

If step 1 returns a real answer from a machine that isn't authorized to query your box, recursion is open and needs fixing immediately — this is the exact Open Recursor Check NODA runs under CAT-SEC.

Additional Notes (Role-Specific)

Sysadmin: recursion no; (BIND) or the Unbound/PowerDNS equivalent access-control list is the fix — verify with an external vantage point (your AWS lab box, if using Option A), not just localhost, since localhost tests don't reveal external exposure.
DevOps: if nameservers are behind a load balancer/firewall, confirm the ACL is enforced at the DNS server itself, not only at the network layer — a firewall rule that gets accidentally opened (common during troubleshooting) shouldn't be the only thing preventing an open resolver.
Security-adjacent: RFC 5358 (advisory, not a MUST/SHALL source per NODA's own Methodology Section 10) is the canonical reference here — cite it in remediation notes, but don't treat it as a hard compliance requirement.

← Back to Lesson 7

Lesson 8

SPF In Depth

Practice Objective

Construct a correct SPF record, deliberately exceed the 10-lookup limit, and recognize the resulting failure.

Why It's Important

SPF's 10-DNS-lookup limit (RFC 7208 §4.6.4) is the most common real-world SPF failure — records grow organically as services get added, silently cross the limit, and SPF starts failing (permerror) for everyone, often unnoticed for months.

Commands to Run / Settings to Verify

# Read your current SPF record
dig yourdomain.com TXT +short | grep spf1

# Count lookups manually — each of these mechanisms costs 1 lookup: include, a, mx, ptr, exists, redirect
# (there's no single dig command for this — walk the record term by term)

# Test with a real SPF validator tool (MarinaDNS's own /mailauth tool does this)
# or manually resolve each 'include:' target to confirm it resolves and count nested includes

# Simulate exceeding the limit: add enough include: mechanisms to cross 10, then check for permerror
# via a real send-test (mail-tester.com or similar) or a dedicated SPF-lookup-count tool

Fix by flattening (replacing an include: with its resolved IP ranges directly, accepting the maintenance tradeoff) or removing unused includes — never by simply hoping the count stays under 10 as more services get added.

Additional Notes (Role-Specific)

Sysadmin: every third-party service added (email marketing, helpdesk, CRM) that sends "as you" typically wants an SPF include — track these in a change log, since nobody remembers all of them 2 years later when the limit gets hit.
DevOps: if SPF is managed as code, a CI lint step that counts lookups before a merge is cheap insurance — this is exactly what NODA's own SPF Lookup Limit Check (CAT-MAIL) automates.
Security-adjacent: a domain sending NO mail should still publish v=spf1 -all (a null policy) — RFC 7208 §10.1 explicitly recommends this, and NODA scores it as Unconditional for exactly this reason (Methodology Section 6.3).

← Back to Lesson 8

Lesson 9

DKIM In Depth

Practice Objective

Generate a DKIM key pair, publish the selector record, and verify a real signed message validates.

Why It's Important

DKIM selector naming isn't standardized (RFC 6376) — unlike SPF/DMARC there's no fixed record name to check, which is why DKIM is the hardest of the three to audit externally and the easiest to get silently wrong.

Commands to Run / Settings to Verify

# Generate a DKIM key pair (example using OpenSSL)
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Publish the public key as a TXT record at: selector._domainkey.yourdomain.com
dig selector._domainkey.yourdomain.com TXT +short

# Send a real test email through a provider configured to sign with this key, then inspect headers:
# look for DKIM-Signature: header, note the 's=' (selector) and 'd=' (domain) tags

# Verify the signature validates against the published key
dig $(echo "your-selector")._domainkey.yourdomain.com TXT +short
# cross-check manually or via a validator (opendkim-testkey, or mail-tester.com)

Confirm the selector name in the actual DKIM-Signature header matches exactly what's published — a mismatch here is the most common DKIM misconfiguration.

Additional Notes (Role-Specific)

Sysadmin: rotate DKIM keys periodically (annually is a reasonable baseline) — publish the new selector alongside the old one, cut sending over, THEN remove the old selector record, mirroring the DNSSEC rollover pattern from Lesson 6.
DevOps: if using a transactional email provider (SendGrid, Postmark, etc.), they manage the private key and give you only the DNS record to publish — your job is verification, not generation; don't assume you need to run openssl yourself in that setup.
Security-adjacent: per NODA's own Methodology (Section 6.3), a DKIM check with no key found at a guessed selector resolves to Informational, not a hard Fail — absence of a signature at a common selector name is not equivalent to confirmed absence of DKIM entirely, since selector names are arbitrary.

← Back to Lesson 9

Lesson 10

DMARC In Depth

Practice Objective

Deploy DMARC through its full policy progression (none → quarantine → reject) and read a real aggregate (RUA) report.

Why It's Important

Jumping straight to p=reject without first observing p=none reports risks blocking your own legitimate mail (a forgotten third-party sender, a CRM, an internal tool) — the progression exists specifically to surface and fix gaps before they become outages.

Commands to Run / Settings to Verify

# Read current DMARC record
dig _dmarc.yourdomain.com TXT +short

# Start at monitoring-only:
# v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

# After 1-2 weeks of real mail flow, inspect the RUA aggregate report (arrives as an XML attachment)
# Look for: source IPs you don't recognize, SPF/DKIM alignment failures on mail you DO recognize as legitimate

# Progress the policy once reports are clean:
# v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com
# ... then eventually:
# v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

# Verify each stage is live
dig _dmarc.yourdomain.com TXT +short

Use pct= to ramp gradually (e.g. 25/50/100) rather than flipping the whole domain to reject at once — this is the safest real-world rollout pattern.

Additional Notes (Role-Specific)

Sysadmin: RUA reports arrive as gzipped XML — a parser (there are many free ones, or write a quick script) is worth it once volume is more than a handful of emails a day; reading raw XML by hand doesn't scale.
DevOps: if mail is sent from multiple pipelines (app transactional mail, marketing platform, support desk), each needs to independently pass SPF or DKIM alignment — DMARC failures often trace to exactly one forgotten pipeline, not a domain-wide misconfiguration.
Security-adjacent: DMARC's real value is anti-spoofing, not deliverability — per NODA's Methodology (Section 6.3), DMARC stays Unconditional regardless of MX presence, since a domain that sends no mail is an even more attractive spoofing target and still needs a policy published.

← Back to Lesson 10

Lesson 11

Reverse DNS & Mail Reputation

Practice Objective

Set up correct PTR records, verify FCrDNS (Forward-Confirmed reverse DNS), and run a full-domain audit as the course's closing exercise.

Why It's Important

Reverse DNS is the most underserved topic in mainstream DNS certification content despite being a major deliverability signal — many mail servers reject or spam-flag mail from IPs with missing or mismatched PTR records, independent of SPF/DKIM/DMARC correctness.

Commands to Run / Settings to Verify

# Reverse lookup: what hostname does your mail-sending IP resolve to?
dig -x your.mail.server.ip +short

# Forward-confirm: does that hostname resolve back to the same IP? (FCrDNS)
dig +short the-ptr-hostname.example.com A

# Full closing capstone — run every prior lesson's check against your domain in one pass:
dig yourdomain.com A AAAA MX TXT NS SOA CAA +noall +answer
dig yourdomain.com DNSKEY DS +short
dig _dmarc.yourdomain.com TXT +short
dig selector._domainkey.yourdomain.com TXT +short
dig -x your.mail.server.ip +short

# Or, simplest: run the whole domain through NODA itself
# https://noda.marinadns.io — same checks, one consolidated report

The capstone is deliberately "run your own domain through everything you've learned, then run it through NODA and see if your manual findings match the automated report."

Additional Notes (Role-Specific)

Sysadmin: PTR records are set by whoever controls the IP block (usually your hosting/cloud provider, not your DNS provider) — this is a common point of confusion; you often can't fix PTR in the same dashboard where you manage forward records.
DevOps: if sending mail from ephemeral cloud infrastructure (auto-scaled instances, containers), PTR records tied to a specific IP become a real operational constraint — a dedicated, stable outbound IP (or a relay service) is usually necessary specifically because PTR can't follow ephemeral infrastructure.
Security-adjacent: FCrDNS mismatches are a classic spam-filter heuristic — even with perfect SPF/DKIM/DMARC, a mismatched or missing PTR can still tank deliverability; treat it as a fourth pillar alongside the email-auth trio, not an afterthought.

← Back to Lesson 11