왜 TXT 와 CNAME 음반은 같은 호스트의 같은 줄에 공존할 수 없습니까?

따라서 TXT 와 CNAME 이 모두 존재할 때 조회된 첫 번째 레코드가 CNAME 이면 해당 TXT 레코드는 조회할 수 없습니다.

이것은 다음과 같이 표준화되어 있습니다.

CNAME 레코드는 DNS 의 특수 레코드 유형이며 일반적으로 "별칭" 레코드로 해석됩니다. 그것의 특별한 점은 아래의 예에 있다. 다음 두 개의 레코드가 DNS 도메인 demo.only 에 등록되어 있다고 가정합니다.

다음은 반복 서버 (해당 도메인의 권한 서버를 사용할 수 없음) 에 대한 dig 쿼리 결과입니다 (중요하지 않은 일부 정보는 생략됨).

MX 레코드 쿼리의 결과는 CNAME 레코드 값으로 구성된 MX 레코드임을 알 수 있습니다. 그러나 반복 서버의 CNAME 레코드 TTL 이 만료된 후 쿼리하고 쿼리 순서가 반대인 경우 (즉, MX 레코드를 먼저 쿼리한 다음 CNAME 레코드를 쿼리함) 정확한 결과를 얻을 수 있습니다.

위의 테스트 과정에서 권한 부여 서버와 재귀 서버는 모두 유명한 DNS 서비스 공급업체로, 사용자가 많기 때문에 프로그램의 버그 발생 가능성을 무시할 수 있습니다. 그렇다면 이 현상을 어떻게 설명할 수 있을까요?

권위 있는 설명은 관련 RFC 설명서를 참조하십시오. 원문 부분의 발췌문은 다음과 같다.

중국어는 다음과 같이 설명됩니다.

재귀적 DNS 서버가 일반 도메인 이름 레코드 (CNAME 레코드 아님) 를 쿼리할 때 해당 도메인 이름에 로컬 캐시에 해당 CNAME 레코드가 있으면 별칭 레코드로 쿼리를 다시 시작합니다. Dig 가 처음으로 MX 레코드를 조회한 것이 바로 이런 상황이다. 라이센스 서버에서 직접 조회하면 항상 원하는 결과를 얻을 수 있습니다. 아니면 단순히 CNAME 이 더 높은 우선 순위를 가지고 있다는 것을 이해할 수 있습니다.

CNAME 유형의 도메인 이름 레코드와 (MX, a, NS 등) 등의 다른 유형의 레코드가 이미 등록되어 있습니다. ), DNSSEC 관련 제외.

이 문서의 시작 부분에 dig 가 MX 레코드를 쿼리할 때 원하는 결과를 얻지 못하는 이유입니다. 사용자의 관점에서, 기록 된 구성에서 CNAME (특히 @ record, MX 를 사용할 가능성이 높기 때문에) 을 사용하는 경우 도메인 이름이 MX 와 같은 다른 레코드와 함께 구성 될 수 없다는 것을 알아야합니다. DNS 서비스 공급업체의 관점에서 사용자에게 이 구성의 위험을 알리고 사용자에게 경고와 교육을 제공할 필요가 있습니다.