Network Glossary

Anycast solves an old problem: how do you deliver the same service globally, but always route the request to the nearest server? Solution: multiple servers in different datacentres announce the same IP via BGP. The routing protocol automatically delivers each client to the topologically nearest one. Famous Anycast IPs: 1.1.1.1 (Cloudflare DNS, in 200+ cities), 8.8.8.8 (Google DNS), 9.9.9.9 (Quad9). Major CDNs (Cloudflare, Fastly) and root DNS servers all rely on Anycast. Latency and resilience both benefit — if one location fails, the next takes over automatically.

An Autonomous System Number identifies a group of IP networks operated under a unified routing policy. Every ISP, large hosting provider and many enterprises have at least one ASN — e.g. AS15169 for Google, AS3320 for Deutsche Telekom. Via BGP (Border Gateway Protocol), ASNs exchange reachability information. When you do a Whois lookup on an IP address, the ASN is the most important pointer to which network the address belongs to.

BGP is the routing protocol that holds the internet together. Each ASN announces its IP prefixes to neighbouring ASNs ("peering") via BGP, and the information spreads globally. Weak spot: the protocol relies on mutual trust — a misconfigured or malicious route announcement (hijack) can divert global traffic, like the 2008 YouTube–Pakistan incident. Mitigation: RPKI cryptographically validates route-origin authorisations. Invisible to end users, but the most important routing mechanism for network admins.

A CAA record is a DNS entry that explicitly lists which CAs (Let's Encrypt, Sectigo, DigiCert & co.) may issue certificates for your domain. Example: example.com. CAA 0 issue "letsencrypt.org". If another CA tries to issue, it refuses (mandated since 2017 by RFC 8659). Protection against mis-issuance — if an employee of a CA is compromised, they still cannot issue certificates for CAA-protected domains. Recommendation: set a CAA record for every production domain.

CIDR replaced the rigid Class A/B/C scheme in 1993 and allows arbitrary network sizes. The notation IP/prefix indicates how many bits belong to the network part: /24 = 256 addresses (254 usable), /16 = 65,536. Rule of thumb: every bit less in the prefix doubles the network size. CIDR is used by admins daily: firewall rules, VPN configs, routing tables, AWS Security Groups — CIDR is everywhere.

A CSR is a Base64-encoded request containing your public key and domain metadata (Common Name, organisation, country). You generate it with openssl req -new -key privkey.pem -out cert.csr, send it to the CA and receive a signed certificate back. Important: the private key never leaves your server. With ACME clients (Certbot & co.) the step is automated — manual CSRs are only needed today for Extended Validation certificates or smart-card/HSM setups.

When sending, the mail server signs the email with a private key; the matching public key sits as a DNS TXT record (selector._domainkey.example.com). The receiving server verifies the signature: did the mail really come from the claimed sender, and was it altered in transit? Together with SPF and DMARC, DKIM forms the three pillars of modern email authentication. Without DKIM, mail to Gmail and Outlook increasingly ends up in spam.

DMARC combines SPF and DKIM with an instruction to the receiving server: p=none (do nothing, just report), p=quarantine (move to spam) or p=reject (refuse entirely). DMARC also delivers daily aggregate reports to an address chosen by the domain owner — so you find out which servers send mail in your name (legitimate or not). Without DMARC, your domain is vulnerable to spoofing.

Before accepting a connection, mail servers query a DNSBL by appending the reversed sender IP to a blacklist hostname: 1.2.3.4 → 4.3.2.1.zen.spamhaus.org. If an A record exists, the IP is listed. Known lists: Spamhaus SBL/XBL/PBL, Barracuda BRBL, SORBS, SpamCop. Anyone running a mail server should regularly check their IP against DNSBLs — a listing blocks delivery worldwide.

DNSSEC fixes an old weakness in DNS: the protocol blindly trusts any resolver cache. An attacker with access to the path between client and resolver can manipulate responses ("cache poisoning"). DNSSEC signs DNS records with public-key crypto — the resolver verifies the signature along a "chain of trust" up to the root zone. Today: all TLDs are DNSSEC-signed, but domain-level adoption is still low (DE: ~5 %, NL: ~60 %). Prerequisite for modern features like DANE and SVCB.

GeoDNS returns different answers depending on the source IP of the DNS resolver. A German query to www.example.com might get 203.0.113.1 (Frankfurt server), a US query gets 198.51.100.1 (Virginia server). Known providers: Cloudflare, AWS Route 53, Akamai. Benefits: low latency (server location matches user location), regulatory compliance (EU traffic stays in the EU). Downside: the same domain has different IPs depending on the observer — when debugging, always ask authoritative servers via dig +trace.

With Strict-Transport-Security: max-age=31536000; includeSubDomains, a website tells the browser: for the next 365 days, never HTTP, always HTTPS. Prevents man-in-the-middle attacks where an attacker intercepts the initial HTTP request and redirects to a forged page (SSL stripping). Domains can additionally enrol on the HSTS preload list — then the browser serves them HTTPS-only *even before* the first request.

IDNA allows domains like münchen.de or café.fr. Since DNS only handles ASCII technically, the Unicode characters are encoded to ASCII strings via Punycode (xn--mnchen-3ya.de). Browsers display the pretty form, DNS works with the encoded form. Security-relevant: homoglyph attacks — Cyrillic а looks like Latin a but is a different character. Phishers register аpple.com (Cyrillic a) and run lookalike sites. Browser defence: when the mix is ambiguous, the Punycode form is shown — if you suddenly see xn-- in the address bar, be cautious.

IPv4 with ~4.3 billion addresses was standardised in 1981 and has been exhausted for years. The successor: IPv6 with 2^128 addresses (an unimaginably large number). IPv6 addresses look like 2001:db8::1 instead of 192.168.1.1. Today most ISPs run dual-stack — devices speak both in parallel. Trouble usually appears when tunnelling (VPN often routes only IPv4, IPv6 leaks around the tunnel). The IPv6 test reveals in 5 seconds whether your connection supports IPv6.

The MTU decides how big a single IP packet may be. Ethernet standard: 1500 bytes. IPv6 minimum MTU: 1280 bytes. If a packet hits a smaller MTU on its path, it must be fragmented — or, with IPv6, it gets dropped (path-MTU discovery via ICMP). Common issues: VPN tunnels have an effective MTU of 1380–1460 bytes, causing hangs with large packets. Symptom: web pages load partially, then stop. Workaround: manually set the MTU of the local VPN interface to 1400.

When someone emails user@example.com, their server asks: "Who handles example.com?" The answer is the MX record: a prioritised hostname (e.g. 10 mx1.example.com, 20 mx2.example.com). Lower priority = preferred. Without an MX record, the domain cannot receive mail. When mail breaks, the MX record is almost always the first thing to check — wrong priority, stale hostname or an expired provider are common causes.

Your home router has one public IP — all devices on the LAN share it via NAT. The router maintains a table of which internal connection maps to which outgoing port. Without NAT, IPv4 would have collapsed long ago. The downside: NAT breaks end-to-end connectivity, which is why VoIP, gaming and P2P require STUN/TURN workarounds. IPv6 deliberately drops NAT — every device gets its own globally unique address again.

NXDOMAIN is the return code from a DNS resolver when the queried domain exists in no zone file. Use cases: URL typos, expired domains, internal hostnames outside the company. Issue: some ISPs in the 2010s practised NXDOMAIN hijacking — instead of returning the error, they served their own ad page. In Germany, Deutsche Telekom stopped doing this in 2009 after complaints. You can detect hijacking by testing a guaranteed-nonexistent subdomain (randomstring1234.example.com) and checking whether the browser displays a third-party page.

OCSP solves a problem: after a certificate is issued, it can be revoked (compromised key, stolen domain). The browser queries the CA via OCSP: "Is this certificate still valid?" Weak spot: OCSP adds an extra round trip and leaks the visited URL to the CA. Solution: OCSP stapling — the web server regularly fetches the OCSP response itself and delivers it together with the certificate. Today the standard. Visible in the SSL check as the field "OCSP status".

A TCP/UDP connection is uniquely identified by: source IP + source port + destination IP + destination port + protocol. Ports range from 0–65535. Well-known: 22 (SSH), 80 (HTTP), 443 (HTTPS), 25 (SMTP), 53 (DNS). Open ports are potential attack surfaces — so only ports actually in use should be reachable from outside. Use the port scanner to check what your IP exposes externally.

While an A record resolves example.com → 93.184.216.34, a PTR record provides the way back: 93.184.216.34 → example.com. Reverse DNS is used primarily by mail servers — without a PTR, many mail servers reject the connection. Geo-IP databases also use Reverse DNS as a hint (e.g. when the hostname is customer-12-34.kabel-deutschland.de). PTR records are maintained by the IP-block owner — i.e. the ISP, not the domain owner.

Punycode converts Unicode domain components into a pure ASCII form that DNS can process. münchen.de becomes xn--mnchen-3ya.de. The xn-- prefix marks a Punycode-encoded component. Browsers automatically display the pretty form; in DNS and URL logs, the encoded form appears. Security risk: phishers register xn--applе-43d.com (Punycode for Cyrillic "e") and run lookalike sites. Modern browsers display the Punycode form when the mix is suspicious — if you suddenly see xn-- in the address bar, be cautious.

RPKI adds a trust layer to BGP. Each IP-block owner publishes a ROA (Route Origin Authorization): "These prefixes may only be announced by ASN X." Receiving routers verify the ROA before accepting a BGP route. Today (2026) roughly 50 % of all global routes are RPKI-validated — major Tier-1 providers (Cogent, NTT, Telia) now actively drop invalid routes. End users notice nothing — but BGP hijack attempts are blocked at scale.

SNI solves a chicken-and-egg problem: with HTTPS, the server must send the correct certificate *before* reading the HTTP request — how does it know which domain is meant? Solution: the client sends the hostname in the TLS ClientHello. Server software like nginx or Apache picks the matching certificate based on SNI. Result: a server with a single IP can host hundreds of HTTPS domains. Virtually every modern browser has supported SNI since 2008 — only very old clients (Windows XP, Android 2.x) had issues. Weak spot: SNI is sent in cleartext, which is why the successor ECH (Encrypted ClientHello) has been rolling out since 2023.

Every DNS zone has exactly one SOA record that defines it. Fields: primary nameserver, admin email (with . instead of @), serial number, refresh interval, retry, expire and minimum TTL. The serial number is decisive for synchronisation between primary and secondary nameservers — on every change it is incremented (convention: YYYYMMDDnn), secondaries detect the new version and refetch the zone. When DNS changes "don't propagate", it's often because the serial wasn't updated — secondaries then think the zone is still current.

An SPF record is a TXT record like v=spf1 mx include:_spf.google.com ~all. Receiving mail servers check: is this mail coming from an IP listed in SPF? If not, the mail can be marked as forged. SPF defends against sender spoofing. The simplest sensible config: v=spf1 mx ~all — allows all servers listed in the MX records, marks everything else as softfail.

An SRV record answers not "where is the domain" but "where is a specific service of the domain". Format: _service._proto.name TTL SRV priority weight port target. Example: _xmpp-server._tcp.example.com SRV 0 5 5269 xmpp.example.com. Use cases: Jabber/XMPP, Microsoft AD, SIP, Minecraft servers, Matrix. Advantage: service endpoint (host + port) can be moved via DNS without reconfiguring clients. Visible in DNS lookups but not in browser URLs — browsers don't use SRV for HTTP.

TLS is the successor to SSL — the terms are used interchangeably in casual conversation, but technically SSL has been insecure and dead since 2014. Currently relevant: TLS 1.2 (standard) and TLS 1.3 (recommended). TLS provides three guarantees: encryption (eavesdroppers see nothing), integrity (no tampering in transit) and authentication (you are talking to the domain whose certificate is shown). The SSL check inspects validity, issuer and encryption strength of any website.

TTL in the DNS context sits in every record and tells resolvers: cache this answer for exactly N seconds. Low TTL (300 = 5 min) = changes propagate quickly, but more DNS load. High TTL (86400 = 24 h) = stable, but changes take long. Pros lower the TTL of their records before a migration to 60–300 seconds, make the switch, then raise it again. In the IP context, TTL also refers to the field in the IP header that prevents packets from looping forever (decrement per hop).

A VPN routes all your internet traffic through an encrypted tunnel to a server in a country of your choice. Benefits: your real IP is hidden, your ISP can no longer see content, geo-blocks can be bypassed. Risks: a bad VPN provider sees everything the ISP saw before — so the logging promise matters more than the marketing. Use the DNS leak test to confirm your VPN really tunnels every query — or whether DNS leaks past the tunnel.