2026-07-05 — Sepia Dns Blocky Migration
Summary
Completed the Blocky DNS migration cutover on Sepia, validated DNS behavior, and updated the main compose include list.
Context
This work follows the active DNS migration plan. The old dns-ad-blocker image was archived and critically outdated, so the goal was to replace it with Blocky while preserving LAN DNS behavior.
Changes
Change 1: Added Blocky config
- Files:
/opt/blocky/config.yml- What: Created a Blocky configuration with upstream resolvers, the existing ad-blocking lists, whitelist entries, caching, and Prometheus metrics.
Change 2: Added Blocky compose service
- Files:
/opt/compose.blocky.yaml- What: Added a new pinned Blocky service listening on the Sepia LAN address and serving DNS plus HTTP metrics.
Change 3: Cut over from dns-ad-blocker
- Files:
/opt/compose.yaml- What: Replaced the dns-ad-blocker include with Blocky and brought the Blocky service up.
Change 4: Verified DNS behavior
- What: Confirmed normal resolution and blocking behavior:
google.comresolved normallydoubleclick.netreturned0.0.0.0api.segment.ioreturned0.0.0.0under the initial config and should be reviewed as part of allowlist tuning before closing the migration
Decisions
- Used the Blocky default
zeroIpblocking mode to preserve the previous ad-blocking style. - Kept the migration in the compose layer rather than changing host DNS tooling.
- Updated the main compose include to point at Blocky after validating the service could start.
Issues Encountered
- The first Blocky start failed because
dns-ad-blockerstill held port 53. - After stopping
dns-ad-blocker, Blocky started successfully. api.segment.iocurrently resolves as blocked under the first-pass config, which means the allowlist still needs a follow-up review if that domain is required by existing clients.
Next Steps
- Review and tune the Blocky allowlist if
api.segment.ioor other domains must remain reachable. - Continue to the compose best-practices and networking-hardening plans in order.
Generated: 2026-07-05