SRV 레코드: 서비스 검색

DNS는 하나의 질문에 답하도록 만들어졌습니다: 이름이 주어졌을 때, IP 주소는 무엇인가? SRV 레코드는 DNS에게 전혀 다른 질문에 답하도록 요청합니다: 내가 필요한 서비스가 있을 때, 어떻게 연결하면 되는가?

VoIP 전화기가 켜지면서 회사의 전화 서버를 찾아야 할 때, 채팅 클라이언트가 도메인의 XMPP 서버를 찾아야 할 때, Minecraft 플레이어가 서버 주소를 입력할 때—무언가가 어디에 연결해야 하는지뿐만 아니라 어떻게 연결해야 하는지도 알려줘야 합니다. 어떤 포트? 어떤 프로토콜? 서버가 여러 개라면 어느 것을 먼저 시도해야 할까요?

SRV 레코드는 이 모든 것을 DNS 안에 담습니다.

SRV 레코드의 구조

SRV 레코드는 특정 형식을 따릅니다:

_service._protocol.name TTL class SRV priority weight port target

각 구성 요소는 명확한 역할을 합니다:

• _service: 서비스 이름 (_sip, _xmpp, _ldap, _minecraft)
• _protocol: 전송 프로토콜 (_tcp 또는 _udp)
• name: 서비스를 제공하는 도메인
• priority: 낮은 값부터 먼저 시도됩니다 (MX 레코드와 동일한 방식)
• weight: 같은 우선순위 서버들 사이에서 트래픽을 분산합니다
• port: 연결할 TCP 또는 UDP 포트
• target: 실제로 서비스를 제공하는 호스트명

SIP 전화 시스템의 실제 예:

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 sipserver1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 40 5060 sipserver2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 100 5060 sipbackup.example.com.

세 개의 서버. 두 단계의 우선순위. 자동 장애 조치와 부하 분산—단 하나의 DNS 쿼리로 모두 해결됩니다.

우선순위와 가중치: 2단계 선택

우선순위는 계층 구조를 만듭니다. 클라이언트는 항상 번호가 가장 낮은 우선순위부터 시도합니다. 위의 예에서 sipserver1과 sipserver2는 모두 우선순위 10이므로 기본 서버입니다. 우선순위 20의 백업 서버는 두 기본 서버가 모두 다운되었을 때만 트래픽을 받습니다.

가중치는 같은 우선순위 내에서 트래픽을 분산합니다. sipserver1(가중치 60)과 sipserver2(가중치 40)가 모두 사용 가능하면, 클라이언트는 가중치에 따라 무작위로 선택합니다—sipserver1이 약 60%, sipserver2가 약 40%의 연결을 받게 됩니다.

가중치 0은 특별합니다. 이 서버들은 우선순위가 낮아지지만 완전히 제외되지는 않습니다. RFC 2782에 따르면, 가중치가 있는 다른 서버가 존재할 때 이 서버들은 "선택될 가능성이 매우 낮습니다"¹. 서버를 사용 가능한 상태로 두되 거의 선택되지 않게 하려면—예를 들어 초과 트래픽만 처리하는 느린 백업 서버라면—가중치 0을 사용하세요.

이 2단계 시스템—장애 조치를 위한 우선순위, 분산을 위한 가중치—덕분에 관리자는 클라이언트 설정을 건드리지 않고도 트래픽 패턴을 세밀하게 제어할 수 있습니다.

SRV 레코드가 빛을 발하는 곳

SIP (VoIP): 데스크 전화기가 부팅되면 _sip._tcp.company.com을 조회해 전화 서버를 찾습니다. IT 팀은 여러 서버를 운영하거나, 서비스를 다른 머신으로 이전하거나, 포트를 변경할 수 있습니다—전화기는 자동으로 새 위치를 찾아갑니다.

XMPP (채팅): 연합(federated) 채팅은 SRV 레코드에 의존합니다. someone@example.com에 메시지를 보낼 때, 클라이언트는 _xmpp-client._tcp.example.com을 조회해 상대방 서버를 찾습니다². 서로 다른 조직이 각자의 서버를 운영하면서도 원활하게 소통할 수 있습니다.

LDAP (디렉터리 서비스): Windows Active Directory는 SRV 레코드를 광범위하게 활용합니다. 도메인 컨트롤러는 _ldap._tcp.company.com 같은 레코드를 통해 자신의 존재를 알리고, 워크스테이션은 인증 서버를 자동으로 찾아냅니다.

Minecraft: 게임 서버는 종종 비표준 포트에서 실행됩니다. _minecraft._tcp.play.example.com에 SRV 레코드를 설정하면, 운영자는 어떤 포트를 사용하든 플레이어는 그냥 play.example.com만 입력하면 됩니다. 깔끔한 주소, 유연한 인프라.

CalDAV/CardDAV: 캘린더와 연락처 동기화 클라이언트는 SRV 레코드를 사용해 수동 설정 없이 올바른 서버를 찾아냅니다.

왜 웹 트래픽에는 적용되지 않을까요?

SRV 레코드는 SIP나 XMPP 같은 프로토콜에는 훌륭하게 작동합니다. 그런데 왜 브라우저는 이걸 사용하지 않을까요?

HTTPS 인증서는 특정 도메인 이름에 묶여 있습니다. SRV 레코드가 브라우저를 www.example.com에서 webserver1.example.com으로 연결하게 한다면, 인증서가 사용자가 입력한 URL과 일치하지 않아 보안 경고가 뜹니다.

웹은 이 문제를 다른 방식으로 해결합니다: 로드 밸런서, CDN, GeoDNS, 애니캐스트. 이 방법들은 모두 인증서 검증의 제약 안에서 작동합니다.

완전한 예시

미국과 EU에 데이터센터를 운영하는 회사는 XMPP를 이렇게 설정할 수 있습니다:

; 미국 기본 서버 (우선순위 10, 50/50 부하 분산)
_xmpp-client._tcp.example.com. 3600 IN SRV 10 50 5222 xmpp-us1.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 10 50 5222 xmpp-us2.example.com.

; EU 장애 조치 (우선순위 20)
_xmpp-client._tcp.example.com. 3600 IN SRV 20 100 5222 xmpp-eu1.example.com.

; 실제 IP 주소
xmpp-us1.example.com. 3600 IN A 203.0.113.10
xmpp-us2.example.com. 3600 IN A 203.0.113.11
xmpp-eu1.example.com. 3600 IN A 198.51.100.20

정상 상태에서는 트래픽이 두 미국 서버에 분산됩니다. 두 서버 모두 장애가 발생하면 EU 서버가 인계받습니다. 클라이언트 재설정은 필요 없습니다.

더 깊은 가치

SRV 레코드는 DNS를 전화번호부에서 서비스 디렉터리로 탈바꿈시킵니다. 클라이언트는 어느 서버인지, 어떤 포트인지, 문제가 생겼을 때 어떻게 해야 하는지 알 필요가 없습니다. DNS에 물어보면, DNS가 연결에 필요한 모든 것을 알려줍니다.

이는 클라이언트 변경 없이 인프라를 자유롭게 발전시킬 수 있다는 뜻입니다. 서비스를 새 서버로 옮기려면? SRV 레코드를 업데이트하세요. 용량을 늘리려면? 같은 우선순위로 레코드를 추가하세요. 유지보수를 위해 서버를 내리려면? 해당 레코드를 잠시 제거하세요. 클라이언트는 자동으로 적응합니다.

SRV 레코드를 지원하는 프로토콜에서, 이것은 그것에 의존하는 모든 것을 망가뜨리지 않으면서도 변화할 수 있는 인프라를 구축하는 방법입니다.

SRV 레코드에 관한 자주 묻는 질문

SRV 레코드를 어떻게 조회하나요?

dig 또는 nslookup을 사용하세요. 예를 들어, dig _sip._tcp.example.com SRV를 실행하면 해당 도메인의 SIP 서비스에 대한 모든 SRV 레코드가 우선순위, 가중치, 포트, 대상 호스트명과 함께 출력됩니다.

SRV 레코드가 없으면 어떻게 되나요?

프로토콜마다 동작이 다릅니다. 일부 클라이언트는 기본 포트에서 A 레코드 조회로 대체합니다. 어떤 것들은 완전히 실패합니다. 잘 설계된 프로토콜은 대체 동작을 명시하지만, 사용 가능하다면 항상 SRV 레코드를 활용하는 것이 바람직합니다.

사용자 정의 서비스에 SRV 레코드를 사용할 수 있나요?

가능합니다. 단, 클라이언트가 SRV 레코드를 조회하도록 구현되어 있어야 합니다. SRV 레코드는 서버가 레코드를 발행하고 클라이언트가 그것을 조회하는 방법을 알 때 작동합니다. 사용자 정의 프로토콜의 경우 양쪽 모두를 직접 제어할 수 있습니다. 표준 프로토콜의 경우 클라이언트가 SRV 조회를 지원하는지 확인하세요.

SRV 레코드에 어떤 TTL을 사용해야 하나요?

낮은 TTL(3003600초)은 더 빠른 장애 조치를 가능하게 하지만 DNS 쿼리 부하가 늘어납니다. 높은 TTL은 쿼리를 줄이지만 장애 조치가 느려집니다. 중요한 서비스라면 515분이 응답 속도와 효율성 사이의 균형을 잘 맞춥니다.

출처