Wofür .aero steht – und was du daraus operativ ableiten solltest
.aero ist eine Endung, die semantisch ziemlich eindeutig „Luftfahrt“ schreit. Das ist als Signal nett, aber als Betreiber solltest du vor allem eins mitnehmen: Solche thematisch klaren TLDs werden häufig als „vertrauenswürdiger“ wahrgenommen, weil sie nach Industrie/Institution klingen. Genau deshalb lohnt sich bei .aero eine extra saubere Betriebsführung. Nicht, weil die TLD technisch exotisch wäre – im Gegenteil: Sie funktioniert wie eine klassische gTLD mit den üblichen Mechaniken (Schnittstellen, Status-Codes, Transfers). Sondern weil der Erwartungsdruck (Trust, Compliance, Zuverlässigkeit) in der Praxis höher sein kann, sobald echte Organisationen daran hängen.
WHOIS & RDAP: zwei Wege zur Wahrheit – RDAP ist der bessere Datenrohstoff
IANA listet sowohl WHOIS als auch RDAP. Das ist super, weil du damit zwei Nutzungsarten abdecken kannst: WHOIS für schnelle Terminal-Checks und RDAP für strukturierte Verarbeitung. RDAP liefert JSON und damit stabil lesbare Felder (Statusliste, Entities, Events wie Ablauf-/Registrierungsdaten, Nameserver-Infos usw.). Das ist ideal, wenn du Monitoring oder interne Tools baust: Du kannst „Domain Health“ messen, statt nur zu hoffen.
# RDAP (strukturierte Daten)
curl -s https://rdap.identitydigital.services/rdap/domain/example.aero | head -n 60
# WHOIS (schnell im Terminal)
whois -h whois.aero example.aero
Status-Codes: die unsichtbaren Schalter hinter Transfers & Änderungen
Wenn eine Domain nicht transferierbar ist oder Änderungen nicht greifen, ist es oft kein Mysterium, sondern ein Status-Flag. Typische Sperren heißen z. B. clientTransferProhibited (Registrar-Lock) oder clientUpdateProhibited. Solche Flags sind nicht „schlecht“ – sie sind Schutz. Das Problem entsteht erst, wenn niemand weiß, wer den Lock gesetzt hat, warum er gesetzt ist und wer ihn im Notfall lösen darf. Wenn .aero in einem Team betrieben wird, definiere Rollen und Freigaben, sonst wird jede Änderung zur Support-Odyssee.
Lifecycle: Ablauf ist kein Punkt, sondern eine Strecke
Bei gTLDs ist der Domain-Lifecycle typischerweise eine Abfolge von Phasen: aktiv → abgelaufen → (je nach Phase) Grace/Restore/Redemption → pending delete → frei. Das ist wichtig, weil „abgelaufen“ nicht heißt „sofort weg“, aber eben auch nicht „ist schon egal“. Wenn .aero als Hauptdomain eingesetzt wird (oder als zentrale Infrastruktur wie Mail/Portale), dann brauchst du: Auto-Renew + unabhängiges Monitoring + einen zweiten Kontaktweg. Denn die häufigsten Totalausfälle sind Abrechnungs- und Account-Themen, nicht DNS.
DNS & DNSSEC: Stabilität ist Planung, nicht Hoffnung
DNS-Probleme sind fast immer Handwerk: falsches NS-Set, Zonen nicht mehr publiziert, TTLs zu hoch bei Migrationen, oder ein „wilder“ TXT-Record-Garten (SPF, DKIM, Verifikationen, alte Providerreste). DNSSEC kann sinnvoll sein, gerade wenn Integrität ein Thema ist – aber nur mit sauberem DS-/Rollover-Prozess. Der Klassiker: DNSSEC aktiv, Providerwechsel, DS nicht aktualisiert → validierende Resolver liefern SERVFAIL, während „bei manchen“ noch alles geht. Das fühlt sich dann an wie Spuk, ist aber nur ein kaputter Prozess.
dig +short NS example.aero
dig +trace example.aero
dig +dnssec example.aero
Ops-Checkliste für .aero (kurz, aber ernst gemeint)
- RDAP-Monitoring: Status, Expiry, Änderungen automatisiert prüfen.
- Lock-Policy: wer setzt Locks, wer hebt sie auf, wie läuft der Notfall.
- DNS Hygiene: NS-Redundanz, TTL-Plan, TXT-Aufräumen in festen Intervallen.
- DNSSEC (optional): nur mit DS-/Rollover-Runbook und Tests.
- Incident-Plan: bei Takeover/Phishing/Fehlkonfig: Zuständigkeiten + schnelle Schritte.
Unterm Strich: .aero ist technisch eine saubere, gut abfragbare gTLD. Der Unterschied entsteht durch die Erwartung: Wer hier schlampig arbeitet, fällt schneller auf – und wer sauber arbeitet, wird selten überhaupt bemerkt. Das ist eigentlich das größte Kompliment im Domainbetrieb.