Glossar
Netzwerk-Glossar
Klare, kompakte Definitionen der wichtigsten Begriffe aus Netzwerk, DNS, E-Mail-Sicherheit und Verschlüsselung. Jeder Eintrag verlinkt auf passende Tools.
Anycast
Routing-Verfahren, bei dem mehrere Server weltweit dieselbe IP-Adresse haben.
Anycast löst ein altes Problem: wie liefert man global denselben Dienst, aber der Request landet immer beim nächsten Server? Lösung: mehrere Server in verschiedenen Rechenzentren announcen via BGP dieselbe IP. Das Routing-Protokoll führt jeden Client automatisch zum topologisch nächstgelegenen. Bekannte Anycast-IPs: 1.1.1.1 (Cloudflare DNS, in 200+ Städten), 8.8.8.8 (Google DNS), 9.9.9.9 (Quad9). Auch große CDNs (Cloudflare, Fastly) und Root-DNS-Server arbeiten mit Anycast. Latenz und Ausfallsicherheit profitieren — fällt ein Standort aus, übernimmt automatisch der nächste.
ASN — Autonomous System Number
Eindeutige Nummer eines Netzwerks im globalen Internet-Routing.
Eine Autonomous System Number identifiziert einen Verbund von IP-Netzen, die unter einer einheitlichen Routing-Politik betrieben werden. Jeder ISP, große Hosting-Provider und viele Konzerne haben mindestens eine ASN — z. B. AS15169 für Google, AS3320 für die Deutsche Telekom. Über BGP (Border Gateway Protocol) tauschen ASNs Erreichbarkeitsinformationen aus. Bei einer Whois-Abfrage einer IP-Adresse ist die ASN der wichtigste Hinweis darauf, zu welchem Netz die Adresse gehört.
BGP — Border Gateway Protocol
Das Protokoll, mit dem Internet-Provider untereinander Routing-Informationen austauschen.
BGP ist das Routing-Protokoll, das das Internet zusammenhält. Jede ASN announct via BGP ihre IP-Präfixe an benachbarte ASNs („Peering"), die Information verbreitet sich weltweit. Schwachstelle: das Protokoll baut auf gegenseitigem Vertrauen — eine falsch oder bösartig angekündigte Route (Hijack) kann globalen Traffic umleiten, wie 2008 beim YouTube-Pakistan-Vorfall. Schutzmechanismus: RPKI validiert Route-Origin-Authorisierungen kryptografisch. Für Endnutzer unsichtbar, für Netzwerk-Admins der wichtigste Routing-Mechanismus.
CAA — Certification Authority Authorization
DNS-Record, der festlegt, welche Zertifizierungsstellen für die Domain ausstellen dürfen.
Ein CAA-Record ist ein DNS-Eintrag, der explizit aufzählt, welche CAs (Let's Encrypt, Sectigo, DigiCert & Co.) berechtigt sind, Zertifikate für Ihre Domain auszustellen. Beispiel: example.com. CAA 0 issue "letsencrypt.org". Versucht eine andere CA, ein Zertifikat auszustellen, weigert sie sich (per RFC 8659 verpflichtend seit 2017). Schutz gegen Mis-Issuance — wenn ein Mitarbeiter einer CA kompromittiert wird, kann er trotzdem keine Zertifikate für CAA-geschützte Domains ausgeben. Empfehlung: für jede produktive Domain einen CAA-Record setzen.
CIDR — Classless Inter-Domain Routing
Notation für IP-Subnetze mit variabler Präfix-Länge (z. B. 192.168.1.0/24).
CIDR löste 1993 die starre Klassen-Einteilung (Class A/B/C) ab und erlaubt beliebige Netzgrößen. Die Notation IP/Präfix gibt an, wie viele Bits zum Netzanteil gehören: /24 = 256 Adressen (254 nutzbar), /16 = 65.536. Faustregel: jedes Bit weniger im Präfix verdoppelt die Netzgröße. CIDR wird täglich von Admins genutzt: Firewall-Regeln, VPN-Konfigurationen, Routing-Tabellen, AWS Security Groups — überall steht CIDR-Notation.
CSR — Certificate Signing Request
Anfrage-Datei, mit der Sie ein TLS-Zertifikat bei einer CA beantragen.
Ein CSR ist eine Base64-kodierte Anfrage, die Ihren öffentlichen Schlüssel und Domain-Metadaten (Common Name, Organisation, Land) enthält. Sie generieren ihn mit openssl req -new -key privkey.pem -out cert.csr, schicken ihn an die CA und erhalten dafür ein signiertes Zertifikat zurück. Wichtig: der private Schlüssel verlässt Ihren Server nie. Mit ACME-Clients (Certbot & Co.) ist der Schritt automatisiert — manuelle CSRs braucht man heute nur noch für Extended-Validation-Zertifikate oder Smart-Card-/HSM-Setups.
DKIM — DomainKeys Identified Mail
Kryptografische E-Mail-Signatur, mit der Empfänger die Authentizität prüfen können.
Beim Versand signiert der Mailserver die E-Mail mit einem privaten Schlüssel; der zugehörige öffentliche Schlüssel liegt als DNS-TXT-Record (selector._domainkey.example.com). Der empfangende Server prüft die Signatur und stellt fest: stammt die Mail tatsächlich vom claimed Absender, und wurde sie unterwegs verändert? Zusammen mit SPF und DMARC bildet DKIM die Säulen moderner E-Mail-Authentifizierung. Fehlt DKIM, landen Mails bei Gmail/Outlook zunehmend im Spam-Ordner.
DMARC — Domain-based Message Authentication, Reporting & Conformance
Policy, die definiert, was mit SPF/DKIM-fehlerhaften Mails passiert.
DMARC verbindet SPF und DKIM mit einer Anweisung an den empfangenden Server: p=none (nichts tun, nur reporten), p=quarantine (in Spam verschieben) oder p=reject (komplett ablehnen). Zusätzlich liefert DMARC tägliche Aggregat-Reports an eine vom Domain-Owner festgelegte Adresse — so erfahren Sie, welche Server in Ihrem Namen Mails versenden (legitim oder nicht). Ohne DMARC ist Ihre Domain anfällig für Spoofing.
DNSBL — DNS-based Blackhole List
Schwarze Liste von IP-Adressen, abgefragt über das DNS-Protokoll.
Mailserver fragen vor der Annahme einer Verbindung eine DNSBL ab, indem sie die Sender-IP umgedreht an einen Blacklist-Hostnamen anhängen: 1.2.3.4 → 4.3.2.1.zen.spamhaus.org. Existiert ein A-Record, ist die IP gelistet. Bekannte Listen: Spamhaus SBL/XBL/PBL, Barracuda BRBL, SORBS, SpamCop. Wer einen Mailserver betreibt, sollte seine IP regelmäßig gegen DNSBLs prüfen — eine Listung blockiert E-Mail-Zustellung weltweit.
DNSSEC — DNS Security Extensions
Kryptografische Signaturen für DNS-Antworten, die Manipulation verhindern.
DNSSEC löst eine alte Schwäche des DNS: das Protokoll vertraut blind jedem Resolver-Cache. Ein Angreifer mit Zugriff auf den Pfad zwischen Client und Resolver kann Antworten manipulieren („Cache Poisoning"). DNSSEC signiert DNS-Records mit Public-Key-Krypto — der Resolver verifiziert die Signatur entlang einer „Chain of Trust" bis zur Root-Zone. Heute aktiv: alle TLDs sind DNSSEC-signiert, die Adoption auf Domain-Ebene ist allerdings noch gering (DE: ~5 %, NL: ~60 %). Voraussetzung für moderne Features wie DANE und SVCB.
GeoDNS — Standortabhängige DNS-Auflösung
Verschiedene DNS-Antworten je nach Standort des Anfragenden.
GeoDNS liefert je nach Herkunfts-IP des DNS-Resolvers unterschiedliche Antworten. Eine deutsche Anfrage an www.example.com bekommt vielleicht 203.0.113.1 (Frankfurt-Server), eine US-Anfrage 198.51.100.1 (Virginia-Server). Bekannte Anbieter: Cloudflare, AWS Route 53, Akamai. Vorteile: niedrige Latenz (Server-Standort matched mit Nutzer-Standort), regulatorische Compliance (EU-Traffic bleibt in der EU). Nachteil: dieselbe Domain hat aus Sicht verschiedener Beobachter unterschiedliche IPs — beim Debugging unbedingt mit dig +trace autoritative Server fragen.
HSTS — HTTP Strict Transport Security
HTTP-Header, der Browser zwingt, eine Website nur über HTTPS zu laden.
Mit Strict-Transport-Security: max-age=31536000; includeSubDomains teilt eine Website dem Browser mit: für die nächsten 365 Tage niemals HTTP, immer HTTPS. Verhindert Man-in-the-Middle-Angriffe, bei denen ein Angreifer den initialen HTTP-Request abfängt und auf eine gefälschte Seite umleitet (SSL Stripping). Domains können sich zusätzlich auf die HSTS-Preload-List eintragen lassen — dann liefert der Browser sie *vor* dem ersten Request schon HTTPS-only aus.
IDNA — Internationalized Domain Names in Applications
Standard, der Domain-Namen mit Umlauten und Unicode-Zeichen ermöglicht.
IDNA erlaubt Domains wie münchen.de oder café.fr. Da DNS technisch nur ASCII versteht, werden die Unicode-Zeichen via Punycode zu ASCII-Strings kodiert (xn--mnchen-3ya.de). Browser zeigen die schöne Form, DNS arbeitet im Hintergrund mit der Kodierung. Sicherheitsrelevant: Homoglyphen-Angriffe — kyrillisches а sieht aus wie lateinisches a, aber ist ein anderes Zeichen. Phisher registrieren z. B. аpple.com (kyrillisches a). Browser-Schutz: bei nicht eindeutig erkennbaren Mischungen wird die Punycode-Form angezeigt.
IPv4 und IPv6
Die beiden im Internet verwendeten IP-Versionen — 32 Bit (IPv4) bzw. 128 Bit (IPv6).
IPv4 mit ~4,3 Milliarden Adressen ist 1981 standardisiert und seit Jahren erschöpft. Ersatz: IPv6 mit 2^128 Adressen (eine unvorstellbar große Zahl). IPv6-Adressen sehen aus wie 2001:db8::1 statt 192.168.1.1. Heute laufen die meisten Internet-Provider Dual-Stack — Gerät spricht parallel beides. Probleme entstehen typisch beim Tunneln (VPN routet oft nur IPv4, IPv6 leakt am Tunnel vorbei). Der IPv6-Test verrät in 5 Sekunden, ob Ihre Verbindung IPv6 unterstützt.
MTU — Maximum Transmission Unit
Größte Paketgröße in Bytes, die ein Netzwerk-Hop ohne Fragmentierung weiterleitet.
Die MTU entscheidet darüber, wie groß ein einzelnes IP-Paket sein darf. Ethernet-Standard: 1500 Bytes. IPv6-Mindest-MTU: 1280 Bytes. Wenn ein Paket eine kleinere MTU im Pfad trifft, muss es fragmentiert werden — oder bei IPv6 wird es einfach verworfen (Path-MTU-Discovery via ICMP). Häufige Probleme: VPN-Tunnel haben oft 1380-1460 Bytes effektive MTU, was bei großen Paketen zu Hängern führt. Symptom: Webseiten laden teilweise, dann steht es. Workaround: MTU der lokalen VPN-Schnittstelle manuell auf 1400 setzen.
MX-Record — Mail Exchanger
DNS-Eintrag, der angibt, welcher Server E-Mails für eine Domain entgegennimmt.
Wenn jemand user@example.com mailt, fragt sein Server: „Wer ist für example.com zuständig?" Die Antwort liefert der MX-Record: ein priorisierter Hostname (z. B. 10 mx1.example.com, 20 mx2.example.com). Niedrigere Priorität = bevorzugt. Fehlt der MX-Record, ist die Domain nicht E-Mail-fähig. Bei Mail-Problemen ist der MX-Record fast immer der erste Check — falsche Priorität, alter Hostname oder ein abgelaufener Provider sind häufige Ursachen.
NAT — Network Address Translation
Technik, bei der mehrere Geräte hinter einer einzigen öffentlichen IP-Adresse arbeiten.
Der Router zu Hause hat eine öffentliche IP — alle Geräte im LAN teilen sie sich via NAT. Der Router führt eine Tabelle, welche interne Verbindung welchem ausgehenden Port zugeordnet ist. Ohne NAT wäre IPv4 längst nicht mehr funktionsfähig. Schattenseite: NAT bricht Ende-zu-Ende-Konnektivität, weshalb VoIP, Gaming und P2P STUN/TURN-Workarounds brauchen. IPv6 verzichtet bewusst auf NAT — jedes Gerät bekommt wieder seine eigene weltweit eindeutige Adresse.
NXDOMAIN — Non-Existent Domain
DNS-Antwort, die signalisiert: diese Domain existiert nicht.
NXDOMAIN ist der Rückgabe-Code eines DNS-Resolvers, wenn die abgefragte Domain in keinem Zone-File existiert. Anwendungsfälle: Tippfehler in der URL, abgelaufene Domain, interne Hostnamen außerhalb der Firma. Problem: einige Internet-Anbieter haben in den 2010ern NXDOMAIN-Hijacking betrieben — statt NXDOMAIN-Fehler eine eigene Werbeseite ausgeliefert. In Deutschland u. a. durch die Telekom 2009 abgestellt nach Beschwerden. Erkennen kann man Hijacking, indem man eine garantiert nicht-existierende Subdomain testet (zufallsstring1234.example.com) und prüft, ob der Browser eine fremde Seite zeigt.
OCSP — Online Certificate Status Protocol
Protokoll zur Echtzeit-Prüfung, ob ein TLS-Zertifikat noch gültig oder bereits zurückgezogen ist.
OCSP löst ein Problem: nach Ausstellung eines Zertifikats kann es zurückgezogen werden (kompromittierter Schlüssel, gestohlene Domain). Der Browser fragt bei der CA via OCSP nach: „Ist dieses Zertifikat noch gültig?" Schwachstelle: OCSP fügt einen extra Roundtrip hinzu und leakt die besuchte URL an die CA. Lösung: OCSP-Stapling — der Webserver holt die OCSP-Antwort regelmäßig selbst und liefert sie zusammen mit dem Zertifikat aus. Heute der Standard. Im SSL-Check als Feld „OCSP-Status" sichtbar.
Port
Nummerierter Endpunkt für eine Netzwerkverbindung — wie eine Tür an einer Hausadresse.
Eine TCP/UDP-Verbindung ist eindeutig identifiziert durch: Quell-IP + Quell-Port + Ziel-IP + Ziel-Port + Protokoll. Ports gehen von 0–65535. Bekannte: 22 (SSH), 80 (HTTP), 443 (HTTPS), 25 (SMTP), 53 (DNS). Offene Ports sind potenzielle Angriffsflächen — daher sollten nur die wirklich gebrauchten von außen erreichbar sein. Mit dem Port-Scanner prüfen Sie, was Ihre IP nach außen freigibt.
Reverse DNS / PTR-Record
DNS-Lookup von IP-Adresse zu Hostname — Gegenstück zum normalen Forward-Lookup.
Während ein A-Record example.com → 93.184.216.34 auflöst, liefert ein PTR-Record den Weg zurück: 93.184.216.34 → example.com. Reverse DNS wird primär von Mailservern eingesetzt — fehlt der PTR, lehnen viele Mailserver die Verbindung ab. Auch Geo-IP-Datenbanken nutzen Reverse DNS als Hinweis (etwa wenn der Hostname customer-12-34.kabel-deutschland.de ist). PTR-Records pflegt der Inhaber des IP-Blocks, also der ISP — nicht der Domain-Owner.
Punycode
ASCII-Kodierung für Unicode-Domain-Namen — DNS-kompatible Schreibweise für „münchen.de".
Punycode wandelt Unicode-Domain-Komponenten in eine reine ASCII-Form um, die DNS verarbeiten kann. Aus münchen.de wird xn--mnchen-3ya.de. Das Präfix xn-- markiert eine punycode-kodierte Komponente. Browser zeigen automatisch die schöne Form, im DNS und in URL-Logs taucht die kodierte Form auf. Sicherheitsrisiko: Phisher registrieren xn--applе-43d.com (Punycode für кyrillisches „e") und betreiben darunter Lookalike-Seiten. Moderne Browser zeigen die Punycode-Form an, wenn die Mischung verdächtig ist — sehen Sie also plötzlich xn-- im Adress-Feld, ist Vorsicht angebracht.
RPKI — Resource Public Key Infrastructure
Kryptografische Validierung von BGP-Routing-Ankündigungen — Schutz gegen Route-Hijacking.
RPKI ergänzt BGP um eine Vertrauens-Ebene. Jeder IP-Block-Inhaber publiziert eine ROA (Route Origin Authorization): „Diese Präfixe dürfen nur von ASN X angekündigt werden." Empfangende Router prüfen vor der Übernahme einer BGP-Route, ob die ROA stimmt. Heute (2026) sind etwa 50 % aller globalen Routen RPKI-validiert — die großen Tier-1-Provider (Cogent, NTT, Telia) verwerfen ungültige Routen mittlerweile aktiv. Endnutzer merken davon nichts — bei einem BGP-Hijack-Versuch werden aber die Routen-Übernahmen breit unterbunden.
SNI — Server Name Indication
TLS-Erweiterung, die mehrere HTTPS-Sites auf einer einzigen IP-Adresse ermöglicht.
SNI behebt ein Henne-Ei-Problem: bei HTTPS muss der Server das richtige Zertifikat senden, *bevor* die HTTP-Anfrage gelesen wird — woher weiß er, welche Domain gemeint ist? Lösung: der Client sendet den Hostnamen schon im TLS-ClientHello mit. Server-Software wie nginx oder Apache wählt anhand SNI das passende Zertifikat. Folge: ein Server mit einer einzigen IP kann hunderte verschiedene HTTPS-Domains hosten. Praktisch jeder moderne Browser unterstützt SNI seit 2008 — nur extrem alte Clients (Windows XP, Android 2.x) hatten Probleme. Schwachstelle: SNI ist im Klartext sichtbar, weshalb der Nachfolger ECH (Encrypted ClientHello) seit 2023 ausgerollt wird.
SOA-Record — Start of Authority
Der DNS-Record, der eine Zone definiert und ihre Verwaltungsdetails festhält.
Jede DNS-Zone hat genau einen SOA-Record, der sie definiert. Felder: primärer Nameserver, Admin-E-Mail (mit . statt @), Serial-Nummer, Refresh-Intervall, Retry, Expire und Minimum-TTL. Die Serial-Nummer ist entscheidend für die Synchronisation zwischen Primary- und Secondary-Nameservern — bei jeder Änderung wird sie erhöht (Konvention: YYYYMMDDnn), Secondaries erkennen die neue Version und holen die Zone neu. Wenn DNS-Änderungen „nicht ziehen", liegt das oft an einer unveränderten Serial — Secondaries glauben dann, die Zone sei noch aktuell.
SPF — Sender Policy Framework
DNS-Eintrag, der festlegt, welche Server berechtigt sind, Mails für eine Domain zu versenden.
Ein SPF-Record ist ein TXT-Record wie v=spf1 mx include:_spf.google.com ~all. Empfangende Mailserver prüfen: kommt diese Mail von einer in SPF gelisteten IP? Wenn nein, kann die Mail als Fake markiert werden. SPF schützt gegen Absender-Fälschung. Die einfachste sinnvolle Konfiguration: v=spf1 mx ~all — erlaubt alle in den MX-Records gelisteten Server, alles andere wird softfail markiert.
SRV-Record — Service Record
DNS-Eintrag für die Service-Discovery — „welcher Server bietet Dienst X auf welchem Port?".
Ein SRV-Record beantwortet nicht „wo ist die Domain", sondern „wo ist ein bestimmter Dienst der Domain". Format: _service._proto.name TTL SRV priority weight port target. Beispiel: _xmpp-server._tcp.example.com SRV 0 5 5269 xmpp.example.com. Anwendungsfälle: Jabber/XMPP, Microsoft AD, SIP, Minecraft-Server, Matrix. Vorteil: Service-Endpoint (Host + Port) kann per DNS verschoben werden, ohne dass Clients neu konfiguriert werden müssen. Im DNS-Lookup sichtbar, in Browser-URLs aber nicht — Browser nutzen SRV nicht für HTTP.
TLS / SSL — Transport Layer Security
Verschlüsselungsprotokoll, das HTTP zu HTTPS und Mail-Verkehr absichert.
TLS ist der Nachfolger von SSL — die Bezeichnungen werden umgangssprachlich synonym verwendet, technisch ist „SSL" seit 2014 unsicher und tot. Aktuell relevant sind TLS 1.2 (Standard) und TLS 1.3 (empfohlen). TLS bietet drei Garantien: Verschlüsselung (Lauscher sehen nichts), Integrität (kein Tamper-Schutz unterwegs) und Authentifizierung (Sie reden mit der Domain, deren Zertifikat angezeigt wird). Per SSL-Check prüfen Sie Gültigkeit, Aussteller und Verschlüsselungsstärke einer Website.
TTL — Time To Live
Lebensdauer eines DNS-Eintrags in Sekunden, bevor er neu abgefragt werden muss.
TTL im DNS-Kontext steht in jedem Record und sagt Resolvern: cache diese Antwort genau N Sekunden. Niedrige TTL (300 = 5 Min) = Änderungen schlagen schnell durch, aber mehr DNS-Last. Hohe TTL (86400 = 24 h) = stabiler, aber Änderungen brauchen lang. Profis senken die TTL ihrer Records vor einer Migration auf 60–300 Sekunden, machen den Switch und erhöhen sie hinterher wieder. Im IP-Kontext meint TTL auch das Feld im IP-Header, das verhindert, dass Pakete ewig im Netz kreisen (Decrement pro Hop).
VPN — Virtual Private Network
Verschlüsselter Tunnel zwischen Ihrem Gerät und einem entfernten Server.
Ein VPN routet Ihren gesamten Internet-Verkehr durch einen verschlüsselten Tunnel zu einem Server in einem von Ihnen gewählten Land. Vorteile: Ihre echte IP wird verborgen, der ISP sieht keine Inhalte mehr, Geo-Blockaden lassen sich umgehen. Risiken: ein schlechter VPN-Anbieter sieht alles, was der ISP vorher sah — daher zählt das Logging-Versprechen mehr als das Marketing. Mit dem DNS-Leak-Test prüfen Sie, ob Ihr VPN wirklich alle Anfragen tunnelt — oder ob DNS am Tunnel vorbei leakt.