To learn quickly and effectively, the perfect combination is:
- solid theoretical resources
- hands-on practice
One of the great things about working in IT is that, thanks to virtualization, there’s really no excuse not to practice. So while finding a good book or video series is a great start, I strongly recommend having an environment where you can put the theory into practice.
I also recommend maintaining public-facing services in your lab. It raises the bar because it forces you to think about availability and security. Just like in production.
My lab is structured into three mains areas:
- Public-facing infrastructure: This includes my authoritative DNS servers and this blog. These services are exposed to the internet and are managed with production-grade standards.
- Networking lab: This is my playground for building networking labs.
- Home infrastructure: This is my internal setup, including a DNS resolver, a NAS, and a pfSense firewall.
Public-facing Infrastructure
These are services running in production, with availability and operational best practices close to real-world standards.
Authoritative DNS
- Zone: jvetter.net
- Primary: BIND 9
- Secondary: Knot DNS 3
- TSIG-protected zone transfers
- DNSSEC Policy: – ECDSA keys with a custom rotation policy. Key Signing Key (KSK) with one-year lifetime and Zone Signing Key (ZSK) renewed every 60 days – NSEC3 (helps prevent DNS enumeration) – Inline-signing (ensures that records are digitally signed as they are served, rather than requiring manual intervention for signing operations) – Explicit transfer and notification configuration
Blog
- Url: https://jvetter.net
- Built with: Hugo + PaperMod theme
- Published via: GitHub + Cloudflare Pages
- Domain Setup:
This is how I handle CNAME flattening by managing my own DNS auth server:
If you go to https://jvetter.net, it is going to a VM I manage, hosted at OVHcloud, which has nginx configured as a reverse proxy, with 80/443 redirect to www.jvetter.net:
sequenceDiagram participant Client as Web Client (Browser) participant DNS as DNS Auth Server (ns1.jvetter.net) participant VM as NGINX Reverse Proxy (VM @OVH) participant CDNName as DNS for jvetter-net.pages.dev (Cloudflare) participant WWW as www.jvetter.net (Cloudflare Pages) %% DNS for apex Client->>DNS: DNS query for jvetter.net DNS-->>Client: A record (VM public IP) %% HTTPS to reverse proxy Client->>VM: HTTPS request to jvetter.net VM->>Client: HTTP 301 redirect to https://www.jvetter.net %% DNS for www Client->>DNS: DNS query for www.jvetter.net DNS-->>Client: CNAME to jvetter-net.pages.dev %% DNS for CDN endpoint Client->>CDNName: DNS query for jvetter-net.pages.dev CDNName-->>Client: A/AAAA record (Cloudflare CDN IP) %% Final HTTPS request Client->>WWW: HTTPS request to www.jvetter.net WWW-->>Client: Serves static site via CDN
If you go to https://www.jvetter.net, it is pointing directly to the Cloudflare Pages CDN:
sequenceDiagram participant Client as Web Client (Browser) participant DNS as DNS Auth Server (ns1.jvetter.net) participant CDNName as DNS for jvetter-net.pages.dev (Cloudflare) participant WWW as www.jvetter.net (Cloudflare Pages) %% DNS for www Client->>DNS: DNS query for www.jvetter.net DNS-->>Client: CNAME to jvetter-net.pages.dev %% DNS for CDN endpoint Client->>CDNName: DNS query for jvetter-net.pages.dev CDNName-->>Client: A/AAAA record (Cloudflare CDN IP) %% Final HTTPS request Client->>WWW: HTTPS request to www.jvetter.net WWW-->>Client: Serves static site via CDN
TLS/HTTPS
- Managed with Let’s Encrypt, using wildcard certificates
- Renewal automated via RFC2136 DNS updates and
certbot
(see article: Let’s Encrypt Certificate Renewal with RFC2136) - Supports HSTS, CSP, and hardened headers, security.txt (RFC9116)
Networking Lab
As a network architect, having a lab setup is essential for building POCs and experimenting quickly. Everything runs on a dedicated server I manage, where I’ve got the tools I need to spin up virtual network topologies:
- GNS3server for vendor-mix labs
- Containerlab to define full topologies in a single file
- Docker
It’s all virtualized, which means not reliable for Data Plane. But for Control Plane validation, it’s perfect. I can test protocols, routing logic, overlays like VXLAN EVPN, and CI/CD workflows with total flexibility.
Infrastructure
- Dedicated server hosted at OVHCloud (Intel Xeon E3-1245v2 - 32GB DDR3 1333MHz - 2x 480GB SSD Soft RAID)
- Containerlab setups with:
- Arista cEOS
- Juniper vJunos
- Linux container (wbitt/network-multitool)
🌐 Example project with containerlab: VXLAN EVPN lab - a hands-on demo of how to use Containerlab to deploy a full fabric with Arista cEOS. It simulates a Data Center Interconnect (DCI) running OSPF as the underlay and VXLAN with head-end replication (HER) as the overlay.
Home Infrastructure
At home, I self-host a few core services to stay hands-on and in control of my environment. This setup includes my own DNS resolver, a firewall for network segmentation, and a NAS for storage and backups.
DNS Resolver
- Software:
knot-resolver
- Features:
- DNSSEC validation
- Cache prefilling (RFC 8806 – root zone local copy)
- RPZ filtering via systemd automation using adblock lists and
Firewall
- Model: Protectli Vault FW4B
- OS: pfSense
- Purpose: Acts as the perimeter firewall and routing engine for the home network
NAS
- Model: Synology DiskStation DS718+ (2* 2TB)
- Storage: Encrypted volumes using eCryptFS
- Purpose: Centralized backup, file storage, and lab ISO/media repository
Lab Inventory
Hostname | Type | Provider | Services | Cost (€) |
---|---|---|---|---|
dd1 | Dedicated Server | OVHCloud | GNS3, Containerlab, GitLab CI | ~26/month |
ns1 | VPS | OVHCloud | Primary auth DNS | ~8/month |
ns2 | VPS | MikroVPS | Secondary auth DNS | ~5/month |
rpi4 | Raspberry Pi | Self-hosted | DNS Resolver | ~70 (upfront) |
fw1 | Protectli Vault FW4B | Self-hosted | pfSense firewall | ~350 (upfront) |
jvetter.net | Domain + mail (5GB) | OVHCloud | jvetter.net |
~13/year |
💡 Total monthly cost: ~€40/month
Next Steps
- Set up a virtual BGP router (e.g., CloudRouter), operate my own ASN, and RPKI
- SVCB/HTTPS DNS records: A standardized way to enable CDN support directly at the apex of a domain, without relying on A-record proxies or CNAME flattening.
📘 RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)