SOP-2 Internal Traffic Routing & Split-Horizon DNS

Objective: Provide seamless, encrypted access to all internal and external web services using a centralized security gateway and optimized local name resolution.

1. The DNS Engine (Split-Horizon Logic)

Rather than relying on external resolvers for local traffic, the Pi-Hole (via dnsmasq) is configured to intercept and redirect traffic at the network edge.

• DDNS Interception: Public hostnames (e.g., radarr.mysha.hopto.org) are mapped to the internal Proxy IP. This provides LAN-speed transfers and eliminates "hair-pinning" through the ISP router.

• Address Mapping:
  address=/radarr.mysha.hopto.org/x.x.x.4
address=/sonarr.mysha.hopto.org/x.x.x.4
address=/lidarr.mysha.hopto.org/x.x.x.4
address=/prowlarr.mysha.hopto.org/x.x.x.4
address=/houzu.mysha.hopto.org/x.x.x.4
address=/nvrweb.mysha.hopto.org/x.x.x.4

2. The Gateway (NGINX Proxy Implementation)

A virtualized NGINX instance on the primary server rig acts as the mandatory TLS termination point for all web traffic.

• Centralized Encryption: By pointing all DNS records to x.x.x.4, every internal connection is upgraded to TLSv1.2/v1.3 before reaching the application.

• Service Proxying: NGINX handles the final "hop" to the specific hardware ports, such as the Pi 5 RAID array on x.x.x.10 or the NVR on x.x.x.200.

• Global Hardening: Implementation of HSTS (Strict-Transport-Security) and custom cipher suites to ensure an A+ security posture.

3. IP Address Management (IPAM)

To maintain the integrity of this routing stack, a Static-Dynamic hybrid approach is used. Below is a logical graph of the network and how packets flow.

• DHCP Reservations: Critical infrastructure—including the Pi 4 (DNS), the Pi 5 (RAID), and the NVR—receive reserved IPs via their MAC addresses.

• DNSSEC Validation: All external queries forwarded to Quad9/Cloudflare are cryptographically validated to prevent DNS poisoning at the perimeter.

Engineering Post-Mortem: Why this Architecture?

"I chose a Split-Horizon DNS strategy with a centralized Reverse Proxy to decouple my services from their physical hardware. This allows me to migrate a service (like moving the -Arr stack to a new Pi) by simply updating one NGINX config file and one DHCP reservation, without the end-user ever seeing a change in URL or a security warning.".

graph TD
    subgraph Internal_LAN [Home Network]
        User((User Device))
        Pi4[Pi 4: DNSMASQ .8]
        Proxy[NGINX Gateway .4]
        Services[Internal Services: .2, .10, .200]
    end

    User -->|DNS Query| Pi4
    Pi4 -.->|Resolve to .4| User
    User -->|HTTPS Request| Proxy
    Proxy -->|Local Proxy Pass| Services