도메인의 정점 (일명 루트)에서 CNAME 레코드를 사용할 수없는 이유는 무엇입니까?

이것은 영역의 정점 (또는 루트)에서 CNAME에 대한 정식 질문 입니다.

CNAME도메인의 정점에있는 레코드가 금기 관행 이라는 것은 일반적인 상식입니다 .

예: example.com. IN CNAME ithurts.example.net.

최상의 시나리오에서 네임 서버 소프트웨어는 구성로드를 거부 할 수 있으며 최악의 경우이 구성을 수락하고 example.com의 구성을 무효화 할 수 있습니다.

최근에 웹 호스팅 회사에서 도메인의 정점을 새 레코드로 CNAME하는 데 필요한 지침을 비즈니스 부서에 전달했습니다. 이것이 BIND에 공급 될 때 이것이 자살 구성이 될 것이라는 것을 알면서, 나는 우리가 준수 할 수 없으며 일반적으로 이단 조언이라고 조언했습니다. 웹 호스팅 회사는이 명백한 표준 정의는 RFC에 의해 금지되지 않는다는 입장을 가지고 가고 있다는 자신의 소프트웨어를 지원합니다. 우리가 에이펙스를 CNAME 할 수 없다면, 그들의 조언은 에이펙스 기록이 전혀없고 리디렉션 웹 서버를 제공하지 않는 것이 었습니다. ...뭐?

우리 대부분은 RFC1912A CNAME record is not allowed to coexist with any other data. 가 RFC가 단지 정보 제공이라는 것을 주장 하지만, 여기서 스스로 솔직하게 말해야 한다는 것을 알고 있습니다. 연습을 금지하는 ververage에 가장 가까운 것은 RFC1034입니다 .

CNAME RR이 노드에 있으면 다른 데이터가 없어야합니다. 이는 표준 이름 및 별명에 대한 데이터가 다를 수 없도록합니다.

불행히도 나는 업계에서 "하지 말아야 할 것"이 "하지 말아야 할 것"과 같지 않다는 것을 알기에 충분히 오랫동안 사용해 왔으며, 이는 대부분의 소프트웨어 설계자들이 그들과 어울릴 수있는 충분한 밧줄입니다. 슬램 덩크에 대한 간결한 링크가 부족하면 내 시간을 낭비한다는 것을 알았으므로 회사는 적절한 공개없이 일반적으로 사용되는 소프트웨어를 중단 할 수있는 구성을 권장하는 꾸짖음으로 벗어날 수있었습니다.

이것은 우리에게 Q & A를 가져옵니다. 나는 우리를 싶습니다 한번 얻기 위해 정말 정점 CNAME이의 광기에 대한 기술, 그리고 우리가 일반적 주제에 할 때 다른 사람의 게시물처럼이 문제를 해결 치마 없습니다. RFC1912 는 내가 생각하지 못한 다른 정보 용 RFC와 마찬가지로 한계를 벗어 났습니다 . 이 아기를 끄자

CNAME레코드는 원래 동일한 리소스를 제공하는 여러 이름을 해당 리소스의 단일 "정식 이름"으로 별칭을 지정할 수 있도록 만들어졌습니다. 이름 기반 가상 호스팅이 출현하면서이를 일반적인 형태의 IP 주소 앨리어싱으로 사용하는 것이 일반적이되었습니다. 불행히도, 웹 호스팅 배경에서 온 대부분의 사람들은 CNAME레코드가 DNS에서 동등성 을 나타낼 것으로 기대 합니다 . 정점에는 표준 호스트 리소스 ( , )를 식별하는 데 명확하게 사용 되지 않는 레코드 유형이 포함되어 있으며 기본 수준에서 표준을 위반하지 않으면 별칭을 지정할 수 없습니다. (특히 구역 절단 과 관련하여 )NSSOA

불행히도, 표준 DNS기구는 표준 거버넌스가 일관된 행동을 정의하기 위해 명백한 언어가 필요하다는 것을 깨닫기 전에 작성되었습니다 ( RFC 2119 ). 모호한 문구로 인해 몇 가지 모퉁이 사례를 명확하게하기 위해 RFC 2181 을 작성해야 했으며, 업데이트 된 언어 는 표준을 어 기지 않고 정점 앨리어싱을 달성하는 데 사용할 CNAME 수 없음을 명확하게합니다 .

6.1. 존 권한

영역의 권한있는 서버는 영역의 출처에 대한 NS 레코드에 열거되며, SOA (Start of Authority) 레코드와 함께 모든 영역의 필수 레코드입니다. 이러한 서버는 다른 영역에없는 영역의 모든 리소스 레코드에 대해 권한이 있습니다. 영역 컷을 나타내는 NS 레코드는 해당 자식 영역의 원점 또는 그 하위 도메인에 대한 다른 레코드와 마찬가지로 생성 된 자식 영역의 속성입니다. 영역의 서버는 다른 영역의 서버가 아닌 한 NS 및 A를 포함하여 다른 영역의 이름과 관련된 쿼리에 대한 정식 응답을 반환하지 않아야합니다.

이은을 설정 SOA하고 NS기록은 필수,하지만 그것에 대해 아무것도 말하지 않는다 A또는 여기에 나타나는 다른 유형. 내가 이것을 인용하는 것은 불필요한 것처럼 보일지 모르지만 잠시 후에 더 관련성이 높아질 것입니다.

RFC 1034 는 CNAME다른 레코드 유형과 함께 존재할 때 발생할 수있는 문제에 대해 다소 모호했습니다 . RFC 2181 은 모호성을 제거하고 그와 함께 존재할 수있는 레코드 유형을 명시 적으로 나타냅니다.

10.1. CNAME 리소스 레코드

별칭 이름과 관련된 표준 이름을 제공하기 위해 DNS CNAME ( "정식 이름") 레코드가 존재합니다. 하나의 별명에 대해 이러한 정식 이름은 하나만있을 수 있습니다. 이 이름은 일반적으로 DNS의 다른 곳에 존재하는 이름이어야하지만, DNS에 정의되지 않은 표준 이름이있는 별명에 대한 응용 프로그램은 거의 없습니다. 별칭 이름 (CNAME 레코드의 레이블)은 DNSSEC가 사용중인 경우 SIG, NXT 및 KEY RR을 가질 수 있지만 다른 데이터는 없을 수 있습니다. 즉, DNS의 레이블 (도메인 이름)에 대해 정확히 다음 중 하나에 해당합니다.

• 선택적으로 SIG, NXT 및 KEY RR과 함께 하나의 CNAME 레코드가 존재합니다.
• CNAME 레코드가 아닌 하나 이상의 레코드가 존재합니다.
• 이름이 존재하지만 모든 유형의 연관된 RR이 없습니다.
• 이름이 전혀 존재하지 않습니다.

이 문맥에서 "별칭 이름"은 CNAME레코드 의 왼쪽을 나타냅니다 . 글 머리 기호 목록은 그것이 명시 적으로 명확하게 SOA, NS그리고 A기록은이 노드에서 볼 수없는 CNAME도 나타납니다. 이를 6.1 절과 결합하면 CNAME필수 SOA및 NS기록 과 함께 살아야하므로 정점 에 a 가 존재할 수 없습니다 .

(이것은 일을하는 것처럼 보이지만 누군가가 더 짧은 증거 경로를 가지고 있다면 그것에 균열을주십시오.)

최신 정보:

가장 최근의 혼란은 Cloudflare가 최근 에 도메인의 정점에 불법 CNAME 레코드를 정의하도록 허용 한 A 레코드를 합성하기로 한 결정 에서 비롯된 것 같습니다 . 링크 된 기사에 설명 된 "RFC 호환"은 Cloudflare에 의해 합성 된 레코드가 DNS와 훌륭하게 재생된다는 사실을 나타냅니다. 이는 완전히 사용자 지정 동작이라는 사실을 변경하지는 않습니다.

내 생각에 이것은 더 큰 DNS 커뮤니티에 대한 장애입니다. 실제로 CNAME 레코드는 아니며 다른 소프트웨어가 그것을 허용하지 못한다고 믿도록 사람들을 오도합니다. (내 질문에 나와있는 것처럼)

인터넷 시스템 컨소시엄 (Internet Systems Consortium)은 최근 존 정점 에서 CNAME에 대한 글을 올렸으며 , 이러한 제한이 존재하는 이유와 여러 대안이 있습니다. 슬프게도 이것은 언제라도 곧 변하지 않을 것입니다.

전 세계의 모든 DNS 서버 구현을 동시에 변경하지 않으면 특수 CNAME 레코드 사용 방법을 변경할 수 없습니다. 그 의미와 해석이 DNS 프로토콜에 엄격하게 정의되어 있기 때문입니다. 현재의 모든 DNS 클라이언트 및 서버 구현은이 사양을 준수합니다. 현재 운영중인 모든 DNS 확인자를 동시에 변경하지 않고 권한있는 서버에서 CNAME이 사용되는 방식을 '휴식'하려고하면 이름 확인이 중단 될 수 있습니다 ( '휴식 된'정식 서버 솔루션을 구현하는 조직에서는 웹 및 전자 메일 서비스를 간헐적으로 사용할 수 없게됩니다.

그러나 희망이 있습니다.

현재 논의중인 또 다른 잠재적 솔루션은 브라우저가 조회 할 수있는 새로운 dns 리소스 레코드 유형을 추가하는 것입니다. 이것은 HTTP 요청에 대한 응용 프로그램 특정 호스트 이름입니다 (MX 작동 방식과 유사).

장점 : 이것은 DNS 디자인과 완전히 일치합니다.
단점 : 아직 사용할 수 없으며 브라우저 클라이언트 업데이트가 필요합니다.

전체 영역을 리디렉션하는 경우 DNAME을 사용해야합니다. 에 따르면 RFC 6672 ,

DNAME RR 및 CNAME RR [RFC1034]는 조회 된 도메인 이름과 다른 도메인 이름에 해당하는 데이터를 (잠재적으로) 리턴하도록합니다. 두 리소스 레코드의 차이점은 CNAME RR이 소유자의 데이터 조회를 다른 단일 이름으로 지정하는 반면 DNAME RR은 소유자 이름의 하위 항목에있는 데이터 조회를 다른 (단일) 노드 아래의 해당 이름으로 지정한다는 것입니다. 나무.

예를 들어 도메인 이름 "foo.example.com"에 대한 영역 (RFC 1034 [RFC1034], 4.3.2, 3 단계 참조)을 살펴보고 "example.com"에 DNAME 리소스 레코드가 있습니다. "example.com"아래의 모든 쿼리는 "example.net"으로 연결됩니다. 조회 프로세스는 "foo.example.net"이라는 새 쿼리 이름으로 1 단계로 돌아갑니다. 쿼리 이름이 "www.foo.example.com"인 경우 새 쿼리 이름은 "www.foo.example.net"입니다.