1. Interpret DNS answer

The goal is to handle interpret dns answer as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

2. Check zone file

The goal is to handle check zone file as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

3. Evaluate SOA and serial

The goal is to handle evaluate soa and serial as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

4. Create TTL plan

The goal is to handle create ttl plan as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

5. Explain delegation

The goal is to handle explain delegation as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

6. Find CNAME conflict

The goal is to handle find cname conflict as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

7. Check MX TXT and mail DNS

The goal is to handle check mx txt and mail dns as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

8. Collect DNSSEC evidence

The goal is to handle collect dnssec evidence as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

9. Document resolver path

The goal is to handle document resolver path as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

10. Write incident note

The goal is to handle write incident note as a traceable DNS activity. The solution must include query evidence, zone context, TTL or delegation relation and a security boundary.

Task

1. Read the matching reference file in docs/.
2. Use one example from examples/.
3. Run only local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Document risk, TTL and cleanup.

Acceptance Criteria

• RCODE and affected RRtype are named.
• Zone, owner name and TTL are traceable.
• No production provider credentials are used.
• Rollback or correction path is described.

Official Sources and Boundary

• RFC 1034, Domain Names - Concepts and Facilities: https://datatracker.ietf.org/doc/html/rfc1034
• RFC 1035, Domain Names - Implementation and Specification: https://datatracker.ietf.org/doc/html/rfc1035
• RFC 8499, DNS Terminology: https://www.rfc-editor.org/info/rfc8499/
• RFC 6891, Extension Mechanisms for DNS (EDNS(0)): https://datatracker.ietf.org/doc/html/rfc6891
• RFC 4033, DNS Security Introduction and Requirements: https://datatracker.ietf.org/doc/html/rfc4033
• RFC 9364, DNSSEC Best Current Practice: https://www.rfc-editor.org/info/rfc9364/
• IANA Root Zone Database: https://www.iana.org/domains/root/db
• ISC BIND 9 Documentation: https://bind9.readthedocs.io/
• CoreDNS Documentation: https://coredns.io/manual/toc/

This workshop does not introduce DNS protocol rules. It maps official DNS concepts into labs, review questions, zone files, resolver models and operational workflows.

Practice Appendix: DNS Evidence for 02-intermediate-exercises-dns-EN.md

This appendix connects the file with repeatable DNS evidence. A DNS statement is reliable only when role, zone, name, RRtype, RCODE, TTL, resolver path and operational impact are reviewed together.

A.1 Namespace and FQDN

DNS starts with a hierarchical namespace. Every analysis must clarify whether a name is relative, fully qualified, part of a zone or affected by a local stub resolver search path.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.2 Stub Resolver

The client stub resolver usually knows only local resolvers and search lists. Errors in resolv.conf, systemd-resolved or search domains can look like server failures.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.3 Recursive Resolver

A recursive resolver performs iteration, caching, DNSSEC validation and forwarding. It is not the same as the authoritative server for a zone.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.4 Authoritative Server

Authoritative servers answer from zones. They should not provide open recursion and need clear zone ownership, transfer rules and monitoring.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.5 Zone and Apex

A zone starts at the apex and contains SOA, NS and authoritative RRsets. Every change needs serial policy, review and rollback.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.6 SOA and Serial

SOA controls zone metadata, refresh, retry, expire and negative cache time. Serial values matter for secondary servers and audit.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.7 TTL and Cache

TTL controls how long answers are cached. Before migrations TTLs must be lowered early enough and stabilized after the change.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.8 Negative Caching

NXDOMAIN and NODATA are cached through SOA information. This explains why deleted or newly created names are not visible everywhere immediately.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.9 Delegation

Delegation connects parent and child zone. NS records, glue and child SOA must be consistent or subtle outages appear.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.10 Glue Records

Glue is needed when name server names live inside the delegated zone. Wrong or missing glue can prevent reachability of the child zone.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.11 Record Types

A, AAAA, CNAME, MX, TXT, SRV, PTR, NS and SOA have different rules. A CNAME must not be combined with other data at the same owner name.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.12 Mail DNS

SPF, DKIM and DMARC are DNS-based mail policy data. Syntax, TTL and organizational ownership must be reviewed separately.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.13 Reverse DNS

PTR zones belong to address space, not the forward zone. Ownership and delegation often differ from the domain zone.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.14 Transport

DNS uses UDP and TCP. EDNS extends UDP response sizes; fragmentation, TC bit and TCP fallback are common failure sources.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.15 EDNS

EDNS(0) enables larger responses and DNSSEC transport, but can be broken by firewalls or middleboxes.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.16 DNSSEC

DNSSEC protects origin and integrity, not confidentiality. DS, DNSKEY, RRSIG, NSEC/NSEC3 and validation status must be reviewed together.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.17 TSIG

TSIG protects zone transfers and dynamic updates with shared keys. These keys do not belong in repositories and need rotation.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.18 Zone Transfer

AXFR and IXFR are operational functions. Allow-transfer, notify, secondary servers and audit must be documented clearly.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.19 Dynamic Update

DNS UPDATE should be allowed only with narrow policy and TSIG. Uncontrolled updates can destroy zone integrity and audit.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.20 Split Horizon

Split horizon creates different answers per view. This is legitimate, but troubleshooting and security review must name the affected view.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.21 Resolver Privacy

DoT, DoH and QNAME minimization affect transport and privacy. They do not replace DNSSEC or correct zone data.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.22 RPZ and DNS Firewall

Response policy zones and DNS firewalls are security controls. They need clear policy, logging, exception process and abuse prevention.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.23 Kubernetes DNS

CoreDNS in Kubernetes combines service discovery, cluster domains and forwarding. Failures can come from CoreDNS, kube-dns configuration, NetworkPolicy or upstream DNS.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.24 Monitoring

DNS monitoring must cover RCODE distribution, latency, SERVFAIL rate, NXDOMAIN spikes, transfer status, DNSSEC validation and zone serials.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.25 Incident Response

DNS incidents need fast classification: affected view, resolver path, RCODE, TTL, cache, delegation, DNSSEC and recent changes.

Concrete review questions:

• Which DNS role is affected?
• Which zone and owner name are affected?
• Which RRtype and RCODE were observed?
• Which TTL or negative cache time applies?
• Which delegation or resolver path is involved?
• Which security control is relevant?
• Which evidence contains no secrets?
• What is the rollback?

Typical evidence:

evidence/
  query-output.txt
  zone-review.txt
  resolver-path.md
  ttl-and-cache.md
  rollback.md

A.26 Minimal Completion Evidence

• RCODE, RRtype, zone and resolver path are documented.
• Zone files contain SOA and NS and do not violate CNAME rules.
• TTL, negative cache time and rollback window are named.
• DNSSEC, TSIG or ACLs are not claimed without evidence.
• Evidence contains no production secrets, API tokens or zone keys.
• Official RFCs and tool documentation replace assumptions.