RFC 2782를 위반하여 CNAME 별칭을 가리키는 SRV 레코드가 게시 되었습니까?

몇 가지 업무를 수행하면서 SRV 레코드를 정리해야하며, Wikipedia 선언을 DNS 발굴에서보고있는 내용과 조정하려고합니다.

SRV 레코드의 대상은 주소 레코드 (A 또는 AAAA 레코드)가있는 호스트 이름을 가리켜 야합니다. CNAME 레코드가있는 호스트 이름을 가리키는 것은 올바른 구성이 아닙니다.

그러나 digCNAME 레코드의 별칭 인 이름을 가리키는 SRV 레코드를 반환하는 레코드가 있습니다.

즉, 다음과 같은 것입니다.

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

SRV 레코드는 Wikipedia 항목이 허용되지 않는 방식과 정확히 일치하는 것으로 보입니다. 내가 무엇을 오해하고 있습니까? SRV 레코드가 주소 레코드가 아닌 CNAME 레코드가있는 alias.domain.com을 가리키는 것으로 표시되지 않습니까?

domain-name-system cname-record srv-record

— 스캇
소스

내 회사에서 우리는 SRV가 많이 기록 사용하고, 대부분은 CNAME이를 사용하고 그렇게 규칙 위반, 벌금을 작동 여부, 그것은 :) 잘 작동

— olivierg

답변:

인용 한 Wikipedia 기사는 SRV 레코드에 대한 관련 RFC 2782의 상태를보고합니다.

표적

대상 호스트의 도메인 이름 이 이름에는 하나 이상의 주소 레코드가 있어야하며, 이름은 별칭이 아니어야합니다 (RFC 1034 또는 RFC 2181의 의미).

당신이보고있는 것은 규칙을 분명히 위반하는 것입니다. 그러나, 그것은 수있는 일을 (그리고 일반적으로 어떤 클라이언트 응용하면 해당 SRV 레코드를 찾고 있습니다 경우에만 응답 A 레코드를 기대한다하더라도, 제대로 CNAME 레코드를 처리 할 수있는 스마트 충분히이며, 않습니다).

그러나 전혀 작동 하지 않을 수도 있습니다 . 지원되지 않으며 클라이언트 응용 프로그램에 전적으로 의존합니다. 따라서 적절한 규칙을 따르지 않고 잘못되거나 예측할 수없는 결과를 초래할 수 있으므로 피해야합니다.

이것은 MX 레코드를 CNAME으로 지정하는 것과 유사합니다. CNAME은 하나 뿐 아니라 두 개의 RFC 에서 잘못 정의 되었지만 여전히 일반적인 관행입니다 (메일 서버에는 문제가없는 것 같습니다).

— 마시모
소스

"충분히 똑똑하다"는 것이 상대적이라는 것을 명심하십시오. 일부 소프트웨어 설계자들은 braindead 구현을 채택하면 더 많은 구현을 장려 할뿐입니다. RFC 2781은 단일 RFC에 의해서만 업데이트되었으며 기대할 사항에 대한 언어는 매우 견고하므로 자비를 기대하지 않습니다.

— 앤드류 B

대부분의 클라이언트 응용 프로그램은 시스템 라이브러리를 사용하여 DNS 쿼리를 수행하며 대부분의 라이브러리 (특히 고급 언어)는 사용자가 던지는 모든 쿼리를 해결하기 위해 최선을 다할 것이며 CNAME을 대상 A 레코드로 행복하고 자동으로 따릅니다. IP 주소.

— Massimo

응용 프로그램은 많은 지능이 필요하지 않습니다. OS가 포트 4443의 "alias.domain.com"에 연결하고 모든 세부 정보를 남기도록 OS에 요청합니다.

— Massimo

업스트림 재귀자가 신뢰할 수있는 데이터를 거부하고 계속하지 않으면 클라이언트 응용 프로그램 및 시스템 라이브러리는 별칭을 따를 기회가 없습니다. BIND의 NS레코드 처리 및 금지 된 앨리어싱은 이에 대한 전형적인 예입니다. 어쨌든, 우리는 예측 불가능한 결과를 가진 사람의 게임이라는 데 동의합니다.

— Andrew B

일부 메일 서버는 CMX에 대한

— Marcel Waldvogel

이것이 제한된 행동의 예입니다. 제한 자체는 "target"의 정의 에서 RFC 2781 에서 비롯됩니다 .

   Target
        The domain name of the target host.  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).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

금지 된 구성을 허용하는 DNS 서버 소프트웨어는 불행히도 새로운 것이 아닙니다. 별명을 가진 대상이 금지 된 다른 레코드 유형 (예 : NS및) 과 마찬가지로 발생할 수 있습니다 MX. (위에 언급했듯이)

그것이 야생에서 발견된다고해서 그것이 "괜찮다"는 것을 의미하지는 않으며, 표준이 무시 될 때 발생하는 일은 제품마다 다릅니다. SRV레코드 와의 상호 작용을 테스트 하지는 않았지만 NS별칭을 가리키는 레코드 와 관련하여 ISC BIND의 매우 잘 알려진 디자인 결정 은 재귀 중에 발견되면 레코드를 완전히 삭제하는 것 입니다. 모든 NS레코드가이 방식으로 삭제 되면 모든 쿼리 결과는 SERVFAIL해당 하위 도메인에 대한 결과입니다 .

요컨대, 표준을 고수하십시오. 유일하게 안전한 일입니다.

— 앤드류 B
소스