도메인 이름
Do기본 이름 시스템은 할 일의 계층 구조입니다기본. 계층 구조는 이름이 단순히 ‘.’인 root 도메인에서 시작합니다. 그 아래에 com, net, org, uk 또는 jp와 같은 최상위 도메인이 있습니다. 최상위 수준 도메인 아래에는 org.uk 또는 co.jp와 같은 두 번째 수준의 도메인이 있습니다. DNS 계층 구조의 do기본는 전 세계 DNS 이름 서버에서 호스트하는 전역적으로 배포됩니다.
도메인 이름 등록 기관은 contoso.com과 같은 도메인 이름을 구입할 수 있는 조직입니다. do기본 이름을 구매하면 해당 이름 아래의 DNS 계층 구조를 제어할 수 있습니다(예: 회사 웹 사이트로 이름을 www.contoso.com 보낼 수 있도록 허용). 등록 기관은 사용자 대신 자체 이름 서버에서 do기본 호스트하거나 대체 이름 서버를 지정할 수 있습니다.
Azure DNS는 할 일을 호스트하는 데 사용할 수 있는 전역적으로 분산된 고가용성 이름 서버 인프라를 제공합니다기본. Azure에 도메인을 호스팅하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다.
Azure DNS는 현재 할 일기본 이름 구매를 지원하지 않습니다. 연간 요금의 경우 App Service 도메인 또는 타사 도메인 이름 등록자를 사용하여 도메인 이름을 구매할 수 있습니다. 그러면 기본 레코드 관리를 위해 Azure DNS에서 호스팅할 수 있습니다. 자세한 내용은 Azure DNS에 도메인 위임을 참조하세요.
DNS 영역
DNS 영역은 특정 도메인의 DNS 레코드를 호스트하는 데 사용됩니다. Azure DNS에서 할 일기본 호스팅을 시작하려면 해당 기본 이름에 대한 DNS 영역을 만들어야 합니다. 그러면 이 DNS 영역 안에 도메인의 각 DNS 레코드가 생성됩니다.
예를 들어 do기본 'contoso.com'에는 'mail.contoso.com'(메일 서버의 경우) 및 'www.contoso.com'(웹 사이트의 경우)와 같은 여러 DNS 레코드가 포함될 수 있습니다.
Azure DNS에서 DNS 영역을 만드는 경우:
- 영역 이름은 리소스 그룹 내에서 고유해야 하며, 영역이 존재해서는 안 됩니다. 그렇지 않으면 작업이 실패합니다.
- 서로 다른 리소스 그룹이나 Azure 구독에서는 동일한 영역 이름을 다시 사용할 수 있습니다.
- 복수 영역이 동일한 이름을 공유할 경우 인스턴스는 각각 다른 이름 서버 주소에 할당됩니다. do기본 이름 등록 기관으로 하나의 주소 집합만 구성할 수 있습니다.
참고
Azure DNS에서 해당 도메인 이름으로 DNS 영역을 만들기 위해 도메인을 소유할 필요는 없습니다. 하지만 도메인 이름 등록 기관에 도메인 이름의 올바른 이름 서버로 Azure DNS 이름 서버를 구성하려면 도메인을 소유해야 합니다.
자세한 내용은 Azure DNS에 도메인 위임을 참조하세요.
DNS 레코드
레코드 이름
Azure DNS에서는 상대 이름을 사용하여 레코드를 지정합니다. FQDN(정규화된 do기본 이름)에는 영역 이름이 포함되지만 상대 이름은 포함되지 않습니다. 예를 들어 영역 contoso.com의 상대 레코드 이름 www는 정규화된 레코드 이름 www.contoso.com을 제공합니다.
루트 레코드는 DNS 영역의 루트(또는 루트)에 있는 DNS 레코드입니다. 예를 들어 DNS 영역에서 contoso.comapex 레코드에는 정규화된 이름 contoso.com 도 있습니다(이를 naked do라고도 함기본). 규칙에 따라 상대 이름 '@'은(는) apex 레코드를 나타내는 데 사용됩니다.
레코드 유형
각 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 레코드 컬렉션입니다. 대부분의 레코드 집합에는 단일 레코드가 포함됩니다. 그러나 레코드 집합에 둘 이상의 레코드가 포함된 위와 같은 예제는 드문 일이 아닙니다.
예를 들어 IP 주소 '134.170.185.46'(위의 첫 번째 레코드)을 가리키는 'contoso.com' 영역에 A 레코드 'www'를 이미 만들었다고 가정합니다. 두 번째 레코드를 만들려면 추가 레코드 집합을 만드는 대신 기존 레코드 집합에 해당 레코드를 추가합니다.
SOA 및 CNAME 레코드 유형은 예외입니다. DNS 표준에서는 이러한 유형의 이름이 같은 여러 레코드를 허용하지 않으므로 이러한 레코드 집합은 단일 레코드만 포함할 수 있습니다.
Time-to-Live
TTL(Time to Live)은 쿼리되기 전에 클라이언트에서 각 레코드를 캐시하는 기간을 지정합니다. 위의 예제에서 TTL은 3600초 또는 1시간입니다.
Azure DNS에서 TTL은 각 레코드가 아닌 레코드 집합에 대해 지정되므로 해당 레코드 집합 내의 모든 레코드에 동일한 값이 사용됩니다. 1에서 2,147,483,647초 사이의 TTL 값을 지정할 수 있습니다.
Wild카드 레코드
Azure DNS는 야생카드 레코드를 지원합니다. 와일드카드 레코드는 이름이 일치하는 모든 쿼리에 대한 응답으로 반환됩니다(와일드카드가 아닌 레코드 집합에서 가까운 일치 항목이 없는 경우). Azure DNS는 NS 및 SOA를 제외한 모든 레코드 종류에 대해 와일드카드 레코드 집합을 지원합니다.
와일드카드 레코드 집합을 만들려면 레코드 집합 이름 '*'를 사용합니다. 또는 맨 왼쪽의 레이블로 '*'가 포함된 이름을 사용할 수 있습니다(예: '*.foo').
CAA 레코드
CAA 레코드를 사용하면 도메인 소유자가 자신의 도메인에 대한 인증서를 발급할 권한이 있는 CA(인증 기관)를 지정할 수 있습니다. 이 레코드는 CA가 일부 환경에서는 인증서가 착오 발급하는 것을 방지할 수 있습니다. CAA 레코드에는 다음 세 가지 속성이 있습니다.
- 플래그: 이 필드는 RFC6844마다 특별한 의미를 갖는 중요한 플래그를 나타내는 데 사용되는 0과 255 사이의 정수입니다.
- 태그: 다음 중 하나일 수 있는 ASCII 문자열입니다.
- 문제: 인증서를 발급할 수 있는 CA를 지정하려는 경우(모든 형식)
- issuewild: 인증서를 발급할 수 있는 CA를 지정하려는 경우(wild카드 인증서만 해당)
- iodef: 권한이 없는 인증서 발급 요청에 대해 알릴 수 있는 메일 주소 또는 호스트 이름을 지정합니다.
- 값: 선택한 특정 태그의 값입니다.
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 레코드를 편집하여 수동으로 업데이트할 수 있습니다.
SPF 레코드
SPF(Sender Policy Framework) 레코드는 도메인 이름 대신 이메일을 전송할 수 있는 이메일 서버를 지정하는 데 사용합니다. 수신자가 전자 메일을 정크 메일로 표시하지 않도록 하려면 SPF 레코드의 올바른 구성이 중요합니다.
DNS RFC는 원래 이 시나리오를 지원하기 위한 새로운 SPF 레코드 유형으로 소개되었습니다. 이전 이름 서버를 지원하기 위해 TXT 레코드 형식을 사용하여 SPF 레코드를 지정할 수도 있습니다. 이러한 모호성으로 인한 혼란은 RFC 7208로 해결되었습니다. TXT 레코드 형식을 사용하여 SPF 레코드를 만들어야 한다고 명시되어 있습니다. 또한 SPF 레코드 유형이 더 이상 사용되지 않는다고 나와 있습니다.
SPF 레코드는 Azure DNS에서 지원되며 TXT 레코드 종류를 사용하여 만들어야 합니다. 사용되지 않는 SPF 레코드 형식은 지원되지 않습니다. DNS 영역 파일을 가져올 때 SPF 레코드 형식을 사용하는 모든 SPF 레코드는 TXT 레코드 형식으로 변환됩니다.
SRV 레코드
SRV 레코드 는 다양한 서비스에서 서버 위치를 지정하는 데 사용됩니다. Azure DNS에서 SRV 레코드를 지정하는 경우:
- 서비스와 프로토콜은 ‘_sip._tcp.name’과 같이 밑줄로 접두사를 지정하여 레코드 집합 이름의 일부로 지정되어야 합니다. 영역 apex에 있는 레코드의 경우 레코드 이름에 ‘@’을 지정하지 않아도 되며 서비스와 프로토콜만 사용합니다(예: ‘_sip._tcp’).
- 우선 순위, 가중치, 포트 및 대상은 레코드 집합에 있는 각 레코드의 매개 변수로 지정됩니다.
TXT 레코드
TXT 레코드는 도메인 이름을 임의의 텍스트 문자열에 매핑하는 데 사용됩니다. 특히 SPF(보낸 사람 정책 프레임워크) 및 Do기본Keys 식별 메일(DKIM)과 같은 전자 메일 구성과 관련된 여러 애플리케이션에서 사용됩니다.
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 정책에서 지정할 수 없습니다.
Etags
두 사람 또는 두 개의 프로세스가 동시에 DNS 레코드를 수정하려고 한다고 가정합니다. 어느 쪽이 성공할까요? 그리고 승자는 다른 사용자가 만든 변경 내용을 덮어썼다는 것을 알고 있을까요?
Azure DNS는 Etag를 사용하여 동일한 리소스에 대한 동시 변경 내용을 안전하게 처리합니다. Etag는 Azure Resource Manager 'Tags'에서 분리됩니다. 각 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> | PUT은 리소스가 존재하고 Etag가 일치하는 경우에만 성공합니다. |
| If-match * | 리소스가 있는 경우에만 PUT 성공 |
| If-none-match * | 리소스가 없는 경우에만 PUT이 성공합니다. |
제한
Azure DNS를 사용할 때 적용되는 기본 제한은 다음과 같습니다.
공용 DNS 영역
| 구독당 퍼블릭 DNS 영역 | 250 1 |
| 공용 DNS 영역당 레코드 집합 | 10,000 1 |
| 공용 DNS 영역에서 설정된 레코드당 레코드 | 20 |
| 단일 Azure 리소스에 대한 별칭 레코드 수 | 20 |
1 이러한 제한을 늘려야 하는 경우 Azure 지원에 문의하세요.
'IT > 보안' 카테고리의 다른 글
| GPG 자료 암호화/복호화하기 (0) | 2024.04.17 |
|---|---|
| Internal Server Error, 서버 500 에러는 어떤 경우에 발생하나요? (0) | 2023.11.29 |
| 이메일 전달성을 위한 SPF 및 DKIM 설정 (0) | 2023.11.11 |
| 빠른 시작: 이메일 통신 서비스에 사용자 지정 확인된 도메인을 추가하는 방법 (0) | 2023.11.11 |
| 스푸핑을 방지할 수 있도록 SPF 설정 (0) | 2023.11.11 |