SRV 레코드가 유용할까요?

DNS에서 SRV 레코드는 실제로 특정 서비스가 호스팅되는 위치를 원격 클라이언트에 알리는 일반적인 형식입니다. 지금은 사람들이 인터넷을 통해 SIP 클라이언트를 사용하여 전화를 걸 수 있도록 사용합니다 (매우 훌륭하게 작동합니다).

SRV 레코드의 장점 중 하나는 서비스에 대해 다른 포트를 지정할 수 있으며 동일한 시스템에 대해 여러 시스템을 가질 수 있다는 것입니다. 따라서 IFF 는 간섭없이 단일 시스템에 여러 웹 서버를 가질 수 있습니다.

그래서 당신은 당신의 DNS에 이것을 가질 수 있습니다 :

_http._tcp SRV 10 50 8080 myserver.basjes.nl
_http._tcp SRV 10 50 8081 myserver.basjes.nl

그러나이 모든 장점에 하나의 얇은 걸림돌이 있습니다 ... 나는 그것을 지원하는 HTTP, FTP, SMTP, ... 클라이언트를 찾을 수 없었습니다.

SIP 및 Wikipedia 페이지에 언급 된 몇 가지 다른 프로토콜 외에 SRV 레코드가 실제로 유용하게 사용됩니까?

아니면 내가 놓친 것이 있습니까?

작동하는 것이 더 좋은 것이 있습니까?

새로운 프로토콜 에만 사용되는 것으로 보입니다 .

SMTP가 사용하는 MX 레코드는 고정 포트가 있고 가중치가없는 SRV 레코드와 같습니다. 다시 말해, 그들은 이미 같은 문제를 적절히 해결했습니다.

예를 들어 HTTP는 현재 메커니즘과의 하위 호환성을 유지해야하므로 SRV for HTTP를 사용하기 시작한 사람은 여전히 ​​대체 메커니즘을 제공해야하며 동일한 작업을 수행하는 두 가지 방법을 유지하려는 사람은 없습니다. (예 : 일부로드 밸런서 및 일부 DNS SRV 레코드 ...) 사이트가 SRV 레코드를 게시하지 않을 경우 (불필요한 작업 만 발생하기 때문에) 클라이언트가 아무도 게시하지 않는 SRV 레코드를 지원하도록 동기를 부여하지 않습니다.

이들은 Active Directory 도메인 에서 매우 유용 합니다 .

SRV 레코드는 많은 Kerberos 지원 서비스 및 클라이언트에서도 사용 중입니다. 이것은 /etc/krb5.conf (또는 이에 상응하는)가 읽을 수 없거나없는 특정 시스템에서 특히 그렇습니다. KDC를 찾기 위해 SRV 레코드 조회가 수행됩니다.

Apple의 Bonjour 기술 (일명 zeroconf)이이를 광범위하게 사용합니다. 작동하지 않는 경우 확인하십시오. 프린터, 라우터, Bonjour 지원 웹 페이지 등을 자동으로 검색 할 수 있습니다.

멀티 캐스트 DNS를 통해 웹 사이트를 광고 할 수있는 mod_bonjour라는 BSD 라이센스 Apache 모듈이 있습니다. SRV 레코드와 일반 DNS를 통해 사이트를 광고 할 수도 있지만 Safari 만 해당 사이트를 감지 할 수 있다고 생각합니다.

Zeroconf 웹 페이지 는 그 작동 방식에 대해 꽤 잘 설명되어 있습니다. 기술에 관심이 있다면 책을 확인하는 것이 좋습니다.

일반적으로이 문제의 큰 문제 중 하나는 DNS 사용자가 자신을 서비스 검색 비즈니스에 속한다고 생각하지 않으며 편집증 보안 담당자는 서비스를 보안 위험으로 발견하는 능력을 고려한다는 것입니다.

실제로 대부분의 응용 프로그램은 아직 지원하지 않습니다.

대상 사용자 ID의 도메인 이 클라이언트 소프트웨어가 연결해야하는 호스트 이름 과 다른 경우가 일반적입니다 . 따라서 SIP 및 Jabber (XMPP)에서도 사용되는 이유입니다.

SMTP는 항상 처음부터 MX 레코드를 가지고 있기 때문에 필요하지 않습니다.

다른 포트를 사용할 수 있다는 이점은 비교적 적기 때문에 다른 프로토콜은 그다지 사용하기 시작하지 않았습니다.

URI 체계 를 제안 하는 인터넷 초안 이 http+srv:있지만 표준 http:URI 요청에 SRV 조회를 추가하려는 현재 제안은 없습니다 .

Outlook 2007 및 Exchange 2007은 SRV 레코드를 사용합니다. http://technet.microsoft.com/en-us/library/bb332063.aspx

SRV 레코드는 DNS-SD (DNS 서비스 검색)의 기본 구조 중 하나이므로 점점 더 중요해질 것입니다.

또한 네트워크에서 bonjour / zeroconf 리소스를 찾을 수있는 iStumbler for mac과 같은 네트워크 브라우저와 같은 DNS-SD 인식 클라이언트와 함께 기존 기술과 함께 사용할 수없는 이유도 없습니다.

내 생각에 SRV 레코드는 동적 업데이트 DNS가 더 많이 사용 가능해질 때만 더 일반적이 될 것입니다. MS-DNS는 Active Directory의 요구 사항으로 인해 기본적으로 동적 업데이트가 매우 많이 켜져 있습니다. 서비스 위치 프로토콜, IPX 네트워크 (Service Advertising Protocol), Bonjour / Avahi 및 DHCP를 포함하여 수년 동안 많은 리소스 광고 디렉토리가있었습니다.

이 중 DNS만이 인터넷 스패닝 리소스 디렉토리에 대한 잠재력을 가지고 있습니다. 퍼블릭 DNS 서버는 이유로 정적 인 경향이 있습니다. SRV 레코드 채택은 SPF 프로토콜에 TXT 레코드 채택과 마찬가지로 정의 된 요구가있을 때 제공됩니다. SRV를 사용하는 SIP는 더 넓은 비 -MS 채택의 문을 여는 첫 번째 단계가 될 수 있습니다.

SRV 레코드는 Windows Vista / 2008 서버를 KMS 서버로 보내 엔터프라이즈에서 활성화하는 데 사용됩니다.

XMPP가 사용하고 있습니다.

그러나 기존 프로토콜은이를 지원하도록 변경되지 않으며 특히 요청을 다른 포트로 리디렉션합니다. 그것은 예상치 못한 일이며, 의심 할 여지없이 일부 보안 관련 가정을 어기는 것입니다.

SRV 레코드는 모든 사람이 동일한 공급자를 사용할 필요없이 통신 서비스를 구현하기위한 메커니즘을 제공합니다. 즉, A 및 MX 레코드가 웹 및 전자 메일에 대해 수행하는 것, SRV 레코드는 모든 서비스에 대해 수행합니다.

이 아이디어는 블로그 게시물 "무료 주소 지정의 힘"에 요약되어 있습니다. http://e-caller.com/?p=4

트위터와 페이스 북의 부상은 SRV 지원 대안이 없기 때문입니다.

Fedora / Red Hat 프로젝트 freeipa는로드 밸런싱 및 확장 성 이유로 꼭두각시 랩 퍼펫을 사용합니다. 나는 그것의 사용 사례에 대해 더 많이 배우고 그것들이 광범위하게 사용되는 방법에 대해 더 많이 사랑합니다. 그것은 DNS와 인프라에 일어난 가장 좋은 일입니다. spotify가이를 어떻게 사용하는지 확인하십시오 https://labs.spotify.com/2013/02/25/in-praise-of-boring-technology/

DNS는 처음부터 구현할 필요가 없으며 동물원 사육사 등과 같은 것보다 훨씬 가볍기 때문에 서비스 로케이터가 필요한 응용 프로그램 스택에 매우 유용합니다. 또한 매우 안전 할 수있는 편의성이 추가되었습니다. Spotify 이외의 사람이 왜 이런 방식으로 그것을 사용하지 않는지 잘 모르겠습니다. 많은 사람들이 자신의 열악한 맞춤형 서비스 위치 소프트웨어를 사용하는 것을 보았습니다. DNS는 빠르고 안정적인 키 값 저장소이며 이미 키를 영역별로 구성합니다. 가장 큰 문제는 모든 종류의 API를 가진 DNS 서버가 거의 없기 때문에 DNS의 클라우드 구현은 RR 생성 / 업데이트 자동화가 불가능하다는 것입니다.

SRV 레코드는 IPv4 공간을 절약 할 수 있도록 호스팅 산업에 매우 중요합니다.

우리는 투명한 문제로 고객을 IPv6으로 전환하는 데 도움이됩니다.