Add DNS Resolution Check to Test Command

[josecelano]

Overview

Add an optional DNS resolution check to the test command that verifies configured domains resolve to the expected instance IP. This helps users identify DNS configuration issues early while keeping infrastructure tests decoupled from DNS setup.

Specification

See detailed specification: docs/issues/336-add-dns-resolution-check-to-test-command.md

🏗️ Architecture Requirements

DDD Layer: Application (Steps) + Infrastructure (DNS resolution)
Module Path: src/application/steps/ + src/infrastructure/dns/
Pattern: Step + Infrastructure Service

Module Structure Requirements

• Follow DDD layer separation (see docs/codebase-architecture.md)
• DNS resolution logic in infrastructure layer
• DNS check orchestration in application layer (as part of test steps)
• Use appropriate module organization (see docs/contributing/module-organization.md)

Architectural Constraints

• DNS resolution belongs in infrastructure layer (external system interaction)
• Test command steps orchestrate DNS checks (application layer)
• Error handling follows project conventions (see docs/contributing/error-handling.md)
• Output uses UserOutput methods (see docs/contributing/output-handling.md)

Anti-Patterns to Avoid

• ❌ Using println! or direct stdout/stderr access (use UserOutput)
• ❌ Making DNS checks required/strict (should be advisory warnings)
• ❌ Mixing DNS resolution logic in application layer
• ❌ Failing infrastructure tests due to DNS issues

Implementation Plan

Phase 1: Add DNS Resolution Infrastructure (2-3 hours)

• Create src/infrastructure/dns/resolver.rs module
• Implement system DNS resolution using Rust's std::net::ToSocketAddrs or trust-dns-resolver crate
• Add error types for DNS resolution failures
• Add unit tests for DNS resolver

Phase 2: Add DNS Check Step (2-3 hours)

• Add DNS check logic to test command steps in src/application/steps/test/
• Extract domain names from environment configuration (trackers, API, Grafana, etc.)
• Compare resolved IPs with expected instance IP
• Format output using UserOutput (warnings, not errors)
• Handle cases where no domains are configured (skip check)

Phase 3: Integration and Testing (1-2 hours)

• Update E2E tests to verify DNS check behavior
• Test with domains that don't resolve (should show warnings)
• Test with correctly configured domains (should show success)
• Test with no domains configured (should skip check)
• Update documentation to explain DNS check behavior

Acceptance Criteria

Note for Contributors: These criteria define what the PR reviewer will check. Use this as your pre-review checklist before submitting the PR to minimize back-and-forth iterations.

Quality Checks:

• Pre-commit checks pass: ./scripts/pre-commit.sh

Task-Specific Criteria:

• DNS resolution check is added to test command
• DNS check shows warnings (not failures) when domains don't resolve
• DNS check shows success when domains resolve correctly
• DNS check is skipped when no domains are configured
• Output uses UserOutput methods (no println! or direct stdout/stderr)
• Error messages include expected IP for troubleshooting
• E2E tests verify DNS check behavior in all scenarios
• Documentation explains DNS check purpose and behavior

Related

• Parent: N/A (Standalone task)
• Roadmap: Roadmap #1 (Project Roadmap) - Section 10.3
• Specification: docs/issues/336-add-dns-resolution-check-to-test-command.md