# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## BDNS — Service DNS migration lab A fictional internal API is moving to a new endpoint. The team assumes DNS changes are immediate and has no rehearsal for stale clients. **Field:** Networking. **Suggested stack:** TypeScript, DNS fixtures, HTTP. **Engineer value:** Practice DNS semantics, migration timing, and network diagnosis. **Company value:** Produce a migration plan that makes cache delay and endpoint compatibility explicit. **Delivery agreement:** Deliver local DNS simulations and a cutover report; modify no real DNS records. ### Setup prerequisites - Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. ### Model DNS responses Define record and cache semantics. #### BDNS-101 — Inventory service records and their consumers **Task · Medium priority · Foundational** noCV practice brief v5 · BDNS-101 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model DNS responses. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The team knows the main hostname but not aliases used by background jobs. Acceptance criteria - List record types, aliases, and modeled consumers. - Identify ownership and current TTL. - Mark unknown client caching behavior. Implementation constraints - Use reserved local test names only. Verification - Resolve the declared alias chain. - Report an unknown consumer cache policy explicitly. Deliverables - DNS dependency inventory. Rollout and recovery: Review inventory before scheduling a cutover. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-102 — Implement TTL-aware positive caching in the resolver fixture **Task · Medium priority · Intermediate** noCV practice brief v5 · BDNS-102 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model DNS responses. Depends on: BDNS-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 60% · Performance engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The simulator caches every answer forever and cannot represent migration delays. Acceptance criteria - Expire answers using an injected clock. - Honor the declared TTL without extending it on reads. - Key cache entries by name and record type. Implementation constraints - Do not use wall-clock sleeps in tests. Verification - Serve a cached answer before expiry. - Advance time and retrieve the changed authoritative answer. Deliverables - Positive-cache simulator. Rollout and recovery: Validate the simulator against its documented semantics before using results. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-103 — Model negative caching separately from empty address records **Task · High priority · Advanced** noCV practice brief v5 · BDNS-103 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model DNS responses. Depends on: BDNS-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 80% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A temporary missing hostname remains unavailable after its record is created. Acceptance criteria - Distinguish nonexistent name from no record of requested type. - Apply declared negative-cache lifetime. - Preserve the reason for cached negative answers. Implementation constraints - Use explicit fixture policy rather than claiming universal resolver behavior. Verification - Create a record after a negative lookup. - Show recovery only after the modeled negative cache expires. Deliverables - Negative-cache scenarios. Rollout and recovery: Avoid deleting names during cutover unless negative-cache effects are accepted. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Rehearse endpoint changes Handle stale clients and lookup failures. #### BDNS-104 — Reject alias loops and excessively deep resolution chains **Bug · High priority · Intermediate** noCV practice brief v5 · BDNS-104 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 70% · Backend 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A mistaken alias points back to the original hostname and exhausts lookup work. Acceptance criteria - Track visited aliases. - Bound chain depth and response size. - Return a clear resolution failure without partial success. Implementation constraints - The resolver fixture remains local and read-only. Verification - Resolve a valid multi-hop chain. - Reject a loop and an over-depth chain. Deliverables - Alias validation. Rollout and recovery: Validate proposed record sets before applying the synthetic change. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-105 — Rehearse lowering TTL before endpoint cutover **Task · High priority · Advanced** noCV practice brief v5 · BDNS-105 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-102, BDNS-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 60% · Site reliability 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Lowering TTL at the same moment as the address change does not shorten existing cached lifetimes. Acceptance criteria - Model caches populated before and after TTL reduction. - Calculate the required wait under declared assumptions. - Track old and new endpoint usage during overlap. Implementation constraints - Do not promise that every real client respects TTL. Verification - Simulate an appropriately staged cutover. - Show a stale pre-change cache after an immediate cutover. Deliverables - TTL staging rehearsal. Rollout and recovery: Keep the old endpoint available through the documented overlap. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-106 — Preserve application compatibility across old and new addresses **Task · High priority · Advanced** noCV practice brief v5 · BDNS-106 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 40% · API design 40% · Quality engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. DNS propagation sends different clients to different service versions. Acceptance criteria - Exercise the same public contract on both endpoints. - Preserve shared operation identity across retries. - Reject incompatible old/new behavior before cutover. Implementation constraints - Use synthetic requests and loopback endpoints. Verification - Complete retries across both endpoints. - Detect a response-contract mismatch during overlap. Deliverables - Endpoint overlap checks. Rollout and recovery: Deploy compatible service behavior before changing DNS. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-107 — Distinguish resolver failure from application connection failure **Story · Medium priority · Intermediate** noCV practice brief v5 · BDNS-107 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-104, BDNS-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 70% · Site reliability 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Operators see one generic network error for lookup failures and refused connections. Acceptance criteria - Classify lookup, address selection, connection, and HTTP failures. - Record bounded timing per stage. - Keep hostnames and request data within the declared safe diagnostic policy. Implementation constraints - No packet payloads or credentials in generic logs. Verification - Diagnose a local nonexistent name. - Resolve an address then distinguish refused connection. Deliverables - Network-stage diagnostics. Rollout and recovery: Add classification before changing retry behavior. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Review cutover Choose timing and recovery controls. #### BDNS-108 — Evaluate rollback when both old and new answers remain cached **Task · High priority · Expert** noCV practice brief v5 · BDNS-108 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review cutover. Depends on: BDNS-105, BDNS-106, BDNS-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 40% · Distributed systems 30% · Site reliability 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Reverting the DNS record does not immediately send every client back to the old endpoint. Acceptance criteria - Model multiple cache ages during rollback. - Define service compatibility and overlap requirements. - Compare DNS rollback with routing-level containment under declared constraints. Implementation constraints - Keep conclusions scoped to the simulated client population. Verification - Roll back with mixed cached answers. - Expose clients that continue using the new endpoint until expiry. Deliverables - DNS recovery decision record. Rollout and recovery: Retain both compatible endpoints until the modeled overlap and operational checks complete. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-109 — Check IPv4 and IPv6 record migration independently **Task · High priority · Advanced** noCV practice brief v5 · BDNS-109 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review cutover. Depends on: BDNS-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 80% · Quality engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Only the IPv4 record is updated while dual-stack clients continue using the old IPv6 endpoint. Acceptance criteria - Track A and AAAA records separately. - Rehearse differing cache ages by family. - Verify contract compatibility on both local address families. Implementation constraints - If IPv6 is unavailable locally, label that execution unverified and use deterministic fixtures. Verification - Simulate synchronized family updates. - Detect a stale AAAA record after A changes. Deliverables - Dual-stack DNS cutover checks. Rollout and recovery: Require family-specific review before final endpoint retirement. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BDNS-110 — Write a DNS change record with cache assumptions **Chore · Low priority · Foundational** noCV practice brief v5 · BDNS-110 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review cutover. Depends on: BDNS-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 70% · Site reliability 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The handoff omits when TTL was lowered and when old endpoints can be removed. Acceptance criteria - Record old/new values and effective times. - List modeled cache and compatibility assumptions. - Define endpoint retirement criteria. Implementation constraints - Use UTC timestamps and synthetic record identities. Verification - Follow the staged change from the record. - Keep retirement blocked when a required client assumption is unknown. Deliverables - DNS cutover runbook. Rollout and recovery: Preserve the change record after rollback or completion. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.