DNS 영역 및 레코드 개요

이 문서에서는 도메인, DNS 영역, DNS 레코드 및 레코드 집합의 주요 개념을 설명합니다. Azure DNS에서 지원되는 방법을 알아봅니다.

도메인 이름

Domain Name System은 도메인 계층 구조입니다. 계층 구조는 이름이 단순히 ‘.’인 root 도메인에서 시작합니다. 그 아래에 com, net, org, uk 또는 jp와 같은 최상위 도메인이 있습니다. 최상위 수준 도메인 아래에는 org.uk 또는 co.jp와 같은 두 번째 수준의 도메인이 있습니다. DNS 계층 구조의 도메인은 전체적으로 분산되며 전 세계의 DNS 이름 서버에서 호스팅됩니다.

도메인 이름 등록 기관은 contoso.com과 같은 도메인 이름을 구입할 수 있는 조직입니다. 도메인 이름을 구입할 경우 해당 이름 하의 DNS 계층 구조를 관리할 수 있습니다. 예를 들어, www.contoso.com이라는 이름을 회사 웹 사이트에 사용할 수 있습니다. 등록 기관은 사용자 대신 자체 이름 서버에 도메인을 호스트하거나 사용자가 다른 이름 서버를 지정할 수 있습니다.

Azure DNS는 전 세계적으로 분산된 고가용성 이름 서버 인프라를 제공하므로 이러한 인프라를 사용하여 도메인을 호스트할 수 있습니다. Azure에 도메인을 호스팅하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다.

Azure DNS는 현재 도메인 이름 구입을 지원하지 않습니다. 연간 요금의 경우 App Service 도메인 또는 타사 도메인 이름 등록자를 사용하여 도메인 이름을 구매할 수 있습니다. 그러면 Azure DNS에 도메인을 호스트하여 레코드 관리에 사용할 수 있습니다. 자세한 내용은 Azure DNS에 도메인 위임을 참조하세요.

DNS 영역

DNS 영역은 특정 도메인의 DNS 레코드를 호스트하는 데 사용됩니다. Azure DNS에서 도메인 호스팅을 시작하려면 해당 도메인 이름의 DNS 영역을 만들어야 합니다. 그러면 이 DNS 영역 안에 도메인의 각 DNS 레코드가 생성됩니다.

예를 들어 'contoso.com' 도메인은 'mail.contoso.com'(메일 서버) 및 'www.contoso.com'(웹 사이트)과 같은 여러 DNS 레코드를 포함할 수 있습니다.

Azure DNS에서 DNS 영역을 만드는 경우:

  • 영역 이름은 리소스 그룹 내에서 고유해야 하며, 영역이 존재해서는 안 됩니다. 그렇지 않으면 작업이 실패합니다.
  • 서로 다른 리소스 그룹이나 Azure 구독에서는 동일한 영역 이름을 다시 사용할 수 있습니다.
  • 복수 영역이 동일한 이름을 공유할 경우 인스턴스는 각각 다른 이름 서버 주소에 할당됩니다. 도메인 이름 등록 기관에는 한 가지 주소 집합만 구성할 수 있습니다.

참고 항목

Azure DNS에서 해당 도메인 이름으로 DNS 영역을 만들기 위해 도메인을 소유할 필요는 없습니다. 하지만 도메인 이름 등록 기관에 도메인 이름의 올바른 이름 서버로 Azure DNS 이름 서버를 구성하려면 도메인을 소유해야 합니다.

자세한 내용은 Azure DNS에 도메인 위임을 참조하세요.

DNS 레코드

레코드 이름

Azure DNS에서는 상대 이름을 사용하여 레코드를 지정합니다. FQDN(정규화된 도메인 이름)은 영역 이름을 포함하는 반면 상대 이름은 영역 이름을 포함하지 않습니다. 예를 들어 영역 contoso.com의 상대 레코드 이름 www는 정규화된 레코드 이름 www.contoso.com을 제공합니다.

apex 레코드는 DNS 영역의 루트(또는 apex)에 있는 DNS 레코드입니다. 예를 들어 DNS 영역 contoso.com에서 루트 레코드는 정규화된 이름 contoso.com도 가집니다(naked 도메인이라고도 함). 규칙에 따라 루트 레코드를 나타내는 데 \'\@\' 상대 이름을 사용합니다.

레코드 유형

각 DNS 레코드에는 이름 및 형식이 있습니다. 레코드는 포함된 데이터에 따라 다양한 형식으로 구성됩니다. 가장 일반적인 형식은 이름을 IPv4 주소에 매핑하는 'A' 레코드입니다. 또 다른 일반적인 형식은 이름을 메일 서버에 매핑하는 'MX' 레코드입니다.

Azure DNS는 A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV, TXT 등 일반적인 DNS 레코드 형식을 모두 지원합니다. SPF 레코드는 TXT 레코드를 사용하여 표현됩니다.

레코드 집합

지정된 이름 및 형식을 가진 DNS 레코드를 두 개 이상 만들어야 하는 경우도 있습니다. 예를 들어 'www.contoso.com' 웹 사이트가 서로 다른 두 IP 주소에서 호스트된다고 가정합니다. 웹 사이트에는 각 IP 주소마다 하나씩, 두 개의 A 레코드가 있어야 합니다. 다음은 레코드 집합의 예제입니다.

www.contoso.com.        3600    IN    A    134.170.185.46
www.contoso.com.        3600    IN    A    134.170.188.221

Azure DNS는 레코드 집합을 사용하여 모든 DNS 레코드를 관리합니다. 레코드 집합(리소스 레코드 집합이라고도 함)은 영역 내에서 동일한 이름과 형식을 가진 DNS 레코드의 컬렉션입니다. 대부분의 레코드 집합은 단일 레코드를 포함합니다. 그러나 레코드 집합에서 레코드를 둘 이상 포함하는 위와 같은 예제도 드물지 않습니다.

예를 들어 'contoso.com' 영역에 IP 주소 '134.170.185.46'(위 첫 번째 레코드)을 가리키는 A 레코드 'www'를 만든 경우를 가정해 보겠습니다. 두 번째 레코드를 만들려면 추가 레코드 집합을 만드는 대신 기존 레코드 집합에 해당 레코드를 추가합니다.

SOA 및 CNAME 레코드 유형은 예외입니다. DNS 표준에서는 이러한 유형의 이름이 같은 여러 레코드를 허용하지 않으므로 이러한 레코드 집합은 단일 레코드만 포함할 수 있습니다.

Time-to-Live

TTL(Time To Live)은 각 레코드가 쿼리되기 전에 클라이언트에 캐시되는 기간을 지정합니다. 위 예제에서 TTL은 3600초, 즉 1시간입니다.

Azure DNS에서 TTL은 각 레코드가 아니라 레코드 집합에 대해 지정되므로 해당 레코드 집합 내의 모든 레코드에 동일한 값이 사용됩니다. 1 ~ 2,147,483,647초 사이의 TTL 값을 지정할 수 있습니다.

와일드카드 레코드

Azure DNS는 와일드카드 레코드를 지원합니다. 와일드카드 레코드는 이름이 일치하는 모든 쿼리에 대한 응답으로 반환됩니다(와일드카드가 아닌 레코드 집합에서 가까운 일치 항목이 없는 경우). Azure DNS는 NS 및 SOA를 제외한 모든 레코드 종류에 대해 와일드카드 레코드 집합을 지원합니다.

와일드카드 레코드 집합을 만들려면 레코드 집합 이름 '*'를 사용합니다. 또는 맨 왼쪽의 레이블로 '*'가 포함된 이름을 사용할 수 있습니다(예: '*.foo').

CAA 레코드

CAA 레코드를 사용하면 도메인 소유자가 자신의 도메인에 대한 인증서를 발급할 권한이 있는 CA(인증 기관)를 지정할 수 있습니다. 이 레코드는 CA가 일부 환경에서는 인증서가 착오 발급하는 것을 방지할 수 있습니다. CAA 레코드에는 다음 세 가지 속성이 있습니다.

  • 플래그: 이 필드는 RFC6844마다 특별한 의미를 갖는 중요한 플래그를 나타내는 데 사용되는 0과 255 사이의 정수입니다.
  • Tag: ASCII 문자열이며 다음 중 하나일 수 있습니다.
    • issue: 인증서(모든 유형)를 발급할 권한이 있는 CA를 지정하려는 경우에 사용합니다.
    • issuewild: 인증서(와일드카드 인증서만 해당)를 발급할 권한이 있는 CA를 지정하려는 경우에 사용합니다.
    • iodef: 권한이 없는 인증서 발급 요청에 대해 알릴 수 있는 메일 주소 또는 호스트 이름을 지정합니다.
  • Value: 선택한 특정 태그에 대한 값입니다.

CNAME 레코드

CNAME 레코드 집합은 동일한 이름의 다른 레코드 집합과 함께 존재할 수 없습니다. 예를 들어 상대 이름이 www인 CNAME 레코드 집합과 상대 이름이 www인 A 레코드를 동시에 만들 수 없습니다.

영역 루트(이름 = '@')는 항상 영역 생성 중에 NS 및 SOA 레코드 집합을 포함하므로 영역 루트에 CNAME 레코드 집합을 만들 수 없습니다.

이러한 제약 조건은 DNS 표준에서 발생하며 Azure DNS의 제한 사항이 아닙니다.

NS 레코드

영역 루트(이름 ‘@’)의 NS 레코드 집합은 각 DNS 영역과 함께 자동으로 생성되며 영역이 삭제될 경우 자동으로 삭제됩니다. 별도로 삭제할 수 없습니다.

이 레코드 집합에는 영역에 할당된 Azure DNS 이름 서버의 이름이 포함됩니다. 이 NS 레코드 집합에 추가 이름 서버를 추가하여 DNS 공급자가 2개 이상 있는 공동 호스팅 도메인을 지원할 수 있습니다. 또한 이 레코드 집합의 TTL 및 메타데이터를 수정할 수 있습니다.또한 이 레코드 집합의 TTL 및 메타데이터를 수정할 수 있습니다. 그러나 미리 채워진 Azure DNS 이름 서버를 제거하거나 수정하는 것은 허용되지 않습니다.

이 제한은 영역 루트에 있는 NS 레코드 집합에만 적용됩니다. 영역의 다른 NS 레코드 집합은 제약 없이 생성, 수정 및 삭제할 수 있습니다(자식 영역을 위임하는 데 사용되므로).

SOA 레코드

SOA 레코드 집합은 각 영역의 루트(name = '@')에서 자동으로 생성되며 영역이 삭제될 경우 자동으로 삭제됩니다. SOA 레코드는 별도로 생성 또는 삭제할 수 없습니다.

host 속성을 제외하고 SOA 레코드의 모든 속성을 수정할 수 있습니다. 이 속성은 Azure DNS에서 제공하는 기본 이름 서버 이름을 참조하도록 미리 구성됩니다.

SOA 레코드의 영역 일련 번호는 영역의 레코드가 변경될 때 자동으로 업데이트되지 않습니다. 필요한 경우 SOA 레코드를 편집하여 수동으로 업데이트할 수 있습니다.

참고 항목

Azure DNS는 현재 SOA 호스트 마스터 사서함 항목에서 '@' 앞에 점(.) 사용을 지원하지 않습니다. 예: john.smith@contoso.xyz (john.smith.contoso.xyz 변환) 및john\.smith@contoso.xyz 허용되지 않습니다.

SPF 레코드

SPF(Sender Policy Framework) 레코드는 도메인 이름 대신 이메일을 전송할 수 있는 이메일 서버를 지정하는 데 사용합니다. SPF 레코드를 올바르게 구성하는 것은 수신자가 이메일을 정크로 지정하지 않도록 하는 데 중요합니다.

DNS RFC는 원래 이 시나리오를 지원하기 위한 새로운 SPF 레코드 유형으로 소개되었습니다. 기존 이름 서버를 지원하기 위해 TXT 레코드 유형을 사용하여 SPF 레코드를 지정할 수도 있습니다. 이러한 모호성으로 인한 혼란은 RFC 7208로 해결되었습니다. 여기서는 SPF 레코드를 TXT 레코드 형식을 사용하여 만들어야 한다고 명시합니다. 또한 SPF 레코드 유형이 더 이상 사용되지 않는다고 나와 있습니다.

SPF 레코드는 Azure DNS에서 지원되며 TXT 레코드 종류를 사용하여 만들어야 합니다. 사용하지 않는 SPF 레코드 유형은 지원되지 않습니다. DNS 영역 파일을 가져올 경우 SPF 레코드 유형을 사용하는 SPF 레코드는 TXT 레코드 유형으로 전환됩니다.

SRV 레코드

SRV 레코드는 다양한 서비스에서 서버 위치를 지정하는 데 사용됩니다. Azure DNS에서 SRV 레코드를 지정할 경우

  • 서비스프로토콜은 ‘_sip._tcp.name’과 같이 밑줄로 접두사를 지정하여 레코드 집합 이름의 일부로 지정되어야 합니다. 영역 apex에 있는 레코드의 경우 레코드 이름에 ‘@’을 지정하지 않아도 되며 서비스와 프로토콜만 사용합니다(예: ‘_sip._tcp’).
  • 우선 순위, 가중치, 포트, 대상은 레코드 집합에서 각 레코드의 매개 변수로 지정됩니다.

TXT 레코드

TXT 레코드는 도메인 이름을 임의의 텍스트 문자열에 매핑하는 데 사용됩니다. 이들은 특히 SPF(Sender Policy Framework)DKIM(DomainKeys Identified Mail)과 같은 이메일 구성과 관련된 여러 애플리케이션에서 사용됩니다.

DNS 표준은 여러 문자열을 포함하는 하나의 TXT 레코드를 허용하며 각각의 문자열 길이는 최대 255자까지 가능합니다. 여러 문자열이 사용되는 경우 이러한 문자열은 클라이언트에 의해 연결되고 단일 문자열로 처리됩니다.

Azure DNS REST API를 호출할 때 각 TXT 문자열을 별도로 지정해야 합니다. Azure Portal, PowerShell 또는 CLI 인터페이스를 사용할 때는 레코드당 하나의 문자열을 지정합니다. 이 문자열은 필요한 경우 자동으로 255자 세그먼트로 나뉩니다.

DNS 레코드의 여러 문자열을 TXT 레코드 집합의 여러 TXT 레코드와 혼동해서는 안 됩니다. TXT 레코드 집합은 여러 레코드를 포함할 수 있으며 각각의 레코드는 여러 문자열을 포함할 수 있습니다. Azure DNS는 모든 레코드가 결합된 각 TXT 레코드 집합에서 총 문자열 길이를 최대 4096자*까지 지원합니다.

* 4096자 지원은 현재 Azure 퍼블릭 클라우드에서만 사용할 수 있습니다. 국가별 클라우드는 4k 지원 롤아웃이 완료될 때까지 1024자로 제한됩니다.

태그 및 메타데이터

태그

태그는 이름-값 쌍의 목록으로, Azure Resource Manager에서 리소스에 레이블을 지정하는 데 사용됩니다. Azure Resource Manager는 태그를 사용하여 Azure 청구서를 필터링하여 표시할 수 있으며 특정 태그에 대한 정책을 설정할 수 있습니다. 태그에 대한 자세한 내용은 태그를 사용하여 Azure 리소스 구성을 참조하십시오.

Azure DNS에서는 DNS 영역 리소스에 Azure Resource Manager 태그를 사용할 수 있으며 아래 설명된 대로 대체 메타데이터가 DNS 레코드 집합에서 지원되기는 하지만 DNS 레코드 집합의 태그는 지원하지 않습니다.

메타데이터

Azure DNS에서는 레코드 집합 태그 대신 메타데이터를 사용하여 레코드 집합에 주석을 추가할 수 있습니다. 태그와 유사한 메타데이터를 사용하면 각 레코드 집합에 이름-값 쌍을 연결할 수 있습니다. 이 기능은 각 레코드 집합의 목적을 기록하는 데 유용할 수 있습니다. 태그와 달리, 메타데이터는 Azure 청구서를 필터링하여 표시하는 데 사용할 수 없으며 Azure Resource Manager 정책에서 지정할 수 없습니다.

Etag

두 사용자 또는 두 프로세스가 동시에 DNS 레코드 수정을 시도한다고 가정합니다. 어느 쪽이 성공할까요? 그리고 승자는 다른 사용자가 만든 변경 내용을 덮어썼다는 것을 알고 있을까요?

Azure DNS는 Etag를 사용하여 동일한 리소스에 대한 동시 변경을 안전하게 처리합니다. Etags는 Azure Resource Manager '태그'와 구분됩니다. 각 DNS 리소스(영역 또는 레코드 집합)에는 Etag가 연결되어 있습니다. 리소스를 검색할 때마다 해당 Etag도 검색됩니다. 리소스를 업데이트할 때 Azure DNS에서 서버의 Etag가 일치하는지 확인할 수 있도록 Etag를 다시 전달하도록 선택할 수 있습니다. 리소스를 업데이트할 때마다 Etag가 다시 생성되므로 Etag 불일치는 동시 변경이 발생했음을 나타냅니다. 새 리소스를 만들 때도 Etag를 사용하여 리소스가 존재하지 않는지 확인합니다.

기본적으로 Azure DNS PowerShell은 Etag를 사용하여 영역 및 레코드 집합에 대한 동시 변경을 차단합니다. 선택적 -Overwrite 스위치를 사용하여 Etag 검사를 무시할 수 있으며, 이 경우 발생한 동시 변경 내용을 덮어쓰게 됩니다.

Azure DNS REST API 수준에서 Etag는 HTTP 헤더를 사용하여 지정됩니다. 해당 동작은 다음 표에 나와 있습니다.

헤더 동작
없음 PUT 항상 성공(Etag 검사 안 함)
If-match <etag> 리소스가 있고 Etag가 일치하는 경우에만 PUT 성공
If-match * 리소스가 있는 경우에만 PUT 성공
If-none-match * 리소스가 없는 경우에만 PUT 성공

제한

Azure DNS를 사용할 경우 다음과 같은 기본 제한이 적용됩니다.

공용 DNS 영역

리소스 제한
구독당 퍼블릭 DNS 영역 250 1
공용 DNS 영역당 레코드 집합 10,000 1
공용 DNS 영역에 있는 레코드 집합당 레코드 20
단일 Azure 리소스의 별칭 레코드 수 20

1 이러한 제한을 늘려야 하는 경우 Azure 지원에 문의하세요.

다음 단계