DNS-Propagations-Prüfer

DNS-Propagation ist der Zeitraum, der benötigt wird, damit auf autoritativen Nameservern vorgenommene Aktualisierungen weltweit auf rekursiven DNS-Resolvern verteilt und aktualisiert werden. Wenn ein DNS-Record geändert wird, behalten zwischengeschaltete Caching-Resolver (wie ISP-Resolver, öffentliche Resolver wie Google und Cloudflare sowie Unternehmens-Forwarder) den alten Record so lange bei, bis dessen Time To Live (TTL) abläuft. Die Propagation dauert je nach vorkonfigurierter TTL in der Regel zwischen einigen Minuten und 24 Stunden.

Wenn sich ein Gästegerät mit einer offenen oder sicheren Gäste-SSID verbindet, leiten Betriebssysteme wie iOS, macOS, Android und Windows automatisierte Prüfungen zur Erkennung von Captive Portals ein (z. B. durch Abfrage von captive.apple.com oder connectivitycheck.gstatic.com). Der Access Point oder Controller fängt den HTTP-Datenverkehr ab und leitet den Client-Browser zur Captive Portal-Domain um (z. B. portal.purple.ai). Verwendet das Client-Gerät einen DNS-Resolver, der den neuen Portal-Record noch nicht gecacht hat, schlägt die DNS-Auflösung fehl. Dies führt zu Browser-Timeouts des Captive Network Assistant (CNA) und zu Fehlschlägen beim Onboarding.

Die TTL (Time To Live) ist eine 32-Bit-Ganzzahl in Sekunden, die für jeden DNS-Resource-Record definiert ist und festlegt, wie lange rekursive Resolver die Antwort cachen dürfen. Eine niedrigere TTL (wie 300 Sekunden) stellt sicher, dass Resolver den autoritativen Nameserver alle 5 Minuten abfragen, was schnelle Umschaltungen ermöglicht. Eine hohe TTL (wie 86.400 Sekunden / 24 Stunden) führt dazu, dass Resolver bis zu einem ganzen Tag lang veraltete gecachte Records ausgeben.

Autoritative Nameserver enthalten die Master-Zonendatei und die verlässliche Informationsquelle (Source of Truth) für eine Domain (z. B. AWS Route 53, Cloudflare DNS, NS1). Rekursive DNS-Resolver (wie Google 8.8.8.8, Cloudflare 1.1.1.1 und ISP-Nameserver) agieren als Zwischeninstanzen, die autoritative Server im Namen von Client-Geräten abfragen und die Ergebnisse gemäß der Record-TTL cachen.

Führen Sie auf macOS `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` im Terminal aus. Führen Sie auf Windows `ipconfig /flushdns` in der Eingabeaufforderung aus. Starten Sie auf Linux systemd-resolved über `sudo systemd-resolve --flush-caches` oder `sudo resolvectl flush-caches` neu. Alternativ können Sie diesen Online-DNS-Propagations-Checker verwenden, um externe Anycast-Resolver direkt abzufragen und das gesamte Caching des lokalen Betriebssystems zu umgehen.

Purple betreibt eine weltweit verteilte Anycast-Cloud-Infrastruktur, die eine DNS-Auflösung in unter 20 ms und ein sofortiges Laden von HTTPS-Splash-Pages weltweit bietet. Die Vorkonfiguration von Walled-Garden-Domain-Whitelists und das Senken von DNS-TTLs vor Umstellungen beim Onboarding gewährleisten eine nahtlose Gäste-Authentifizierung über Hardware von Cisco Meraki, Aruba, Ubiquiti UniFi, Ruckus und Cisco Catalyst.