요약

  • DNS SRV는 도메인이 여러 서비스 대상, 그 포트, 기본·백업 계층, 그리고 동일 우선순위 호스트 사이의 정적 선택 편향을 프로토콜별로 공개할 수 있는 방법을 제공했습니다.
  • Priority와 Weight는 서로 다른 종류의 의도를 담습니다. 도달 가능한 가장 낮은 숫자 우선순위 계층이 먼저 시도되며, 가중치에 따른 무작위 순서는 그 계층 내에서만 클라이언트가 결정합니다. Weight는 실시간 부하 텔레메트리가 아닙니다.
  • 이 레코드는 서비스 결정을 완성하지 못합니다. 클라이언트는 여전히 각 정식 대상을 해석하고, 공지된 전송 방식과 포트로 접속을 시도하며, 애플리케이션 엔드포인트를 검증해야 합니다. DNS 공개는 발견의 근거이지 신원이나 건강 상태가 아닙니다.

서비스가 고유한 이름을 갖기 전

초기 도메인 이름 시스템은 강력하되 더 좁은 질문에 답했습니다. 이 호스트 이름에는 어떤 주소가 속하는가. 애플리케이션은 나머지를 관례에서 얻는 경우가 많았습니다. 서비스가 보통 특정 포트를 차지한다는 점을 알고 있었고,/etc/services같은 로컬 테이블을 참조하거나 관리자가 문서에 기록해 둔 정확한 서버 이름을 요청했습니다.

이 배치는 여러 결정을 하나로 묶어 버렸습니다. 공개 이름, 서비스를 실어 나르는 호스트, 운영자가 고른 포트, 그리고 대체 계획이 클라이언트에게는 하나의 사실처럼 보였습니다. 서비스를 옮기려면 주소 변경, 클라이언트 재설정, 또는 별도의 발견 시스템이 필요할 수 있었습니다. 여러 서버를 제공하는 것은 보통 여러 주소를 공개하는 일이었는데, 이는 어느 기계가 기본이고 어느 기계가 비상 백업인지, 어느 기계가 더 큰 정적 몫을 감당할 수 있는지를 표현하지 못했습니다.

RFC 2052는 1996년 10월, 다른 레코드를 제안했습니다. 클라이언트는 호스트의 주소가 아니라 서비스의 위치를 DNS에 물어보는 것입니다. 실험적 SRV 레코드는 서비스 레이블과 전송 프로토콜을 도메인에 결합한 뒤, 우선순위, 가중치, 포트 정보를 담은 대상들을 돌려주었습니다.

이 설계는 2000년 2월의RFC 2782로 승격되고 다듬어졌습니다. 그 서두의 근거는 의도적으로 실용적이었습니다. 관리자는 하나의 도메인에 여러 서버를 사용하고, 서비스를 큰 수고 없이 호스트 간에 옮기며, 기본과 백업을 모두 식별할 수 있어야 한다는 것이었습니다. IANA는 여전히 SRV를 DNS 자원 레코드type 33, Server Selection으로 기록하고 있습니다.

질의는 서비스, 전송 방식, 도메인을 분리했다

example.com안을 찾는 SRV 인식 LDAP 클라이언트는example.com자체가 기억해 둔 로컬 포트에서 LDAP을 실행한다고 가정하는 것부터 시작하지 않습니다. 클라이언트는_ldap._tcp.example.com을 질의합니다. 왼쪽 레이블들은 원하는 서비스와 전송 방식을 밝히고, 나머지 이름은 그 서비스를 찾는 행정 도메인을 밝힙니다.

RFC 2782는 실험 문서를 대체하면서 선행 밑줄 문자를 추가했습니다. 그 목적은 장식이 아니었습니다. 서비스 메타데이터가 호스트나 다른 용도로 이미 사용 중인 일반 DNS 이름과 충돌할 위험을 낮추는 것이었습니다. 개정판은 가중치 알고리즘도 명확히 했습니다.

이후의 레지스트리 작업은 네임스페이스 경계를 더 명시적으로 만들었습니다.RFC 6335는 서비스 이름과 포트 번호 절차를 통합했고, 포트 번호가 배정되지 않은 경우에도 등록된 서비스 이름을 SRV 같은 발견 메커니즘이 사용할 수 있게 했습니다. 등록은 이름을 조율하는 것이며, IANA는 그것이 애플리케이션, 제품 또는 트래픽에 대한 보증이 아니라고 명시적으로 경고합니다.

2019년,RFC 8552는 전역 범위의 밑줄 접두 DNS 노드 이름용 레지스트리를 만들어, 서로 다른 사양이 같은 전역 속성 리프를 호환되지 않는 용도에 조용히 배정하는 일을 막았습니다. 이어서RFC 8553은 배포된 관행을 보존하면서 SRV를 사용하는 사양들을 그 레지스트리 모델에 맞게 갱신했습니다. 충돌 회피로 시작한 관행이 하나의 감사 가능한 할당 표면을 갖게 된 것입니다.

네 개 필드, 네 가지 서로 다른 주장

SRV 레코드는Priority,Weight,Port,Target을 담습니다. 이를 하나의 일반적인 부하 분산 정책으로 다루면 설계가 지워집니다.

Priority는 계층을 정의합니다. 클라이언트는 도달 가능한 대상 중 가장 낮은 숫자 우선순위를 먼저 시도해야 합니다. 더 높은 숫자의 레코드는 트래픽을 덜 받는 동급 후보가 아니라 백업입니다. 낮은 계층에 도달할 수 없을 때만 다음 계층이 관련이 됩니다.

Weight는 같은 우선순위를 공유하는 레코드 사이에서 작동합니다. 더 큰 가중치는 비례적으로 더 큰 선택 확률을 받아야 합니다. RFC 2782는 무작위화 절차를 설명합니다. 가중치를 모두 더하고, 균일 난수를 하나 뽑고, 누적합을 기준으로 대상을 고른 뒤, 그 대상을 제거하고 순서가 완성될 때까지 반복합니다. 그 결과는 클라이언트의 소유입니다. DNS는 모든 요청을 위한 고정 경로가 아니라 상대적 의도를 제공합니다.

이 구분은 RFC의 가상 예제에서 드러납니다. 두 선호 호스트가 우선순위 0을 공유하며 가중치는 각각 1과 3입니다. 충분히 많은 독립적 선택에 걸쳐 두 번째 호스트는 첫 시도의 약 4분의 3을 받는 경향을 보여야 합니다. 우선순위 1에 놓인 다른 두 호스트는 선호 쌍이 서비스할 수 없을 때만 고려됩니다. 한 번의 질의나 한 명의 사용자에게 정확한 3 대 1 결과가 약속되는 것은 아닙니다.

Weight는 CPU, 대기열 깊이, 현재 지연 시간의 실시간 척도도 아닙니다. RFC 2782는 동적 부하 변화가 캐시된 DNS 데이터에 비해 너무 빠르다고 말합니다. 매우 짧은 TTL로 그것을 쫓는 것은 캐싱을 약화시키고, DNS 부하를 늘리며, 신뢰성을 떨어뜨립니다. Weight는 서버 상대 용량이나 네트워크 연결 품질 같은 더 느리게 움직이는 사실을 표현하도록 의도되었습니다.

Port는 또 하나의 숨은 의존성을 제거합니다. 서비스는 모든 클라이언트가 우연히 기억하는 포트가 아니라, 그 대상에 대해 공개된 포트에서 실행될 수 있습니다. 이 값은 배정된 포트와 일치할 수도 있지만 그럴 필요는 없습니다. 덕분에 운영자는 서비스를 특권 유닉스 포트 범위 밖으로 옮기거나, 모든 클라이언트 기기의 파일을 갱신하지 않고도 새 서비스를 도입할 수 있었습니다.

Target은 접촉할 호스트를 지정하지만, 엄격한 종결 규칙이 있습니다. 주소 레코드를 가져야 하고 별칭이어서는 안 됩니다. 클라이언트는 DNS 추가(Additional) 섹션에서 돌아온 주소를 사용하거나 별도의 A 및 AAAA 질의를 낼 수 있습니다. SRV는 주소 해석으로 이어줄 수 있지만, 대상 필드 안의 무한한 CNAME이나 DNAME 체인을 감출 수는 없습니다.

부재와 의도적 이용 불가는 다르다

루트 레이블.은 SRV 대상으로서 좁은 의미를 갖습니다. 그것이 유일한 레코드라면, 해당 도메인에서 이 서비스는 결연하게 이용 불가하다는 뜻입니다. 이는 도메인을 찾지 못한 실패도, 다른 모든 서비스가 없다는 주장도 아니며, 긍정적인 행정적 선언입니다.

이 차이는 자동화에 중요합니다. 사용 가능한 SRV 응답이 없다는 것은 프로토콜의 구식 발견 관례를 여전히 시도해야 한다는 의미일 수 있습니다. 명시적 루트 대상은 이 서비스를 도메인의 평범한 주소에서 추론해서는 안 된다고 말합니다.

RFC 2782는 보편적인 클라이언트 업그레이드가 비현실적이었기 때문에 이 호환 경로를 보존했습니다. 사용 가능한 SRV 레코드가 없으면 그 절차는 질의된 도메인에 대한 주소 조회로 폴백합니다. 관리자는 구형 클라이언트를 위해 적절한 주소 레코드를 유지하도록 권고받았습니다. 그러나 백업 전용 호스트는 구형 클라이언트가 그것을 기본으로 착각할 수 있다면 평범한 주소 집합에 노출되어서는 안 됩니다.

그 결과는 깔끔한 플래그 데이가 아니었습니다. 새 클라이언트는 서비스, 포트, 우선순위, 가중치를 이해할 수 있었습니다. 구형 클라이언트는 주소와 관례적 포트를 계속 보았습니다. 운영자는 이 호환성 표면이 접근을 보존하는지, 아니면 SRV가 표현하던 정책 그 자체를 우회하는지 판단해야 했습니다.

후보를 공개하는 것이 서비스를 증명하지는 않는다

규격에 맞는 클라이언트는 전체 RRset을 해석하고 우선순위별로 그룹화하며, 각 계층 안에서 가중치에 따른 순서를 수행하고, 대상 주소를 해석하고, 그 결과로 나온 프로토콜/주소/포트 조합을 시도합니다. 각 단계는 독립적으로 실패할 수 있습니다.

권위 있는 DNS 응답이 증명하는 것은 기껏해야 관련 DNS 권위가 무엇을 공개했고, 그 진위 메커니즘이 무엇을 보호하는지입니다. 대상이 접속을 수락한다는 것, 공지된 포트의 프로세스가 건강하다는 것, 애플리케이션 신원이 올바르다는 것, 대상 운영자가 목록에 오르는 것에 동의했다는 것, 두 대상 이름이 같은 조직에 속한다는 것은 증명하지 않습니다.

RFC 2782의 보안 절은 추가적인 통제 표면을 보이게 합니다. DNS 스푸퍼는 잘못된 호스트나 주소뿐 아니라 잘못된 포트도 공급할 수 있습니다. 한 도메인은 클라이언트를 무관한 사이트의 호스트로 보내 원치 않는 트래픽을 만들 수 있습니다. 세분화된 서비스 포트는 필터링을 복잡하게 만들고 DNS 운영자와 네트워크 운영자의 조율을 요구합니다. SRV가 근본 약점을 모두 만든 것은 아니지만, 거짓 발견 선언이 이끌 수 있는 범위를 넓혔습니다.

그래서 적용 가능성 규칙이 중요합니다. 애플리케이션 사양은 클라이언트가 SRV를 사용한다고 선언하고, 상징적 서비스 이름을 정의하며, 보안 고려사항을 다루어야 합니다. 도메인 관리자는 모든 클라이언트 프로토콜이 발명된 레이블을 따르도록 일방적으로 만들 수 없습니다. 프로토콜 저자는 발견 계약을 통제하고, 도메인 권위는 그 안의 레코드를 통제하며, 클라이언트는 실제 선택과 시도를 통제합니다.

출처와 그것이 보여줄 수 없는 것

여기서의 역사적 기록은 여섯 개 공식 출처로 닫혀 있습니다. 실험적RFC 2052, 표준 트랙의RFC 2782,RFC 6335의 서비스 이름 절차,RFC 8552의 밑줄 레지스트리 설계, 그 SRV 갱신인RFC 8553, 그리고 현재의IANA DNS Parameters 레지스트리입니다.

이들은 문법, 순서, 행정적 경계, 규범적 진화를 확립합니다. 그러나 현재의 채택률, 절약된 지연 시간, 가중치 분포의 정확성, 소프트웨어의 규격 준수, 어떤 실제 서비스의 건강 상태도 측정하지 않습니다. 발견 레코드를 소유권, 권위, 성공적 전달의 증명으로 바꾸지도 못합니다.

SRV의 역사적 기여는 더 소박하고 더 오래 지속되었습니다. DNS 이름이 범위가 한정된 선택 집합을 실었기 때문에, 하나의 서비스는 한 호스트와 한 기본 포트보다 오래 살아남을 수 있었습니다. 그러나 클라이언트가 해석하고, 선택하고, 접속하고, 무엇이 응답했는지 검증하기 전까지는 모든 선택이 불완전한 채로 남았습니다.