Dienst-Standort-Einträge
DNS & Einträge
DNS-Abfrage Alle DNS-Einträge für jede Domain A-Eintrag-Abfrage IPv4-Adressen für eine Domain AAAA-Eintrag-Abfrage IPv6-Adressen für eine Domain MX-Abfrage Mailserver für eine Domain NS-Abfrage Autoritative Nameserver TXT-Abfrage TXT-Einträge, SPF, Verifizierung CNAME-Abfrage Kanonische Namen (Alias)-Einträge SOA-Abfrage Start-of-Authority-Eintrag SRV-Abfrage Dienst-Standort-Einträge CAA-Abfrage Welche CAs Zertifikate ausstellen dürfen Reverse DNS (PTR) IP-Adresse zu Hostname DNSSEC-Prüfung Ist die Domain signiert und validiert? DNS-Gesundheitscheck Ein vollständiger Bericht zu Delegierung & DNSE-Mail-Zustellbarkeit
SPF-Prüfung Validieren Sie Ihren Sender-Policy-Framework-Eintrag DMARC-Prüfung Untersuchen und bewerten Sie Ihre DMARC-Richtlinie DKIM-Prüfung Finden und validieren Sie Ihren öffentlichen DKIM-Schlüssel Blacklist-Prüfung Prüfen Sie eine IP gegen E-Mail-Sperrlisten (DNSBLs) SMTP-Test Mit einem Mailserver verbinden und STARTTLS prüfen MTA-STS-Prüfung Erzwungene TLS-Richtlinie für eingehende Mails BIMI-Prüfung Markenlogo-Eintrag für E-Mail TLS-RPT-Prüfung SMTP-TLS-BerichtsrichtlinieNetzwerk & Web
SSL-Zertifikat-Prüfung TLS-Zertifikat und Ablauf einer Website untersuchen HTTP-Header-Prüfung Antwort-Header, Weiterleitungen und Sicherheit untersuchen Ping (TCP) Erreichbarkeit und Latenz über TCP Port-Prüfung Welche gängigen Ports offen sindDomain
WHOIS-Abfrage Registrierungsdaten für Domains, IPs und ASNsEin SRV-Record (Service) gibt den Hostnamen und Port für einen bestimmten Dienst bekannt – etwa SIP, XMPP, LDAP oder Microsoft Autodiscover – zusammen mit Priorität und Gewicht zur Lastverteilung. Anders als ein A-Record teilt er Clients nicht nur mit, wo ein Dienst liegt, sondern auch auf welchem Port, sodass Anwendungen Dienste ohne fest codierte Konfiguration finden können. Fragen Sie sie über die Form _service._proto.domain ab.
Ein SRV-Record wird nach einem unverwechselbaren Muster benannt: _service._proto.domain, zum Beispiel _sip._tcp.example.com. Die Unterstriche verhindern Kollisionen mit gewöhnlichen Hostnamen. Die Daten des Records enthalten vier Werte: Priorität, Gewicht, Port und Ziel. Priorität funktioniert wie bei MX – niedrigere Zahlen werden zuerst versucht. Gewicht verteilt die Last unter Zielen derselben Priorität, wobei höhere Gewichte proportional mehr Verkehr erhalten. Port ist der TCP- oder UDP-Port, auf dem der Dienst lauscht, und Ziel ist der Hostname, der ihn bereitstellt und der einen eigenen A- oder AAAA-Record haben muss.
IPeek gibt für den abgefragten Dienstnamen Priorität, Gewicht, Port und Ziel-Host jedes SRV-Records zurück. Lesen Sie zuerst die Priorität: Clients nutzen die Ziele mit der niedrigsten Priorität, bevor sie auf höhere zurückgreifen. Unter gleichen Prioritäten entscheidet das Gewicht über den Anteil des Verkehrs, den jedes Ziel erhält. Bestätigen Sie, dass der Port zum erwarteten Dienst passt – 5060 für SIP, 389 für LDAP, 443 für viele Autodiscover-Setups. Prüfen Sie, dass jedes Ziel zu einem gültigen Host auflöst. Ein leeres Ergebnis bedeutet, dass der Dienst unter diesem Namen auf der Domain nicht bekannt gegeben wird.
SRV-Records sind immer dann wichtig, wenn Clients einen Dienst automatisch entdecken müssen, statt sich auf feste Einstellungen zu verlassen. Microsoft Teams, Skype for Business und SIP-Anbieter nutzen sie, um Sprach- und Präsenzserver zu finden. XMPP-Chat, LDAP-Verzeichnisabfragen, Minecraft-Server und Kerberos hängen alle von der SRV-Erkennung ab. Der große Vorteil ist Flexibilität: Verschieben Sie einen Dienst auf einen neuen Host oder Port oder verteilen Sie ihn über mehrere Server, und Clients folgen den SRV-Records ohne Neukonfiguration. Wenn ein Dienst einen bestimmten _service._proto-Namen erfordert, veröffentlichen Sie einen passenden SRV-Record, sonst finden Clients ihn nicht.
Dieses Muster benennt einen SRV-Record nach dem Dienst und Protokoll, das er beschreibt. _service ist die Dienstbezeichnung (wie _sip oder _ldap), _proto ist der Transport (_tcp oder _udp) und domain ist Ihre Domain. Zum Beispiel gibt _sip._tcp.example.com SIP über TCP bekannt. Die führenden Unterstriche bewahren diese Bezeichnungen davor, mit normalen Hostnamen zu kollidieren.
Priorität und Gewicht steuern, welches Ziel ein Client wählt. Priorität funktioniert wie bei MX-Records: Clients versuchen zuerst die Ziele mit der niedrigsten Priorität und greifen auf höhere Zahlen zurück. Unter Zielen, die sich eine Priorität teilen, legt das Gewicht den Anteil des Verkehrs fest, den jedes erhält, sodass ein höheres Gewicht mehr Verbindungen anzieht. Zusammen ermöglichen sie sowohl Failover als auch Lastverteilung.
Ein A-Record bildet einen Hostnamen auf eine IP-Adresse ab, während ein SRV-Record zusätzlich den Port angibt und Priorität und Gewicht für einen benannten Dienst hinzufügt. SRV lässt Clients sowohl wo als auch auf welchem Port ein Dienst läuft entdecken, plus wie die Last zu verteilen ist – was ein einfacher A-Record nicht ausdrücken kann. SRV-Ziele verlassen sich zur Auflösung weiterhin auf A-Records.
SIP- und VoIP-Systeme, XMPP-Chat, LDAP und Active Directory, Kerberos, Microsoft Teams und Skype for Business und sogar Minecraft-Server nutzen häufig SRV-Records. Jedes Protokoll, das von automatischer Diensterkennung ohne fest codierte Host- und Port-Einstellungen profitiert, ist ein Kandidat. Der Client muss so geschrieben sein, dass er den jeweiligen _service._proto-Namen abfragt.
Ein leeres SRV-Ergebnis bedeutet meist, dass unter genau diesem _service._proto.domain-Namen kein Record veröffentlicht ist. Prüfen Sie, dass Dienstbezeichnung, Protokoll und Domain korrekt geschrieben sind, einschließlich der Unterstriche. Der Dienst nutzt möglicherweise einen anderen Namen als erwartet, oder der Record existiert schlicht nicht. Bestätigen Sie den genauen Namen, den die Client-Anwendung benötigt.