개요
얼마 전, 신규 해외 서비스를 오픈하며 개발과 운영 환경의 도메인을 매핑하는 작업을 진행했다.
개발 환경은 특이하게 Vercel이라는 자동 배포 및 서버리스 클라우드 플랫폼을 활용하고 있었다.(vercel은 Next,js 개발사인데, 그래서 Next.js 프로젝트 배포에 많이 사용되는 것 같다.)
작업 중 Vercel CDN 도메인에 개발용 도메인을 매핑하는 과정에서 진행이 막히는 부분이 발생했었는데, 원인을 파악하면서 내가 놓치고 있던 몇 가지 DNS 기본 개념과 동작 원리를 되돌아보게 되었다.
이번 글에서는 이 과정을 되짚어보며, DNS의 개념과 작동 원리, 그리고 Vercel 배포 시 발생했던 문제를 설명해보려 한다.
1. DNS 개념과 동작 원리
1.1 도메인(domain)과 DNS(domain name system)
도메인은 인터넷에 연결된 시스템을 사람이 쉽게 기억하고 입력할 수 있도록 문자로 만든 인터넷 주소이다. 도메인은 보통 웹사이트와 연결하기 위해 등록하는데, 이때 DNS 관리 서비스를 이용한다.
즉, 도메인은 문자열의 인터넷 주소이며, DNS(Domain Name System)는 이 도메인 이름을 시스템이 읽을 수 있는 IP 주소로 변환하는 것을 말한다.
1.2 일반 최상위 도메인(gTLD)
일반 최상위 도메인(Generic Top-Level Domains)은 특정 조직과 계열에 따라 사용되는 최상위 도메인이다.
.com, .net 등이 포함되어 있으며 다른 최상위 도메인들에 비해 오랜 역사를 가지고 있어 가격대가 낮고 시스템이 안정적이다.
일부를 제외면 신청 자격에 제한이 없다.
ex, .com, .net, .org, .biz 등…
1.3 국가 코드 최상위 도메인(ccTLD)
국가 코드 최상위 도메인(Country Code Top-Level Domains)은 국가 코드로 특정 국가나 지역을 나타낸다.
국가 코드는 일반적으로 ISO(국제 표준화 기구)에서 정한 ISO 3166-1 표준에 따르며,예외적으로 영국은 ISO 기준 약자는 GB이지만, 국가 도메인인 .uk이다.
국가 도메인을 나타낼 때는 언제나 앞에 점을 찍어 사용하는 것을 원칙으로 하고 있다.
ex, .kr(한국), .jp(일본), .us(미국), .uk(영국) 등…
1.4 2차 도메인(SLD)
SLD(2차 도메인)은 최상위 도메인 아래에 직접 위치한 도메인이다. 도메인 확장자라고도 불리며 도메인 이름의 첫 번째 부분이다.
예를 들면, cwdev.site 에서 cwdev 부분이 2차 도메인이다.
2차 도메인은 최상위 도메인과 결합되어 하나의 완전한 도메인 이름을 만든다.
2차 도메인은 등록자가 선택할 수 있으며, 특정 기업이나 개인의 고유 이름을 나타낼 수 있다.
(도메인은 전 세계에서 고유해야 하므로 도메인 등록기관을 통해서 등록해야 한다.)
1.5 루트 도메인과 서브 도메인
루트 도메인은 지금까지 설명한 최상위 도메인(TLD), 2차 도메인(SLD)를 합친, DNS의 최상위 계층이다..
루트 도메인은 베어 도메인(bare domain), 에이펙스 도메인(apex domain)으로도 부른다.
루트 도메인은 DNS 계층에서 최상위에 위치하고 있기 때문에, DNS 서버가 도메인 이름을 찾을 때 가장 먼저 참조하는 기준이 된다.
반면 서브 도메인은 최상위 도메인과 2차 도메인 아래에 위치한 추가적인 도메인으로, 특정 서비스를 구분하거나 웹사이트 내에서 다양한 섹션을 나누는데 사용된다.
예를 들면, www.cwsite.com에서 www부분이 서브 도메인이다..
# 전체 도메인 네이밍 구조
예시: www.cwsite.com
www . cwsite . com
<서브도메인>.<2차 도메인>.<최상위 도메인>
<--------루트 도메인------->다시 정리하자면, 루트 도메인은 DNS 트리에서 최상위에 있고, 그 아래 최상위 도메인, 2차 도메인, 서브 도메인이 위치하는 구조로 이루어져 있다.
1.6 도메인과 URL의 차이점
- 도메인(Domain): 도메인은 문자열의 인터넷 주소로, DNS 서버를 통해 IP 주소로 변환시켜 연결된다.
- URL(Uniform Resoruce Locator): 도메인을 포함한 접근 경로. 프로토콜+도메인+경로로 나타난다.
즉 도메인은 인터넷 주소이며, URL은 인터넷 주소를 포함한 인터넷 자원의 전체 주소이다.. 도메인은 URL의 일부분이며, URL은 특정 위치를 지정하는 더 구체적인 주소라고 볼 수 있다.
1.7 DNS의 흐름
위 도메인 개념에서 DNS는 도메인 이름을 IP주소로 변환하는 역할을 한다고 했었는데, IP 주소로 변환하며 대상을 찾아가는 과정에 대해서 동작하는 원리와 과정을 설명해보겠다.
DNS의 동작 과정은 다음과 같다.
| 1. 웹사이트 접속 요청 |
|
| 2. 로컬 DNS 캐시 확인 |
|
| 3. DNS 질의 시작 |
|
| 4. 루트 DNS 서버의 IP 주소 조회 |
|
| 5. TLD DNS 서버 정보 얻기 |
|
| 6. Authoritative DNS 서버의 IP 주소 얻기 |
|
| 7. IP 주소 조회 |
|
| 8. IP 주소 캐시 저장 및 웹사이트 표시 |
|
1.8 Root DNS 서버
Root DNS 서버는 인터넷에서 가장 중요한 DNS 서버 중 하나이다. 전 세계적으로 분산되어 있으며, 인터넷 상의 모든 도메인 이름에 대한 최상위 DNS 서버로, DNS 시스템의 핵심 역할을 담당한다.
루트 도메인 이름을 관리하며(ex, .com), TLD DNS 서버의 IP 주소를 알고 있다.
즉, 위 DNS 동작 과정에서 설명한 내용처럼 Root DNS 서버는 TLS DNS 서버의 IP 주소를 반환하고 사용자의 DNS 쿼리는 TLS DNS 서버로 전달된다.
- Root DNS 서버는 ICANN(Internet Corporation for Assigned Names and Numbers)에서 관리된다.
1.9 TLD DNS 서버
TLD DNS 서버는 인터넷에서 사용되는 최상위 도메인 이름(Top-Level Domain)을 관리하는 DNS 서버이다.
.com, .org, .edu 등과 같이 최상위 도메인 이름에 대한 DNS 서버로, 각 도메인 이름의 DNS 쿼리를 처리한다.
TLD DNS 서버는 각 TLD 도메인 이름에 대한 IP 주소와 기타 DNS 레코드 정보를 관리한다.
예를 들어, .com 도메인 이름에 대한 TLD DNS 서버는 .com 도메인 이름에 대한 모든 DNS 쿼리를 처리합니다. 이러한 DNS 쿼리는 해당 도메인 이름에 대한 IP 주소를 찾는 것이 주된 목적이다.
- TLD DNS 서버도 Root DNS와 마찬가지로 ICANN에 등록되어 있으며, 해당 TLD 도메인 이름을 사용하는 등록 업체와 협력하여 정보를 업데이트한다.
1.10 Second-Level DNS 서버(Authoritative DNS 서버)
Second-Level DNS는특정 도메인 이름에 대한 IP 주소 정보를 제공하는 DNS 서버이며, 일반적으로 도메인/호스팅 업체의 네임서버를 말한다.
또한 해당 도메인 이름에 대한 정보를 가지고 있는 최종적인 답변자 역할을 한다. 예를 들어 cwdev.site 도메인 이름에 대한 IP 주소를 알고 있는 DNS 서버가 있다면 , 해당 DNS 서버는 Second-Level DNS 서버가 된다.
(ex, 가비아, 후이즈, AWS Route53, Ncloud global DNS 등…)
2. DNS 레코드 종류
DNS 레코드는 DNS에서 도메인 이름과 해당 도메인과 연결된 IP 주소를 매핑하는 데 사용되는 데이터 항목이다. DNS 레코드는 도메인 이름과 관련된 정보를 담고 있으며, DNS 쿼리를 수행하는 서버에 의해 사용된다.
자주 접하는 DNS 레코드 종류는 다음과 같다.
| A 레코드 |
|
| CNAME 레코드 |
|
| MX 레코드 |
|
| NS 레코드 |
|
| TXT 레코드 |
|
| SPF (Sender Policy Framework) 레코드 |
|
| SRV (Service) 레코드 |
|
| AAAA 레코드 |
|
| SOA (Start of Authority) 레코드 |
|
3. 도메인 연결 방법
도메인 연결 방법은 간단한데, 보통 각 도메인 구입처나, AWS, NCP 등 클라우드 DNS 서비스에 등록하여 사용하는 방법이 있다.
나는 vercel 사례와 비슷하게 서버(혹은 IP)에 직접 매핑하는 것이 아닌 운영중인 github 웹 페이지에 CNAME 레코드로 개인 도메인을 매핑하는 실습을 진행해보겠다.
3.1 개인 사이트 연결해보기(A 레코드 설정하여 변경)
기존 내 github에서 운영중인 chanw-pack.github.io 사이트에 가비아에서 구매한 도메인을 연결해보겠다.
(정확히는 가비아에서 대행으로 구매를 해준다는 개념이다.)
! 필자는 가비아로 진행하였지만 여러 도메인 관리 업체 모두 동일한 방식이니 등록 방법보다는 위 설명한 개념적인 부분을 이해하기 위해 확인해본다고 생각하시면 좋습니다.
가비아에 로그인 후, My가비아로 이동한다.
My가비아에 접근하면 구매한 도메인 정보를 확인할 수 있다.
설정할 도메인으로 이동하면 DNS 레코드 설정 항목이 있다.
DNS 레코드 설정에서 resume 라는 서브도메인을 CNAME 타입으로 레코드 생성을 진행하였다.
즉, resume.cwdev.site 로 이동하면 기존 chanw-pack.github.io 사이트로 이동하게 된다.
도메인이 적용된 것을 확인한다.
4. ROOT 도메인에서 CNAME 사용이 가능할까?
이제 DNS 및 도메인 설명에서 돌아와 vercel 사용중 발생한 문제에 대해서 상세히 설명해보겠다.
현재 개발서버에 이미 A도메인을 연결하여 사용중이다.(vercel 사용중)
이 때, 새로운 B 도메인을 매핑하여, 두 도메인을 사용하려고 한다. (두 도메인 모두 사용되어야 한다.)
4.1 환경 소개 및 가능 여부 파악
- 개발팀에게 요청받은 요구사항
- cname / cwdev.site / cname.vercel-dns.com (문제되는 요청)
- cname / www.cwdev.site / cwdev.site
- A / admin.cwdev.site / 123.123.456.78
ROOT 도메인을 CNAME 레코드 타입으로 생성하는것은 여러 방식에 따라 가능할 수 있다. 하지만 결론부터 말하자면, 위 요청은 우리 환경에서는 불가능했다.
https://blog.enyou.net/ko/archives/517
왜 CNAME은 ROOT에서 쓸 수 없는가? PTR 레코드란 무엇인가? – Enyou’s Atelier
왜 CNAME은 ROOT에서 쓸 수 없는가? PTR 레코드란 무엇인가? 글쓴이 연유 날짜 2020년 4월 30일2020년 4월 30일 개요 도메인 등록 회사를 구글 도메인으로 바꾸면서 도메인의 루트에 CNAME을 등록할 수 없
blog.enyou.net
요약하면, 다음 DNS 표준 규칙으로 제약 사항이 있다.
그 이유를 상세히 확인해보겠다.
1. 현재 본인은 후이즈에서 도메인을 구입하였고, NCP GlobalDNS로 네임서버를 변경하여 사용중에 있다.
2. 위 요구사항 중, 루트 도메인을 CNAME으로 지정해야하는 사항이 있다.그러나 CNAME은 일반적으로는 루트에 등록할 수 없다.
- SOA와 NS 레코드는 루트 도메인에서 반드시 표현되어야 한다. (RFC 1912)
- DNSSEC의 SIG, NXT, KEY RR 레코드를 제외하고서는 CNAME 레코드는 다른 레코드와 같이 쓰일 수 없다. (RFC 2181)
- 물론, 기술적으로 완전히 강제되는것은 아니다. 사용하는 도메인 서비스마다 루트 도메인에 CNAME 레코드를 허용하기도 한다. AWS의 경우에도 Route53에 등록할 시, 외부 시스템은 불가하지만 내부(ex,EC2등) 서비스끼리는 루트 도메인의 CNAME 구성이 가능하다.(alias 매핑으로 가능합니다.)
- 그러나 vercel DNS는 클라우드 플랫폼 외 시스템이라 alias 매핑이 불가하며 A 레코드 또한 vercel DNS가 CDN 처럼 계속 IP가 변경되기 때문에 A레코드로도 할당할 수 없는 상황이다.
4.2 대처방안
1. NCP Global DNS에서 AWS Route53으로 전환
(AWS Route53은 루트 도메인을 CNAME으로 사용 가능하다는 이야기를 얼핏 들은 것 같다.)
- 일단 route53에서도 루트 도메인에 대해 cname으로 사용이 불가하다.
- 단, alias를 통해 aws 내부 서비스에는 가능하다.
- 그래서 aws cli를 통해 직접 대상을 넣는다면, alias를 외부 도메인을 넣을 수도 있을법하다.
- 안됨…
4.3 결론
루트 도메인 사용이 필요한 vercel 레코드를 A 레코드로 사용하도록 변경 요청하여 해결하였다.
5. 마치며
이번 작업에서 root 도메인은 CNAME 레코드 사용 불가하며, 클라우드의 alias 레코드는 내부 서비스에만 연결 가능하다는 사실을 알게 되었습니다. (AWS는 가능할 줄 알았네요.. 😅)
결국 Vercel의 CNAME 레코드를 A 레코드로 변경하여 문제를 해결했지만, 작업을 진행하면서 root 도메인에 CNAME 매핑이 불가능하다는 DNS 정책을 미리 인지했더라면 더 수월하게 작업을 마칠 수 있었을 거란 아쉬움이 남았습니다.
지금까지 많은 도메인 관련 작업을 진행해왔지만, 이번 경험을 통해 도메인의 기본 개념과 구조, 다양한 레코드 타입, 그리고 DNS 표준 규칙으로 인한 제약들의 중요성을 다시 한 번 체감했습니다. 근래 최신 인프라는 점점 더 복잡해지고, 고도화된 기술 능력을 요구하고 있지만, 이런 도메인, URL, DNS 등 기초적인 CS 지식이야말로 기반이 된다는 점을 깨닫게 되는 시간이였습니다.
다음은 SSL 인증서와 도메인 운영 작업에 대해서 제가 경험했던 사례들을 공유해보는 포스팅을 이어가보겠습니다.
읽어주셔서 감사합니다.🙇♂️
+여담. id 도메인의 사용 인증
예전에 cwdev.id라는 도메인을 사용하는데 해당 도메인이 사용이 불가한 상황이 발생했었다.
확인해보니 도메인 Status가 clientHold 상태로 나타났다.
이에 후이즈에 문의해보니, .id 도메인의 경우 등록완료 후 인증이 완료되어야 사용이 가능하다고 한다.. (SSL 인증서와 비슷합니다.)
다시 전달받은 메일로 인증 후 정상 동작을 확인하였다.
최상위 도메인별로 인증이 따로 발생할 수 있는점, 염두해두시면 좋을 것 같습니다.
참고자료
https://blog.enyou.net/ko/archives/517
https://velog.io/@jangsebari/route53-을-이용하여-vercel-도메인-변경
https://velog.io/@gun_123/Route-53-CNAME-vs-Alias
https://velog.io/@jungmyeong96/AWS-SAA-Route53-TTL-CNAME-ALIAS
https://vercel.com/docs/projects/domains/add-a-domain
https://vercel.com/docs/projects/domains/managing-dns-records
https://aws.amazon.com/ko/route53/what-is-dns/
https://blog.daouidc.com/blog/domain-definition-0
https://sudo-minz.tistory.com/13
'DevOps > Network_네트워크' 카테고리의 다른 글
| [정보보안] SSL 인증서의 동작 원리 및 종류 (+암호화 원리, 유형, 알고리즘) (0) | 2025.01.31 |
|---|---|
| [OpenVPN] OpenVPN Server 구축(Linux) (0) | 2024.11.17 |
| [VPN] FortiGate(Fortinet) SSL-VPN 설정 (0) | 2023.07.18 |
| [NetWork] IPSEC VPN 개념과 2가지 모드 (0) | 2023.07.18 |
| [NetWork] SSL VPN 개념과 유형 (0) | 2023.07.17 |
