Network and Address Reference

Purpose

This page documents the addressing, DNS, routing, and network-access model used by the Bytek homelab.

Use this page when:

Home Network

Service Address Inventory

Public Hostname Inventory

The public application records are managed through the WHC cPanel Zone Editor.

The public DNS destination is the VPS, not the private application address.

Private Hostname Inventory

All HTTPS application hostnames point internally to Traefik.

Proxmox is the exception because Proxmox does not sit behind Traefik.

Public DNS Flow

When an external client opens a hosted application:

Public DNS must never point directly to a private address such as 192.168.2.121.

Private RFC1918 addresses are not reachable from the public internet.

Internal Split-DNS Flow

When a client on the home LAN opens a hosted application:

This allows internal clients to use the same application hostnames and HTTPS certificates as external clients.

Benefits include:

Public and Private DNS Comparison

Proxmox DNS Design

The Proxmox host intentionally uses Quad9:

Proxmox does not use Pi-hole as its general resolver.

This design prevents the hypervisor from depending on a guest VM or LXC for DNS.

As a result, the Proxmox host normally resolves:

The Proxmox OIDC server-to-server path can therefore travel through:

If this public path causes a future OIDC reliability issue, a single entry may be added to the Proxmox /etc/hosts file:

This would route only Authentik directly through local Traefik while keeping general Proxmox DNS on Quad9.

Proxmox Private Hostname

The hostname pve.bytek.ca is intentionally private.

Pi-hole resolves it to:

No public WHC record should exist for pve.bytek.ca.

The Proxmox interface is accessed at:

Open Proxmox VE

Access should be limited to:

TCP port 8006 must not be exposed directly to the public internet.

Application Backend Reference

Traefik connects to each application using a private IP and backend port.

Backend ports should be accessible only from the systems that require them.

For example:

DHCP Reservations

Infrastructure services should use DHCP reservations based on their virtual NIC MAC addresses.

Known reservations include:

Additional infrastructure reservations should be confirmed in Pi-hole before being added to this page.

To locate a VM MAC address on Proxmox, use:

qm config <VMID>

Locate the net0 line and record the MAC address.

For an LXC, use:

pct config <CTID>

Reservations prevent unexpected address changes from breaking:

Firewall Source Reference

Known infrastructure sources include:

Typical firewall requirements include:

Avoid broad any-source rules when a specific infrastructure source can be used.

Browser Secure-DNS Warning

Firefox and Zen can use DNS over HTTPS and bypass Pi-hole.

This can cause private hostnames such as pve.bytek.ca to fail even when Pi-hole is configured correctly.

Recommended browser setting:

If an internal hostname fails only in the browser:

Useful Windows commands:

Expected result:

DNS Validation

Verify an Internal Record

Use:

nslookup portal.bytek.ca 192.168.2.65

Expected result:

Verify a Public Record Through Pi-hole

Use:

nslookup google.com 192.168.2.65

Expected result:

Verify Public WHC DNS

Query an authoritative WHC server and confirm that application hostnames resolve to:

Verify a Backend Port

Examples:

A successful connection confirms TCP reachability but does not prove the application is healthy.

Network Troubleshooting Order

When a hostname is unreachable, troubleshoot in this order:

Do not change DNS, firewalling, and application configuration simultaneously.

Address-Change Procedure

If a service IP changes:

A stale backend IP previously affected several deployment steps, so the old address should be searched across configuration files after every change.

Document Control