웹사이트 검색

DNS 용어, 구성 요소 및 개념 소개


소개

DNS 또는 도메인 이름 시스템은 종종 웹 사이트 및 서버 구성 방법을 배우는 데 있어 매우 어려운 부분입니다. DNS 작동 방식을 이해하면 웹 사이트에 대한 액세스 구성 문제를 진단하는 데 도움이 되며 배후에서 진행되는 작업에 대한 이해를 넓힐 수 있습니다.

이 가이드에서는 DNS 구성을 시작하는 데 도움이 되는 몇 가지 기본 DNS 개념에 대해 설명합니다. 이 가이드를 다루고 나면 고유한 DNS 서버를 설정할 준비가 된 것입니다.

도메인을 확인하기 위해 자체 서버를 설정하거나 제어판에서 도메인을 설정하기 전에 이 모든 것이 실제로 어떻게 작동하는지에 대한 몇 가지 기본 개념을 살펴보겠습니다.

도메인 용어

용어를 정의하는 것부터 시작해야 합니다. 이러한 주제 중 일부는 다른 맥락에서 친숙하지만 컴퓨팅의 다른 영역에서 너무 자주 사용되지 않는 도메인 이름 및 DNS에 대해 이야기할 때 사용되는 용어가 많이 있습니다.

쉽게 시작해 봅시다:

도메인 명 시스템

더 일반적으로 "DNS\로 알려진 도메인 이름 시스템은 사람에게 친숙한 이름을 고유한 IP 주소로 확인할 수 있는 네트워킹 시스템입니다.

도메인 이름

도메인 이름은 우리가 인터넷 리소스와 연결하는 데 익숙한 인간 친화적인 이름입니다. 예를 들어 "google.com\은 도메인 이름입니다. 어떤 사람들은 "google\ 부분이 도메인이라고 말하지만 일반적으로 결합된 형태를 도메인 이름이라고 할 수 있습니다.

URL "google.com”은 Google Inc. 소유의 서버와 연결되어 있습니다. 도메인 이름 시스템을 사용하면 "google.com을 입력할 때 Google 서버에 연결할 수 있습니다. >”를 브라우저에 입력합니다.

IP 주소

IP 주소는 네트워크 주소 지정 가능 위치라고 합니다. 각 IP 주소는 해당 네트워크 내에서 고유해야 합니다. 웹사이트에 대해 이야기할 때 이 네트워크는 전체 인터넷입니다.

가장 일반적인 형태의 주소인 IPv4는 4개의 숫자 집합으로 작성되며 각 집합은 최대 3개의 숫자로 이루어지며 각 집합은 점으로 구분됩니다. 예를 들어 "111.222.111.222\는 유효한 IPv4 IP 주소일 수 있습니다. DNS를 사용하면 각 위치에 대한 복잡한 숫자 집합을 기억할 필요가 없도록 해당 주소에 이름을 매핑합니다. 네트워크에서 방문하고 싶습니다.

최상위 도메인

최상위 도메인(TLD)은 도메인의 가장 일반적인 부분입니다. 최상위 도메인은 오른쪽에서 가장 먼 부분입니다(점으로 구분됨). 일반적인 최상위 도메인은 \com, \net, \org, \gov, \edu 및 \io입니다.

최상위 도메인은 도메인 이름 측면에서 계층 구조의 최상위에 있습니다. 특정 당사자는 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 최상위 도메인에 대한 관리 권한을 부여받습니다. 그런 다음 이러한 당사자는 일반적으로 도메인 등록 기관을 통해 TLD에 따라 도메인 이름을 배포할 수 있습니다.

호스트

도메인 내에서 도메인 소유자는 도메인을 통해 액세스할 수 있는 별도의 컴퓨터 또는 서비스를 나타내는 개별 호스트를 정의할 수 있습니다. 예를 들어 대부분의 도메인 소유자는 베어 도메인(example.com)과 "호스트\ 정의 "www\(www.example.comwww.example.com).

일반 도메인 아래에 다른 호스트 정의가 있을 수 있습니다. "api\ 호스트(api.example.com)를 통해 API에 액세스하거나 "ftp\ 또는 "files\( ftp.example.com 또는 files.example.com) 호스트 이름은 도메인에 고유한 경우 임의로 지정할 수 있습니다.

하위 도메인

호스트와 관련된 주체는 하위 도메인입니다.

DNS는 계층 구조로 작동합니다. TLD는 그 아래에 많은 도메인을 가질 수 있습니다. 예를 들어 "com\ TLD에는 "google.com\ 및 "ubuntu.com\이 모두 있습니다. "하위 도메인\은 모든 도메인을 나타냅니다. 그것은 더 큰 도메인의 일부입니다. 이 경우 "ubuntu.com\은 "com\의 하위 도메인이라고 할 수 있습니다. 일반적으로 이를 도메인이라고 부르거나 "ubuntu\ 부분을 SLD라고 부르며 이는 2단계 도메인을 의미합니다.

마찬가지로 각 도메인은 그 아래에 있는 "하위 도메인\을 제어할 수 있습니다. 이것은 일반적으로 하위 도메인을 의미합니다. 예를 들어 "www.history.school에서 학교의 역사 부서에 대한 하위 도메인을 가질 수 있습니다. .edu”. "기록\ 부분은 하위 도메인입니다.

호스트 이름과 하위 도메인의 차이점은 호스트는 컴퓨터 또는 리소스를 정의하는 반면 하위 도메인은 상위 도메인을 확장한다는 것입니다. 도메인 자체를 세분화하는 방법입니다.

하위 도메인에 대해 이야기하든 호스트에 대해 이야기하든 도메인의 가장 왼쪽 부분이 가장 구체적이라는 것을 알 수 있습니다. 이것이 DNS가 작동하는 방식입니다. 왼쪽에서 오른쪽으로 읽을 때 가장 구체적인 것부터 가장 덜 구체적인 것까지입니다.

정규화된 도메인 이름

종종 FQDN이라고 하는 정규화된 도메인 이름은 우리가 절대 도메인 이름이라고 부르는 것입니다. DNS 시스템의 도메인은 서로 상대적으로 지정될 수 있으므로 다소 모호할 수 있습니다. FQDN은 도메인 이름 시스템의 절대 루트와 관련된 위치를 지정하는 절대 이름입니다.

즉, TLD를 포함하여 각 상위 도메인을 지정합니다. 적절한 FQDN은 DNS 계층 구조의 루트를 나타내는 점으로 끝납니다. FQDN의 예는 "mail.google.com.”입니다. 경우에 따라 FQDN을 호출하는 소프트웨어에는 종료 점이 필요하지 않지만 ICANN 표준을 준수하려면 후행 점이 필요합니다.

이름 서버

이름 서버는 도메인 이름을 IP 주소로 변환하도록 지정된 컴퓨터입니다. 이러한 서버는 DNS 시스템에서 대부분의 작업을 수행합니다. 총 도메인 변환 수가 한 서버에 너무 많기 때문에 각 서버는 요청을 다른 이름 서버로 리디렉션하거나 담당하는 하위 도메인 하위 집합에 대한 책임을 위임할 수 있습니다.

이름 서버는 "권한\이 있을 수 있습니다. 즉, 제어할 수 있는 도메인에 대한 쿼리에 대한 답변을 제공합니다. 그렇지 않으면 다른 서버를 가리키거나 다른 이름 서버 데이터의 캐시된 복사본을 제공할 수 있습니다.

영역 파일

영역 파일은 도메인 이름과 IP 주소 간의 매핑을 포함하는 간단한 텍스트 파일입니다. 이것이 DNS 시스템이 사용자가 특정 도메인 이름을 요청할 때 접속해야 하는 IP 주소를 최종적으로 찾는 방법입니다.

영역 파일은 이름 서버에 있으며 일반적으로 특정 도메인에서 사용 가능한 리소스 또는 해당 정보를 얻기 위해 갈 수 있는 위치를 정의합니다.

기록

영역 파일 내에서 레코드가 보관됩니다. 가장 간단한 형태의 레코드는 기본적으로 리소스와 이름 간의 단일 매핑입니다. 이들은 도메인 이름을 IP 주소에 매핑하고, 도메인의 이름 서버를 정의하고, 도메인의 메일 서버를 정의하는 등의 작업을 수행할 수 있습니다.

DNS 작동 방식

이제 DNS와 관련된 일부 용어에 익숙해졌으므로 시스템이 실제로 어떻게 작동합니까?

이 시스템은 높은 수준의 개요에서는 매우 단순하지만 세부 사항을 보면 매우 복잡합니다. 하지만 전반적으로 오늘날 우리가 알고 있는 인터넷 채택에 필수적인 매우 안정적인 인프라입니다.

루트 서버

위에서 말했듯이 DNS는 기본적으로 계층적 시스템입니다. 이 시스템의 맨 위에는 "루트 서버\라고 하는 것이 있습니다. 이러한 서버는 다양한 조직에서 제어하며 ICANN(Internet Corporation for Assigned Names and Numbers)에서 권한을 위임합니다.

현재 13개의 루트 서버가 운영 중입니다. 그러나 매분 확인해야 하는 이름이 엄청나게 많기 때문에 이러한 각 서버는 실제로 미러링됩니다. 이 설정에서 흥미로운 점은 단일 루트 서버의 각 미러가 동일한 IP 주소를 공유한다는 것입니다. 특정 루트 서버에 대한 요청이 있으면 요청은 해당 루트 서버의 가장 가까운 미러로 라우팅됩니다.

이러한 루트 서버는 무엇을 합니까? 루트 서버는 최상위 도메인에 대한 정보 요청을 처리합니다. 따라서 하위 수준의 이름 서버가 해결할 수 없는 항목에 대한 요청이 들어오면 도메인의 루트 서버에 쿼리가 수행됩니다.

루트 서버는 실제로 도메인이 호스팅되는 위치를 알지 못합니다. 그러나 특별히 요청된 최상위 도메인을 처리하는 이름 서버로 요청자를 안내할 수 있습니다.

따라서 "www.wikipedia.org”에 대한 요청이 루트 서버에 생성되면 루트 서버는 레코드에서 결과를 찾지 않습니다. 일치하는 목록에 대한 영역 파일을 확인합니다. \www.wikipedia.org”. 하나도 찾지 못할 것입니다.

대신 "org\ TLD에 대한 레코드를 찾고 "org\ 주소를 담당하는 이름 서버의 주소를 요청 엔터티에 제공합니다.

TLD 서버

그런 다음 요청자는 요청의 최상위 도메인을 담당하는 IP 주소(루트 서버에서 제공)로 새 요청을 보냅니다.

예를 계속 들면 "org\ 도메인에 대해 알고 있는 이름 서버에 요청을 보내어 "www.wikipedia.org\가 어디에 있는지 알고 있는지 확인합니다.

다시 한 번 요청자는 영역 파일에서 "www.wikipedia.org”를 찾습니다. 파일에서 이 레코드를 찾지 않습니다.

그러나 "wikipedia.org”를 담당하는 이름 서버의 IP 주소를 나열한 레코드를 찾을 것입니다. 이것은 우리가 원하는 답에 훨씬 더 가까워지고 있습니다.

도메인 수준 이름 서버

이 시점에서 요청자는 리소스의 실제 IP 주소를 알아야 하는 이름 서버의 IP 주소를 가집니다. 다시 한 번 "www.wikipedia.org”를 확인할 수 있는지 묻는 새 요청을 이름 서버에 보냅니다.

이름 서버는 영역 파일을 확인하고 "wikipedia.org”와 연결된 영역 파일이 있음을 찾습니다. 이 파일 내부에는 "www” 호스트에 대한 레코드가 있습니다. 이 레코드는 이 호스트가 있는 IP 주소를 알려줍니다. 이름 서버는 요청자에게 최종 답변을 반환합니다.

리졸빙 네임서버란?

위의 시나리오에서 "요청자\라고 했습니다. 이 상황에서 요청자는 무엇입니까?

거의 모든 경우에 요청자는 "이름 서버 확인\이라고 합니다. 해결 이름 서버는 다른 서버에 질문을 하도록 구성된 서버입니다. 기본적으로 이전 쿼리 결과를 캐시하여 속도를 개선하고 루트 서버의 주소를 알고 있는 사용자를 위한 중개자로서 요청을 \해결\할 수 있습니다. 이미 알지 못합니다.

기본적으로 사용자는 일반적으로 자신의 컴퓨터 시스템에 몇 개의 확인 이름 서버를 구성합니다. 해결 이름 서버는 일반적으로 ISP 또는 기타 조직에서 제공합니다. 예를 들어 Google은 쿼리할 수 있는 해결 DNS 서버를 제공합니다. 컴퓨터에서 자동 또는 수동으로 구성할 수 있습니다.

브라우저의 주소 표시줄에 URL을 입력하면 컴퓨터는 먼저 리소스가 있는 로컬 위치를 찾을 수 있는지 확인합니다. 컴퓨터와 몇 가지 다른 위치에서 "hosts\ 파일을 확인합니다. 그런 다음 확인 이름 서버에 요청을 보내고 리소스의 IP 주소를 받을 때까지 기다립니다.

확인 이름 서버는 응답을 위해 캐시를 확인합니다. 찾지 못하면 위에 설명된 단계를 거칩니다.

네임서버 해석은 기본적으로 최종 사용자에 대한 요청 프로세스를 압축합니다. 클라이언트는 확인 이름 서버에 리소스가 있는 위치를 물어보고 조사하고 최종 답변을 반환할 것이라는 확신만 있으면 됩니다.

영역 파일

위의 프로세스에서 "영역 파일\ 및 "레코드\에 대한 아이디어를 언급했습니다.

영역 파일은 이름 서버가 알고 있는 도메인에 대한 정보를 저장하는 방식입니다. 이름 서버가 알고 있는 모든 도메인은 영역 파일에 저장됩니다. 평균 이름 서버로 오는 대부분의 요청은 서버가 영역 파일을 가질 대상이 아닙니다.

resolving name server와 같이 재귀 쿼리를 처리하도록 구성되어 있으면 답을 찾아서 반환합니다. 그렇지 않으면 요청자에게 다음에 볼 위치를 알려줍니다.

이름 서버에 있는 영역 파일이 많을수록 정식으로 응답할 수 있는 요청이 많아집니다.

영역 파일은 기본적으로 전체 DNS 명명 시스템의 하위 집합인 DNS "영역\을 설명합니다. 일반적으로 단일 도메인을 구성하는 데 사용됩니다. 여기에는 도메인에 대한 리소스가 있는 위치를 정의하는 여러 레코드가 포함될 수 있습니다. 질문.

영역의 $ORIGIN은 기본적으로 영역의 최고 권한과 동일한 매개변수입니다.

따라서 영역 파일을 사용하여 "example.com.” 도메인을 구성하는 경우 $ORIGINexample.com. 로 설정됩니다. .

이것은 영역 파일의 맨 위에서 구성되거나 영역 파일을 참조하는 DNS 서버의 구성 파일에서 정의될 수 있습니다. 어느 쪽이든 이 매개변수는 영역이 권한을 갖게 될 대상을 설명합니다.

마찬가지로 $TTL은 제공하는 정보의 "존속 기간\을 구성합니다. 기본적으로 타이머입니다. 캐싱 이름 서버는 이전에 쿼리한 결과를 사용하여 TTL 값이 소진될 때까지 질문에 답할 수 있습니다. .

레코드 유형

영역 파일 내에서 다양한 레코드 유형을 가질 수 있습니다. 여기서는 보다 일반적인(또는 필수 유형) 몇 가지를 살펴보겠습니다.

SOA 레코드

권한 시작 또는 SOA 레코드는 모든 영역 파일의 필수 레코드입니다. 파일의 첫 번째 실제 레코드여야 합니다($ORIGIN 또는 $TTL 사양이 위에 나타날 수 있음). 또한 이해하기 가장 복잡한 것 중 하나입니다.

전거 레코드의 시작은 다음과 같습니다.

domain.com.  IN SOA   ns1.domain.com. admin.domain.com. (
                          12083           ; serial number
                          3h              ; refresh interval
                          30m             ; retry interval
                          3w              ; expiry period
                          1h              ; negative TTL
                          )

각 부분의 용도를 설명하겠습니다.

  • domain.com.: 영역의 루트입니다. 이것은 영역 파일이 domain.com. 도메인용임을 지정합니다. 종종 위에서 배운 $ORIGIN 변수의 내용을 대체하는 자리 표시자인 @로 대체되는 것을 볼 수 있습니다.\n
  • IN SOA: "IN\ 부분은 인터넷을 의미합니다(많은 레코드에 표시됨). SOA는 이것이 권한 시작 레코드임을 나타내는 지표입니다.\n
  • ns1.domain.com.: 이 도메인의 기본 이름 서버를 정의합니다. 이름 서버는 기본 또는 보조일 수 있으며 동적 DNS가 구성된 경우 한 서버는 "기본\이어야 합니다. 동적 DNS를 구성하지 않은 경우 이는 기본 이름 서버 중 하나일 뿐입니다.\n
  • admin.domain.com.: 이 영역에 대한 관리자의 이메일 주소입니다. 이메일 주소에서 \@”는 점으로 대체됩니다. 이메일 주소의 이름 부분에 일반적으로 점이 있는 경우 이 부분(your.name@domain. com귀하의\name.domain.com).
  • 12083: 영역 파일의 일련 번호입니다. 영역 파일을 편집할 때마다 영역 파일이 올바르게 전파되도록 이 숫자를 늘려야 합니다. 보조 서버는 영역에 대한 기본 서버의 일련 번호가 시스템에 있는 일련 번호보다 큰지 확인합니다. 그렇다면 새 영역 파일을 요청하고, 그렇지 않으면 원본 파일을 계속 제공합니다.\n
  • 3h: 영역의 새로 고침 간격입니다. 이것은 영역 파일 변경 사항에 대해 기본을 폴링하기 전에 보조가 대기하는 시간입니다.\n
  • 30m: 이 영역에 대한 재시도 간격입니다. 새로 고침 기간이 끝났을 때 보조가 기본에 연결할 수 없으면 이 시간 동안 기다렸다가 기본 폴링을 다시 시도합니다.\n
  • 3w: 만료 기간입니다. 보조 이름 서버가 이 시간 동안 기본 이름 서버에 연결할 수 없는 경우 더 이상 이 영역에 대한 신뢰할 수 있는 소스로 응답을 반환하지 않습니다.\n
  • 1h: 이 파일에서 요청된 이름을 찾을 수 없는 경우 이름 서버가 이름 오류를 캐시하는 시간입니다.\n

A 및 AAAA 레코드

이 두 레코드는 모두 호스트를 IP 주소에 매핑합니다. "A\ 레코드는 호스트를 IPv4 IP 주소에 매핑하는 데 사용되는 반면 "AAAA\ 레코드는 호스트를 IPv6 주소에 매핑하는 데 사용됩니다.

이러한 레코드의 일반적인 형식은 다음과 같습니다.

host     IN      A       IPv4_address
host     IN      AAAA    IPv6_address

따라서 SOA 레코드가 "ns1.domain.com”에서 기본 서버를 호출했으므로 이를 "ns1.domain 이후의 IP 주소에 대한 주소에 매핑해야 합니다. com”은 이 파일이 정의하는 "domain.com” 영역 내에 있습니다.

레코드는 다음과 같을 수 있습니다.

ns1     IN  A       111.222.111.222

전체 이름을 제공할 필요는 없습니다. FQDN 없이 호스트에 제공하면 DNS 서버가 $ORIGIN 값으로 나머지를 채웁니다. 그러나 시맨틱하게 느껴지면 전체 FQDN을 쉽게 사용할 수 있습니다.

ns1.domain.com.     IN  A       111.222.111.222

대부분의 경우 여기에서 웹 서버를 "www\로 정의합니다.

www     IN  A       222.222.222.222

또한 기본 도메인이 확인되는 위치를 알려야 합니다. 다음과 같이 할 수 있습니다.

domain.com.     IN  A       222.222.222.222

대신 "@”를 사용하여 기본 도메인을 참조할 수 있습니다.

@       IN  A       222.222.222.222

또한 이 서버에 대해 명시적으로 정의되지 않은 이 도메인 아래의 모든 것을 해결할 수 있는 옵션이 있습니다. "*” 와일드 카드를 사용하여 이를 수행할 수 있습니다.

*       IN  A       222.222.222.222

이 모든 것은 IPv6 주소에 대한 AAAA 레코드와 마찬가지로 잘 작동합니다.

CNAME 레코드

CNAME 레코드는 서버의 표준 이름에 대한 별칭을 정의합니다(A 또는 AAAA 레코드로 정의된 이름).

예를 들어 "server1\ 호스트를 정의하는 A 이름 레코드가 있을 수 있으며 "www\를 이 호스트의 별칭으로 사용할 수 있습니다.

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

이러한 별칭은 서버에 대한 추가 쿼리가 필요하기 때문에 약간의 성능 손실이 있습니다. 대부분의 경우 추가 A 또는 AAAA 레코드를 사용하여 동일한 결과를 얻을 수 있습니다.

CNAME이 권장되는 한 가지 경우는 현재 영역 외부의 리소스에 대한 별칭을 제공하는 것입니다.

MX 레코드

MX 레코드는 도메인에 사용되는 메일 교환을 정의하는 데 사용됩니다. 이렇게 하면 이메일 메시지가 메일 서버에 올바르게 도착하는 데 도움이 됩니다.

다른 많은 레코드 유형과 달리 메일 레코드는 일반적으로 전체 영역에 적용되기 때문에 호스트를 무언가에 매핑하지 않습니다. 따라서 일반적으로 다음과 같이 보입니다.

        IN  MX  10   mail.domain.com.

처음에는 호스트 이름이 없습니다.

또한 거기에 추가 번호가 있습니다. 여러 메일 서버가 정의되어 있는 경우 컴퓨터가 메일을 보낼 서버를 결정하는 데 도움이 되는 기본 설정 번호입니다. 숫자가 낮을수록 우선 순위가 높습니다.

MX 레코드는 일반적으로 CNAME에 의해 정의된 호스트가 아니라 A 또는 AAAA 레코드에 의해 정의된 호스트를 가리켜야 합니다.

따라서 두 개의 메일 서버가 있다고 가정해 보겠습니다. 다음과 같은 레코드가 있어야 합니다.

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

이 예에서 "mail1\ 호스트는 기본 이메일 교환 서버입니다.

다음과 같이 작성할 수도 있습니다.

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

NS레코드

이 레코드 유형은 이 영역에 사용되는 이름 서버를 정의합니다.

\영역 파일이 이름 서버에 있으면 왜 자신을 참조해야 합니까?\라고 궁금해할 수 있습니다. DNS를 성공적으로 만드는 요인 중 하나는 여러 수준의 캐싱입니다. 영역 내에서 이름 서버를 정의하는 한 가지 이유 파일은 영역 파일이 실제로 다른 이름 서버의 캐시된 복사본에서 제공될 수 있다는 것입니다. 이름 서버 자체에 정의된 이름 서버가 필요한 다른 이유가 있지만 여기서는 다루지 않겠습니다.

MX 레코드와 마찬가지로 영역 전체 매개변수이므로 호스트도 사용하지 않습니다. 일반적으로 다음과 같이 보입니다.

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

하나의 서버에 문제가 있을 경우 제대로 동작하기 위해서는 각 존 파일에 적어도 두 개의 네임 서버가 정의되어 있어야 합니다. 대부분의 DNS 서버 소프트웨어는 이름 서버가 하나만 있는 경우 영역 파일을 유효하지 않은 것으로 간주합니다.

항상 그렇듯이 A 또는 AAAA 레코드가 있는 호스트에 대한 매핑을 포함합니다.

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

사용할 수 있는 몇 가지 다른 레코드 유형이 있지만 아마도 가장 일반적인 유형일 것입니다.

PTR 기록

PTR 레코드는 IP 주소와 관련된 이름을 정의하는 데 사용됩니다. PTR 레코드는 A 또는 AAAA 레코드의 반대입니다. PTR 레코드는 .arpa 루트에서 시작하고 IP 주소 소유자에게 위임된다는 점에서 고유합니다. RIR(Regional Internet Registries)은 조직 및 서비스 공급자에 대한 IP 주소 위임을 관리합니다. 지역 인터넷 레지스트리에는 APNIC, ARIN, RIPE NCC, LACNIC 및 AFRINIC이 포함됩니다.

다음은 111.222.333.444에 대한 PTR 레코드의 예입니다.

444.333.222.111.in-addr.arpa.	33692	IN	PTR	host.example.com.

IPv6 주소에 대한 PTR 레코드의 이 예는 Google의 IPv6 DNS 서버 2001:4860:4860::8888의 반대 니블 형식을 보여줍니다.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

-x 플래그가 있는 명령줄 도구 dig를 사용하여 IP 주소의 역방향 DNS 이름을 조회할 수 있습니다.

다음은 dig 명령의 예입니다. 출력을 역방향 DNS 이름으로 줄이기 위해 +short가 추가됩니다.

  1. dig -x 8.8.4.4 +short

위의 dig 명령에 대한 출력은 IP 주소에 대한 PTR 레코드의 도메인 이름입니다.

google-public-dns-b.google.com.

인터넷상의 서버는 PTR 레코드를 사용하여 로그 항목 내에 도메인 이름을 배치하고 정보에 입각한 스팸 처리 결정을 내리고 다른 장치에 대한 읽기 쉬운 세부 정보를 표시합니다.

가장 일반적으로 사용되는 이메일 서버는 이메일을 수신하는 IP 주소의 PTR 레코드를 조회합니다. 소스 IP 주소에 연결된 PTR 레코드가 없으면 전송되는 이메일이 스팸으로 처리되어 거부될 수 있습니다. PTR의 FQDN이 전송되는 이메일의 도메인 이름과 일치하는 것은 중요하지 않습니다. 중요한 것은 일치하는 정방향 A 레코드가 있는 유효한 PTR 레코드가 있다는 것입니다.

일반적으로 인터넷의 네트워크 라우터에는 물리적 위치에 해당하는 PTR 레코드가 제공됩니다. 예를 들어 뉴욕시나 시카고에 있는 라우터에 대해 'NYC' 또는 'CHI'에 대한 참조를 볼 수 있습니다. 이는 traceroute 또는 MTR을 실행하고 인터넷 트래픽이 사용하는 경로를 검토할 때 유용합니다.

전용 서버 또는 VPS 서비스를 제공하는 대부분의 공급자는 고객에게 IP 주소에 대한 PTR 레코드를 설정할 수 있는 기능을 제공합니다. DigitalOcean은 Droplet이 도메인 이름으로 명명될 때 모든 Droplet의 PTR 레코드를 자동으로 할당합니다. Droplet 이름은 생성 중에 지정되며 나중에 Droplet 제어판의 설정 페이지를 사용하여 편집할 수 있습니다.

참고: PTR 레코드의 FQDN에 해당하는 정방향 A 레코드가 있어야 합니다. 예: 111.222.333.444에는 server.example.com의 PTR이 있고 server.example.com111.222.333.444.

CAA 레코드

CAA 레코드는 도메인에 대해 SSL/TLS 인증서를 발급할 수 있는 인증 기관(CA)을 지정하는 데 사용됩니다. 2017년 9월 8일부터 모든 CA는 인증서를 발급하기 전에 이러한 기록을 확인해야 합니다. 레코드가 없으면 모든 CA에서 인증서를 발급할 수 있습니다. 그렇지 않으면 지정된 CA만 인증서를 발급할 수 있습니다. CAA 레코드는 단일 호스트 또는 전체 도메인에 적용될 수 있습니다.

CAA 레코드의 예는 다음과 같습니다.

example.com.	IN	CAA	0 issue "letsencrypt.org"

호스트, IN 및 레코드 유형(CAA)은 일반적인 DNS 필드입니다. 위의 CAA 관련 정보는 0 issue letsencrypt.org 부분입니다. 플래그(0), 태그(issue) 및 값(\letsencrypt.org\)의 세 부분으로 구성됩니다.

  • 플래그는 CA가 이해하지 못하는 태그를 처리하는 방법을 나타내는 정수입니다. 플래그가 0이면 레코드가 무시됩니다. 1인 경우 CA는 인증서 발급을 거부해야 합니다.
  • 태그는 CAA 레코드의 목적을 나타내는 문자열입니다. 현재 특정 호스트 이름에 대한 인증서를 생성하도록 CA를 인증하는 issue, 와일드카드 인증서를 인증하는 issuewild 또는 URL을 정의하는 iodef가 될 수 있습니다. CA는 정책 위반을 보고할 수 있습니다.
  • 값은 레코드의 태그와 연결된 문자열입니다. issueissuewild의 경우 일반적으로 권한을 부여하는 CA의 도메인입니다. iodef의 경우 문의 양식의 URL이거나 이메일 피드백을 위한 mailto: 링크일 수 있습니다.

다음 옵션을 사용하여 dig를 사용하여 CAA 레코드를 가져올 수 있습니다.

  1. dig example.com type257

CAA 레코드에 대한 자세한 내용은 DigitalOcean DNS를 사용하여 CAA 레코드를 만들고 관리하는 방법을 참조하세요.

결론

이제 DNS가 작동하는 방식을 꽤 잘 이해하셨을 것입니다. 일반적인 아이디어는 전략에 익숙해지면 상대적으로 이해하기 쉽지만, 이는 여전히 경험이 없는 관리자가 실행하기 어려울 수 있는 것입니다.

개요는 DigitalOcean 제어판에서 도메인을 설정하는 방법을 확인하십시오.