Laurent Brand home
← Portfolio homelab
Browse homelab topics

Homelab / Technical documentation

Locate the failing boundary before changing DNS.

A successful Sonarr lookup, a validated but unproven daemon setting, and the difference between a tunnel connection and a working route.

Jump to a section

23 October: Sonarr resolution recovered

Recovered report with a successful lookup. Several containers had different network and DNS behavior. Sonarr received explicit public resolvers in its Compose configuration, was recreated and resolved the previously failing name. That result belongs to Sonarr’s test, not every integration or container.

Historical configuration values · S10 · edited Compose fragment
services:
  sonarr:
    dns:
      - 1.1.1.1
      - 9.9.9.9

This documents the incident’s change. It is not a recommendation to bypass Pi-hole or impose those resolvers on the current lab.

Evidence: S10.

Validation is not activation

Historical file content · S10 · /etc/docker/daemon.json
{"dns": ["1.1.1.1", "9.9.9.9"]}

The November record reports dockerd --validate returning configuration OK. That proves syntax acceptance for the file tested. It does not prove a daemon restart, container adoption or the final state of Radarr and NZBGet.

Reference: Docker daemon configuration and DNS options.

Evidence: S10.

A layered, read-only DNS investigation

Illustrative · read-only · substitute an authorized non-sensitive test name
getent ahosts <TEST_HOST>
docker exec <CONTAINER> getent ahosts <TEST_HOST>
docker inspect <CONTAINER> --format '{{json .HostConfig.Dns}}'
docker inspect <CONTAINER> --format '{{range $name, $network := .NetworkSettings.Networks}}{{println $name}}{{end}}'
  1. Test the same name on the host and inside the affected container, if its image provides getent. A missing diagnostic tool is not a DNS failure.
  2. Compare per-container overrides and network membership before blaming the host resolver. Avoid printing full container configuration.
  3. Inspect the intended daemon file locally and validate it separately. Record whether the service actually adopted it; do not restart Docker simply to gather documentation.
  4. Repeat the application’s failing request after an approved fix. DNS resolution alone does not validate authentication or the complete integration.

Remote-access results have different scopes

Tailscale is a separate HP LXC in the owner-confirmed layout. Historical Cloudflare work includes four registered QUIC connections and a successful ingress validation, alongside missing-credential/configuration errors and unresolved external 502 responses. Local Home Assistant HTML on port 8123 did not prove its external route worked.

The useful diagnostic sequence is local application response → configured origin reachability → tunnel ingress match → external route → access policy. Tunnel registration alone confirms only one boundary. No current tunnel identifier, endpoint or access policy is published or claimed freshly verified.

Evidence: S16 · S19.

The historical IoT Wi-Fi solution is documented separately under Linux access point.