Reference Registry — Networking Purpose This note is the networking-specific seed for the broader cybersecurity reference registry. Use it to: - standardize references for networking notes - keep source quality consistent - help Codex assign references without inventing weak source sets - make future networking notes easier to expand Source of truth rule For networking notes, this registry is the primary source of truth. Use it together with: - <a href="networking/index.html">Networking Index</a> for study order and branch structure - <a href="reference-registry.html">Cybersecurity Reference Registry</a> for broader cross-branch fallback only when this note does not yet cover a networking topic When assigning references: - choose the smallest set of strongest references for the exact note - do not invent random networking reference sets ad hoc - if a note is missing here, infer from the closest networking parent topic first and add a registry entry proposal - keep networking references tied to security implications, not academic abstraction Reference selection policy Source priority official documentation official labs and practical training standards and testing guides high-signal research secondary sources only when they add clear value Per-note target minimum 2 references ideal 3 references avoid bloating notes with long lists Labeling Use: - Foundational - Testing / Lab - Research / Deep Dive - Official Tool Docs Networking topic map tcp-ip-basics Preferred references: - Foundational: RFC 9293 (Transmission Control Protocol) — https://datatracker.ietf.org/doc/html/rfc9293 - Foundational: RFC 791 (Internet Protocol) — https://datatracker.ietf.org/doc/html/rfc791 - Official Tool Docs: Nmap Network Scanning — https://nmap.org/book/toc.html - Official Tool Docs: Wireshark User’s Guide — https://www.wireshark.org/docs/wsug_html_chunked/ Why: - TCP/IP notes should stay grounded in real network behavior, not abstract theory - Nmap and Wireshark are the most practical anchors for how communication and reachability are observed ports-and-services Preferred references: - Official Tool Docs: Nmap Reference Guide — https://nmap.org/book/man.html - Official Tool Docs: Nmap Network Scanning — https://nmap.org/book/toc.html - Foundational: OWASP WSTG — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/ Why: - this topic is operational and tied directly to attack surface - Nmap is the core practical reference dns-resolution Preferred references: - Foundational: Cloudflare Learning Center on DNS records — https://www.cloudflare.com/learning/dns/dns-records/ - Foundational: ICANN DNS Concepts — https://www.icann.org/resources/pages/dns-2012-02-25-en - Testing / Lab: OWASP WSTG Information Gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/ - Research / Deep Dive: ProjectDiscovery guide to DNS takeovers — https://projectdiscovery.io/blog/guide-to-dns-takeovers Why: - this note should explain how names resolve in practice and why that matters for ownership, exposure, and asset discovery dns-security Preferred references: - Foundational: OWASP WSTG Information Gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/ - Foundational: ICANN DNSSEC — https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en - Mitigation: CISA Domain Name System Security Best Practices — https://www.cisa.gov/resources-tools/resources/domain-name-system-dns-security-best-practices - Research / Deep Dive: ProjectDiscovery guide to DNS takeovers — https://projectdiscovery.io/blog/guide-to-dns-takeovers - Research / Deep Dive: HackerOne guide to subdomain takeovers — https://www.hackerone.com/blog/guide-subdomain-takeovers-20 Why: - DNS matters most here as attack surface, ownership drift, and domain-control hygiene, not just protocol theory dangling-dns-records Preferred references: - Foundational: Cloudflare Learning Center on DNS records — https://www.cloudflare.com/learning/dns/dns-records/ - Testing / Lab: OWASP WSTG Information Gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/ - Research / Deep Dive: ProjectDiscovery guide to DNS takeovers — https://projectdiscovery.io/blog/guide-to-dns-takeovers - Research / Deep Dive: HackerOne guide to subdomain takeovers — https://www.hackerone.com/blog/guide-subdomain-takeovers-20 Why: - this note owns the DNS lifecycle and stale-record mechanism that can later become a subdomain-takeover finding in attack-surface mapping http-overview Preferred references: - Foundational: MDN HTTP overview — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview - Foundational: RFC 9110 (HTTP Semantics) — https://datatracker.ietf.org/doc/html/rfc9110 - Foundational: MDN HTTP request methods — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods - Testing / Lab: PortSwigger Web Security Academy — https://portswigger.net/web-security Why: - MDN provides the practical browser/server behavior anchor; RFC 9110 anchors the formal semantics; PortSwigger is the canonical hands-on lab path for HTTP-rooted vulnerabilities http-messages Preferred references: - Foundational: MDN HTTP messages — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages - Foundational: RFC 9112 (HTTP/1.1 Message Syntax) — https://datatracker.ietf.org/doc/html/rfc9112 - Testing / Lab: PortSwigger request smuggling academy — https://portswigger.net/web-security/request-smuggling - Research / Deep Dive: James Kettle, "HTTP Desync Attacks: Request Smuggling Reborn" — https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn Why: - HTTP messages are best understood through both protocol shape and security consequences. RFC 9112 anchors the formal HTTP/1.1 wire syntax; the Kettle paper is the strongest research anchor on what happens when two parsers disagree on it http-headers Preferred references: - Foundational: MDN HTTP headers — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers - Foundational: RFC 9110 (HTTP Semantics) — https://datatracker.ietf.org/doc/html/rfc9110 - Mitigation: OWASP HTTP Headers Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html - Testing / Lab: PortSwigger Web Security Academy — https://portswigger.net/web-security Why: - header behavior sits at the intersection of protocol semantics, browser behavior, caching, proxy trust, and multiple exploit classes cookies-and-sessions Preferred references: - Foundational: MDN Set-Cookie header — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie - Foundational: OWASP Session Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html - Testing / Lab: OWASP WSTG Session Management Testing — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/ - Testing / Lab: PortSwigger CSRF topic — https://portswigger.net/web-security/csrf Why: - this note needs browser semantics plus security testing/mitigation framing tls-https Preferred references: - Foundational: MDN HTTPS — https://developer.mozilla.org/en-US/docs/Glossary/HTTPS - Foundational: RFC 8446 (TLS 1.3) — https://datatracker.ietf.org/doc/html/rfc8446 - Foundational: Mozilla SSL Configuration Generator — https://ssl-config.mozilla.org/ - Official Tool Docs: OpenSSL s_client — https://docs.openssl.org/master/man1/openssl-s_client/ - Testing / Lab: testssl.sh — https://github.com/drwetter/testssl.sh Why: - this note stays practical (transport trust, TLS termination, HSTS, certificate inspection). RFC 8446 anchors the modern TLS spec, Mozilla SSL Configuration Generator is the canonical posture-policy reference, openssl s_client is the standard inspection tool, and testssl.sh is the standard scanner. MDN remains the practical entry point reverse-proxies Preferred references: - Foundational: MDN HTTP messages — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages - Foundational: RFC 7239 (Forwarded HTTP Extension) — https://datatracker.ietf.org/doc/html/rfc7239 - Testing / Lab: PortSwigger request smuggling academy — https://portswigger.net/web-security/request-smuggling - Research / Deep Dive: James Kettle, "HTTP Desync Attacks: Request Smuggling Reborn" — https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn Why: - reverse proxies are a trust-boundary note. RFC 7239 and MDN anchor the forwarding-header semantics, the PortSwigger academy is the canonical smuggling lab, and the Kettle paper is the strongest single research anchor for the parser-disagreement class client-ip-trust Preferred references: - Foundational: MDN X-Forwarded-For — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For - Foundational: RFC 7239 (Forwarded HTTP Extension) — https://datatracker.ietf.org/doc/html/rfc7239 - Testing / Lab: PortSwigger Web Security Academy — https://portswigger.net/web-security - Research / Deep Dive: James Kettle, "Practical Web Cache Poisoning" — https://portswigger.net/research/practical-web-cache-poisoning Why: - this note is about how trust headers affect logging, rate limiting, allowlists, and access controls. RFC 7239 anchors the structured-Forwarded spec; the Kettle paper is the canonical writeup on why unkeyed forwarding headers like XFF and X-Forwarded-Host are dangerous header-trust-in-node-express Preferred references: - Official Tool Docs: Express behind proxies — https://expressjs.com/en/guide/behind-proxies.html - Foundational: MDN X-Forwarded-For — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For - Foundational: RFC 7239 (Forwarded HTTP Extension) — https://datatracker.ietf.org/doc/html/rfc7239 Why: - this note is the framework-specific bridge from client-ip-trust into Express. Express documentation owns trust proxy; MDN and RFC 7239 anchor the forwarding-header semantics load-balancers Preferred references: - Foundational: MDN HTTPS — https://developer.mozilla.org/en-US/docs/Glossary/HTTPS - Foundational: MDN HTTP headers — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers - Testing / Lab: PortSwigger Web Security Academy — https://portswigger.net/web-security - Research / Deep Dive: James Kettle, "Practical Web Cache Poisoning" — https://portswigger.net/research/practical-web-cache-poisoning Why: - load balancers are entry-point and trust-boundary notes, not just infra notes firewalls-and-network-boundaries Preferred references: - Testing / Lab: OWASP WSTG Information Gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/ - Official Tool Docs: Nmap Network Scanning — https://nmap.org/book/toc.html - Official Tool Docs: Nmap Reference Guide — https://nmap.org/book/man.html - Mitigation: OWASP SSRF Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html Why: - this note should connect exposure assumptions to evidence-based discovery nat-and-private-networks Preferred references: - Foundational: RFC 1918 (Private Address Allocation) — https://datatracker.ietf.org/doc/html/rfc1918 - Foundational: RFC 6598 (CGNAT shared address space) — https://datatracker.ietf.org/doc/html/rfc6598 - Testing / Lab: PortSwigger SSRF topic — https://portswigger.net/web-security/ssrf - Foundational: OWASP SSRF Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html - Official Tool Docs: Nmap Network Scanning — https://nmap.org/book/toc.html Why: - the value of this note is in linking private reachability to SSRF and internal trust boundaries. RFC 1918 + 6598 anchor the formal address-space definitions; the OWASP cheat sheet anchors the SSRF defenses that close the link-local / private-range gates; PortSwigger and Nmap are the practical lab anchors metadata-endpoints Preferred references: - Foundational: AWS Instance Metadata Service docs — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html - Foundational: GCP metadata server docs — https://cloud.google.com/compute/docs/metadata/overview - Foundational: Azure Instance Metadata Service docs — https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service - Foundational: OWASP SSRF Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html - Testing / Lab: PortSwigger SSRF topic — https://portswigger.net/web-security/ssrf Why: - this note tightly connects internal reachability, SSRF, and cloud-credential exposure risk. The three cloud-vendor docs are the only authoritative sources for protocol shape per platform (AWS IMDSv1/v2, GCP Metadata-Flavor, Azure header-required). OWASP and PortSwigger are the canonical defense and lab anchors nmap-scanning Preferred references: - Official Tool Docs: Nmap Reference Guide — https://nmap.org/book/man.html - Official Tool Docs: Nmap Network Scanning — https://nmap.org/book/toc.html - Testing / Lab: OWASP WSTG Information Gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/ Why: - Nmap should be taught from the official manual first service-enumeration Preferred references: - Official Tool Docs: Nmap Reference Guide — https://nmap.org/book/man.html - Official Tool Docs: Nmap Network Scanning — https://nmap.org/book/toc.html - Testing / Lab: OWASP WSTG Information Gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/ Why: - this note is where discovery becomes actionable understanding of exposed services and protocols wireshark-workflows Preferred references: - Official Tool Docs: Wireshark User’s Guide — https://www.wireshark.org/docs/wsug_html_chunked/ - Official Tool Docs: Wireshark docs portal — https://www.wireshark.org/docs/ - Official Tool Docs: Wireshark display filters — https://www.wireshark.org/docs/man-pages/wireshark-filter.html Why: - this topic is tool-native and should remain grounded in the official docs packet-analysis Preferred references: - Official Tool Docs: Wireshark User’s Guide — https://www.wireshark.org/docs/wsug_html_chunked/ - Official Tool Docs: Wireshark display filter reference — https://www.wireshark.org/docs/dfref/ - Official Tool Docs: tcpdump man page — https://www.tcpdump.org/manpages/tcpdump.1.html - Foundational: MDN HTTP messages — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages Why: - packet analysis needs both capture tooling and message interpretation caching-and-security Preferred references: - Foundational: MDN HTTP caching — https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching - Foundational: MDN Cache-Control — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control - Testing / Lab: PortSwigger Web Cache Poisoning — https://portswigger.net/web-security/web-cache-poisoning - Research / Deep Dive: James Kettle, "Practical Web Cache Poisoning" — https://portswigger.net/research/practical-web-cache-poisoning Why: - caching issues are subtle and often arise from protocol semantics interacting with shared infrastructure Registry usage rules choose the smallest set of strongest references for each exact note do not assign generic links blindly prefer official documentation and strong labs if a future networking note is missing from this registry, map it to the closest parent topic first when adding cloud-specific networking notes later, add provider docs only if the note becomes implementation-specific Suggested next networking registry entries Add these when the branch expands: - dns-record-types - http-status-codes - http-methods - caching-keys-and-vary - content-negotiation - health-check-endpoints - network-segmentation - egress-control