DNS에서 사용되는 레코드 유형 - 3편
by softPine일단 기본적으로 AWS를 사용하고 있기에 AWS Route53에서 지원하는 DNS 레코드 유형을 정리해본다.
A 레코드
IPv4 주소를 사용하여 웹 서버와 같은 리소스로 트래픽을 라우팅 하는 역할
AAAA 레코드
A 레코드와 같은 용도지만 IPv6 주소를 사용한다.
CAA 레코드
Domain Record type Flags Tag Value
example.com. CAA 0 issue "SomeCA.com"
example.com. CAA 0 issue "amazon.com"
example.com. CAA 0 issue "amazontrust.com"
example.com. CAA 0 issue "awstrust.com"
example.com. CAA 0 issue "amazonaws.com"
example.com CAA 0 issue ";"
위 예제에서는 도메인 이름이 먼저 나오고 뒤이어 레코드 유형(CAA)이 나온다. flags 필드의 값은 항상 0. tags 필드는 issue 또는 issuewild일 수 있다. 필드가 issue이고 value 필드에 CA 서버의 도메인 이름을 입력하는 경우 CAA 레코드는 지정된 서버가 요청된 인증서를 발급할 권한이 있음을 나타낸다. value 필드에 세미콜론(;)을 입력하면 CAA 레코드는 어떤 CA에서도 인증서를 발급할 권한이 없음을 나타낸다. CAA 레코드의 구성은 DNS 공급자의 따라 달라진다.
CAA의 tag 필드 값
명시한다. issuewild의 경우는 issue와 같으며 와일드카드 인증서에 대한 권한을 나타낸다.
CNAME 레코드
CNAME 레코드는 캐노니컬 네임 레코드(Canonical Name Record), 줄여서 CNAME 레코드라 불린다. 이 레코드는 하나의 도메인 네임을 다른 이름(별칭)으로 매핑시키는 레코드이다. 예를 들면 softpine.dev 도메인을 blog.softpine.dev처럼 Subdomain을 매핑시킬 때 사용한다. CNAME을 사용 시 이점은 하나의 IP 주소로부터 여러 개의 서비스를 실행할 때 관리하기 편해진다. IP 변경이 이뤄지더라도 A 레코드 하나만 변경하면 되기 때문이다. 이 CNAME 레코드는 무조건 다른 도메인 네임을 가리켜야 하며 직접 IP 주소를 가리켜서는 안 된다.
MX 레코드
MX 레코드는 메일 서버의 이름을 지정하고, 두 개 이상의 메일 서버가 있는 경우 우선순위를 지정한다. MX 레코드의 각 값마다 다음과 같은 두 가지 값인 우선순위와 도메인 이름이 포함된다.
Priority
이메일 서버의 우선순위를 나타내는 정수. 서버를 1개만 지정하는 경우 우선순위는 0~65536의 정수가 될 수 있다. 서버를 다수 지정하는 경우 우선순위로 지정하는 값은 이메일이 라우팅되는 이메일 서버의 순서를 의미한다. Priority 값이 가장 낮은 서버가 우선순위를 갖는다. 예를 들어 이메일 서버가 2개이고 우선순위로 10과 20을 지정 시, 사용할 수 없는 경우를 제외하고 이메일이 항상 우선순위가 10인 서버로 라우팅 된다. 하지만 10, 10으로 지정하면 거의 동일하게 두 서버로 라우팅 된다.
도메인 이름
이메일 서버의 도메인 명. A 또는 AAAA 레코드의 값(mx.softpine.dev)을 지정한다. RFC 2181, Clarifications to the DNS Specification에 의하면 도메인 이름값에 CNAME 레코드의 이름 지정을 금지한다. 이 말은 즉 미리 A 또는 AAAA 레코드로 메일 서버(mx.softpine.dev)의 값이 설정되어 있어야 한다.
NAPTR 레코드
NAPTR 레코드는 DDDS 애플리케이션에서 사용하는 규칙을 저장하는 데 사용된다. 사실 이 레코드는 찾아봐도 잘 모르겠다... SIP 1의 서버 및 사용자 주소 매핑에서 인터넷 전화 통신의 응용 프로그램에서 가장 일반적으로 사용된다는데 추후에 사용하거나 이해가 된다면 업데이트를 해야 할 것 같다. 2
NS 레코드
NS 레코드는 '네임 서버'를 의미하며, 이 레코드는 어떤 DNS가 해당 도메인의 권한 있는 네임서버(실제 DNS 레코드를 갖고 있는 서버)인지 지시한다. 기본적으로 NS 레코드는 해당 도메인의 IP 주소를 찾기 위해 가야 할 곳을 알려준다.
PTR 레코드
기존 DNS의 역할과는 반대로 IP 주소를 DNS 명에 매칭을 시켜주는 레코드이다.
SOA 레코드
해당 도메인에 대해 네임서버가 인증(authoritative)된 자료를 갖고 있음을 의미하며, 해당 도메인에 대한 정보가 최적의 상태로 유지, 관리될 수 있도록 한다. SOA 레코드가 가지는 필드는 그 순서에 따라 설명을 하면 다음과 같다.
SOA 레코드 형식
domain.name. IN SOA hostname.domain.name. mailbox.domain.name.( serial-number refresh retry expire minimum-ttl )
각 필드 항목은 위 형식에서 IN SOA 이후의 항목에 대한 값들이다.
용도 구분 | SOA 필드 명칭 | 개요 |
마스터 네임 서버 표시 | mname | 'master name'의 약자. 마스터 네임서버의 도메인 이름을 설정함 |
존 관리자 연락처 표시 | rname | 'responsible name'의 약자. 도메인 존 관리자/담당자의 e-mail 주소를 도메인이름 형식으로 표현하여 설정 |
존 데이터 동기화 관리 기준 | serial refresh retry expire |
도메인 존의 갱신 버전번호 정보 설정. 도메인 존을 갱신하는 주기 시간을 초단위로 설정. 도메인 존 갱신여부 확인에 실패한 경우, 재시도 주기 시간을 초단위로 설정. 도메인 존 갱신이 실패하여 도메인에 대한 DNS 질의응답을 중단해야 하는 기간을 초단위로 설정. |
존에 없는 레코의 TTL 값 | minimum | 존에 없는 도메인/레코드에 응답 경우, 이 도메인/레코드(부재 도메인/레코드) 부재 정보의 캐싱에 적용하는 TTL 값 |
SPF 레코드
SPF 레코드는 이전에는 이메일 메시지 발신자의 자격 증명을 확인하는 데 사용되었다. 그러나 지금은 현재 SPF 레코드 생성은 권장하지 않는다. SPF 메커니즘의 단점으로 인한 운용 결함이 있어서 사용에 대한 권장을 지양하고 있다. AWS Route53은 SPF 레코드 대신 해당하는 값을 포함하는 TXT 레코드를 생성하도록 권장한다.
SPF Issue Link
SRV 레코드
SRV 레코드(Service Record)는 서비스와 호스트네임 사이의 연결을 하는 데 사용된다. 애플리케이션이 특정 서비스의 위치를 찾아야 하는 경우 관련된 SRV 레코드를 검색한다. 만약 해당 레코드를 찾게 되면 서비스 목록과 연결된 호스트네임을 검색하여 다음을 찾는다.
- Hostname
- Ports
- Priority & Weight
- ip Address ( 관련된 경우 )
이 SRV 레코드를 사용하게 되면 나중에 시간을 절약할 수 있다. 예를 들자면, 새로운 e-mail 클라이언트가 새로 구성된 경우 SRV 레코드에서 포트 및 기본 설정을 가져온다. SRV 레코드가 없으면 새 이메일 클라이언트는 이러한 기본 설정을 추측한다(일반적으로는 잘못한다).
SRV 레코드의 구조
Service | Protocol | Domain | Priority | Weight | Port | Target |
_imaps. | _tcp. | softpine.dev. | 10 | 20 | 993 | username.mail.pairserver.com. |
- Service
- 각 SRV 레코드는 언더스코어(_)로 시작되며 바로 다음에 서비스 명이 나온다. 이 서비스 명에는 SRV 레코드에서 사용되는 이름이 있으며 이 서비스 명은 정보를 알려준다. 이 서비스 명은 이전 글에서 언급한 IANA에서 관리하며 리스트를 확인하려면 다음 Link에서 확인할 수 있다.
- Protocol
- 다음 역시 언더스코어(_)로 시작을 알리며 프로토콜을 보여준다. 보통 TCP, UDP이다.
- Domain
- 다음은 서비스의 도메인 명이 보인다.
- Priority
- 다음은 우선순위이다. SRV 레코드는 종종 여러 서비스를 나열하므로 어떤 서비스를 먼저 확인해야 하는지 설정하기 위해 각 라인에 우선순위 번호가 부여된다. 이 값이 낮을수록 더 빨리 확인한다.
- Weight
- 둘 이상의 서비스가 동일한 우선순위를 갖는 경우 가중치 번호를 사용하여 먼저 오는 라인을 결정한다. 숫자가 높을수록 더 빨리 확인한다.
- Port
- 포트 번호는 선택 사항이며, 일반적으로 이메일과 관련된 포트에만 사용한다.
- Target
- 서비스를 제공하는 호스트의 이름이다. 마침표를 사용하여 끝을 알리는 데 사용한다. 만약 호스트 이름이 없다면 기본적으로 자기 자신의 내부를 설정하며, 이 호스트 이름이 마침표(.) 일 경우 서비스가 차단된다.
TXT 레코드
TXT 레코드(TXT record)는 호스트나 기타 이름과 임의의 텍스트를 연계하는 기능을 제공하기 위해 도메인 네임에 체계적으로 사용되는 리소스 레코드의 일종이다. 보편적으로 TXT 레코드를 사용하는 예는 다음과 같다.
종류 | 설명 |
DKIM 레코드 | 이 레코드는 전송중인 이메일의 유효성 검사에 사용되는 중요한 정보를 저장한다. |
DMARC 레코드 | Domain-based Message Authentication Reporting and Conformance의 약자. 피싱, 스푸핑 같은 이메일 공격에 대해 완화한다. |
SPF 레코드 | 위에 SPF 레코드와 같다. SPF 레코드 대신 TXT 레코드로 대체한다. 대게 이 레코드는 도메인에 대해 메일을 보낼 권한이 있는 호스트를 메일 교환에 표시하는 데 사용됩니다. |
Site Verification 레코드 | 이 레코드는 도메인의 소유권을 증명하며 Microsoft 365 및 G-Suite와 같은 서비스를 특정 도메인에 연결하는 데 사용할 수 있습니다. |
'IT 기반 지식 > DNS' 카테고리의 다른 글
DNS 원리와 동작 - 2편 (0) | 2021.03.19 |
---|---|
DNS란? - 1편 (0) | 2021.03.19 |
블로그의 정보
나의 삽질저장소
softPine