여러 개의 CNAME이 있음

11

역사적 이유로 5 단계 CNAME의 DNS 도메인이 있습니다. 일부는 고 가용성 등으로 아웃소싱되었지만 여기서는 그렇지 않습니다. 내 질문에 5 개의 CNAME이 DNS 확인자에게 과잉 행동을하고 있습니까? 다른 DNS 도메인을 가리키는 2-3 개 이상의 중첩 된 CNAME이있는 유명한 웹 사이트를 찾을 수 없었습니다.

CNAME 홉은 다음과 같습니다. (예를 들어 xyz를 사용하고 있습니다)

www.xyz.com-> xyz.akadns.net-> xyz.worldwide.akadns.net-> xyz.cedexis.net-> xyz.msedge.net-> host1.msedge.net (최종 A \ AAAA 레코드)

http://check-host.net/check-dns?host=www.xyz.com 을 사용 하여 DNS를 테스트 할 때 다른 사이트에서 제대로 작동 할 때 많은 클라이언트가 웹 사이트에 대한 DNS 확인 문제에 대해 불평하는 것을보고 있습니다 . 해결.

항상 세계적으로 잘 작동하는 것 같습니다. 내 결론은 위의 홉 중 하나가 해결되지 않으면 로컬 ISP 제공 업체 DNS 확인자가 망친다는 것입니다. 이 클라이언트 컴퓨터에서는 nslookup이 웹 사이트에 대해서만 실패하고 너무 산발적으로 발생합니다.

이런 종류의 멀티 레벨 CNAME은 일반적으로 나쁜 디자인입니까?

domain-name-system cname-record

— 비샬 나이 두
소스

1

몇 년 전에 Akamai에서 근무했으며 고객 중 한 명이 특정 라우터에 5 단계의 중첩 문제가 있다고보고했습니다. 라우터 펌웨어가 결국 수정되었다고 생각합니다.

— Barmar

15

이런 종류의 멀티 레벨 CNAME은 일반적으로 나쁜 디자인입니까?

CNAME 대 CNAME 체인은 금지되지 않지만 이미 경험했듯이 매우 강력한 솔루션은 아닙니다.

각 추가 CNAME은 리졸버의 재귀 깊이를 증가 시키며 해당 깊이가 항상 무제한 인 것은 아닙니다. 또한 루프를 만들거나 루프 감지 알고리즘을 트리거 할 위험이 있습니다.

사용자 이름 서버가 몇 개의 쿼리를 수행해야하는지에 대한 인상을 얻으려면 DNS 추적을 실행하십시오.

dig +trace www.example.com

또는 Windows

nslookup -debug www.example.com

— HBruijn
소스

11

HBrujin은 정확하지만 사실 재귀 깊이는 무엇이든 dig +trace보여줄 것 보다 훨씬 나쁩니다 . 재귀 깊이는 종종 재채기되고 지나치게 사소한 것이지만, 그 사람들은 당신이 ~ 5 CNAME레코드를 해결하는 것이 아니라는 것을 잊어 버립니다 . CNAME레코드 의 대상을 해결하면 경로에서 모든 네임 서버 를 찾아야 할 필요가 생겨나 기 때문에 종종 언뜻보기에는 많은 것입니다.

않는 CNAME대상은 다른 도메인에 살고? NS레코드 조회뿐만 아니라 A(AAA)글루가없는 조회 도 필요로하는 네임 서버로 재귀를 돌려야합니다 . 에 대한 네임 서버 마십시오 그 네임 서버는 다른 최상위 도메인에 살고? 이러한 TLD가 네임 서버를 공유하지 않는 경우, 글루 레코드가 포함되지 않을 가능성이 있으며 다른 TLD의 네임 서버를 통해서도 재귀해야합니다. 등등.

CNAME체인에 추가 된 모든 레코드는 재귀해야하는 네임 서버 수에 따라 필요한 조회 수를 기하 급수적으로 추가 할 수 있습니다. 이러한 CNAME+ NS+ A(AAA)레코드 조회 체인은 혼란스러운 캐시에서 150 레벨 이상의 깊이에 도달 할 수 있습니다. 여기에서 재귀 수준 제한이 매우 불쾌 해져 빈 캐시에서 도메인을 일시적으로 조회하지 못하는 경우가 많으며 종종 눈에 띄지 않는 경우가 있습니다.

요컨대,이 작업을 수행 할 수 있지만주의해서 진행하고이 특성에 대한 피드백을 진지하게 받아들입니다. 인터넷에서 재귀 DNS 서버가 얼마나 자주 다시 시작 또는 제거되는지 제어 할 수 없습니다.

— 앤드류 B
소스

내 클라이언트 소프트웨어는 원격 http 호출을 수행하는 여러 시스템에 있습니다. 그런 다음 클라이언트에서 모든 CNAME을 재 시도하여 리졸버의 재귀 수준을 줄이십시오. 이 방법이 좋습니까? 아니면 뭔가 빠졌습니까? CNAME은 지역에 따라 변경되지 않습니다.

— Vishal Naidu

좋은 접근 방식이 아닙니다. 일반적으로 데이터를 찾지 못한 서버는 일시적으로 장애를 캐시합니다. 쿼리는 나중에 다시 성공할 수 있지만 (즉, 5 분 후) 즉시 재 시도 할 수 없습니다. DNS 레코드 이름을 제공하면 이것이 실제로 재귀 수준 문제인지 또는 덜 분명한지 알려줄 수 있습니다. 나는 우리가 잘못된 토끼 구멍을 내려가는 것을 싫어합니다.

— 앤드류 B

0

다단계 CNAME는 종종 실제로 편리합니다. 각 수준의 리디렉션은 잠재적으로 다른 관리 영역 또는 완전히 다른 조직에서 수준의 제어를 제공합니다. 이것은 거의 모든하지만 기술적으로 필요한 그것을 해결할 수있는 조직의 문제.

다른 사람들이 지적했듯이 이것은 어려움을 유발할 수 있지만 다음과 같이 해결할 수 있습니다.

모든 DNS 서버를 모니터링 하십시오. 아마도 하나가 오작동하고있을 것입니다. 외부 서버와 자체 서버를 모니터링하십시오. Akamai 또는 다른 공급 업체에 문제를보고해야 할 수도 있습니다.
TTL들 캐싱 그러나 당신이 당신의 응용 프로그램에 대해 충분히 빨리 트래픽을 전환 할 수 있음을 충분히 낮은 수 있도록하기 위해 충분히 높은 설정해야

— 병아리
소스

2

모니터링 권장 사항을 이해하지 못했습니다. 재귀 깊이 제한은 제품마다 다양 할뿐만 아니라 모니터링을 어떻게 제안합니까? 다른 사람의 재귀 인프라에 대한 근본 원인을 쉽게 식별 할 수 없습니다.

— Andrew B