Wofür .net „eigentlich“ gedacht war (und warum das heute egal ist)
.net war historisch als „Network“-Gegenstück zu .com gedacht. Praktisch ist .net heute ein ganz normaler, globaler Namensraum: Firmen, Communities, Infrastruktur-Domains, alles drin. Technisch ist gerade das Interessante: .net ist extrem standardisiert, gut dokumentiert und lässt sich sauber überwachen. Wenn man irgendwo Domain-Ops lernen will, ist .net ein dankbares Spielfeld, weil die üblichen Werkzeuge (RDAP, WHOIS, Status-Codes, DNSSEC-Checks) zuverlässig greifen.
RDAP statt WHOIS: Warum du bei .net ruhig maschinell denken darfst
WHOIS ist oft der „erste Reflex“, aber RDAP ist der bessere Alltag: JSON, klare Felder, Status-Flags, Entities. Bei .net ist der RDAP-Endpunkt in der IANA-Datenbank angegeben, du kannst also ziemlich direkt arbeiten. Das ist für Monitoring super: Du kannst z. B. regelmäßig prüfen, ob sich Status-Codes ändern, ob ein Ablaufdatum näher rückt, oder ob die Domain plötzlich in einen Sperr-/Hold-Zustand läuft.
curl -s https://rdap.verisign.com/net/v1/domain/example.net | head -n 30
Status-Codes: die unsichtbaren „Schranken“ bei Transfers
Wenn ein Transfer klemmt, ist es selten „ein Bug“. Meist ist es ein Status-Code: clientTransferProhibited (oft vom Registrar gesetzt) oder serverTransferProhibited (eher registryseitig/Policy). Dazu kommen typische Fristen: nach bestimmten Änderungen (z. B. Registrant-Wechsel) können Transfers zeitweise blockiert sein, je nach Registrar-Policy und ICANN-Regelwerk. Der Trick: nicht raten, sondern die Status-Flags aus RDAP/WHOIS auslesen und dann gezielt im Registrar-Panel handeln.
Domain-Lifecycle: Auto-Renew ist kein „Gefühl“
Bei gTLDs wie .net läuft vieles über klar definierte Lebenszyklen: Registrierung → Verlängerung → Ablauf → Grace Periods → Redemption/Restore → Delete. In der Praxis ist wichtig: „Expired“ bedeutet nicht immer „weg“. Viele Domains sind in einer Phase, in der sie technisch noch delegiert sind, aber kommerziell/vertraglich schon wackeln. Wenn du Domains professionell verwaltest, brauchst du: (1) zentrale Renewal-Überwachung, (2) Zuständigkeiten (wer darf verlängern?), (3) saubere Zahlungswege und (4) einen Plan für „Failover“, falls ein Registrar ausfällt oder ein Account kompromittiert wird.
DNS & DNSSEC: Stabilität ist ein Prozess, kein Button
DNS-Fehler bei .net sind meistens Handwerk: falsches NS-Set, fehlender Glue bei In-Bailiwick-Nameservern, oder TTL-Chaos bei Migrationen. DNSSEC kann zusätzlich Sicherheit geben, aber nur, wenn du Rollovers und DS-Updates sauber managst. Der Klassiker: Providerwechsel, neue KSK, alter DS bleibt im Parent → validierende Resolver werfen SERVFAIL, während „manche“ Nutzer noch reinkommen. Wer DNSSEC nutzt, sollte Rollovers dokumentieren und nicht „nebenbei“ im Panel klicken.
dig +short NS example.net
dig +dnssec example.net
dig +trace example.net
Ops-Checkliste für .net (kurz, aber ernst gemeint)
- RDAP-Monitoring: Status-Flags, Expiry, Änderungen.
- Registrar-Security: 2FA, Rollen, Transfer-Lock-Policy.
- DNS-Redundanz: echte Verteilung (nicht 2 Nameserver auf einem Host).
- DNSSEC: nur mit Rollover-Plan & DS-Prozess.
- Renewals: keine „Kalender-Reminder“, sondern echte Kontrollen.
.net wirkt „ruhig“ – und genau deshalb ist es eine gute TLD, um Domain-Betrieb professionell aufzuziehen. Wenn hier etwas schiefgeht, liegt es fast nie an der TLD selbst, sondern an Prozessen oder Konfigurationen drumherum.