| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- httpasswd
- SQL
- aws-loadbalacner-controller
- saa-c03 #saa #aws certified solutions architect - associate
- helm_release
- NAT
- 코드커버리지
- s3
- docker
- dns
- fruition
- 테라폼
- instances failed to join cluster
- Terraform
- 에이전트 구성
- jenkins
- 스터브
- 추가 보안 그룹
- node group
- kubernetes
- ingestion
- 클러스터 보안 그룹
- Pipeline
- assumerole
- Gateway
- route53
- 에이전트 유형
- IRSA
- 이렇게 하면 된다
- aws ses #aws lambda
- Today
- Total
cloudwithbass
[DNS] DNS 구성 요소와 이름 풀이 과정, 레코드 타입 본문
목차
1. DNS구성 요소
DNS에선 아래와 같이 세 종류의 구성 요소가 있습니다.
- 스터브 리졸버
- 풀 리졸버에게 이름 풀이를 요청합니다.
- 주로 OS에 내장되어 있습니다.
- 풀 리졸버
- 실제로 이름 풀이를 수행합니다.
- 인터넷 상의 서버에 질의하기 때문에 공인 IP를 할당하는 것이 일반적입니다.
- 대표적으로 구글이나 클라우드 플레어의 8.8.8.8, 1.1.1.1 같은 오픈 리졸버가 있습니다.
- 권한이 있는 서버(네임 서버)
실제론 스터브 리졸버와 풀 리졸버에 '포워더'라는 구성 요소도 존재합니다.
포워더는 스터브 리졸버와 풀 리졸버 간 질의와 응답을 중계합니다.
Forwarder와 Conditional Forwarding 차이 (출처: https://blog.naver.com/mschoi72/221996559578)
Conditional Forwards
: DNS서버가 가지고 있지 않은 외부 레코드에 대해 쿼리가 들어오게 되면 DNS 서비스는 Root Hits 라는 DNS 루트 서버 리스트를 이용하여 외부 DNS로 쿼리를 하게 됩니다. 만약 이 Root Hits 가 없다면 외부 DNS 레코드에 대해서는 어디로 쿼리를 해야 할지 모르기 때문에 쿼리가 실패하게 됩니다. 그런데 문제는 Root Hits 를 사용하게 되면 어디 루트 DNS 서버를 통해서 외부 쿼리가 되는지 정확히 알 수 없고 신뢰할 수 있는 DNS 서버로 부터 값을 가지고 오는 것이지 등 등을 알 수 없는 상황이 될 수 있기 때문에 만약 어떤 특정 도메인에 대해서는 특정 외부 DNS를 설정할 수 있습니다. 이렇게 설정한 DNS서버를 Conditional Forwards 라고 표현합니다. 그렇다면 Conditional Forwards 가 있으면 일반 Forward 도 있지 않을 까요? 맞습니다. 어떤 조건이 필요없이 모든 외부 DNS에 대해 무조건적으로 Forwarding 하는 DNS 서버는 그냥 Forwarder 라고 표현합니다
[이름 풀이 과정]
아래는 test.kr 도메인에 대해 처음으로 이름 풀이를 하는 예시 과정입니다.

1. 스터브 리졸버 호출
클라이언트가 이름 풀이가 필요하면 스터브 리졸버를 호출합니다.
Windows OS에선 DNSClient라는 서비스가 스터브 리졸버 역할을 담당합니다.

2. 스터브 리졸버가 풀 리졸버에 질의
- 스터브 리졸버가 직접 이름 풀이하는 게 아닌, 풀 리졸버에게 이름 풀이를 요구합니다.
3. 풀 리졸버가 루트의 네임서버에 질의
- 루트 존의 네임 서버는 .kr 네임 서버의 정보인 'b.dns.kr'을 응답합니다.
- 풀 리졸버는 이 정보를 캐싱합니다.
- 풀 리졸버는 루트 서버 리스트를 갖고 있고, 갱신하기 위한 구조도 마련되어 있습니다.
4. 풀 리졸버가 .kr의 네임 서버에 질의
- .kr 네임 서버는 test.kr의 네임 서버인 'ns1.test.kr'을 응답합니다.
- 풀 리졸버는 이 정보를 캐싱합니다.
5. 풀 리졸버가 test.kr의 네임 서버에 질의
- ns1.test.kr은 test.kr의 네임 서버이므로 test.kr의 IP를 관리합니다.
- 따라서 이 때 1.1.2.3이라는 IP를 응답하며, 풀 리졸버는 이 정보를 캐싱합니다.
6. 풀 리졸버가 스터브 리졸버에 응답
- test.kr의 IP 주소는 1.1.2.3이라고 응답합니다.
[캐시와 네거티브 캐시]
DNS 처리 효율을 높이기 위해 캐시와 네거티브 캐시를 사용합니다.
캐싱한 내용이 있으면 이제 같은 질의에 대해선 이름 풀이를 수행하지 않고 바로 응답할 수 있습니다.
네거티브 캐시란, '존재하지 않는다'라는 결과도 캐싱하는 동작입니다.
이 결과를 캐싱하지 않으면 존재하지 않는 결과에 대해 반복적으로 이름 풀이하는 경우가 발생합니다.
[네임 서버의 가용성]
네임 서버가 여러 개일 경우, zone의 데이터를 각 네임 서버에 복사해야 합니다.
이를 존 전송(zone transfer)이라고 합니다.
이 때 데이터를 전송하는 서버를 primary server, 데이터를 받는 서버를 secondary server라고 합니다.
네임 서버가 여러개면 풀 리졸버는 RTT(Round Trip Time)값으로 질의할 네임 서버를 선택합니다.
RTT는 질의 후 응답이 돌아오기까지의 시간입니다.
[풀 리졸버의 가용성]
스터브 리졸버는 질의 대상으로 여러 풀 리졸버를 지정할 수 있습니다.
이 경우 설정한 순서대로 질의를 요청합니다.
Windows OS에선 네트워크 연결 -> IPv4 설정에서 지정할 수 있습니다.

2. 네임 서버가 응답하는 정보
도메인 이름, TTL, 클래스, 레코드 타입, 데이터를 응답합니다.
TTL과 클래스는 생략할 수 있습니다.
| 레코드 타입 | 내용 |
| SOA | zone 관리에 관한 기본적인 정보 |
| NS | zone 위임에 관한 정보 |
| A | 도메인 이름에 대한 IPv4 주소 |
| AAAA | 도메인 이름에 대한 IPv6 주소 |
| MX | 메일 전송에 관한 정보 |
| CNAME | 도메인 이름에 대한 정식 이름 |
| TXT | 임의 문자열 |
| PTR | IP 주소에 대한 도메인 이름 |
[SOA 레코드]
Start of Authority, 즉 위임받은 존을 관리할 때 필요한 정보를 설정합니다.
dig naver.com soa
도메인 이름, TTL, 클래스 타입, 레코드, MNAME, RNAME, SERIAL NUMBER, REFRESH, RETRY, EXPIRE, MINIMUM 순서입니다.

- 클래스 타입: 현재는 IN(internet)만 사용됩니다.
- MANME: 이 zone의 primary server host name입니다.
- RNAME: zone 관리자의 메일입니다. RNAME의 메일 주소는 '@'를 '.'으로 변경해 설정합니다.
- SERIAL NUMBER: secondary server는 자신의 번호보다 큰 번호를 갖는 zone이 있다면 존 전송을 요구해서 최신화합니다.
- REFRESH: 이 시간이 지나면 자발적으로 존 데이터를 갱신합니다.
- RETRY: 존 데이터 갱신 실패 시 이 시간이 지나서 다시 시도합니다.
- EXPIRE: 이 시간까지 존 데이터 갱신에 실패하면 존 데이터 만료로 처리합니다.
- MINIMUM: 네거티브 캐시를 보유해도 되는 시간입니다.
[NS 레코드]
위임에 관한 정보를 NS 레코드로 설정합니다.
dig naver.com ns

도메인 이름, TTL, IN, NS, 네임 서버의 호스트 이름 순서입니다.
즉, naver.com 도메인은 ns1~3.naver.com 네임 서버들에서 관리합니다.
[A 레코드]
도메인 이름에 해당하는 IP 주소 정보를 설정합니다.
dig naver.com a

[MX 레코드]
메일 주소를 사용하기 위해선 우선 순위와 함께 MX 레코드로 네임 서버에 설정해야 합니다.
dig naver.com mx

도메인 이름, TTL, IN, MX, 우선 순위, 네임 서버의 호스트 이름 순서입니다.
우선 순위 값이 낮은 메일 서버부터 순서대로 메일 전송을 시도합니다.
[CNAME 레코드]
CNAME을 사용하면 외부 서비스를 다른 이름으로 이용할 수 있습니다.
예를 들어 aws alb의 도메인인 my-alb-123456.ap-northeast-2.elb.amazonaws.com를 alb.example.com으로 사용할 수 있게 합니다.
CNAME 레코드를 확인하면, 진짜 이름인 my-alb-123456.ap-northeast-2.elb.amazonaws.com에 대해 다시 한번 이름 풀이를 합니다.
[TXT 레코드]
도메인 이름 외 임의의 텍스트를 문자 정보로 추가할 수 있습니다.
dig naver.com txt

외부 서비스와 연동할 때, 이 도메인을 컨트롤할 수 있다는 것을 인증하기 위해 특정 값을 TXT 레코드로 설정하는 용도로도 사용됩니다. 사진에 있는 naver.com의 TXT 레코드도 그런 용도로 보입니다.
[PTR 레코드]
IP 주소에 대응하는 도메인 이름을 알아낼 수 있습니다.
DNS는 역순으로 조회하기 때문에 풀 리졸버가 IP 주소 표기를 역순으로 표기한 뒤, 마지막에 '.in-addr-arpa.'를 붙입니다.
ex) 192.0.2.3 -> 3.2.0.192.in-addr-arpa.
활용 예시
- 스팸 메일 필터
- 메일 서버가 메일 발송 서버의 IP를 이용하여 도메인을 조회(PTR)
- 다시 그 도메인의 IP를 조회해서 일치하지 않으면 수신 측에 보내지 않음
'Network' 카테고리의 다른 글
| [DNS] DNS의 등장 배경과 관리 체계 (0) | 2026.05.04 |
|---|---|
| [Network] MAC, ARP, VLAN에 대해 알아보자 (1) | 2025.02.09 |
| [Network] 스위치와 라우터 (6) | 2024.10.20 |
| [Network] HTTP 통신 (8) | 2024.10.19 |
| [Network] TCP/IP 소켓 통신과 Docker Socket (4) | 2024.10.18 |