소개
DNS 또는 도메인 이름 시스템은 웹 사이트 및 서버를 구성하는 방법을 배우는 데 종종 매우 어려운 부분입니다. DNS가 작동하는 방식을 이해하면 웹 사이트에 대한 액세스를 구성하는 문제를 진단하고 배경에서 무슨 일이 일어나는지에 대한 이해를 넓힐 수 있습니다.
이 가이드에서는 DNS 구성을 시작할 때 도움이 되는 몇 가지 기본적인 DNS 개념에 대해 논의합니다. 이 가이드를 참고한 후에는 디지털오션에서 도메인 이름을 설정하거나 자체 DNS 서버를 설정할 준비가되어 있어야합니다.디지털오션에서 도메인 이름을 설정하거나 자체 DNS 서버를 설정할 준비가되어 있어야합니다.
도메인이나 제어판에서 도메인을 해결하기 위해 자체 서버를 설정하기로 들어가기 전에 실제로 모든 것이 어떻게 작동하는지에 대한 몇 가지 기본적인 개념을 살펴 보겠습니다.
도메인 용어
우리는 용어를 정의하는 것부터 시작해야합니다. 이러한 주제 중 일부는 다른 맥락에서 익숙하지만, 도메인 이름 및 DNS에 대해 이야기 할 때 사용되는 많은 용어가 컴퓨팅의 다른 영역에서 그렇게 자주 사용되지는 않습니다.
시작합시다:
도메인 이름 시스템
도메인 이름 시스템(Domain Name System), 더 일반적으로 알려진 “DNS”는 인간이 이해하기 쉬운 이름을 고유한 IP 주소로 해석할 수 있도록 하는 네트워킹 시스템입니다.
도메인 이름
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
URL “google.com“은 Google Inc. 소유의 서버와 연결되어 있습니다. 도메인 이름 시스템을 통해 “google.com”을 브라우저에 입력하면 Google 서버에 연결할 수 있습니다.
IP 주소
IP 주소는 네트워크 주소 가능한 위치를 말합니다. 각 IP 주소는 해당 네트워크 내에서 고유해야 합니다. 웹사이트에 대해 이야기할 때, 이 네트워크는 전체 인터넷입니다.
IPv4는 가장 일반적인 형태의 주소로, 네 자리의 숫자 세트로 작성되며, 각 세트는 최대 세 자리의 숫자로 이루어져 있으며, 각 세트는 점으로 구분됩니다. 예를 들어, “111.222.111.222”가 유효한 IPv4 IP 주소일 수 있습니다. DNS를 사용하여 해당 주소에 이름을 매핑하여 네트워크에서 방문하려는 각 위치에 대해 복잡한 숫자 세트를 기억할 필요가 없습니다.
최상위 도메인
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
최상위 도메인은 도메인 이름의 계층 구조에서 맨 위에 있습니다. ICANN(인터넷 주소 및 이름 할당을 위한 인터넷 기업)에 의해 특정 당사자에게 최상위 도메인의 관리 권한이 부여됩니다. 그런 다음 이러한 당사자는 일반적으로 도메인 등록기를 통해 TLD(Top-Level Domain) 아래 도메인 이름을 배포할 수 있습니다.
호스트
도메인 내에서 도메인 소유자는 개별 호스트를 정의할 수 있습니다. 이는 도메인을 통해 접근할 수 있는 별도의 컴퓨터 또는 서비스를 나타냅니다. 예를 들어 대부분의 도메인 소유자는 웹 서버를 베어 도메인(example.com) 및 “www” 호스트 정의(www.example.com)를 통해 접근할 수 있도록합니다.
일반 도메인 아래 다른 호스트 정의를 가질 수 있습니다. “api” 호스트를 통해 API에 액세스할 수 있거나 “ftp” 또는 “files”라는 호스트를 정의하여 ftp에 액세스할 수 있습니다(ftp.example.com 또는 files.example.com). 호스트 이름은 도메인 내에서 고유하면 임의로 지정할 수 있습니다.
하위 도메인
A subject related to hosts are subdomains.
DNS는 계층 구조로 작동합니다. 최상위 도메인(TLD)은 여러 도메인을 가질 수 있습니다. 예를 들어 “com” TLD에는 “google.com”과 “ubuntu.com”이라는 도메인이 있습니다. “서브도메인”은 더 큰 도메인의 일부인 모든 도메인을 의미합니다. 이 경우에는 “ubuntu.com”이 “com”의 서브도메인이라고 말할 수 있습니다. 이것은 일반적으로 도메인이라고 하며 “ubuntu” 부분은 두 번째 수준 도메인을 의미하는 SLD라고 합니다.
마찬가지로, 각 도메인은 해당 도메인 아래에 있는 “서브도메인”을 제어할 수 있습니다. 보통 우리가 서브도메인이라고 말하는 것은 이것을 의미합니다. 예를 들어 학교의 역사 학과를 위한 서브도메인을 “www.history.school.edu”에서 가질 수 있습니다. “history” 부분은 서브도메인입니다.
호스트 이름과 서브도메인의 차이점은 호스트가 컴퓨터나 리소스를 정의하는 반면, 서브도메인은 상위 도메인을 확장합니다. 이것은 도메인 자체를 세분화하는 방법입니다.
서브도메인이나 호스트에 대해 이야기할 때, 도메인의 가장 왼쪽 부분이 가장 구체적인 것을 볼 수 있습니다. DNS가 작동하는 방식입니다: 왼쪽에서 오른쪽으로 읽을 때 가장 구체적인 것부터 가장 일반적인 것까지.
완전한 정규 도메인 이름(Fully Qualified Domain Name)
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
이것은 TLD를 포함한 각 부모 도메인을 지정한다는 것을 의미합니다. 올바른 FQDN은 DNS 계층의 루트를 나타내는 점(.)으로 끝납니다. FQDN의 예는 “mail.google.com.”입니다. 때로는 FQDN을 호출하는 소프트웨어가 끝에 점을 요구하지 않을 수 있지만, ICANN 표준을 준수하기 위해 점을 뒤에 붙여야 합니다.
네임 서버
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
네임 서버는 “권한 있는” 경우일 수 있으며, 이는 그들이 자신의 관리하에 있는 도메인에 대한 쿼리에 대한 답변을 제공한다는 것을 의미합니다. 그렇지 않으면, 다른 서버를 가리키거나, 다른 네임 서버의 데이터의 캐시된 복사본을 제공할 수 있습니다.
존 파일
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
존 파일은 네임 서버에 있으며 일반적으로 특정 도메인 아래에 있는 리소스를 정의하거나 해당 정보를 가져올 수 있는 위치를 정의합니다.
레코드
존 파일 내에서 레코드가 유지됩니다. 가장 간단한 형태로, 레코드는 기본적으로 리소스와 이름 간의 단일 매핑입니다. 이러한 매핑은 도메인 이름을 IP 주소에 매핑하거나, 도메인의 네임 서버를 정의하거나, 도메인의 메일 서버를 정의할 수 있습니다.
DNS 작동 방식
이제 DNS와 관련된 일부 용어에 익숙해졌으니, 시스템은 실제로 어떻게 작동합니까?
시스템은 전반적으로 보면 매우 간단하지만, 세부 사항을 살펴보면 매우 복잡합니다. 그러나 전반적으로 보면, 오늘날 우리가 알고 있는 인터넷의 채택에 필수적인 매우 신뢰할 수 있는 인프라입니다.
루트 서버
우리가 언급한 대로 DNS는 본질적으로 계층적인 시스템입니다. 이 시스템의 맨 위에는 “루트 서버”라고 하는 것이 있습니다. 이러한 서버는 다양한 조직에 의해 제어되며 ICANN(인터넷 주소 및 이름 할당 기구)에 의해 권한이 위임됩니다.
현재 13개의 루트 서버가 운영 중입니다. 그러나 분당 처리해야 할 이름이 무수히 많기 때문에 각각의 서버는 사실상 미러링됩니다. 이 구성의 흥미로운 점은 단일 루트 서버의 각 미러가 동일한 IP 주소를 공유한다는 것입니다. 특정 루트 서버에 대한 요청이 발생하면 해당 루트 서버의 가장 가까운 미러로 경로가 지정됩니다.
루트 서버는 최상위 도메인에 대한 정보 요청을 처리합니다. 하위 레벨 이름 서버에서 해결할 수 없는 요청이 들어오면, 해당 도메인에 대해 루트 서버에 쿼리가 이루어집니다.
루트 서버는 실제로 도메인이 호스팅되는 위치를 알지 못합니다. 그러나, 요청자가 특정 요청된 최상위 도메인을 처리하는 이름 서버를 찾도록 안내할 수 있습니다.
예를 들어 “www.wikipedia.org”에 대한 요청이 루트 서버로 이루어지면, 루트 서버는 자신의 기록에서 결과를 찾지 못합니다. “www.wikipedia.org”와 일치하는 목록을 자신의 zone 파일에서 확인합니다. 찾지 못할 것입니다.
대신에 “org” TLD에 대한 기록을 찾고, “org” 주소를 담당하는 이름 서버의 주소를 요청한 개체에게 제공할 것입니다.
TLD 서버
그 다음 요청자는 요청의 최상위 도메인을 담당하는 IP 주소(루트 서버에 의해 제공됨)로 새로운 요청을 보냅니다.
우리 예제를 계속한다면, “org” 도메인에 대해서 알고 있는 이름 서버에 “www.wikipedia.org”의 위치를 알고 있는지 확인하기 위해 요청을 보낼 것입니다.
다시 한번, 요청자는 “www.wikipedia.org”를 그의 zone 파일에서 찾을 것입니다. 파일 안에서 이 기록을 찾지 못할 것입니다.
그러나 “wikipedia.org”을 담당하는 이름 서버의 IP 주소를 나열한 레코드를 찾을 것입니다. 이는 우리가 원하는 답에 훨씬 가까워지고 있습니다.
도메인 수준의 이름 서버
이 시점에서 요청자는 리소스의 실제 IP 주소를 알고 있는 이름 서버의 IP 주소를 가지고 있습니다. 새로운 요청을 보내어 다시 한번 “www.wikipedia.org”을 해결할 수 있는지 물어봅니다.
이름 서버는 자신의 존 파일을 확인하고 “wikipedia.org”와 연결된 존 파일이 있다는 것을 확인합니다. 이 파일 안에는 “www” 호스트에 대한 레코드가 있습니다. 이 레코드는 이 호스트의 위치를 나타내는 IP 주소를 알려줍니다. 이름 서버는 요청자에게 최종 답변을 반환합니다.
해결 이름 서버란?
위의 시나리오에서 “요청자”라는 용어를 사용했습니다. 이 상황에서 요청자란 무엇입니까?
거의 모든 경우에, 요청자는 우리가 “해결 이름 서버”라고 부르는 것입니다. 해결 이름 서버는 다른 서버에 질문을 하는 방식으로 구성된 것입니다. 기본적으로 이것은 이전 쿼리 결과를 캐시하여 속도를 향상시키고 이미 알지 못하는 것에 대한 요청을 “해결”할 수 있도록 루트 서버의 주소를 알고 있는 사용자를 위한 중개자입니다.
기본적으로 사용자는 컴퓨터 시스템에 몇 개의 해결 이름 서버를 구성하게 됩니다. 해결 이름 서버는 보통 ISP나 다른 기관에서 제공됩니다. 예를 들어, 구글은 쿼리할 수 있는 해결 DNS 서버를 제공합니다. 이 서버들은 자동으로 또는 수동으로 컴퓨터에 구성될 수 있습니다.
브라우저의 주소 표시줄에 URL을 입력하면, 컴퓨터는 먼저 리소스가 어디에 있는지 로컬로 찾을 수 있는지 확인합니다. 컴퓨터의 “hosts” 파일과 몇 가지 다른 위치를 확인합니다. 그런 다음, 요청을 해결 이름 서버로 보내고 리소스의 IP 주소를 받기를 기다립니다.
그런 다음, 해결 이름 서버는 답변을 위해 캐시를 확인합니다. 그것을 찾지 못하면, 위에 설명된 단계를 따릅니다.
해결 이름 서버는 기본적으로 최종 사용자의 요청 프로세스를 압축합니다. 클라이언트들은 단순히 해결 이름 서버에 리소스가 어디에 있는지 물어보고 최종 답변을 조사하고 반환할 것을 확신하면 됩니다.
존 파일
우리는 위 과정에서 “존 파일”과 “레코드”라는 개념을 언급했습니다.
존 파일은 네임 서버가 알고 있는 도메인에 대한 정보를 저장하는 방법입니다. 네임 서버가 알고 있는 모든 도메인이 존 파일에 저장됩니다. 평균적인 네임 서버에 오는 대부분의 요청은 서버가 존 파일을 가지고 있지 않은 것입니다.
재귀적 쿼리를 처리하도록 구성되어 있다면(예: 해결 네임 서버), 답변을 찾아 반환합니다. 그렇지 않으면 요청한 당사자에게 다음으로 어디를 찾아야 하는지 알려줍니다.
네임 서버가 가지고 있는 존 파일이 많을수록 서버가 권한 있는 답변을 할 수 있습니다.
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
존의 $ORIGIN은 기본적으로 존의 최상위 권한 수준과 동일한 매개변수입니다.
따라서 존 파일이 “example.com.” 도메인을 구성하는 데 사용된다면, $ORIGIN은 example.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변수의 내용을 대체하는 플레이스홀더인@입니다. -
SOA에서 “IN” 부분은 인터넷을 의미합니다 (많은 레코드에 나타납니다). SOA는 이것이 권한 부여 레코드의 시작임을 나타냅니다.
-
ns1.domain.com.: 이것은 이 도메인의 기본 이름 서버를 정의합니다. 이름 서버는 주 서버 또는 보조 서버일 수 있으며, 동적 DNS가 구성된 경우 하나의 서버는 여기에 “기본”이어야 합니다. 동적 DNS를 구성하지 않은 경우, 이것은 단지 기본 이름 서버 중 하나입니다. -
admin.domain.com.: 이것은 이 영역의 관리자의 이메일 주소입니다. 이메일 주소에서 “@”는 점(.)으로 대체됩니다. 이메일 주소의 이름 부분에 일반적으로 점(.)이 있는 경우, 이 부분에서는 이를 역슬래시(\)로 대체합니다 ([email protected]은your\name.domain.com으로 변환됩니다). -
12083: 이것은 존 파일의 일련 번호입니다. 존 파일을 편집할 때마다 존 파일이 올바르게 전파되도록이 번호를 증가해야 합니다. 보조 서버는 기본 서버의 존에 대한 일련 번호가 그들의 시스템에 있는 것보다 큰지 확인합니다. 그렇다면 새로운 존 파일을 요청하고, 그렇지 않으면 원래 파일을 계속 제공합니다.
-
3시간: 이것은 존의 새로 고침 간격입니다. 보조가 기본에게 존 파일 변경 사항을 폴링하기 전에 기다리는 시간입니다.
-
30m: 이것은 이 존의 재시도 간격입니다. 보조가 새로 고침 기간이 끝날 때 기본 서버에 연결할 수 없는 경우, 이 시간 동안 기다린 다음 기본 서버를 다시 폴링하려고 시도합니다.
-
3w: 이것은 만료 기간입니다. 보조 이름 서버가 이 시간 동안 기본 서버에 연락할 수 없는 경우, 더 이상 이 존에 대해 권한 있는 소스로 응답하지 않습니다.
-
1h: 이것은 이름 서버가 이 파일에서 요청된 이름을 찾을 수 없는 경우 이름 오류를 캐시하는 시간입니다.
A and AAAA Records
이 두 레코드는 호스트를 IP 주소에 매핑합니다. “A” 레코드는 호스트를 IPv4 IP 주소에 매핑하는 데 사용되며, “AAAA” 레코드는 호스트를 IPv6 주소에 매핑하는 데 사용됩니다.
이러한 레코드의 일반적인 형식은 다음과 같습니다:
host IN A IPv4_address
host IN AAAA IPv6_address
그래서 우리의 SOA 레코드가 “ns1.domain.com”에 있는 기본 서버를 지정했으므로 “ns1.domain.com”이 이 파일에서 정의하는 “domain.com” 영역 내에 있기 때문에이를 IP 주소로 매핑해야합니다.
레코드는 다음과 같이 보일 수 있습니다:
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 레코드를 사용하여 이를 대체할 수 있습니다.
별칭이 권장되는 한 가지 경우는 현재 존 외부의 리소스에 대한 별칭을 제공하는 것입니다.
MX 레코드
MX 레코드는 도메인에 사용되는 메일 교환을 정의하는 데 사용됩니다. 이는 이메일 메시지가 올바른 방법으로 메일 서버에 도착하도록 도와줍니다.
다른 레코드 유형과는 달리 메일 레코드는 일반적으로 호스트를 어떤 것에 매핑하지 않습니다. 왜냐하면 그것들은 전체 존에 적용되기 때문입니다. 따라서 일반적으로 다음과 같이 보입니다:
IN MX 10 mail.domain.com.
처음에 호스트 이름이 없음을 주의하십시오.
또한 그 안에 추가 번호가 있는 것을 주의하십시오. 이것은 여러 메일 서버가 정의되어 있는 경우 컴퓨터가 어떤 서버로 메일을 보낼지 결정하는 데 도움이 되는 우선 순위 번호입니다. 숫자가 낮을수록 우선 순위가 높습니다.
MX 레코드는 일반적으로 A 또는 AAAA 레코드로 정의된 호스트를 가리켜야 하며 CNAME으로 정의된 호스트를 가리키지 않아야 합니다.
그러면 두 개의 메일 서버가 있다고 가정해 봅시다. 다음과 같은 레코드가 있어야 합니다:
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)은 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.
dig 명령줄 도구에 -x 플래그를 사용하여 IP 주소의 역 DNS 이름을 조회할 수 있습니다.
다음은 dig 명령어의 예시입니다. +short는 출력을 역 DNS 이름으로 줄이기 위해 추가됩니다.
위의 dig 명령의 출력은 IP 주소의 PTR 레코드에 대한 도메인 이름입니다:
google-public-dns-b.google.com.
인터넷 상의 서버는 로그 항목에 도메인 이름을 배치하거나, 정보가 풍부한 스팸 처리 결정을 내리거나, 다른 장치에 대한 쉽게 읽을 수 있는 세부 정보를 표시하기 위해 PTR 레코드를 사용합니다.
가장 많이 사용되는 이메일 서버들은 이메일을 받는 IP 주소의 PTR 레코드를 조회합니다. 만약 소스 IP 주소에 연관된 PTR 레코드가 없다면, 보내진 이메일들은 스팸으로 간주되어 거부할 수 있습니다. PTR의 FQDN이 보낸 이메일의 도메인 이름과 일치하는 것이 중요한 것은 아닙니다. 중요한 것은 해당되고 일치하는 forward A 레코드를 가진 유효한 PTR 레코드가 있다는 것입니다.
일반적으로 인터넷에 있는 네트워크 라우터들은 그들의 물리적 위치와 일치하는 PTR 레코드를 부여받습니다. 예를 들어, 뉴욕이나 시카고의 라우터에 대해 ‘NYC’ 또는 ‘CHI’로 참조가 있을 수 있습니다. 이것은 traceroute나 MTR을 수행하고 인터넷 트래픽이 어떤 경로를 따르는지 검토할 때 도움이 됩니다.
전용 서버 또는 VPS 서비스를 제공하는 대부분의 제공업체들은 고객들에게 그들의 IP 주소에 대한 PTR 레코드를 설정할 수 있게 합니다. DigitalOcean은 Droplet이 도메인 이름으로 명명될 때 Droplet의 PTR 레코드를 자동으로 할당합니다. Droplet 이름은 생성 시에 할당되며, Droplet 제어판의 설정 페이지를 사용하여 나중에 편집할 수 있습니다.
주의: PTR 레코드의 FQDN이 해당되고 일치하는 forward A 레코드를 가지고 있어야 합니다. 예를 들어: 111.222.333.444는 PTR이 server.example.com이고, server.example.com은 111.222.333.444을 가리키는 A 레코드입니다.
CAA 레코드
CAA 레코드는 도메인에 대한 SSL/TLS 인증서를 발급할 수 있는 인증 기관(CAs)을 지정하는 데 사용됩니다. 2017년 9월 8일부터 모든 CAs는 인증서를 발급하기 전에 이러한 레코드를 확인해야 합니다. 레코드가 없으면 어떤 CA든지 인증서를 발급할 수 있습니다. 그렇지 않으면 지정된 CAs만 인증서를 발급할 수 있습니다. 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 레코드의 목적을 나타내는 문자열입니다. 현재
issue는 특정 호스트에 대한 인증서 발급을 승인하는 데 사용됩니다.issuewild는 와일드카드 인증서를 승인하고,iodef는 CA가 정책 위반을 보고할 URL을 정의합니다. - 값은 레코드의 태그와 연결된 문자열입니다.
issue및issuewild의 경우 일반적으로 권한을 부여하는 CA의 도메인일 것입니다.iodef의 경우 연락처 양식의 URL이나 이메일 피드백을 위한mailto:링크일 수 있습니다.
dig를 사용하여 다음 옵션을 사용하여 CAA 레코드를 가져올 수 있습니다:
CAA 레코드에 대한 자세한 정보는 RFC 6844를 참조하거나 당사의 튜토리얼 DigitalOcean DNS를 사용하여 CAA 레코드를 생성하고 관리하는 방법
결론
DNS 작동 방식에 대해 꽤 잘 이해하게 되었을 것입니다. 전반적인 아이디어는 전략에 익숙해지면 비교적 쉽게 이해할 수 있지만, 이것은 여전히 경험이 부족한 관리자에게 실제로 실천하기 어려운 것입니다.
개요는 DigitalOcean 제어판에서 도메인 설정하는 방법을 참조하세요.