Warum .gov operativ „anders“ ist
.gov ist kein „kauf dir mal eben beim Registrar“-Namensraum wie viele gTLDs. Die entscheidende Eigenschaft ist die Restriktion: die Endung ist für staatliche Stellen gedacht und wird entsprechend verwaltet. Für Technik heißt das etwas ganz Praktisches: Du solltest nicht erwarten, dass alle Workflows identisch zu .com/.net sind, aber du bekommst trotzdem moderne Werkzeuge wie RDAP, um Zustände sauber zu prüfen. Und: Security ist hier nicht „Optional“, sondern Kern der Erwartungshaltung.
RDAP als Status- und Strukturquelle
Der RDAP-Endpunkt ist offiziell benannt. Das ist hilfreich für Monitoring, Audits und Incident Response: Du kannst prüfen, welche Status-Flags sichtbar sind, ob eine Domain in ungewöhnliche Zustände läuft, und du kannst Prozesse automatisieren, ohne dich auf UI-Screenshots zu verlassen. Gerade bei kritischen öffentlichen Services willst du „Domain-Health“ als Teil der Betriebsüberwachung sehen.
curl -s https://rdap.nic.gov/rdap/domain/example.gov | head -n 55
WHOIS: schnell testen, wenn’s brennt
WHOIS ist bei .gov ebenfalls im IANA-Record ausgewiesen. Das ist für schnelle CLI-Checks praktisch, z. B. wenn du bei DNS-Ausfällen erstmal klären willst, ob die Domain überhaupt aktiv/delegiert ist oder ob ein administrativer Zustand vorliegt. Wichtig: WHOIS ist nicht „mehr Wahrheit“ als RDAP – es ist nur ein anderes Interface. Im Zweifel gilt: strukturiert (RDAP) gewinnt.
whois -h whois.nic.gov example.gov
DNS & DNSSEC: für .gov besonders relevant
Bei staatlichen Domains ist DNSSEC häufig ein Thema, weil Integrität der Namensauflösung ein Sicherheitsbaustein ist. Gleichzeitig gilt auch hier: DNSSEC ist nur so gut wie der Prozess dahinter. DS-Änderungen und Rollovers müssen planbar sein, ansonsten kann DNSSEC selbst zum Ausfallfaktor werden. Zusätzlich gilt: Nameserver-Redundanz ist Pflicht, nicht Kür: nicht „zwei NS beim gleichen Provider“, sondern echte Diversität (Anycast/Provider-Mix).
dig +short NS example.gov
dig +trace example.gov
dig +dnssec example.gov
Typische Fehlerbilder (die man in .gov vermeiden will)
- Account-Risiko: fehlende Rollen, unklare Recovery, zu viele Admins.
- DNS-Migration ohne Plan: TTL zu hoch, Zertifikate nicht vorbereitet, Redirects kippen.
- Subdomain-Shadow-IT: Subsysteme entstehen, keiner überwacht sie (Phishing-Risiko).
- DNSSEC ohne Rollover-Runbook: DS/Keys werden irgendwann „vergessen“.
- Fehlende Domain-Monitoring-Signale: HTTP-Uptime allein sieht Domain-Probleme nicht früh genug.
Ops-Checkliste für .gov (pragmatisch)
- RDAP Monitoring: Status/Expiry/Nameserver im Blick.
- DNS Governance: Change-Prozess, Logging, Freigaben.
- Security am Zugang: 2FA, Rollenmodell, Recovery getestet.
- DNSSEC: nur mit DS-/Rollover-Plan und Testmethodik.
- Incident-Prozesse: Wer reagiert bei Takeover/Phishing/Delegation-Fehlern?
.gov ist technisch nicht „mystisch“ – aber es ist ein Umfeld, in dem man Domainbetrieb wie Infrastruktur behandeln muss. Alles andere rächt sich schnell.