Module 9 · Lesson 5

Final Project: DNS Audit and Architecture Review

A practical capstone project. Audit a real or sample DNS setup across five dimensions: portfolio, architecture, security, developer integration, and strategy.

Final Project: DNS Audit and Architecture Review

This is the capstone exercise. You can run it against a real setup you own or manage, or against the sample scenario provided below. Either way, work through all five sections.

The audit template at the end of this lesson is yours to keep and reuse. It's designed to be a working document, not a checkbox exercise.

The Scenario

If you don't have a real setup to audit, use this sample scenario:

Company: A B2B software company with around 200 employees. Primary product is a cloud-based project management tool. They have:

  • 1 primary domain: buildflo.com
  • 12 secondary domains (regional variants, product-specific, defensive)
  • Infrastructure on AWS, primarily in us-east-1 with a secondary region in eu-west-1
  • Email through Google Workspace
  • Transactional email through SendGrid
  • DNS currently managed manually through Route 53 console
  • No secondary authoritative provider
  • No formal domain portfolio review process
  • DMARC set to p=none from initial setup, never updated
  • Monitoring: application uptime monitoring, no DNS-specific checks

Work through the audit as if you're the person responsible for their DNS infrastructure.

Section 1: Domain Portfolio Audit

Objective: Know what you have, why you have it, and what the risks are.

Steps

  1. Inventory all domains. For each domain, capture:

    • Domain name
    • Registrar
    • Expiry date
    • Nameservers (authoritative provider)
    • EPP status codes
    • Registrant contact (is it current? does the email address work?)

  2. Classify by use. Use these categories:

    • Active brand — receives live traffic, hosts services, or is used for email
    • Active redirect — redirects to another domain; important to the brand
    • Defensive — registered to prevent misuse; no direct use
    • Unknown — can't determine why it was registered

  3. Identify risks.

    • Domains expiring within 60 days
    • Domains where the registrant contact email is unreachable
    • Domains without transfer lock (clientTransferProhibited)
    • Domains classified as "unknown"

Sample Audit Table

DomainRegistrarExpiryUseEPP LockRisk
buildflo.comNamecheap2025-03-15Active brandYesExpires in 34 days
buildflo.netNamecheap2025-07-22DefensiveYesNone
buildflo.ioGoDaddy2024-12-01UnknownNoExpired, no lock
getbuildflo.comNamecheap2025-09-18Active redirectYesNone
buildflo.frGandi2025-05-10Active brand (EU)NoNo transfer lock

Findings from this sample:

  • buildflo.com expires in 34 days — needs immediate attention
  • buildflo.io may have already expired — verify and recover if valuable
  • buildflo.fr has no transfer lock — add it
  • Unknown-classified domains need owner investigation before next renewal

Section 2: DNS Architecture Review

Objective: Assess the authoritative setup, TTL strategy, and redundancy.

Questions to Answer

Authoritative DNS:

  • How many DNS providers are authoritative for your primary domain?
  • If your primary provider has an outage, what happens?
  • Are zone transfers configured between providers if multi-provider?
  • Are SOA serials consistent across providers?

Record architecture:

  • Is the apex domain handled correctly (ALIAS/ANAME, not a bare CNAME)?
  • Are wildcard records in use? If so, are they intentional?
  • Are there deprecated subdomains still in DNS pointing to decommissioned infrastructure?

TTL strategy:

  • What are the current TTLs on your primary A records?
  • Is there a documented process for pre-lowering TTLs before planned changes?
  • What's the TTL on your MX records? (Should be 3600s or higher once stable)

Architecture Scorecard

ItemCurrent StateTarget StatePriority
Authoritative providersSingle (Route 53)Multi-provider (Route 53 + Cloudflare)High
Zone transfer configuredN/AConfigured and testedHigh
SOA serial syncN/AAutomated checkMedium
Apex record typeALIAS (correct)—Pass
Deprecated records3 found0Medium
TTL on primary A record3600s300s (until stable)Low
TTL on MX300s3600sLow

Section 3: Security Posture

Objective: Assess DNSSEC status, email authentication completeness, registrar security, and monitoring.

Email Authentication Checklist

For each domain that sends email:

[ ] SPF record present
[ ] SPF record covers all sending sources
[ ] SPF record ends with ~all or -all (not +all)
[ ] DKIM selector published for each sending provider
[ ] DMARC record present
[ ] DMARC policy is quarantine or reject (not just none)
[ ] DMARC aggregate reports configured (rua=)
[ ] DMARC reports are being reviewed at least monthly
[ ] DMARC failure reports configured (ruf=) — optional but useful

DNSSEC

  • Is DNSSEC enabled on your primary domain?
  • If yes: are DS records published at the parent registry?
  • If yes: are keys being rotated on a documented schedule?
  • If no: evaluate the risk/complexity tradeoff for your situation

DNSSEC is not required for all deployments. It adds protection against cache poisoning attacks and provides cryptographic verification of DNS responses. The operational complexity (key management, zone signing, monitoring for signature expiry) is real. For most SaaS applications, a strong registrar lock plus monitoring is a higher-return investment than DNSSEC.

Registrar Security

[ ] 2FA enabled on registrar account
[ ] Registrar account uses a dedicated email address (not an individual's personal email)
[ ] EPP transfer lock enabled on all Tier 1 domains
[ ] Registry lock enabled on critical domains (if offered by registrar)
[ ] Auth codes are documented and current
[ ] No unauthorized users on the registrar account

Monitoring

[ ] External DNS health checks running for primary domain (A record)
[ ] MX record monitoring configured
[ ] Passive DNS monitoring for new registrations targeting brand
[ ] NXDOMAIN rate alerting on internal resolvers
[ ] SERVFAIL rate alerting
[ ] Certificate Transparency monitoring for unexpected cert issuance
[ ] SOA serial consistency check between providers (if multi-provider)

Section 4: Developer Integration Check

Objective: Assess how well DNS is integrated into development practices and infrastructure automation.

Container/Kubernetes DNS

  • What is the ndots setting in your pod DNS configuration?
  • Are containers making external API calls with high frequency DNS lookups?
  • Is CoreDNS configured and monitored?
  • Are service discovery patterns using Kubernetes DNS correctly?

Check current ndots setting:

kubectl get configmap coredns -n kube-system -o yaml | grep ndots
# Or check a running pod:
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

Check CoreDNS NXDOMAIN rate:

kubectl top pods -n kube-system
# Then check CoreDNS metrics endpoint if Prometheus is configured

Infrastructure as Code

  • Are DNS records managed via Terraform, Pulumi, or OctoDNS, or manually through the console?
  • If IaC: is DNS configuration in version control?
  • Is there a drift detection process (e.g., terraform plan run on schedule)?
  • Are DNS changes part of deployment pipelines?

Application-Level DNS Behavior

  • Do applications cache DNS responses? Do they respect TTLs?
  • Are health check intervals appropriate for your TTL values?
  • Are there hardcoded IP addresses in application configuration that should be hostnames?

Section 5: Portfolio Strategy

Objective: Ensure the domain portfolio is sustainable and intentional.

Strategic Questions

  1. Does your domain strategy match your business scope? If you're operating in 3 countries, are you registered in those ccTLDs? If you've entered a new market since your last domain review, does your registration reflect that?

  2. What's the renewal budget and is it justified? List every domain and its annual cost. Total it. Is the value each domain provides commensurate with the cost?

  3. What would an attacker register tomorrow if they wanted to impersonate you? List the 5 most damaging typosquats. Are any of them already registered by someone else? (Check WHOIS.) Are the high-risk ones in your portfolio?

  4. What is your monitoring coverage? Passive DNS monitoring should be alerting on newly registered domains that match your brand patterns. If it's not, set it up.

  5. Is there an annual review process? The domain portfolio should be reviewed at least annually, with a documented owner. If no one owns it, decisions get made by whoever has the registrar credentials and a renewal reminder.

Renewal Decision Framework

For each domain at renewal:

QuestionYesNo
Does this domain receive traffic?KeepInvestigate
Is it critical to redirect chains?KeepInvestigate
Is it a Tier 1 or Tier 2 defensive registration?KeepEvaluate drop
Does anyone know why it was registered?Informed decisionDefault to drop

Completing the Project

Once you've worked through all five sections:

  1. Prioritize findings. High priority: security issues (expired domains, missing auth, no transfer lock on active brands), imminent expirations, single-provider DNS for critical infrastructure. Medium: TTL strategy, IaC gaps, monitoring gaps. Low: optimization and cleanup.

  2. Write a remediation backlog. Not a project plan — just a list of findings with priority and estimated effort. This is what you bring to a team meeting.

  3. Set a review cadence. DNS audits decay quickly. Schedule the next review before you close this one.

The Reusable Audit Template

Save this and adapt it:

# DNS Audit — [Organization Name] — [Date]

## Portfolio Summary
| Total domains | Active brand | Active redirect | Defensive | Unknown | Expired |
|---|---|---|---|---|---|
| | | | | | |

## Architecture Summary
| Primary DNS provider | Secondary provider | Multi-provider configured | DNSSEC |
|---|---|---|---|
| | | | |

## Security Summary
| DMARC policy | SPF coverage | Registry lock on Tier 1 | Monitoring in place |
|---|---|---|---|
| | | | |

## Critical Findings
1.
2.
3.

## High Priority Actions
- [ ]
- [ ]

## Medium Priority Actions
- [ ]
- [ ]

## Next Review Date: ___________
## Owner: ___________

Key Takeaways

  • An audit is not a one-time exercise. Schedule the next one when you finish this one.
  • Most DNS problems show up during the portfolio and security sections. The architecture section reveals single points of failure; the security section reveals long-standing misconfigurations.
  • Passive DNS monitoring and DMARC reporting are both cheap and valuable. If they're missing from the setup you're auditing, they go in the high-priority backlog.
  • The portfolio strategy section is often the most neglected. Domain registrations accumulate over time without a corresponding accumulation of strategic intent.

Up Next

Lesson 6 — Closing: Anouar's final word — 20 years of DNS, distilled into what actually matters.