SRV 레코드

SRV record

서비스 레코드(SRV 레코드)는 도메인네임 시스템 내의 데이터 사양으로 지정된 서비스의 서버 위치(호스트 이름 및 포트 번호)를 정의합니다.RFC 2782에 정의되어 있으며 유형 코드는 33입니다.Session Initiation Protocol(SIP)이나 Extensible Messaging and Presence Protocol(XMPP) 등의 일부 인터넷 프로토콜에서는 네트워크 요소에 의한 SRV 지원이 필요한 경우가 많습니다.

레코드 형식

SRV 레코드의 형식은 다음과 같습니다.

_서비스._proto.name. ttl IN SRV priority weight 포트 타깃.
  • service: 목적의 서비스의 심볼 이름.
  • proto: 원하는 서비스의 전송 프로토콜. 보통 TCP 또는 UDP 중 하나입니다.
  • name: 이 레코드가 유효한 도메인 이름(도트로 끝남).
  • ttl: 표준 DNS 존속 가능 시간 필드.
  • IN: 표준 DNS 클래스 필드(항상 IN).
  • SRV: Type of Record(이것은 항상 SRV).
  • priority: 타겟호스트의 priority가 작을수록 우선도가 높아집니다.
  • weight : 우선순위가 같은 레코드의 상대적인 가중치는 값이 클수록 선택 가능성이 높아집니다.
  • port: 서비스가 검출되는TCP 포트 또는 UDP 포트
  • target: 서비스를 제공하는 머신의 표준 호스트 이름. 끝은 닷입니다.

존 파일에서 찾을 수 있는 텍스트 형식의 SRV 레코드의 예는 다음과 같습니다.

_cisco._context.sipserver.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com 。

이것은 다음 이름의 서버를 가리킵니다.sipserver.example.comSIP(Session Initiation Protocol) 프로토콜 서비스를 TCP 포트 5060에서 수신합니다.여기서 지정된 우선순위는 0이고 무게는 5입니다.

MX 레코드와 마찬가지로 SRV 레코드의 타깃은 주소 레코드(A 또는 AAAA 레코드)가 있는 호스트명을 가리켜야 합니다.CNAME 레코드가 있는 호스트명을 지정하는 [1]것은 유효한 설정이 아닙니다.

높은 서비스 가용성을 위한 프로비저닝

우선순위 필드는 레코드 데이터의 사용 우선순위를 결정합니다.클라이언트는 우선 가장 낮은 번호의 priority 값을 가진 SRV 레코드를 사용하고, 접속에 실패했을 경우 높은 값의 레코드로 폴백해야 합니다.서비스에 같은 priority 값을 가진 여러 SRV 레코드가 있는 경우 클라이언트는 가중치 필드의 값에 비례하여 이들 레코드를 로드밸런싱해야 합니다.다음 예제에서는 priority 필드와 weight 필드를 모두 사용하여 로드밸런싱과 백업서비스의 조합을 제공합니다. 

# _서비스_param.name.  TTL 클래스 SRV priority weight 포트 타깃_backets._backets.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com._cisco._context.smallbox1.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com._cisco._context.smallbox2.example.com. 86400 IN SRV 10 20 5060 smallbox2.example.com._backets._backets.backupbox.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.

처음 3개의 레코드는 priority 10을 공유하기 때문에 클라이언트는 무게 필드의 값을 사용하여 어떤 서버(호스트와 포트의 조합)에 접속할지를 결정합니다.세 값의 합계는 모두 100입니다.bigbox.example.com60%가 사용됩니다.두 호스트,smallbox1그리고.smallbox2전체 요청의 40%에 사용되며, 그 중 절반은 다음 주소로 전송됩니다.smallbox1, 나머지 절반은 small box2 입니다.빅박스를 사용할 수 없는 경우 나머지 2대의 머신은 각각 50%씩 선택되므로 부하를 균등하게 분담합니다.

priority 10의 3개의 서버를 모두 사용할 수 없는 경우 다음으로 priority 값이 낮은 레코드가 선택됩니다.backupbox.example.com이것은 다른 물리적인 장소에 있는 머신일 가능성이 있으며, 아마 처음 3개의 호스트를 사용할 수 없게 되는 원인이 되는 어떠한 것에 대해서도 취약하지 않을 것입니다.

SRV 레코드에 의해 제공되는 로드밸런싱은 기본적으로 정적이기 때문에 본질적으로 제한됩니다.priority(또는 중량) 값을 신속하게 갱신할 수 있을 정도로 TTL 값이 낮지 않은 한 서버의 현재 로드는 고려되지 않습니다.

사용.

SRV 레코드는 다음과 같은 표준화된 통신 [clarification needed]프로토콜과 함께 사용됩니다.

Microsoft Windows 2000에서는 클라이언트는 SRV 레코드를 쿼리하여 특정 서비스의 도메인컨트롤러를 판별합니다.SRV 레코드는 Outlook 2007, 2010 및 Macintosh 10.6 메일에서도 Exchange Autodiscover [15]서비스를 찾기 위해 사용됩니다.Microsoft Windows 네트워크 도메인 컨트롤러에서는 Active Directory의 네트워크 서비스 유형을 DNS에 등록합니다.

이전 버전의 OpenPGP 웹 키 디렉토리용 인터넷 초안에서는 SRV 레코드를 사용하여 웹 [16]서버를 통해 OpenPGP 키를 검출합니다.SRV 레코드의 사용은 이후 [17]버전에서 인터넷 드래프트의 일부가 아닙니다.

SRV 레코드 및 프로토콜의 서비스 이름 레지스트리는 RFC 6335에 [18]정의된 대로 Internet Assigned Numbers Authority(IANA; 인터넷 할당 번호 기관)에 의해 유지됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Gulbrandsen, A.; Vixie, P.; Esibov, L. (February 2000). "The format of the SRV RR". A DNS RR for specifying the location of services (DNS SRV). doi:10.17487/RFC2782. RFC 2782. Retrieved 3 December 2021. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).
  2. ^ "DNS SRV record support in apt". Debian. 4 May 2018. Archived from the original on 17 November 2019. Retrieved 17 November 2019.
  3. ^ "Looking up Monitors through DNS – Ceph Documentation". Ceph Documentation. Archived from the original on 5 December 2017. Retrieved 4 December 2017.
  4. ^ "Hostnames for the Master and Slave KDCs". Massachusetts Institute of Technology. Archived from the original on 21 October 2012. Retrieved 23 May 2012.
  5. ^ Zeilenga, K. (April 2001). OpenLDAP Root Service - An experimental LDAP referral service. IETF. doi:10.17487/RFC3088. RFC 3088. Archived from the original on 16 January 2020. Retrieved 5 July 2020.
  6. ^ Daboo, C. (March 2011). Use of SRV Records for Locating Email Submission/Access Services. IETF. doi:10.17487/RFC6186. RFC 6186. Archived from the original on 17 April 2013. Retrieved 17 April 2013.
  7. ^ "Federation API". Matrix.org. Archived from the original on 5 July 2020. Retrieved 5 January 2018.
  8. ^ "Java Edition 1.3.1". Minecraft Wiki. Archived from the original on 5 July 2020. Retrieved 5 July 2020.
  9. ^ "Add DNS SRV record support - mumble-voip/mumble". GitHub. Archived from the original on 5 July 2020. Retrieved 5 July 2020.
  10. ^ "Baraza - Userguide". Archived from the original on 22 August 2008.
  11. ^ "Puppet Docs: Scaling Puppet with compile masters, Using DNS SRV Records". Puppet Labs. Archived from the original on 11 October 2019. Retrieved 17 December 2019.
  12. ^ "[Suggestion] TS DNS". Teamspeak Forum. Archived from the original on 14 November 2016. Retrieved 25 October 2013.
  13. ^ "TeamSpeak 3 Client Version 3.0.8 Released". Teamspeak Forum. Archived from the original on 27 September 2016. Retrieved 5 July 2020.
  14. ^ "XEP-0156: Discovering Alternative XMPP Connection Methods". XMPP.org. Archived from the original on 7 May 2012. Retrieved 23 May 2012.
  15. ^ "A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service". Microsoft Support. 13 May 2010. Archived from the original on 20 April 2012. Retrieved 23 May 2012.
  16. ^ Koch, Werner. "OpenPGP Web Key Directory draft-koch-openpgp-webkey-service-06". IETF Datatracker. Internet Engineering Task Force. Retrieved 5 June 2021.
  17. ^ Koch, Werner. "OpenPGP Web Key Directory draft-koch-openpgp-webkey-service-12". IETF Datatracker. Internet Engineering Task Force. Retrieved 5 June 2021.
  18. ^ Cotton, M.; Eggert, L.; Touch, J.; Westerlund, M.; Cheshire, S. (August 2011). Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. IETF. doi:10.17487/RFC6335. RFC 6335. Archived from the original on 6 July 2020. Retrieved 6 July 2020.

외부 링크