DNS에서 IN NS가 CNAME을 가리킬 수 있습니까?


17

NS 레코드를 CNAME으로 사용할 수 있습니까? 예 :

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1

이것은 물론 (물론) 다음과 같이 바인딩에서 작동하지 않는 것 같습니다.

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1

이 설정을 금지하는 RFC에 대한 모든 의견을 부탁드립니다.

답변:


20

NS RR ( RFC1035 ) 을 정의하는 실제 RFC 는 대상의 RR 유형을 지정하지 않고 도메인 이름이라고 말합니다 (IP가 될 수는 없지만). 그러나 RFC1912 , 섹션 2.4 에 구체적으로 언급되어 있습니다 .

NS 레코드가 CNAME을 가리키는 것은 좋지 않으며 현재 BIND 서버와 심각하게 충돌 할 수 있습니다. 실제로, 현재의 BIND 구현은 그러한 레코드를 무시하여 불완전한 위임으로 이어질 수 있습니다. DNS NS 레코드 스푸핑을 방지하기 위해 BIND에서 일정량의 보안 검사가 수행됩니다. 또한 이전 BIND 서버는 별칭이 지정된 네임 서버의 주소를 알아 내려고 시도하면서 무한 쿼리 루프에 걸리게되어 지속적인 DNS 요청 스트림이 전송됩니다.

꼭해야 할 것은 아니지만, 현재보고있는 행동에 꼭 맞아야합니다.


5
그리고 RFC1034는 항상 기본 이름이 아닌 별명에 포인트. 강건성 원리에 의해, 물론 .... 정보에 액세스에서이 피합니다 추가 indirections을, 도메인 소프트웨어가 실패하지 말아야 할 또 다른 이름에있는 점의 RR의 도메인 이름 ", 말한다 CNAME 체인 또는 루프가 표시되면 CNAME 체인을 따라야하며 CNAME 루프가 오류로 표시됩니다. "
larsks

10
나는 RFC 2181 10.3이 그것이 유효하지 않다고 분명히 말했지만 당신의 대답은 충분했습니다.
Mark Wagner

1
명확성을 더하기 위해 : MUST NOTRFC 1912는 정보 용이며 표준을 정의하지 않기 때문에 여기에서 진실은 중요하지 않습니다. 마크는 것이 올바른 RFC 2181는 올바른 참조입니다. (RFC 1034는 언어 표준이 확정되기 전에 작성되었으므로 모호함)
Andrew B
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.