서비스 위치 레코드
DNS 및 레코드
DNS 조회 모든 도메인의 전체 DNS 레코드 A 레코드 조회 도메인의 IPv4 주소 AAAA 레코드 조회 도메인의 IPv6 주소 MX 조회 도메인의 메일 서버 NS 조회 권한 있는 네임 서버 TXT 조회 TXT 레코드, SPF, 인증 CNAME 조회 정규 이름(별칭) 레코드 SOA 조회 Start of Authority 레코드 SRV 조회 서비스 위치 레코드 CAA 조회 어떤 CA가 인증서를 발급할 수 있는지 역방향 DNS (PTR) IP 주소에서 호스트명으로 DNSSEC 점검 도메인이 서명되고 검증되는가? DNS 헬스 체크 위임 및 DNS 전체를 진단하는 종합 리포트이메일 전달성
SPF 점검 Sender Policy Framework 레코드 검증 DMARC 점검 DMARC 정책 검사 및 등급 평가 DKIM 점검 DKIM 공개 키 찾기 및 검증 블랙리스트 점검 이메일 차단 목록(DNSBL)에 대해 IP 점검 SMTP 테스트 메일 서버에 연결하여 STARTTLS 점검 MTA-STS 점검 수신 메일에 대한 강제 TLS 정책 BIMI 점검 이메일용 브랜드 로고 레코드 TLS-RPT 점검 SMTP TLS 보고 정책네트워크 및 웹
SSL 인증서 점검 사이트의 TLS 인증서 및 만료 검사 HTTP 헤더 점검 응답 헤더, 리디렉션 및 보안 검사 핑 (TCP) TCP를 통한 도달성 및 지연 시간 포트 점검 어떤 일반 포트가 열려 있는지도메인
WHOIS 조회 도메인, IP 및 ASN의 등록 데이터SRV(Service) 레코드는 SIP, XMPP, LDAP, Microsoft autodiscover 같은 특정 서비스의 호스트명과 포트를, 부하 분산을 위한 우선순위 및 가중치와 함께 알립니다. A 레코드와 달리 서비스가 어디에 있는지뿐 아니라 어느 포트에 있는지까지 클라이언트에 알려 주어, 애플리케이션이 하드코딩된 구성 없이 서비스를 찾을 수 있게 합니다. _service._proto.domain 형식으로 조회합니다.
SRV 레코드는 독특한 패턴인 _service._proto.domain으로 이름이 지어지며, 예를 들어 _sip._tcp.example.com입니다. 밑줄은 일반 호스트명과의 충돌을 막습니다. 레코드 데이터는 네 개의 값을 담습니다. priority, weight, port, target입니다. priority는 MX처럼 작동해 낮은 숫자가 먼저 시도됩니다. weight는 같은 우선순위의 대상 간에 부하를 분배하며, 가중치가 높을수록 비례적으로 더 많은 트래픽을 받습니다. port는 서비스가 수신 대기하는 TCP 또는 UDP 포트이고, target은 이를 제공하는 호스트명으로 자체 A 또는 AAAA 레코드를 가져야 합니다.
IPeek는 조회한 서비스 이름에 대해 각 SRV 레코드의 priority, weight, port, target 호스트를 반환합니다. priority를 먼저 읽으세요. 클라이언트는 더 높은 것으로 넘어가기 전에 가장 낮은 우선순위의 대상을 사용합니다. 동등한 우선순위 중에서는 weight가 각 대상이 받는 트래픽 비중을 결정합니다. port가 예상하는 서비스와 일치하는지 확인하세요. SIP는 5060, LDAP는 389, 많은 autodiscover 설정은 443입니다. 각 대상이 유효한 호스트로 확인되는지 확인하세요. 결과가 비어 있으면 그 이름으로 서비스가 도메인에 광고되지 않은 것입니다.
SRV 레코드는 클라이언트가 고정된 설정에 의존하지 않고 서비스를 자동으로 검색해야 할 때마다 중요합니다. Microsoft Teams, Skype for Business, SIP 제공업체는 이를 사용해 음성과 프레즌스 서버를 찾습니다. XMPP 채팅, LDAP 디렉터리 조회, Minecraft 서버, Kerberos 모두 SRV 검색에 의존합니다. 큰 장점은 유연성입니다. 서비스를 새 호스트나 포트로 옮기거나 여러 서버에 분산해도 클라이언트가 재구성 없이 SRV 레코드를 따라갑니다. 서비스가 특정 _service._proto 이름을 요구한다면 일치하는 SRV 레코드를 게시하지 않으면 클라이언트가 찾지 못합니다.
이 패턴은 SRV 레코드가 설명하는 서비스와 프로토콜로 이름을 짓습니다. _service는 서비스 레이블(예: _sip 또는 _ldap), _proto는 전송 방식(_tcp 또는 _udp), domain은 귀하의 도메인입니다. 예를 들어 _sip._tcp.example.com은 TCP를 통한 SIP를 광고합니다. 앞의 밑줄은 이 레이블이 일반 호스트명과 충돌하지 않게 합니다.
priority와 weight는 클라이언트가 어떤 대상을 선택할지 제어합니다. priority는 MX 레코드처럼 작동해, 클라이언트가 가장 낮은 우선순위의 대상을 먼저 시도하고 더 높은 숫자로 넘어갑니다. 우선순위를 공유하는 대상 중에서는 weight가 각자 받는 트래픽 비율을 정하므로 가중치가 높을수록 더 많은 연결을 끌어옵니다. 둘이 함께 장애 조치와 부하 분산을 모두 가능하게 합니다.
A 레코드는 호스트명을 IP 주소에 매핑하는 반면, SRV 레코드는 추가로 포트를 지정하고 명명된 서비스에 priority와 weight를 더합니다. SRV는 클라이언트가 서비스가 어디에서 어느 포트로 실행되는지, 그리고 부하를 어떻게 분산할지까지 검색할 수 있게 하며, 이는 일반 A 레코드로는 표현할 수 없습니다. SRV 대상도 여전히 확인을 위해 A 레코드에 의존합니다.
SIP 및 VoIP 시스템, XMPP 채팅, LDAP 및 Active Directory, Kerberos, Microsoft Teams 및 Skype for Business, 심지어 Minecraft 서버까지 SRV 레코드를 흔히 사용합니다. 하드코딩된 호스트 및 포트 설정 없이 자동 서비스 검색의 이점을 누리는 프로토콜이라면 모두 후보입니다. 클라이언트가 해당 _service._proto 이름을 조회하도록 작성되어 있어야 합니다.
SRV 결과가 비어 있는 것은 보통 정확히 그 _service._proto.domain 이름으로 게시된 레코드가 없다는 뜻입니다. 서비스 레이블, 프로토콜, 도메인이 밑줄을 포함해 올바르게 표기되었는지 확인하세요. 서비스가 예상과 다른 이름을 쓰거나 레코드가 단순히 존재하지 않을 수 있습니다. 클라이언트 애플리케이션이 요구하는 정확한 이름을 확인하세요.