Computer >> 컴퓨터 >  >> 네트워킹 >> 인터넷

도메인의 루트가 CNAME이 될 수 없는 이유 및 DNS에 대한 기타 정보

이 게시물은 위의 질문을 사용하여 DNS을 탐색합니다. , dig , A 레코드, CNAME 레코드 및 ALIAS/ANAME 초심자의 관점에서 기록. 시작하겠습니다.

첫 번째, 몇 가지 정의

  • 도메인 이름 시스템 (DNS):사람이 기억할 수 있는 도메인 이름(example.com)을 IP 주소(93.184.216.34)로 변환하기 위한 전체 시스템. IP 주소는 웹페이지를 표시하는 데 필요한 파일이 저장되는 서버(일반적으로 웹 서버)의 주소입니다.
  • DNS 서버 (이름 서버 또는 이름 서버라고도 함):DNS 소프트웨어를 사용하여 도메인 주소에 대한 정보를 저장합니다. 각 ISP, 루트(전 세계적으로 총 13개), 최상위 도메인(TLD, 예:'.com') 및 도메인 수준 DNS 서버에 속하는 여러 수준이 있습니다.
  • 도메인 이름 :TLD(.com)와 결합된 도메인(예시). '도메인'이라는 용어는 도메인 이름과 동의어로 사용되는 경우가 많지만 서로 다릅니다. 레지스트라 또는 리셀러로부터 '도메인'을 구입하면 특정 도메인 이름(example.com)과 생성하려는 하위 도메인(my-site.example.com, mail.example.com, 등).

고수준 쿼리 흐름

브라우저에 "example.com"을 입력할 때 발생하는 작업의 상위 수준 흐름은 아래와 같이 ISP, 루트 및 TLD DNS 서버에 대한 홉을 제거하도록 단순화할 수 있습니다.

도메인의 루트가 CNAME이 될 수 없는 이유 및 DNS에 대한 기타 정보
간단한 DNS 요청 흐름, 더 자세한 흐름에서 더 많은 것을 볼 수 있음

도메인에는 일반적으로 도메인 이름(example.com)과 관련된 레코드가 포함된 두 개 이상의 이름 서버가 있습니다.

많은 유형의 레코드를 저장할 수 있으며 대부분은 유형당 여러 항목을 가질 수 있습니다.

  • A :도메인 이름을 IP 주소에 매핑하는 주소 레코드
  • CNAME :정식 이름 레코드. 한 도메인 이름(또는 하위 도메인 이름)을 다른 도메인 이름으로 별칭하는 데 사용됩니다. 이에 대해서는 나중에 자세히 살펴보겠습니다.
  • MX :이메일 전달 담당자에게 이메일을 전달해야 하는 위치를 알려주는 Mail eXchange 기록
  • TXT :다양한 용도로 문자열을 저장하기 위한 유연한 텍스트 레코드
  • SOA :단일 권한 시작 레코드는 도메인의 최상위 수준에 보관됩니다. 도메인에 대한 특정 필수 정보(예:기본 이름 서버) 포함
  • NS :도메인과 연결된 네임서버

장치가 이름 서버에 도달하는 쿼리를 보내면 서버는 도메인의 레코드 노드에서 A를 찾습니다. 레코드 및 연결된 저장된 IP 주소(example.com:93.184.216.34). 그런 다음 요청한 웹 페이지 또는 리소스를 검색하기 위해 올바른 웹 서버에 요청을 보내는 데 사용하기 위해 기기로 반환됩니다.

'파기' 사용

dig (도메인 정보 검색기 )은 DNS 서버를 쿼리하기 위한 명령줄 도구입니다. 이 명령은 일반적으로 문제 해결에 사용되거나 현재 시스템 설정에 대해 더 많이 이해하기 위해 사용됩니다.

$ dig example.com 결과적으로 터미널에 긴 응답이 인쇄됩니다. 기본 출력은 여기에 자세히 설명되어 있습니다. 이 중 ANSWER SECTION에 관심이 있습니다. .

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

이제 example.com A 반환 93.184.216.34 레코드 . 때때로 도메인에는 둘 이상의 A이 있습니다. 둘 이상의 웹 서버가 필요한 정보를 제공할 수 있는 경우 기록하십시오.

더있다! 다른 예를 시도하면 곧 또 다른 공통 레코드가 나타나는 것을 볼 수 있습니다. CNAME .

$ dig www.skyscanner.net :

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

+short 사용 플래그를 사용하면 형성된 경로를 명확하게 볼 수 있습니다.

$ dig www.skyscanner.net +short 

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

CNAME 레코드를 사용하면 도메인 이름을 다른 정식(실제) 도메인의 별칭으로 사용할 수 있습니다.

DNS 서버가 CNAME을 반환할 때 기록하지 않으면 클라이언트에게 반환하지 않습니다. 오히려 반환된 도메인 이름을 다시 조회한 다음 A를 반환합니다. 레코드의 IP 주소. 이 체인은 많은 CNAME를 계속할 수 있습니다. 수준이 낮지만 캐싱이 발생하기 전에 여러 조회로 인해 약간의 성능 저하가 발생합니다.

이에 대한 간단한 예는 모든 사진을 보관하는 서버가 있는 경우일 수 있습니다. 일반적으로 photos.example.com를 통해 액세스할 수 있습니다. . 그러나 photographs.example.com을 통한 액세스를 허용할 수도 있습니다. . 이를 가능하게 하는 한 가지 방법은 CNAME를 추가하는 것입니다. photographs을 가리키는 기록 photos로 . 즉, 누군가가 photographs.example.com을 방문하면 photos.example.com과 동일한 콘텐츠가 제공됩니다. .

$ dig photographs.example.com 쿼리 사용 우리는 다음을 보게 될 것입니다:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

CNAME 오른쪽에 있는 부분입니다. 왼쪽은 별칭 이름 또는 레이블입니다.

또 다른 일반적인 용도는 www입니다. 하위 도메인. example.com 구매 www.example.com를 입력하는 사용자도 원할 것입니다. 같은 콘텐츠를 보려면.

여기서 example.com 정점, 루트 또는 네이키드 도메인 이름이라고 할 수 있습니다.

한 가지 옵션은 다른 A를 설정하는 것입니다. example.com과 동일한 IP 주소를 가리키는 레코드 . 이것은 완전히 유효하며 실제 example.com 하지만 잘 확장되지 않습니다. example.com IP 주소를 업데이트해야 하는 경우 어떻게 됩니까? 를 가리키다? www에 대해서도 업데이트해야 합니다. 하위 도메인 및 기타 귀하가 사용할 수 있습니다.

CNAME인 경우 레코드가 별칭 www.example.com에 사용되었습니다. example.com을 가리키기 위해 다른 모든 노드가 이를 가리키므로 루트 도메인만 업데이트하면 됩니다.

CNAME 제한 사항

DNS 표준이 작성될 당시에는 DNS 표준의 사용을 통제하기 위한 몇 가지 규칙이 설정되었습니다. RFC 1912 및 RFC 2181은 다음과 같이 설정합니다.

  • SOA 및 NS 레코드는 루트 도메인에 있어야 합니다.
  • CNAME 레코드는 단일 레코드로만 존재할 수 있으며 다른 리소스 레코드와 결합할 수 없습니다( DNSSEC SIG , NXT 및 KEY RR 레코드 제외)

CNAME는 제외됩니다. 두 규칙이 서로 모순되기 때문에 루트 도메인에서 사용됩니다.

여기서 중요한 것은 이것이 기술적인 제한이 아니라 계약상의 제한이라는 것입니다. CNAME를 사용할 수 있습니다. 그러나 예상되는 동작 계약을 위반하므로 예기치 않은 오류가 발생할 수 있습니다.

Cloudflare는 CNAME을 사용한 후 Microsoft Exchange 메일 서버에서 발생한 문제에 대해 설명합니다. 루트 도메인:

도메인은 일반적으로 MX 레코드라고 하는 것을 통해 이메일을 처리하는 서버를 지정합니다. 문제는 Exchange 서버가 ... 루트 레코드에서 CNAME을 선택한 다음 MX 레코드에 설정된 CNAME을 적절하게 존중하지 않을 수 있다는 것입니다. 당신은 정말로 Exchange를 비난할 수 없습니다. DNS 사양에 명시된 가정 하에 운영되고 있었습니다.

여기에서 여러 서버 소프트웨어 또는 라이브러리에 나타날 수 있는 단점을 볼 수 있습니다. CNAME에 대한 표준이 있기 때문에 유일한 노드에 레코드가 없으면 다른 레코드가 검색되지 않습니다. 다른 모든 레코드는 경고나 오류 메시지 없이 자동으로 무시됩니다. MX 레코드가 이메일을 수신하도록 설정되었습니다. MX CNAME 때문에 존재하지 않는 것처럼 무시됩니다. 먼저 평가됩니다. A가 있는 경우에도 마찬가지입니다. 레코드:CNAME 우선적으로 적용되며 A 레코드를 읽을 수 없습니다.

현대 인터넷

왜 이것이 문제입니까? 왜 CNAME을 사용하고 싶습니까? 어쨌든 루트 도메인에 대해? 귀하의 콘텐츠를 호스팅하는 웹 서버의 IP 주소를 찾을 때 경로의 끝이 확실합니까?

현대 인터넷 환경에서는 더 이상 그렇지 않습니다. DNS 표준이 작성되었을 때와는 세상이 많이 다릅니다.

Heroku와 같은 PaaS(Platform as a Service) 공급자를 사용하고 웹 서버에 콘텐츠를 저장하도록 선택할 수 있습니다. 콘텐츠는 제어하지만 인프라는 제어하지 않으며 PaaS 공급자가 네트워크 유지 관리의 무거운 작업을 수행합니다. 일반적으로 URL(my-app.herokuapp.com ) 해당 루트 도메인의 하위 도메인이며 콘텐츠가 있는 웹 서버의 IP 주소를 볼 수 있습니다. 그러나 이는 전적으로 PaaS 제공업체의 통제 하에 있으며 경고 없이 변경될 것입니다.

PaaS 제공업체가 수행한 백엔드 변경의 규모와 빈도로 인해 루트 도메인 A을 유지 관리하기 어려울 수 있습니다. 단일 IP 주소를 가리키는 레코드. 이상적으로는 다음과 같이 하는 것이 좋습니다.

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

Heroku(또는 선택한 호스트 공급자)가 A 업데이트를 관리하도록 허용 CNAME 변경 사항 없이 를 가리킵니다. 그러나 우리가 지금 알고 있듯이 이것은 DNS 사양을 위반하므로 매우 나쁜 생각입니다.

example.com에서 301/302 리디렉션을 간단히 구현할 수 있습니다. www.example.com.으로 그러나 그 명령은 웹 서버에서 발생합니다(그래서 여전히 고정된 A을 사용해야 하는 문제가 있습니다. 해당 웹 서버를 가리키도록 DNS에 기록) 또는 사용자 지정 DNS 공급자 리디렉션(HTTPS와 복잡함을 겪음).

이것은 또한 원하지 않을 수도 있는 URL 표시줄에 표시되는 도메인을 변경하는 부작용이 있습니다. 이 방법은 확장 가능한 방식으로 복잡하게 변화하는 백엔드를 가리키는 문제를 해결하기보다는 웹사이트가 영구적으로 이동했거나 SEO 순위를 유지하려는 경우에 사용됩니다.

솔루션

다음을 포함하여 여러 DNS 제공업체에서 이 문제를 해결하기 위한 맞춤형 솔루션을 개발했습니다.

  • ALIAS DNSimpl에서
  • ANAME DNS Made Easy에서
  • ANAME easyDNS에서
  • CNAME (가상) CloudFlare

다음은 CNAME을 제공하는 모든 가상 레코드 유형입니다. 행동처럼 단점이 없습니다. 정확한 구현은 다를 수 있지만 상위 수준에서 DNS 서버는 이러한 가상 레코드 유형 중 하나를 볼 때 DNS 확인자 역할을 합니다. A에서 해결될 때까지 별칭에 의해 생성된 체인을 따릅니다. 기록(또는 기록)하고 이러한 A를 반환합니다. DNS 서버에 기록합니다. 이것은 CNAME를 '평탄화'합니다. A에 연결 레코드가 반환되고 전송된 쿼리와 구별할 수 없습니다. 쿼리는 순수한 A만 봅니다. DNS 사양을 위반하지 않고 CNAME의 단점이 없는 레코드 .

이러한 가상 레코드는 의도하지 않은 동작에 대한 두려움 없이 루트에서 다른 레코드와 나란히 위치할 수 있습니다. CNAME를 따를 때 공급자의 DNS 확인 방법에 따라 다름 체인에서 이전 조회를 캐싱하여 성능상의 이점을 얻을 수도 있습니다.

DNSimple 설정의 경우 아래와 같이 구성합니다. 이 솔루션에는 도메인 이름 별칭의 모든 장점이 있으며 루트 수준에서 사용할 위험이 없습니다.

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

읽어 주셔서 감사합니다! ?

항상 그렇듯이 수정 사항이나 추가 사항이 있을 수 있습니다.

자원

  • DNS 서버란
  • DNS 이름 서버 설정
  • DNSimple 지원 페이지 및 ALIAS 블로그
  • Cloudflare 지원 및 CNAME 블로그
  • dig 방법
  • 몇 가지 훌륭한 스택 오버플로 또는 StackExchange 게시물
  • 잘 쓰여진 Wikipedia 항목
  • Netlify 블로그 'www로 또는 www가 아님'