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

DNS (Domain Name System)은 인터넷을 구동하는 중요한 구성 요소 중 하나입니다. DNS가 어떻게 작동하는지 올바르게 이해하면 웹사이트 설정 문제를 진단하고 배후에서 일어나는 일에 대한 이해를 넓히는 데 도움이 될 수 있습니다.

이 가이드에서는 DNS 설정을 작업하는 동안 탄탄한 기반을 제공하기 위해 DNS의 몇 가지 기본 개념에 대해 설명합니다. 이 가이드는 또한 자체 도메인 이름 또는 DNS 서버를 설정하는 데 도움이 될 것입니다.

시작해 보겠습니다!

도메인 용어

먼저, 우리가 사용할 용어에 대한 이해를 확립해야 합니다. 다른 맥락을 통해 이미 이 중 일부에 익숙할 수도 있습니다. 하지만 도메인 이름과 DNS에 대해 이야기할 때는 다른 컴퓨팅 분야에서는 많이 다루지 않는 구체적인 용어가 많이 있습니다.

• 도메인 네임 시스템

도메인 네임 시스템(줄여서 DNS)은 사람이 읽기 쉬운 도메인 이름을 고유한 IP 주소로 변환하는 네트워킹 시스템입니다.

• 도메인 이름

도메인 이름은 인터넷 리소스와 연결하는 데 사용되는 사람이 읽기 쉬운 이름을 말합니다. 예를 들어, “cloudsigma.com”은 도메인 이름입니다. 일부는 “cloudsigma” 부분만 도메인 이름이라고 주장할 수도 있지만, 일반적으로는 전체를 가리킵니다.

URL “cloudsigma.com”은 CloudSigma가 소유한 서버와 연결되어 있습니다. 웹 브라우저에 URL을 입력하면 DNS와 통신하여 대상 서버의 IP 주소에 연결합니다.

• IP 주소

IP 주소는 네트워크에 연결된 장치의 네트워크 주소 역할을 합니다. 각 IP 주소는 네트워크 내에서 고유해야 합니다. 웹사이트의 맥락에서 네트워크는 대부분의 경우 인터넷 전체를 의미합니다.

IP 주소에는 두 가지 유형이 있습니다:

• • IPv4: 가장 일반적인 형태의 IP 주소입니다. 네 개의 숫자 세트로 작성되며, 각 세트는 최대 3자리 숫자로 구성됩니다. 각 세트는 점으로 구분됩니다. IPv4의 범위는 0.0.0.0 ~ 255.255.255.255.

  • IPv6: 이는 다음 문제를 해결하기 위해 개발된 보다 현대적인 표준입니다: IPv4 address exhaustion. IPv4는 최대 232개의 고유 주소를 지원하는 반면, IPv6는 최대 2128개의 주소를 지원합니다. 모든 IPv6 주소는 16진수로 작성됩니다. 최대 32자리 숫자를 포함할 수 있으며, 8개 섹션(각 섹션당 4자리)으로 나뉩니다. 각 섹션은 콜론(:)으로 구분됩니다.

최상위 도메인

최상위 도메인(줄여서 TLD)은 도메인의 가장 일반적인 부분입니다. 가장 오른쪽 끝부분(점으로 구분됨)을 가리킵니다. 일반적인 최상위 도메인은 다음과 같습니다.

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

도메인 이름 측면에서 이러한 도메인은 계층 구조의 최상위에 있습니다. ICANN(Internet Corporation for Assigned Names and Numbers)은 특정 당사자에게 최상위 도메인에 대한 제어 권한을 부여할 수 있습니다. 권한을 부여받은 당사자는 해당 TLD 하위의 도메인 이름을 분배할 수 있습니다(보통 도메인 등록 대행업체를 통해).

• 호스트

도메인에서 소유자는 도메인을 통해 액세스할 수 있는 개별 머신/서비스를 가리키는 개별 호스트를 지정할 수 있습니다. 예를 들어, 기본 도메인( example.com) 및 “호스트” 정의인 “www  ( www.example.com).

일반 도메인 아래에 추가 호스트를 가질 수도 있습니다. 예를 들어, 다음을 통한 API 액세스: “api” 호스트( api.example.com), 다음을 통한 FTP 액세스: “ftp” 또는 “files” 호스트( ftp.example.com 또는 files.example.com).

도메인 이름은 도메인 내에서 고유하기만 하면 임의로 지정할 수 있습니다.

• 서브도메인

서브도메인은 호스트와 관련된 주제입니다. DNS는 계층 구조로 작동합니다. TLD는 그 아래에 많은 도메인을 가질 수 있습니다. 예를 들어, “ example.com”, “ cloudsigma.com” 등은 모두 “com” TLD 아래에 있습니다. 그런 점에서 서브도메인은 대상 도메인의 일부인 모든 도메인에 대한 참조입니다. 따라서 “example.com”은 “com”의 서브도메인이라고 할 수 있습니다. 일반적으로 “example” 부분은 SLD(2차 도메인)라고 합니다.

마찬가지로, 도메인은 그 아래에 있는 모든 “서브도메인”을 제어할 수 있습니다. 보통 “서브도메인”이라는 용어는 이를 가리킬 때 사용됩니다. 예를 들어, “ history.example.com”은 “ 의 서브도메인입니다example.com”.

호스트 이름과 서브도메인의 주요 차이점은 호스트는 컴퓨터/리소스를 정의하는 반면 서브도메인은 상위 도메인을 확장한다는 것입니다. 서브도메인이나 호스트에 대해 이야기할 때, 도메인의 가장 왼쪽 부분이 가장 구체적이므로 이를 보고 확인할 수 있습니다. 이것이 DNS가 작동하는 방식입니다. 가장 구체적인 부분(가장 왼쪽)에서 가장 덜 구체적인 부분(가장 오른쪽)으로 진행됩니다.

• 정규화된 도메인 이름

정규화된 도메인 이름(줄여서 FQDN)은 절대 도메인 이름을 나타냅니다. DNS 시스템에서 도메인은 서로 상대적으로 지정될 수 있습니다. 이는 일부 모호성을 유발할 수 있습니다. 그러나 FQDN은 도메인 이름 시스템의 절대적인 루트를 가리키는 절대적인 이름입니다.

즉, FQDN은 TLD를 포함한 각 상위 도메인을 지정합니다. 적절한 예는 “ mail.google.com”입니다. 특정 경우에 FQDN이 점으로 끝나지 않을 수 있지만, 마지막에 점이 있어야 합니다(ICANN 표준에 의해 요구됨).

• 네임서버

네임서버는 도메인 이름을 IP 주소로 변환하는 전용 컴퓨터입니다. 네임서버는 DNS 시스템에서 대부분의 부하를 감당합니다. 전체 도메인 변환 요청 수가 단일 서버가 처리하기에는 너무 많기 때문에, 부하를 분산하기 위해 요청이 다른 네임서버로 리디렉션되는 경우가 많습니다.

네임서버는 “권한 있는(authoritative)” 서버일 수 있으며, 이는 자신이 제어하는 도메인에 대한 쿼리에만 답변을 제공함을 의미합니다. 이러한 서버는 요청을 다른 네임서버로 전달하거나 다른 네임서버 데이터의 캐시된 복사본을 제공할 수 있습니다.

• 존 파일

존 파일은 도메인 이름과 IP 주소 간의 매핑을 포함하는 텍스트 파일입니다. 이는 DNS 시스템의 데이터베이스 역할을 합니다. 이는 특정 도메인 이름에 대한 사용자 요청을 완료할 때 DNS가 연결할 IP 주소를 찾는 데 사용하는 카탈로그입니다.

일반적으로 네임서버는 존 파일을 호스팅하고 단일 도메인 아래에서 사용 가능한 리소스를 정의합니다. 또한 해당 정보를 얻기 위해 어디로 가야 하는지에 대한 정보도 보유할 수 있습니다.

• 레코드

존 파일은 수많은 레코드로 구성됩니다. 여기서 레코드는 리소스와 이름 간의 단일 매핑으로 정의됩니다. 레코드는 IP 주소에 매핑되는 도메인 이름, 특정 도메인 아래에서 사용 가능한 리소스, 또는 정보를 얻을 수 있는 위치에 대한 참조일 수 있습니다.

DNS 작동 방식

지금까지 우리는 DNS와 관련된 몇 가지 일반적인 용어에 익숙해졌습니다. 하지만 이 시스템은 실제로 어떻게 작동할까요? 상위 수준에서 보면 시스템이 매우 단순해 보일 수 있습니다. 그럼에도 불구하고 세부 사항을 더 깊이 파고들면 그 진정한 복잡성이 드러날 것입니다. 전반적으로 DNS 시스템은 인터넷의 광범위한 보급에 중요합니다.

• 루트 서버

DNS는 핵심적으로 계층 구조로 작동합니다. 시스템의 최상위에는 “루트 서버”가 있습니다. 이 서버들은 다양한 기관의 통제를 받습니다. 이 서버들의 권한은 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 위임됩니다.

현재 약 13개의 루트 서버가 운영되고 있습니다. 그러나 부하 때문에 이러한 각 서버는 미러링되어 있습니다. 모든 미러 서버가 루트 서버와 동일한 IP 주소를 공유한다는 점에 유의하는 것이 중요합니다. 루트 서버에 요청이 있을 때마다 해당 요청은 해당 서버의 가장 가까운 미러로 리디렉션됩니다.

루트 서버의 역할은 무엇일까요? 이들은 최상위 도메인에 대한 정보를 제공합니다. 하위 수준의 네임서버가 요청을 해결하지 못할 때마다 해당 도메인의 루트 서버로 리디렉션됩니다.

하지만 루트 서버는 실제로 도메인의 위치를 알지 못합니다. 단지 특별히 요청된 최상위 도메인을 처리할 요청을 리디렉션할 뿐입니다. 예를 들어, “ blog.cloudsigma.com”에 대한 요청이 발생하면, 루트 서버는 해당 레코드를 가지고 있지 않습니다. 영역 파일을 검색하지만 이에 대한 레코드는 없을 것입니다. 대신 “com” TLD를 인식하고 요청한 엔티티를 “com” 주소를 처리하는 네임서버로 리디렉션합니다.

• TLD 서버

이전 예시에 이어서, 요청 엔티티는 이제 (루트 서버가 제공한) IP 주소로 요청을 보냅니다. “ blog.cloudsigma.com”의 경우, “com” 네임서버가 영역 파일에서 해당 레코드를 검색합니다.

요청에 해당하는 레코드는 없을 것입니다. 하지만 다음을 담당하는 네임서버의 IP 주소가 나열된 레코드를 찾을 것입니다: “ cloudsigma.com”.

• 도메인 수준 네임서버

이제 요청 엔티티는 “ blog.cloudsigma.com”에 대한 정보를 실제로 호스팅하는 네임서버의 IP 주소를 갖게 됩니다. 이제 서버에 “www.cloudsigma.com”을 확인하도록 요청하는 새로운 요청을 보냅니다.

이전과 마찬가지로, 네임서버는 영역 파일을 확인하여 “ cloudsigma.com”와 관련된 파일을 찾습니다. 이 파일 내부에는 “www” 호스트에 대한 항목이 존재합니다. 이 레코드는 호스트의 위치를 설명합니다. 그런 다음 최종 답변이 요청 엔티티로 전달됩니다.

• 리졸빙 네임서버

예시에서 요청 엔티티를 언급했습니다. 그것은 무엇일까요? 대부분의 경우 요청자는 “리졸빙 네임서버”가 됩니다. 이는 다른 서버에 질문을 하도록 구성된 서버입니다. 사용자를 위한 중개 서버 역할을 합니다. 속도를 향상시키기 위해 결과를 캐싱합니다.

일반적으로 모든 사용자는 시스템에 두 개 정도의 리졸빙 네임서버가 구성되어 있습니다. 일반적으로 리졸빙 네임서버는 ISP 또는 기타 조직에서 제공합니다. 예를 들어, Google은 쿼리할 수 있는 공개 리졸빙 DNS 서버를 제공합니다. 시스템에 수동으로 구성할 수 있습니다.

웹 브라우저에 URL을 입력하면 리소스의 위치를 찾습니다. 먼저 로컬에서 검색이 수행됩니다. 여기에는 “hosts” 파일(및 일부 다른 위치)이 포함됩니다. 찾지 못하면 요청이 리졸빙 네임서버로 전송됩니다. 요청을 받은 후 리졸빙 네임서버는 캐시에서 답을 검색합니다. 찾지 못하면 앞서 언급한 단계를 거칩니다.

리졸빙 네임서버는 최종 사용자의 요청 프로세스를 단순화합니다. 클라이언트는 리졸빙 네임서버에 리소스의 위치를 묻기만 하면 됩니다. 네임서버가 조사하여 최종 답변을 반환합니다.

• 영역 파일

우리는 이미 “영역 파일”과 “레코드”의 개념에 대해 논의했습니다. 그렇다면 이들은 어떻게 작동할까요?

영역 파일은 네임서버의 데이터베이스 역할을 하며, 네임서버가 알고 있는 도메인에 대한 정보를 저장합니다. 네임서버가 알고 있는 모든 도메인은 해당 영역 파일에 저장됩니다. 그러나 네임서버로 들어오는 대부분의 요청은 영역 파일에 의해 해결되지 않습니다. 서버 구성이 재귀적 쿼리(예: 리졸빙 네임서버)를 처리하도록 되어 있다면 답변을 반환할 것입니다. 그렇지 않으면 요청한 측을 다음에 찾아볼 다른 위치로 리디렉션합니다.

네임서버가 더 많은 영역 파일을 호스팅할수록 그 답변의 권한이 더 커집니다. 영역 파일은 DNS “영역”(전체 DNS 명명 시스템의 하위 집합)을 설명합니다. 일반적으로 영역 파일에는 단일 도메인의 구성 데이터만 포함됩니다. 여기에는 해당 도메인의 리소스 위치를 정의하는 수많은 레코드가 포함될 수 있습니다.

영역의 $ORIGIN 매개변수는 해당 영역의 최고 권한 수준과 같습니다. 예를 들어, “ cloudsigma.com”의 영역 파일은 $ORIGIN을 “ cloudsigma.com”. 이 매개변수의 값은 영역 파일의 시작 부분이나 DNS 서버의 설정에 저장될 수 있습니다. 어느 쪽이든, 이 매개변수는 해당 파일이 어떤 영역에 대해 권한이 있는지를 설명합니다.

The $TTL 매개변수는 제공하는 결과의 “time to live”(수명) 정보를 설정합니다. 이는 캐싱 서버가 캐시된 응답의 유효성을 추적하는 데 사용할 수 있는 타이머로 설명할 수 있습니다. TTL 값이 만료되면 해당 응답은 더 이상 유효하지 않으며 폐기됩니다.

• 레코드 유형

영역 파일은 수많은 레코드로 구성됩니다. 레코드에는 여러 가지 유형이 있습니다. 다음으로 가장 일반적이고 필수적인 몇 가지 레코드 유형을 살펴보겠습니다.

SOA 레코드

Start of Authority(줄여서 SOA) 레코드는 모든 영역 파일에 필수적입니다. 파일에서 첫 번째 실제 레코드여야 합니다. 하지만 다음과 같은 항목은 $ORIGIN 또는 $TTL 이 이전에 나타나는 것은 허용됩니다.

SOA 레코드는 더 복잡한 레코드 유형 중 하나입니다. 구조는 다음과 같습니다.

자세히 분석해 보겠습니다:

• • example.com: 이 부분은 영역의 루트를 정의합니다. 이 예에서 영역 파일은 “ example.com” 도메인을 위한 것입니다. 때로는 이 값이 @ ( 의 값을 대체하는 자리 표시자 $ORIGIN).

  • IN SOA: “IN”이라는 용어는 “인터넷(internet)”을 의미합니다. 많은 레코드에서 이 용어를 볼 수 있습니다. “SOA”라는 용어는 이것이 SOA 레코드임을 나타냅니다.

  • ns1.example.com: 이 값은 “ example.com” 도메인의 기본 네임서버를 지정합니다. 네임서버는 기본(primary) 또는 보조(secondary)일 수 있습니다. 동적 DNS로 구성된 경우 하나의 “기본” 서버가 있어야 합니다. 동적 DNS가 구성되지 않은 경우 기본 네임서버 중 하나가 됩니다.

  • admin.example.com: 이 자리에는 영역 관리자의 이메일 주소가 들어갑니다. 참고로 @은(는) 여기에서 .로 대체됩니다. 원래 이메일 주소에 점(dot)이 포함되어 있으면 \로 대체됩니다. 예를 들어, “ my.domain@example.com”은(는) “ my\domain.example.com”.

  • 12083: 영역 파일의 일련번호(serial number)입니다. 영역 파일이 수정될 때마다 파일이 올바르게 전파되도록 번호를 업데이트해야 합니다. 보조 서버는 이 일련번호를 사용하여 자체 영역 파일이 최신 상태인지 추적합니다.

  • 3h: 영역의 새로 고침 간격(refresh interval)을 나타냅니다. 보조 서버는 영역 파일 업데이트를 확인하기 전에 이 시간 동안 대기합니다.

  • 30m: 이 값은 영역의 재시도 간격(retry interval)을 나타냅니다. 보조 서버가 새로 고침 주기가 만료된 후 기본 서버에 연결하지 못하면, 기본 서버에 다시 요청하기 전에 이 시간 동안 대기합니다.

  • 3w: 이 값은 만료 기간(expiry period)을 나타냅니다. 보조 서버가 이 시간 동안 기본 서버에 연결하지 못하면, 해당 응답을 “권한 있음(authoritative)”으로 반환하는 것을 중단합니다.

  • 1h: 이 값은 네임서버가 영역 파일에서 이름을 찾지 못했을 때 이름 오류(name error)를 캐싱하는 시간의 양을 나타냅니다.

A 및 AAAA 레코드

이 레코드들은 호스트와 IP 주소 간의 매핑을 설정합니다. 여기서 “A” 레코드는 호스트에 대한 IPv4 매핑을 나타내고, AAAA는 IPv6 매핑을 나타냅니다.

이것이 A 및 AAAA 레코드의 기본 구조입니다:

SOA 레코드 예시에서 우리는 네임서버를 “ ns1.exampel.com”(이)라고 불렀습니다. 네임서버는 “ example.com” 도메인에 속합니다. 해당 A 레코드는 다음과 같습니다:

전체 이름을 제공할 필요가 없었다는 점에 유의하세요. FQDN이 없는 호스트 이름만으로도 DNS 서버는 $ORIGIN의 값으로 나머지를 채울 수 있습니다. 하지만 여전히 FQDN을 사용할 수 있습니다:

웹 서버를 “www”로 정의하는 방법은 다음과 같습니다:

기본 도메인에 대한 매핑도 포함해야 합니다. 항목은 다음과 같습니다:

또는 다음과 같이 @ 기호를 사용하여 (전체 이름 대신) 기본 도메인을 나타낼 수 있습니다:

명시적으로 정의되지 않은 이 도메인 하위의 모든 항목을 확인하는 옵션을 활성화하는 와일드카드 항목을 포함하는 것이 좋습니다:

동일한 구조가 AAAA 레코드에도 적용됩니다. 유일한 차이점은 IPv6 주소입니다.

CNAME Records

CNAME 레코드는 서버의 정식 이름(A 또는 AAAA 레코드로 정의됨)에 대한 별칭 역할을 합니다. 다음 예시를 살펴보세요:

여기서는 “www” 이름을 정의하기 위한 별칭으로 “server1”을 사용했습니다. 이러한 단축 방식은 서버가 최종 답변을 얻기 위해 추가 쿼리를 실행해야 하므로 성능 비용이 발생한다는 점에 유의하세요. 별칭 레이어의 수에 따라 이는 쉽게 큰 성능 저하를 초래할 수 있습니다. 하지만 CNAME 별칭 지정이 유용한 특정 사례가 있는데, 예를 들어 현재 영역 외부의 리소스를 제공하는 경우입니다.

MX Records

MX 레코드는 도메인의 메일 교환을 정의합니다. 이메일이 서버에 올바르게 도착하도록 도와줍니다. 다른 레코드와 달리 MX 레코드는 전체 영역에 적용되므로 호스트를 특정 대상에 매핑하지 않습니다. 이것이 MX 레코드가 다음과 같이 보이는 이유입니다:

항목 시작 부분에 호스트 이름이 없다는 점에 유의하세요. 또한 줄에 추가 값이 있는 것을 볼 수 있습니다. 이는 메일을 보낼 서버를 결정하는 데 도움이 되는 우선순위 번호입니다(여러 메일 서버가 정의된 경우). 숫자가 낮을수록 우선순위가 높습니다.

MX 레코드는 CNAME이 아닌 A 또는 AAAA 레코드로 정의된 호스트를 가리켜야 합니다. 이를 염두에 두고 두 개의 메일 서버가 구성되어 있다면 레코드는 다음과 같이 보일 것입니다:

이 예시에서 우선순위 번호로 판단할 때 “mail1”이 “mail2”보다 선호되는 서버입니다. 전체 도메인 이름을 생략하여 코드를 더 단축할 수 있습니다:

NS Records

이 레코드는 특정 영역의 네임서버를 정의합니다. 여기서 당연한 질문은, 영역 파일이 네임서버 내에 존재한다면 왜 자신에 대한 참조가 필요할까요? 이 질문에 대한 한 가지 답은 DNS 시스템의 다중 캐싱 메커니즘입니다. 영역 파일은 실제로 다른 서버에 캐시된 복사본일 수 있습니다.

MX 레코드와 마찬가지로 NS 레코드는 전체 영역에 적용됩니다. 따라서 기본적으로 특정 호스트를 가지지 않습니다. NS 레코드 항목은 다음과 같이 보일 것입니다:

한 서버가 올바르게 작동하지 않을 경우를 대비하여 두 개의 네임서버를 정의하는 것이 좋습니다. 게다가 대부분의 DNS 서버는 네임서버가 하나만 포함된 영역 파일은 거부합니다.

또한 A 또는 AAAA 레코드를 사용한 호스트 매핑도 포함해야 합니다:

PTR Records

PTR 레코드는 일반적인 A 또는 AAAA 레코드의 역방향입니다. 이 레코드는 IP 주소와 관련된 이름을 정의하는 데 사용됩니다. 이 레코드는 에서 시작한다는 고유한 속성을 가지고 있습니다..arpa 루트이며 IP 주소의 소유자를 나타냅니다. 조직 및 서비스 제공업체에 IP 주소를 배포하는 곳은 RIR(Regional Internet Registries, 대륙별 인터넷 등록기관)입니다. RIR에는 APNIC, AFRINIC, LACNIC, RIPE NCC, ARIN 등이 있습니다.

예를 들어, 에 대한 PTR 레코드는111.222.333.444 다음과 같이 보일 것입니다:

다음 PTR 레코드 예시에서는 Google’의 IPv6 DNS 서버를 살펴보겠습니다. 2001:4860:4860::8888:

dig 도구에 플래그를 사용하여-x IP 주소의 역방향 DNS 이름을 조회할 수 있습니다. 예를 들어, 의 역방향 DNS IP 주소를 확인해 보세요.8.8.4.4:

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

일반적으로 사용되는 이메일 서버는 이메일이 발송된 IP 주소의 PTR 레코드를 조회합니다. PTR 레코드가 비어 있으면 해당 이메일이 스팸일 가능성이 높습니다(따라서 거부됨). FQDN과 PTR 레코드의 도메인 이름이 일치하는지 여부는 중요하지 않습니다. 중요한 요소는 유효한 PTR 레코드가 일치하고 대응하는 정방향 A 레코드와 연결되어 있는지 여부입니다.

일반적으로 인터넷의 네트워크 라우터는 물리적 위치에 해당하는 PTR 레코드를 가집니다. 예를 들어, “NYC” 또는 “CHI”는 뉴욕과 시카고에 위치한 라우터에 대한 유효한 참조입니다. 이 기술은 traceroute 또는 MTR을 수행하고 패킷이 이동하는 경로를 검토할 때 유용합니다.

CAA 레코드

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

다음은 CAA 레코드의 예입니다:

항목에서 CAA 전용 부분은 0 issue "letsencrypt.org"입니다. 이 부분은 세 가지 파트로 구성됩니다:

• Flags: CA가 이해하지 못하는 태그를 어떻게 처리해야 하는지 나타내는 정수 값입니다. 플래그 값이 0(으)로 설정되면 레코드가 무시됩니다. 값이 1이면 CA는 인증서 발급을 거부해야 합니다.
• Tags: CAA 레코드의 목적을 나타내는 문자열입니다. 현재 유효한 값은 다음과 같습니다. issue (특정 도메인에 대해 CA가 인증서를 발급하도록 허용), issuewild (와일드카드 인증서 허용), 및 iodef (CA가 정책 위반을 보고하는 URL 정의).
• Values: 레코드의 태그와 관련된 문자열입니다. 태그가 issue 또는 issuewild인 경우, 값은 일반적으로 권한을 부여하려는 CA의 도메인이 됩니다. 태그가 iodef인 경우, 문의 양식의 URL 또는 이메일 피드백을 위한 mailto: 링크가 됩니다.

dig 도구를 사용하여 CAA 레코드를 가져올 수 있습니다:

CAA 레코드에 대한 자세한 정보는 다음을 확인하세요. RFC 6844.

마치며

이 가이드는 다양한 DNS 관련 용어를 설명합니다. 또한 모든 구성 요소가 어떻게 함께 작동하는지도 설명합니다. 이 철저한 개요를 염두에 두면 DNS 시스템의 기능에 대해 잘 이해할 수 있을 것입니다. 일반적인 개념은 간단하고 이해하기 쉽지만, 세부적인 내용은 매우 빠르게 복잡해집니다. 경험이 부족한 관리자에게는 이러한 개념과 전략을 적용하는 것이 어려울 수 있습니다.

CloudSigma 고객이신가요? 그렇다면 다음을 확인해 보세요. CloudSigma 인프라에 대한 역방향 DNS/PTR 레코드 관리 및 업데이트.

즐거운 컴퓨팅 되세요!