티스토리 뷰

반응형

컴퓨터가 브라우저에서 웹을 접속하는 첫 과정으로, 웹 브라우저에 웹사이트 주소(예를 들어, https://www.google.com)를 입력하면 실제 홈페이지가 열린다. 

 

근데, 생각해보면 모든 서버는 고유한 주소(IP 주소)로 이루어져 있다. 그럼, 브라우저에 "https://www.google.com"를 입력하면 이것이 IP 주소로 자동 변환되는 것인가? 브라우저에 모든 서버에 대한 주소를 담고 있는 것인가? 모든 서버에 대한 주소를 담고 있으면, 새로 생성된 서버에 대한 주소는 누가 가지고 있는 것인가?

 

우리가 모르는 번호가 있으면 전화로 114에 물어보고, 모르는 것이 있으면 구글링이 있듯이, 브라우저도 해당 주소에 대하여 모르면 "구글링"을 수행한다.

 

이때, 114 안내소, 구글 검색처럼 홈페이지의 주소를 실제 서버 주소("https://www.google.com" => 142.250.207.100)로 안내해주는 서버가 있으니, 이를 우린 DNS 서버라 부른다.

 

웹의 첫 이정표를 담당하는 DNS에 대하여 알아보자.

 

DNS
DNS에 대하여 알아보자.


1. DNS?

 

DNS(Domain Name Service)란 호스트 이름을 IP 주소로 변환해주는 일종의 응용프로그램 서비스이다. 사람은 이름, 주민번호, 면허증 등 여러 정보를 바탕으로 특정할 수 있듯이, 각 서버들은 네트워크 패킷 등을 식별하기 위하여 IP 주소를 사용한다.

 

그러나, 사람이 이 IP 주소를 달달 외울 수는 없었다. 사람도 모든 지인의 전화번호를 외울 수 없듯이, 컴퓨터가 이를 모두 외우기에는 많은 자원 소모가 들어간다. 또한, 사람은 주로 회사와 관련된 도메인을 외우지, 실제 IP 주소를 외우는 사람은 없다. (구글 주소를 www.google.com로 외우지, 142.250.207.100로 외우는 변태는 보통 없다.)

 

따라서, 이 도메인과 www.google.com  <=> 142.250.207.100로 서로 매핑해주는 네임 서비스가 필요했으니, 이는 DNS의 탄생이다.

 

DNS 서비스는 이에 대한 요구로 전세계적으로 생성되었으며, 현재도 수 천 개의 DNS 서버가 고루 분포되어 있다.

 

자신이 사용하는 DNS를 알고싶다면(정확히 컴퓨터에 담긴 DNS 캐시나 사전에 설정된 DNS를 알고 싶다면), 윈도우일 경우 터미널에 "ipconfig /displaydns"를 치거나, 리눅스일 경우 "$ cat /etc/resolv.conf"에서 확인할 수 있다.

 

실제 패킷 감청 도구인 Wireshark를 통해 DNS 서버와의 통신을 알아보자.


2. DNS 서버와의 통신

 

DNS 서버와의 통신을 간단히 하면 다음의 단계를 거친다.

 

  1. User 호스트는 DNS Application의 클라이언트쪽 앱을 실행한다.
  2. 브라우저는 접속하고자 하는 호스트 이름을 추출한다.(ex. https://www.google.com)
  3. 이때, DNS 클라이언트는 DNS 서버에 호스트 이름과 함께 쿼리를 보낸다.(www.google.com의 IP 주소가 뭐야?)
  4. DNS 서버는 DNS 클라이언트의 쿼리에 알맞은 IP 주소를 보낸다.(www.google.com의 IP 주소는 x.x.x.x야.)
  5. 브라우저가 IP 주소를 수신하면, 해당 서버에 TCP 연결을 수행한다.

 

직접 네트워크 패킷을 뜯어보며 이 과정을 살펴보자. Wireshark는 윈도우 OS의 환경에서 진행되었다.

 

DNS 서버에 GDSC Yonsei 신촌 캠퍼스 홈페이지(https://gdsc.community.dev/yonsei-university-seoul-campus/)에 쿼리를 보내보자. 이에 앞서, 다음 두 명령을 통해 DNS 주소 캐시를 지우고, DNS 캐시가 지워진 것을 확인하자

ipconfig /flushdns
ipconfig /displaydns

이제, Wireshark를 키고, 직접 GDSC Yonsei에 접속하여보자!


2-1) DNS 패킷

Wireshark에 패킷 스니핑을 한 결과 중 GDSC Yonsei 신촌 캠퍼스 홈페이지 DNS 쿼리, 응답은 각각 2043번 패킷, 4115번 패킷에서 찾을 수 있었다.

DNS 쿼리 사진
DNS 쿼리 패킷. 2043번 패킷이다.
DNS 응답문
DNS 응답 패킷. 4115번 패킷이다.

현재 사용된 DNS 서버 주소는 1.0.0.1(cloudflare 회사의 DNS라 알고 있다.)이고, 이에 대한 쿼리 패킷은 위와 같다.

 

DNS 패킷의 특징을 하나하나씩 살펴보자. Network layer로 IP 프로토콜, Transport layer로 UDP 프로토콜이 사용된 것을 확인할 수 있다. DNS 요청과 응답은 신뢰도보다 속도가 중요하기에, TCP보다 UDP가 더 적합하다. 다만, 특수한 상황에서는 DNS도 TCP 프로토콜을 사용할 수 있다.

 

이제, DNS 관련 헤더를 분석하여보자.

 

2-1-1) ID (Transaction ID)

ID는 클라이언트의 요청과 응답을 비교하기 위하여 있는 필드로, 같은 응답일 경우 같은 숫자를 가진다. (TCP의 sequence number와 비슷한 개념으로 생각하면 된다.)

 

2-1-2) Flags

Flags는 DNS 패킷의 여러 종류의 옵션을 선택하는 필드이다. 다음과 같이 여러 세부 필드가 있다.

 

  • Response

Response는 이 패킷이 요청인지 응답인지 구분해주는 필드이다. 0일 경우 요청(query), 1일 경우 응답(response)이다.

 

  • Opcode

Opcode는 요청이 어떤 종류인지에 대한 정보를 담은 필드이다. 다음과 같이 정리할 수 있다.

 

Opcode 종류
0 Query / Response = "www.google.com"의 주소 좀 알려주세요!" / "www.google.com의 주소는..."
1 Inverse Query = "xxx.xxx.xxx.xxx"가 누군지 알려주세요!"
2 Status = "지금 DNS 서버 상태가 어때요?"
4 Notify = "현재 DNS 관련 정보가 변경되었어요. 준비하세요!"
5 Update = "지금 보내는 정보로 바꾸어주세요!"
3, 6 ~ 15 Unassigned (해당 flag에 대한 정보는 없음)

 

  • Authoritative

Authoritative는 해당 DNS 서버가 도메인을 관리하는 네임 서버인지를 알려주는 필드이다. 해당 DNS 서버가 쿼리 도메인을 관리하는 서버라면 1, 아니라면 0이 채워진다.

 

  • Truncated

Truncated는 DNS 쿼리가 정해진 길이(512 바이트)를 초과하여서 정보가 파편화 되어있는지 표시하는 필드이다. 만약, DNS 서버가 쿼리문이 파편화되었다면, TCP 프로토콜을 사용해 다시 쿼리를 전송하도록 한다.

 

  • Recursion Desired

만약 내가 입력한 도메인이 DNS서버 에 없을 수 있다. 이 경우 어떻게 DNS 서버는 처리할까? 이에 대하여 두 가지 방법이 있다. 사람으로 비유하면 다음과 같다.

 

철수한테 영희의 주소를 물어본다고 하자.

 

1. 철수가 모르면, 철수보고 다른 사람들에게 물어보라고 한 후, 이에 대한 대답을 철수한테 듣는다.

2. 철수가 모르면, 철수가 알려주는, 다른 사람에게 물어본다. 만약 다른 사람이 모른다면 그 사람이 알려주는 또 다른 사람에게 물어본다.

 

1번은 Recursive Query, 2번은 Iterated Query에 관한 내용이다. Recursive Query의 경우 내가 쿼리를 전송한 DNS 서버가 모를 경우, 그 서버가 다른 상위 계층 서버로 DNS 쿼리가 전달된다. Iterated Query의 경우 내가 쿼리를 전송한 DNS 서버가 모를 경우, 그 서버가 다른 DNS 서버 주소를 알려주며 클라이언트 측이 쿼리를 새로운 DNS 서버에 보내도록 한다.

 

Recursion Desired가 1이면 Recursive Query를 활용하고, 0이면 활용하지 말라는 의미이다. (0일 경우 보통 Iterated Query를 사용한다.)

 

  • Recursion Available

Recursion available는 응답한 DNS 서버가 Recursive Query가 사용 가능한 지 표시하는 필드이다. DNS 응답 패킷에만 존재하고, 1일 경우 Recursive Query가 가능하다는 의미이다.

 

  • Z(reserved)

Z 필드는 이후에 사용될 때를 대비하여 비워놓은 필드이다.

 

  • Answer Authenticated

Answer authernticated는 DNS 응답이 서버로부터 인증받은 패킷인지 나타내는 필드이다. DNS 응답에만 존재하며, 인증되었을 경우 1, 인증되지 않았을 경우 0이다.

 

  • Non-authenticated Data

Non-authenticated data 필드는 DNS 요청 혹은 응답이 확인되지 않은 패킷을 받아드릴 것인지에 대한 필드이다. 보통 0으로 설정되어, 확인되지 않은 내용은 거르게 된다.

 

  • Reply Code

Reply Code는 DNS 응답 상태에 관한 코드이다. 다음 주소에서 여러 응답 코드에 관한 정보를 알 수 있다. (https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6)

 

2-1-3) Questions

Questions의 경우 몇 개의 주소를 질의하는 지 나타내는 필드이다. 보통 한 개의 질의를 가지고 있으므로 1이 담겨있다.

 

2-1-3) Answer RRs(Answer Resource Record)

Answer RRs의 경우 DNS의 응답에서 답변의 개수를 뜻한다.

 

2-1-4) Authoritative RRs(Authoritative Resource Record)

Authoritative RRs의 경우 DNS의 응답에서 도메인을 관리하는 네임 서버의 개수를 뜻한다.

 

2-1-5) Additional RRs(Additional Resource Record)

Answer RRs의 경우 DNS의 응답에서 추가 정보의 개수를 의미한다.

 

2-1-6) Queries

Queries
Queries의 경우 다음과 같은 정보를 담고 있다.

Queries의 경우 구체적인 DNS 쿼리를 의미하며 name, type, class에 관한 정보를 담고 있다.

 

  • Name

Name의 경우 호스트 이름이 들어간다. 이 경우 알고싶은 사이트의 도메인 이름이 gdsc.community.dev이므로 이를 헥사 코드로 변환되어서 들어간다.

 

  • Type

Type의 경우 어떤 query(레코드)인지에 대한 정보가 들어가며, 이에 대한 내용은 쿼리에 대한 응답 패킷에서 설명하겠다.

 

  • Class

Class의 경우 현재 사용중인 네트워크를 알려준다. 일반적인 경우 IN(INternet)이며, 다른 네트워크일 경우 다른 알파벳이 들어간다.(예를 들어, CSNet의 경우 CS란 알파벳이 들어간다.)

 

2-1-7) Answers

Answers
Answers의 경우 다음과 같은 정보를 담고 있다.

Queries의 경우 구체적인 DNS 쿼리를 의미하며 name, type, class, TTL, Data length, RData에 관한 정보를 담고 있다.

 

  • Name

Name의 경우 호스트 이름이 들어간다. 보통 요청한 쿼리의 도메인 혹은 CNAME로 얻은 새로운 도메인이 들어간다.

 

  • Type

Type의 경우 쿼리의 유형과 관련된 정보가 담겨있다. 다음과 같은 종류의 레코드가 자주 사용된다.

Type 의미 예시
A IPv4와 도메인 주소간 매핑 www.google.com  => 142.250.207.100
AAAA IPv6와 도메인 주소간 매핑 www.google.com  => 1050:0000:0000:0000:0005:0600:300c:326b
CNAME 도메인과 별명 도메인 주소간 매핑 gdsc.community.dev <=> dsc.bevylabs.com
MX 도메인과 메일 서버간 매핑 google.com => imap.gmail.com / smtp.gmail.com
NS 도메인과 네임 서버간 매핑 google.com => ns1.google.com / ns2.google.com
PTR IP와 도메인 주소간 매핑 142.250.207.100 => www.google.com
SOA 도메인의 정보와 관련 레코드 네임 서버, 서버 갱신 주기, 시도 등 여러 정보 포함
TXT 텍스트 레코드 메모 레코드

 

  • Class

Class의 경우 현재 사용중인 네트워크를 알려준다. 일반적인 경우 IN(INternet)이며, 다른 네트워크일 경우 다른 알파벳이 들어간다.(예를 들어, CSNet의 경우 CS란 알파벳이 들어간다.)

 

  • TTL

TTL(Time-To-Live)의 경우 DNS 응답에 사용된 데이터를 캐시에 저장하고 있는 시간을 의미한다. TTL이 5분이라면 5분 동안은 캐시에 담고 정보를 갱신하지 않는다는 의미이다.

 

  • Data Length

Data Length의 경우 실제 정보(Rdata)의 길이를 의미한다.

 

  • Rdata

Rdata의 경우 실제 정보를 의미한다. A 혹은 AAAA의 경우 IP 주소, CNAME의 경우 다른 도메인 주소 등을 담고있다. 위의 패킷에서 gdsc.community.dev에 대한 CNAME으로 dsc.bevylabs.com을 담고 있는데, 실제 dsc.bevylabs.com에 접속할 경우 gdsc.community.dev에 접속되는 것을 확인할 수 있다.


2-2) DNS 서버

DNS 서버는 하나가 아니다. 하나일 경우 모든 DNS 쿼리를 감당할 수 없고, 서버를 점검해야할 경우나 서버가 터질 경우 굉장히 많은 문제가 생길 수 있다. (실제 지역 DNS 하나가 터지면 이런 상황이 생긴다. 하물며 사용자가 많은 DNS 서버가 터지면...)

 

따라서, DNS 서버는 자신들만의 계층을 이루고 있으며, 보통 Root DNS > TLD DNS > Authoritative DNS 계층을 이룬다. Local DNS는 조금 다른 역할을 수행한다.

 

Local DNS는 계층에 따로 속하지 않고, 클라이언트가 1차적으로 쿼리를 보내는 DNS 서버 역할을 수행한다. Local DNS는 각 회사, 개인, 기관, ISP 별로 하나씩 있으며, 만약 요청된 주소가 Local DNS에 매핑된 정보 혹은 캐싱된 정보가 없으면 Root DNS에 쿼리를 보낸다.

 

Root DNS의 경우 Local DNS의 쿼리를 받는 곳이며, 세계적으로 400여개의 Root DNS가 존재한다. 만약 요청된 주소가 Root DNS에 매핑된 정보 혹은 캐싱된 정보가 없으면 TLD DNS에 쿼리를 보낸다.

 

TLD(Top-Level Domain) DNS의 경우 Root DNS의 퀴리를 받는 곳이며, 최상위 도메인에 관한 정보를 담고 있는 DNS 서버이다. 가령 "https://www.google.com"에 대한 정보는 TLD DNS 서버 중 .com DNS 서버에서 찾을 수 있다. 만약 요청된 주소가 TLD DNS에 매핑된 정보 혹은 캐싱된 정보가 없으면 Authoritative DNS에 쿼리를 보낸다.

 

Authoritative DNS의 경우 기관 혹은 회사에서 운영하는 DNS 서버로, 해당 기관 및 회사에 대한 IP 정보를 담고 있다.

 

위의 방법으로 DNS 서버의 계층 순서로 쿼리가 전달되고, 이에 대한 응답은 쿼리 방법에 따라 각 방법으로 받을 수 있다.


3. 그냥 컴퓨터에 저장해놓으면 안돼요?

자주 사용하는 주소를 매번 요청하기에는 너무 귀찮기도 하고, 만약 도메인과 IP 주소를 수동으로 연결해놓고싶으면 어떡할까? 사실 DNS 서버 통신과정에서 0번이 빠져있긴 하다.

 

  • 0. 로컬 저장소 안의 hosts에서 ip 주소 정보가 있는지 확인한다.

컴퓨터 안에는 hosts 파일이 있고, DNS 서버와 통신 전 이 파일을 먼저 뒤져본다. 실제 컴퓨터의 hosts 파일을 메모장으로 열어보면 다음과 같은 정보를 담고 있다.

hosts 파일
필자의 컴퓨터 hosts 파일에는 다음과 같이 담겨있다.

이 hosts 파일의 경우, host.docker.internal에 접속하면 DNS 서버에 쿼리를 보내지 않고 바로 "172.30.1.2" IP 주소로 접속한다.

 

다만, 자동으로 hosts 파일 수정은 해킹 혹은 보안에 위험이 있기 때문에 함부로 수정하지 못하도록 한다.


4. 세 줄 요약

  1. DNS = 도메인과 IP 주소를 매핑해놓은, 네임 서비스를 수행하는 서버이다.
  2. DNS는 여러 서버가 있다.
  3. DNS 대신 컴퓨터의 hosts를 바꾸어 사용이 가능하다.
반응형

'Network' 카테고리의 다른 글

[Network] HTTP Response Status Code 한 방 정리  (0) 2022.10.06
댓글
Total
Today
Yesterday
공지사항
최근에 올라온 글
최근에 달린 댓글
링크
«   2024/05   »
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 31
글 보관함