지원되는 DNS 레코드 유형 - Amazon Route 53
레코드 유형AAAA 레코드 유형CAA 레코드 유형CNAME 레코드 유형DS 레코드 유형HTTPS 레코드 유형MX 레코드 유형NAPTR 레코드 유식NS 레코드 유형PTR 레코드 유형SOA 레코드 유형SPF 레코드 유형SRV 레코드 유형SSHFP 레코드 유형SVCB 레코드 유형TLSA 레코드 유형TXT 레코드 유형

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

지원되는 DNS 레코드 유형

Amazon Route 53은 이 섹션에 나열된 DNS 레코드 유형을 지원합니다. 각 레코드 유형 역시 API를 사용해 Route 53에 액세스할 때 Value 요소를 포맷하는 방법에 대한 한 가지 예를 포함합니다.

참고

도메인 이름을 포함하는 레코드 유형에 대해서는 예를 들어 www.example.com과 같은 전체 주소 도메인 이름을 입력합니다. 뒤에 오는 점은 선택 사항이며, Route 53은 도메인 이름을 전체 주소 도메인 이름으로 간주합니다. 다시 말해 Route 53은 www.example.com(뒤에 점 없음)과 www.example.com.(뒤에 점 있음)을 동일하게 처리합니다.

Route 53은 별칭 레코드라고 하는 DNS 기능에 대한 확장을 제공합니다. CNAME 레코드와 마찬가지로 별칭 레코드를 사용하면 CloudFront 배포 및 Amazon S3 버킷과 같은 선택한 AWS 리소스로 트래픽을 라우팅할 수 있습니다. 별칭 레코드와 CNAME 레코드의 비교를 포함한 자세한 내용은 별칭 또는 비 별칭 레코드 선택 단원을 참조하십시오.

레코드 유형

A 레코드에서 점이 있는 십진법으로 된 IPv4 주소를 사용하여 웹 서버와 같은 리소스로 트래픽을 라우팅합니다.

Amazon Route 53 콘솔에 대한 예제

192.0.2.1

Route 53 API에 대한 예제

<Value>192.0.2.1</Value>

AAAA 레코드 유형

AAAA 레코드에서 콜론으로 구분된 16진법 형식의 IPv6 주소를 사용하여 웹 서버와 같은 리소스로 트래픽을 라우팅합니다.

Amazon Route 53 콘솔에 대한 예제

2001:0db8:85a3:0:0:8a2e:0370:7334

Route 53 API에 대한 예제

<Value>2001:0db8:85a3:0:0:8a2e:0370:7334</Value>

CAA 레코드 유형

CAA 레코드는 도메인 또는 하위 도메인에 대한 인증서 발급이 허용되는 인증 기관(CA)을 지정합니다. CAA 레코드를 생성하면 잘못된 CA가 도메인에 대한 인증서를 발급하는 것을 방지하는 데 도움이 됩니다. CAA 레코드는 인증 기관에서 지정한 보안 요구 사항(예: 도메인의 소유자임을 확인하기 위한 요구 사항) 대신 사용할 수 없습니다.

CAA 레코드를 사용하여 다음을 지정할 수 있습니다.

  • SSL/TLS 인증서(있는 경우)를 발급할 수 있는 인증 기관(CA)

  • CA가 도메인 또는 하위 도메인에 인증서를 발급할 때 연락처의 이메일 주소 또는 URL

CAA 레코드를 호스팅 영역에 추가할 때 공백으로 구분하여 다음 세 가지 설정을 지정합니다.

flags tag "value"

CAA 레코드의 형식에 대해 다음을 알아 두십시오.

  • tag 값에는 A-Z, a-z, 0-9 등의 문자만 포함될 수 있습니다.

  • value는 항상 인용 부호("")로 묶습니다.

  • 일부 CA는 value에 대한 추가 값을 허용하거나 요구합니다. 이름-값 페어로 추가 값을 지정하고 세미콜론(;)으로 구분합니다. 예를 들면 다음과 같습니다.

    0 issue "ca.example.net; account=123456"

  • CA가 하위 도메인(예: www.example.com)에 대한 인증서 요청을 받았는데 해당 하위 도메인에 대해 아무런 CAA 레코드도 없는 경우, CA는 상위 도메인(예: example.com)용 CAA 레코드에 대한 DNS 쿼리를 제출합니다. 상위 도메인에 대한 레코드가 존재하고 인증서 요청이 유효한 경우 CA는 하위 도메인에 대한 인증서를 발행합니다.

  • CAA 레코드에 대해 지정할 값을 결정하려면 CA에 문의하는 것이 좋습니다.

  • 이름이 동일한 CAA 레코드와 CNAME 레코드를 생성할 수 없습니다. DNS에서 CNAME 레코드와 기타 다른 유형의 레코드에 대해 동일한 이름을 사용하지 못하도록 하기 때문입니다.

CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인

CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인하려면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다.

  • flags – 0

  • tag – issue

  • value - 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인하는 CA에 대한 코드

예를 들어, ca.example.net에서 example.com에 대한 인증서를 발행하도록 승인하려는 경우를 가정해 봅시다. 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.

0 issue "ca.example.net"

에 인증서 발급 AWS Certificate Manager 권한을 부여하는 방법에 대한 자세한 내용은 AWS Certificate Manager 사용 설명서의 CAA 레코드 구성을 참조하세요.

CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인

CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인하려면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다. 와일드카드 인증서는 도메인 또는 하위 도메인 및 모든 하위 도메인에 적용됩니다.

  • flags – 0

  • tag – issuewild

  • value - 도메인 또는 하위 도메인과 그 하위 도메인에 대한 인증서를 발행하도록 승인하는 CA에 대한 코드

예를 들어, ca.example.net에서 example.com에 대한 와일드카드 인증서(example.com과 example.com의 모든 하위 도메인에 적용되는 인증서)를 발행하도록 승인하려는 경우를 가정해 봅시다. 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.

0 issuewild "ca.example.net"

CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인하고 싶으면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다. 와일드카드 인증서는 도메인 또는 하위 도메인 및 모든 하위 도메인에 적용됩니다.

CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하지 못하도록 금지

CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하지 못하도록 금지하려면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다.

  • flags – 0

  • tag – issue

  • value – ";"

예를 들어, 어떤 CA에서도 example.com에 대한 인증서를 발행하지 못하도록 하려는 경우를 가정해 봅시다. 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.

0 issue ";"

어떤 CA에서도 example.com 또는 그 하위 도메인에 대한 인증서를 발행하지 못하도록 하려면 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.

0 issuewild ";"

참고

example.com에 대한 CA 레코드를 생성하고 다음 값을 둘 다 지정하면 ca.example.net 값을 사용하는 CA가 example.com에 대한 인증서를 발행할 수 있습니다.

0 issue ";"
0 issue "ca.example.net"

CA가 잘못된 인증서 요청을 수신하는 경우 CA가 사용자에게 연락하도록 요청

인증서에 대해 잘못된 요청을 수신하는 CA가 귀하에게 연락하도록 하려면 다음 설정을 지정합니다.

  • flags – 0

  • tag – iodef

  • value - CA가 인증서에 대해 잘못된 요청을 수신한 경우 CA가 알리려는 URL 또는 이메일 주소입니다. 해당하는 형식을 사용합니다.

    "mailto:email-address"

    "http://URL"

    "https://URL"

예를 들어, 인증서에 대해 잘못된 요청을 수신하는 CA가 admin@example.com으로 이메일을 보내도록 하려는 경우 다음 설정으로 CAA 레코드를 생성합니다.

0 iodef "mailto:admin@example.com"

CA에서 지원하는 다른 설정 사용

CA가 CAA 레코드에 대해 RFC에 정해지지 않은 기능을 지원하는 경우 다음 설정을 지정합니다.

  • flags - 128(이 값은 CA가 지정된 기능을 지원하지 않으면 인증서를 발행하지 못하도록 합니다.)

  • tag - CA가 사용하도록 승인한 태그

  • value - 태그의 값에 해당하는 값

예를 들어, CA가 잘못된 인증서 요청을 수신하는 경우 문자 메시지 전송 기능을 지원한다고 가정해 봅시다. (이 옵션을 지원하는 CA에 대해서는 알지 못합니다.) 레코드에 대한 설정은 다음과 같을 수 있습니다.

128 exampletag "15555551212"

예시

Route 53 콘솔에 대한 예제

0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"

Route 53 API에 대한 예제

<ResourceRecord>
   <Value>0 issue "ca.example.net"</Value>
   <Value>0 iodef "mailto:admin@example.com"</Value>
</ResourceRecord>

CNAME 레코드 유형

CNAME 레코드는 acme.example.com과 같은 현재 레코드의 이름에 대한 DNS 쿼리를 다른 도메인(example.com or example.net) 또는 하위 도메인(acme.example.com or zenith.example.org)으로 매핑합니다.

중요

DNS 프로토콜을 사용하면 Zone Apex라고 하는 DNS 네임스페이스의 최상위 노드에 대한 CNAME 레코드를 생성할 수 없습니다. 예를 들어, DNS 이름 example.com을 등록하면 zone apex는 example.com입니다. example.com에 대한 CNAME 레코드를 생성할 수는 없지만, www.example.com, newproduct.example.com 등에 대한 CNAME 레코드는 생성할 수 있습니다.

뿐만 아니라, 하위 도메인에 대한 CNAME 레코드를 생성하면, 그 하위 도메인에 대해서는 다른 레코드를 생성할 수 없습니다. 예를 들어 www.example.com에 대한 CNAME을 생성한 경우, 이름 필드의 값이 www.example.com인 다른 레코드는 생성할 수 없습니다.

또한 Amazon Route 53는 CloudFront 배포 및 Amazon S3 버킷과 같은 선택한 AWS 리소스로 쿼리를 라우팅할 수 있는 별칭 레코드를 지원합니다. 별칭들은 어떤 면에서 CNAME 레코드 유형과 유사하지만, zone apex에 대한 별칭을 생성할 수 있습니다. 자세한 내용은 별칭 또는 비 별칭 레코드 선택 단원을 참조하십시오.

Route 53 콘솔에 대한 예제

hostname.example.com

Route 53 API에 대한 예제

<Value>hostname.example.com</Value>

DS 레코드 유형

DS(Delegation Signer) 레코드는 위임된 하위 도메인 영역의 영역 키를 참조합니다. DNSSEC 서명을 구성할 때 신뢰 체인을 설정하면 DS 레코드를 만들 수 있습니다. Route 53의 DNSSEC 구성에 관한 정보는 Amazon Route 53에서 DNSSEC 서명 구성 섹션을 참조하세요.

처음 세 개의 값은 키 태그, 알고리즘 및 다이제스트 유형을 나타내는 10진수입니다. 네 번째 값은 영역 키의 다이제스트입니다. DS 레코드 유형에 대한 자세한 내용은 RFC 4034를 참조하세요.

Route 53 콘솔에 대한 예제

123 4 5 1234567890abcdef1234567890absdef

Route 53 API에 대한 예제

<Value>123 4 5 1234567890abcdef1234567890absdef</Value>

HTTPS 레코드 유형

HTTPS 리소스 레코드는 확장 구성 정보를 제공하는 서비스 바인딩(SVCB) DNS 레코드의 한 형태로, 클라이언트가 HTTP 프로토콜을 사용하여 서비스에 쉽고 안전하게 연결할 수 있습니다. 구성 정보는 여러 DNS 쿼리가 필요하지 않고 하나의 DNS 쿼리에서 연결을 허용하는 파라미터로 제공됩니다.

HTTPS 리소스 레코드의 형식은 다음과 같습니다.

SvcPriority TargetName SvcParams(optional)

다음 파라미터는 RFC 9460, 섹션 9.1에 설명되어 있습니다.

SvcPriority

우선 순위를 나타내는 정수입니다. 우선 순위 0은 별칭 모드를 의미하며 일반적으로 영역 정점에서 별칭을 지정하기 위한 것입니다. 이 값은 Route 53의 정수 0-32767이며,이 중 1-32767은 서비스 모드 레코드입니다. 우선 순위를 낮추고 기본 설정을 높입니다.

TargetName

별칭 대상(별칭 모드의 경우) 또는 대체 엔드포인트(ServiceMode의 경우)의 도메인 이름입니다.

SvcParams(선택 사항)

각 파라미터가 Key=Value 페어 또는 독립 실행형 키로 구성된 공백으로 구분된 목록입니다. 값이 두 개 이상인 경우 쉼표로 구분된 목록으로 표시됩니다. 다음은 정의된 SvcParams입니다.

  • 1:alpn - 애플리케이션 계층 프로토콜 협상 프로토콜 IDs. 기본값은 HTTP/1.1이고, h2는 TLS를 통한 HTTP/2이며, h3는 HTTP/3(QUIC 프로토콜을 통한 HTTP)입니다.

  • 2:no-default-alpn - 기본값은 지원되지 않으므로 alpn 파라미터를 제공해야 합니다.

  • 3:port - 대체 엔드포인트 또는 서비스에 연결할 수 있는 포트입니다.

  • 4:ipv4hint - IPv4 주소 힌트.

  • 5:ech - 암호화된 클라이언트 Hello.

  • 6:ipv6hint – IPv6 주소 힌트.

  • 7:dohpath – HTTPS를 통한 DNS 템플릿

  • 8:ohttp - 서비스가 Oblivious HTTP 대상을 운영합니다.

별칭 모드용 Amazon Route 53 콘솔의 예

0 example.com

서비스 모드용 Amazon Route 53 콘솔의 예

16 example.com alpn="h2,h3" port=808

별칭 모드용 Amazon Route 53 API의 예

<Value>0 example.com</Value>

서비스 모드용 Route 53 API의 예

<Value>16 example.com alpn="h2,h3" port=808</Value>

자세한 내용은 RFC 9460, DNS를 통한 서비스 바인딩 및 파라미터 사양(SVCB 및 HTTPS 리소스 레코드)을 참조하세요.

참고

Route 53는 임의의 알 수 없는 키 프레젠테이션 형식을 지원하지 않습니다. keyNNNNN

MX 레코드 유형

MX 레코드는 메일 서버의 이름을 지정하고, 두 개 이상의 메일 서버가 있는 경우 우선 순위를 지정합니다. MX 레코드의 각 값마다 다음과 같은 두 가지 값인 우선 순위와 도메인 이름이 포함됩니다.

우선순위

이메일 서버의 우선 순위를 나타내는 정수. 서버를 1개만 지정하는 경우 우선 순위는 0~65535의 정수가 될 수 있습니다. 서버를 다수 지정하는 경우 우선 순위로 지정하는 값은 이메일이 라우팅되는 이메일 서버의 순서를 의미합니다. priority 값이 가장 낮은 서버가 우선 순위를 갖습니다. 예를 들어 이메일 서버가 2개이고 우선 순위로 10과 20을 지정하면, 사용할 수 없는 경우를 제외하고 이메일이 항상 우선 순위가 10인 서버로 라우팅됩니다. 하지만 10과 10으로 지정하면 이메일이 거의 동일하게 두 서버로 라우팅됩니다.

도메인 이름

이메일 서버의 도메인 이름. A 또는 AAAA 레코드의 이름(예: mail.example.com)을 지정합니다. RFC 2181, Clarifications to the DNS Specification의 단원 10.3에서는 도메인 이름 값에 CNAME 레코드의 이름 지정을 금지합니다. (RFC에서 언급하는 "별칭"은 Route 53 별칭 레코드가 아닌 CNAME 레코드를 의미합니다.)

Amazon Route 53 콘솔에 대한 예제

10 mail.example.com

Route 53 API에 대한 예제

<Value>10 mail.example.com</Value>

NAPTR 레코드 유식

이름 인증 포인터(NAPTR)는 하나의 값을 또 다른 값으로 변환하거나 대체하기 위해 Dynamic Delegation Discovery System(DDDS) 애플리케이션에서 사용하는 레코드의 유형입니다. 예를 들어, 하나의 일반적인 용도는 전화번호를 SIP URI로 변환하는 것입니다.

NAPTR 레코드의 Value 요소는 공백으로 구분된 6개의 값으로 구성되어 있습니다.

Order

레코드를 두 개 이상 지정할 때 DDDS 애플리케이션이 레코드를 평가하도록 할 시퀀스입니다. 유효한 값은 0~65535입니다.

기본 설정

[Order]가 동일하게 지정된 레코드를 세 개 이상 지정할 경우 이러한 레코드가 평가되는 시퀀스에 대한 기본 설정입니다. 예를 들어, 두 개의 레코드에 [Order]가 1로 지정된 경우 DDDS 애플리케이션이 더 낮은 [Preference]이 적용되는 레코드를 먼저 평가합니다. 유효한 값은 0~65535입니다.

플래그

DDDS 애플리케이션에 고유한 설정입니다. RFC 3404에 현재 정의된 값은 대문자 및 소문자 ["A"], ["P"], ["S"] 및 ["U"]와 빈 문자열 [""]입니다. [Flags]는 인용 부호로 묶여 있습니다.

Service

DDDS 애플리케이션에 고유한 설정입니다. [Service]는 인용 부호로 묶여 있습니다.

자세한 내용은 관련 RFC를 참조하십시오.

Regexp

DDDS 애플리케이션에서 입력 값을 출력 값으로 변환하는 데 사용하는 정규식입니다. 예를 들어, IP 전화 시스템에서 사용자가 입력한 전화번호를 SIP URI로 변환하는 정규식을 사용할 수 있습니다. [Regexp]는 인용 부호로 묶여 있습니다. [Regexp]의 값 또는 [Replacement]의 값 중 하나만 지정합니다.

정규식에 다음과 같은 인쇄 가능한 ASCII 문자를 포함할 수 있습니다.

  • a-z

  • 0~9

  • - (하이픈)

  • (공백)

  • ! # $ % & ' ( ) * + , - / : ; < = > ? @ [ ] ^ _ ` { | } ~ .

  • "(인용 부호) 문자열에 리터럴 따옴표를 포함하려면 \ 문자를 앞에 입력합니다(\").

  • \ (backslash). 문자열에 백슬래시를 포함하려면 \ 문자를 앞에 입력합니다(\\).

다국어 도메인 이름과 같은 기타 모든 값은 8진수 형식으로 지정합니다.

Regexp에 대한 구문을 보려면 RFC 3402, 3.2절 대체식 구문을 참조하십시오.

대체

DDDS 애플리케이션에서 DNS 쿼리를 제출하도록 할 다음 도메인 이름의 정규화된 도메인 이름(FQDN)입니다. DDDS 애플리케이션이 입력 값을 [Replacement]에 지정하는 값으로 대체합니다(있는 경우). [Regexp]의 값 또는 [Replacement]의 값 중 하나만 지정합니다. Regexp의 값을 지정하는 경우에는 점(.)을 교체에 지정합니다.

도메인 이름에 a-z, 0-9 및 -(하이픈)을 포함할 수 있습니다.

DDDS 애플리케이션 및 NAPTR 레코드에 대한 자세한 내용은 다음 RFC를 참조하십시오.

Amazon Route 53 콘솔에 대한 예제

100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .

Route 53 API에 대한 예제

<ResourceRecord>
   <Value>100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .</Value>
   <Value>100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .</Value>
   <Value>100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .</Value>
</ResourceRecord>

NS 레코드 유형

NS 레코드는 호스팅 영역에 대한 이름 서버를 식별합니다. 다음 사항에 유의하세요.

  • NS 레코드의 가장 일반적인 용도는 도메인에 대해 인터넷 트래픽이 라우팅되는 방식을 제어하는 것입니다. 호스팅 영역의 레코드를 사용하여 도메인의 트래픽을 라우팅하려면 기본 NS 레코드에 있는 네 개의 이름 서버를 사용하도록 도메인 등록 설정을 업데이트합니다. 이는 호스팅 영역과 이름이 같은 NS 레코드입니다.

  • 하위 도메인(acme.example.com)에 대해 별도의 호스팅 영역을 생성하고 해당 호스팅 영역을 사용하여 하위 도메인과 그 하위 도메인(subdomain.acme.example.com)에 대한 인터넷 트래픽을 라우팅할 수 있습니다. 루트 도메인(example.com)에 대한 호스팅 영역에 다른 NS 레코드를 생성하여 “하위 도메인에 대한 책임을 호스팅 영역으로 위임”이라고 하는 이 구성을 설정합니다. 자세한 내용은 하위 도메인에 대한 트래픽 라우팅 단원을 참조하십시오.

  • 또한 NS 레코드를 사용하여 화이트 레이블 이름 서버를 구성합니다. 자세한 내용은 화이트 레이블 이름 서버 구성 단원을 참조하십시오.

NS 및 SOA 레코드에 대한 자세한 내용은 Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드 단원을 참조하십시오.

Amazon Route 53 콘솔에 대한 예제

ns-1.example.com

Route 53 API에 대한 예제

<Value>ns-1.example.com</Value>

PTR 레코드 유형

PTR 레코드는 IP 주소를 해당 도메인 이름에 매핑합니다.

Amazon Route 53 콘솔에 대한 예제

hostname.example.com

Route 53 API에 대한 예제

<Value>hostname.example.com</Value>

SOA 레코드 유형

권한 시작(SOA) 레코드에는 도메인 및 해당 Amazon Route 53 호스팅 영역에 대한 정보가 제공됩니다. SOA 레코드의 필드에 대한 자세한 내용은 Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드 단원을 참조하십시오.

Route 53 콘솔에 대한 예제

ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60

Route 53 API에 대한 예제

<Value>ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60</Value>

SPF 레코드 유형

SPF 레코드는 이전에는 이메일 메시지 발신자의 자격 증명을 확인하는 데 사용되었습니다. 그러나 레코드 유형이 SPF인 레코드 생성은 권장하지 않습니다. RFC 7208, 즉 Sender Policy Framework(SPF) for Authorizing Use of Domains in Email, Version 1(이메일에서 도메인 사용을 인증하기 위한 메일 서버 등록제, 버전 1)은 "...[RFC4408]에 정의된 그 존재 및 메커니즘은 어떤 상호 운용성 문제로 귀결되었다. 따라서 SPF 버전 1에 대해 그것을 사용하는 것은 이제 적절하지 않다. 구현은 그것을 사용해서는 안 된다"라는 내용으로 업데이트되었습니다. RFC 7208에서는 14.1 섹션인 SPF DNS 레코드 유형을 참조하십시오.

저희는 SPF 레코드 대신에 해당되는 값을 포함하는 TXT 레코드를 생성하도록 권장합니다. 유효한 값에 대한 자세한 내용은 Wikipedia 기사 Sender Policy Framework를 참조하십시오.

Amazon Route 53 콘솔에 대한 예제

"v=spf1 ip4:192.168.0.1/16 -all"

Route 53 API에 대한 예제

<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>

SRV 레코드 유형

SRV 레코드 Value 요소는 공백으로 구분된 4개의 값으로 구성되어 있습니다. 처음의 세 값은 우선 순위, 가중치, 포트를 나타내는 10진수들입니다. 4번째 값은 도메인 이름입니다. SRV 레코드는 이메일 또는 통신용 서비스 등의 서비스에 액세스하는 데 사용됩니다. SRV 레코드 유형에 대한 자세한 내용은 연결할 서비스의 설명서를 참조하세요.

Amazon Route 53 콘솔에 대한 예제

10 5 80 hostname.example.com

Route 53 API에 대한 예제

<Value>10 5 80 hostname.example.com</Value>

SSHFP 레코드 유형

Secure Shell 지문 레코드(SSHFP)는 도메인 이름과 연결된 SSH 키를 식별합니다. 신뢰 체인을 설정하려면 SSHFP 레코드를 DNSSEC로 보호해야 합니다. DNSSEC에 대한 자세한 내용은 섹션을 참조하세요. Amazon Route 53에서 DNSSEC 서명 구성

SSHFP 리소스 레코드의 형식은 다음과 같습니다.

[Key Algorithm] [Hash Type] Fingerprint

다음 파라미터는 RFC 4255에 정의되어 있습니다.

키 알고리즘

알고리즘 유형:

  • 0 - 예약되어 있고 사용되지 않습니다.

  • 1: RSA – Rivest–Shamir–Adleman 알고리즘은 최초의 퍼블릭 키 암호화 시스템 중 하나이며 보안 데이터 전송에 여전히 사용되고 있습니다.

  • 2: DSA - 디지털 서명 알고리즘은 디지털 서명을 위한 연방 정보 처리 표준입니다. DSA는 모듈식 지수와 이산 로그 수학 모델을 기반으로 합니다.

  • 3: ECDSA - 타원 곡선 디지털 서명 알고리즘은 타원 곡선 암호화를 사용하는 DSA의 변형입니다.

  • 4: Ed25519 – Ed25519 알고리즘은 SHA-512(SHA-2) 및 Curve25519를 사용하는 EdDSA 서명 체계입니다.

  • 6: Ed448 – Ed448은 SHAKE256 및 Curve448을 사용하는 EdDSA 서명 체계입니다.

해시 유형

퍼블릭 키 해시를 생성하는 데 사용되는 알고리즘:

  • 0 - 예약되어 있고 사용되지 않습니다.

  • 1: SHA-1

  • 2: SHA-256

지문

해시의 16진수 표현입니다.

Amazon Route 53 콘솔에 대한 예제

1 1 09F6A01D2175742B257C6B98B7C72C44C4040683

Route 53 API에 대한 예제

<Value>1 1 09F6A01D2175742B257C6B98B7C72C44C4040683</Value>

자세한 내용은 RFC 4255: DNS를 사용하여 SSH(Secure Shell) 키 지문을 안전하게 게시하기를 참조하세요.

SVCB 레코드 유형

SVCB 레코드를 사용하여 서비스 엔드포인트에 액세스하기 위한 구성 정보를 전달합니다. SVCB는 일반 DNS 레코드이며 다양한 애플리케이션 프로토콜의 파라미터를 협상하는 데 사용할 수 있습니다.

SVCB 리소스 레코드의 형식은 다음과 같습니다.

SvcPriority TargetName SvcParams(optional)

다음 파라미터는 RFC 9460, 섹션 2.3에 설명되어 있습니다.

SvcPriority

우선 순위를 나타내는 정수입니다. 우선 순위 0은 별칭 모드를 의미하며 일반적으로 영역 정점에서 별칭을 지정하기 위한 것입니다. 우선 순위를 낮추고 기본 설정을 높입니다.

TargetName

별칭 대상(별칭 모드의 경우) 또는 대체 엔드포인트(ServiceMode의 경우)의 도메인 이름입니다.

SvcParams(선택 사항)

각 파라미터가 Key=Value 페어 또는 독립 실행형 키로 구성된 공백으로 구분된 목록입니다. 값이 두 개 이상인 경우 쉼표로 구분된 목록으로 표시됩니다. 이 값은 Route 53의 정수 0-32767이며,이 중 1-32767은 서비스 모드 레코드입니다. 다음은 정의된 SvcParams입니다.

  • 1:alpn - 애플리케이션 계층 프로토콜 협상 프로토콜 IDs. 기본값은 HTTP/1.1이고, h2는 TLS를 통한 HTTP/2이며, h3는 HTTP/3(QUIC 프로토콜을 통한 HTTP)입니다.

  • 2:no-default-alpn - 기본값은 지원되지 않으므로 alpn 파라미터를 제공해야 합니다.

  • 3:port - 서비스에 연결할 수 있는 대체 엔드포인트의 포트입니다.

  • 4:ipv4hint - IPv4 주소 힌트.

  • 5:ech - 암호화된 클라이언트 Hello.

  • 6:ipv6hint – IPv6 주소 힌트.

  • 7:dohpath – HTTPS를 통한 DNS 템플릿

  • 8:ohttp - 서비스가 Oblivious HTTP 대상을 운영합니다.

별칭 모드용 Amazon Route 53 콘솔의 예

0 example.com

서비스 모드용 Amazon Route 53 콘솔의 예

16 example.com alpn="h2,h3" port=808

별칭 모드용 Amazon Route 53 API의 예

<Value>0 example.com</Value>

서비스 모드용 Route 53 API의 예

<Value>16 example.com alpn="h2,h3" port=808</Value>

자세한 내용은 RFC 9460, DNS를 통한 서비스 바인딩 및 파라미터 사양(SVCB 및 HTTPS 리소스 레코드)을 참조하세요.

참고

Route 53는 임의의 알 수 없는 키 프레젠테이션 형식을 지원하지 않습니다. keyNNNNN

TLSA 레코드 유형

TLSA 레코드를 사용하여 명명된 엔터티의 DNS 기반 인증(DANE)을 사용합니다. TLSA 레코드는 인증서/퍼블릭 키를 TLS(전송 계층 보안) 엔드포인트와 연결하고 클라이언트는 DNSSEC로 서명된 TLSA 레코드를 사용하여 인증서/퍼블릭 키를 검증할 수 있습니다.

도메인에서 DNSSEC가 활성화된 경우에만 TLSA 레코드를 신뢰할 수 있습니다. DNSSEC에 대한 자세한 내용은 섹션을 참조하세요. Amazon Route 53에서 DNSSEC 서명 구성

TLSA 리소스 레코드의 형식은 다음과 같습니다.

[Certificate usage] Selector [Matching type] [Certificate association data]

다음 파라미터는 RFC 6698, 섹션 3에 지정되어 있습니다.

인증서 사용

TLS 핸드셰이크에 제공된 인증서와 일치시키는 데 사용할 제공된 연결을 지정합니다.

  • 0: CA 제약 - 인증서 또는 퍼블릭 키는 TLS에서 서버에서 제공하는 최종 엔터티 인증서의 퍼블릭 키 인프라(PKIX) 인증 경로에서 찾을 수 있어야 합니다. 이 제약 조건은 지정된 서비스에 대한 인증서를 발급하는 데 사용할 수 있는 CAs를 제한합니다.

  • 1: 서비스 인증서 제약 조건 - 서버에서 TLS로 제공한 최종 엔터티 인증서와 일치해야 하는 최종 엔터티 인증서(또는 퍼블릭 키)를 지정합니다. 이 인증은 호스트의 지정된 서비스에서 사용할 수 있는 최종 엔터티 인증서를 제한합니다.

  • 2: 신뢰 앵커 어설션 - TLS에서 서버에서 제공하는 최종 엔터티 인증서를 검증할 때 “신뢰 앵커”로 사용해야 하는 인증서(또는 퍼블릭 키)를 지정합니다. 도메인 관리자가 트러스트 앵커를 지정할 수 있습니다.

  • 3: 도메인 발급 인증서 - TLS에서 서버에서 제공한 최종 엔터티 인증서와 일치해야 하는 인증서(또는 퍼블릭 키)를 지정합니다. 이 인증을 통해 도메인 관리자는 타사 CA를 사용하지 않고 도메인에 대한 인증서를 발급할 수 있습니다. 이 인증서는 PKIX 검증을 통과할 필요가 없습니다.

Selector

핸드셰이크에서 서버에서 제공하는 인증서의 어떤 부분이 연결 값과 일치하는지 지정합니다.

  • 0: 전체 인증서가 일치해야 합니다.

  • 1: Subject Public Key 또는 DER 인코딩 바이너리 구조가 일치해야 합니다.

일치하는 유형

인증서 일치의 프레젠테이션(선택기 필드에 의해 결정됨)을 지정합니다.

  • 0: 콘텐츠의 정확한 일치.

  • 1: SHA-256 해시.

  • 2: SHA-512 해시.

인증서 연결 데이터

다른 필드의 설정에 따라 일치시킬 데이터입니다.

Amazon Route 53 콘솔에 대한 예제

0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971

Route 53 API에 대한 예제

<Value>0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971</Value>

자세한 내용은 RFC 6698, 명명된 엔터티의 DNS 기반 인증(DANE) 전송 계층 보안(TLS) 프로토콜: TLSA를 참조하세요.

TXT 레코드 유형

TXT 레코드는 큰따옴표(")로 묶여 있는 하나 이상의 문자열을 포함합니다. 간단한 라우팅 정책을 사용할 때 도메인(example.com) 또는 하위 도메인(www.example.com)에 대한 모든 값을 같은 TXT 레코드에 포함합니다.

TXT 레코드 값 입력

단일 문자열에는 다음을 포함하여 최대 255자가 포함될 수 있습니다.

  • a-z

  • A-Z

  • 0~9

  • 공간

  • - (하이픈)

  • ! " # $ % & ' ( ) * + , - / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ .

255자보다 긴 값을 입력해야 하는 경우, 값을 255자 이하의 문자열로 나누고 각 문자열을 큰따옴표(")로 묶습니다. 콘솔에서 모든 문자열을 같은 줄에 나열하십시오.

"String 1" "String 2" "String 3"

API의 경우 동일한 Value 요소에 모든 문자열을 포함시킵니다.

<Value>"String 1" "String 2" "String 3"</Value>

TXT 레코드의 최대 값 길이는 4,000자입니다.

TXT 값을 하나 이상 입력하려면 행당 하나의 값을 입력합니다.

TXT 레코드 값의 특수 문자

TXT 레코드에 다음 문자가 포함되어 있는 경우, \three-digit octal code 형식의 이스케이프 코드를 사용하여 문자를 지정해야 합니다.

  • 000 - 040 사이의 8진수 문자(0 - 32 사이의 10진수, 0x00 - 0x20 사이의 16진수)

  • 177 - 377 사이의 8진수 문자(127 - 255 사이의 10진수, 0x7F - 0xFF 사이의 16진수)

예를 들어 TXT 레코드의 값이 "exämple.com"인 경우 "ex\344mple.com"을 지정합니다.

ASCII 문자와 8진수 코드 간의 매핑을 위해 인터넷에서 "ASCII 8진수 코드"를 검색합니다. 한 가지 유용한 참조 웹 페이지는 ASCII Code - The extended ASCII table입니다.

문자열에 인용 부호(")를 포함하려면 인용 부호 앞에 백래시(\) 문자를 넣으십시오(즉, \").

TXT 레코드 값의 대문자 및 소문자

대/소문자가 유지되므로 "Ab"와 "aB"는 서로 다른 값임에 유의하십시오.

예시

Amazon Route 53 콘솔에 대한 예제

각 값을 별도의 라인에 입력합니다.

"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"

Route 53 API에 대한 예제

각 값을 별도의 Value 요소에 입력합니다.

<Value>"This string includes \"quotation marks\"."</Value>
<Value>"The last character in this string is an accented e specified in octal format: \351"</Value>
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>