DNS

Solf·2024년 11월 18일

WEB

목록 보기

5/11

기본적인 구조

Fragment의 경우 원하는 요소의 id값을 적으면 해당 위치로 이동한다.

도메인 네임의 구조

도메인은 점으로 구분되며 오른쪽에서 왼쪽으로 읽는다.
인터넷의 IP를 직관적이고 외우기 쉽도록 별명을 지어준 것이 도메인이다.

DNS(Domain Name System)에 의해서 관리되며, 도메인 네임을 IP주소로 변환해주는 역할을 한다.
DNS에서 오른쪽부터 왼쪽으로 값을 읽으며 각 서버를 거쳐 최종적으로 우리가 원하는 도메인의 IP를 가져오게 된다.
이후 우리가 잘아는 통신이 이루어진다. 여기서 DNS Resolver(사용자가 가지는 최초의 DNS 서버)은 인터넷 회사가 보통 제공한다.

루트 도메인
웹사이트의 최상위 계층 루트이다. DNS 서버 이름을 (.)이라고 표기한다.
목록도 확인할 수 있다.
논리적으로는 13개가 존재하며 물리적인 서버는 1700여대 정도 된다고 한다.

최상위 도메인 (TLD, Top-Level Domain)
도메인 레벨 중에 가장 높은 단계에 있는 도메인이다. 도메인의 목적, 종류, 국가를 나타낸다.

N level Domain
그 뒤로 붙는 도메인들을 Second, Third이런식으로 붙인다.

왜 굳이 3개나 2개?
특별한 기능적 이유가 있다기보다 초창기에는 3개가 유행하다가 더 짧은 도메인이 외우기 쉽다보니 2개도 많이 쓰게 됐다.
이런 구조에서 별도로 domain name이나 sub domain이라는 용어를 맞춰서 쓰기도 하는데, 조사해보니 명확한 개념은 아닌거 같다.

URI vs URL vs URN

URI (Uniform Resource Identifier) = 자원 자체를 식별하는 방법
URL (Uniform Resource Locator) = 자원의 위치를 알려주는 방법
URN (Uniform Resource Name) = 자원의 이름

결국 모두 자원을 식별한다는 의미는 같으며, 굉장히 모호한 개념이다. 확실한 것은 URL이 URI의 부분집합인 것이다.
예를 들면 URI는 urn:isbn:0451450523이런 값도 될 수 있다.

url parameter value vs path value vs request body

API 문서에서 가끔 헷갈리기 때문에 정리한다.

url parameter : url에 포함되는 ?뒤의 속성값
path value : url의 경로에 포함되는 값
request body : 요청에 포함되는 값

DNS가 동작하는 원리

구글에 사용자가 접속해서 구글의 페이지가 나오는 상황까지를 그려보자.

1. IP 주소를 찾기

클라이언트는 브라우저에 DNS주소(www.google.com)를 입력한다.
브라우저 캐시를 확인한다. (www.google.com의 ip주소를 확인한다.)
브라우저에 없다면, 운영체제 캐시를 확인한다. (다른 브라우저가 요청했던 기록등을 확인하기 위해서)
그래도 없다면, 컴퓨터의 특수 파일 Hosts File을 확인한다.

2. 내 컴퓨터에서 찾을 수 없는 경우, 리커시브 DNS에 질문

통신사(ISP)에서 제공하는 리커시브 DNS에 주소를 물어본다.
리커시브 DNS 서버도 이 주소가 캐시에 없다면, root(최상위) DNS에 물어본다. (root는 .com에 대한 서버 주소를 안다)
TLD(Top-Level Domain) DNS에 요청 (.com과 같은 DNS이며, google.com에 대해서 물어본다)
TLD에서 관리하는 권한이 있는 네임서버에 물어본다.(google.com을 관리하는 서버이며, 진짜 아이피를 가지고 있다)

3. IP주소 획득 및 캐시 저장

리커시브 DNS 서버는 이렇게 알아낸 IP 주소를 자신의 캐시에 저장한다.
IP를 내 PC의 OS에 전달하게 된다.
OS는 이 IP 주소를 브라우저에게 전달

4. 서버와 실제 통신 시작(TCP/IP 통신)

TCP 3-way Handshake 진행 (SYN, SYN + ACK, ACK)
HTTP request 전송
브라우저가 response를 받아 렌더링

서버 개발자가 알아야할 DNS

서버 개발자라면 도메인 주소를 직접 구매해서 사용할 일이 발생한다. 주로 가비아, 카페24, AWS Route53을 사용하고는 하는데 이에 대해서 조금 더 자세히 알아보자.

1. 도메인 구매

정해진 기간동안 해당 도메인 이름에 대한 사용 권한을 임대하게 된다.
1. 등록 대행자(Registrar) 선택 :가비아 또는 AWS Route 53과 같은 등록 대행자를 통해 도메인을 등록한다. 이들은 ICANN(국제인터넷주소관리기구)의 공인을 받은 업체들이다.
2. 정보 등록 및 전파 : 이걸 구매한 나의 개인이나 회사의 정보와 돈을 주면, 등록 대행자는 TLD의 레지스트리에게 이를 전달한다. (ex com이라면 Versign, kr이라면 KISA)

2. 내 도메인의 NS(Name Server)지정

NS는 나의 도메인에 대한 IP를 확인하는 과정을 담당해줄 책임자라고 볼 수 있다.
1. Route53이던 가비아던 도메인을 구매후 상세 페이지에 가보면, ns-xxx.awsdns-xx.org나 ns1.gabia.co.kr같은 주소가 등록되어 있는데 여기에 등록된 것이 내 도메인의 NS이다. 이는 실제로 도메인을 판매하는 대행 서비스들이 운영중인 DNS의 주소이다. 이 NS는 TLD DNS에 이미 등록되어 있다.
2. 위에서 등록된 NS정보는 등록 대행자를 통해 TLD 서버에 전파되어 저장된다.(mydomain.com이 .com DNS서버에 저장된다고 볼 수 있다.)

이제 우리 도메인을 검색하면 우리 도메인의 TLD가 우리의 NS를 찾아오도록 한다.

3. NS에게 실제 주소 알려주기 (DNS Record)

아직 우리의 NS는 우리의 실제 IP주소를 모른다. 이걸 DNS Record 설정을 통해 알려준다.

Record의 종류

A 레코드 : 도메인 이름과 실제 공인 IP 주소를 등록하는 레코드
CNAME 레코드 : 특정 도메인 이름을 다른 도메인의 별명으로 지정하는 레코드
(ex www.mydomain.com -> mydomain.com)
AAA 레코드 : A레코드의 IPv6버전 레코드
MX 레코드 : 이메일 서버 주소 지정 레코드
TXT 레코드 : 도메인 소유권 인증 등 다양한 텍스트 정보를 저장하는 레코드

좀 더 다양하게 존재하지만 많이 사용하는건 위와 같다.