DNS 서버가 IP주소를 가져오는 방법

Hansu Park·2023년 12월 3일
haedal-studynetwork
0
post-thumbnail
post-custom-banner

DNS(Domain Name System)은 전화번호를 직접 기억하지 않고, 주소록에 이름을 검색하여 전화번호를 찾는 것처럼, IP를 직접 기억하지 않고, DNS Server에 도메인을 검색하여 IP를 찾을 수 있게 해주는 시스템이다.

클라이언트에서 요청한 URL이 DNS 서버에 의해 IP로 변환되는 과정을 살펴보자.

리소스 레코드

앞서, DNS서버가 어떠한 정보들을 보관하고 있는지 살펴보자. DNS 서버는 아래와 같은 데이터들을 유지하며 이들은 리소스 레코드라고도 불린다. TTL(time-to-live)을 가지고 있어 해당 기간동안 데이터를 캐싱하여 보관한다. (TTL 이후 재요청시 캐싱 데이터를 갱신한다.)

  • 이름: 목적지 주소 (e.g. www.example.com)
  • 클래스: 네트워크의 클래스
    • 현재는 인터넷(Internet)만 사용하기에 무조건 IN이다
    • 따라서 생략하기도 한다.
  • 타입: 해당 레코드로 들어온 요청을 처리하는 방법에 대한 정보
    • A: 주소(Address)의 약자로, IPv4에서 도메인에 대응되는 IP주소를 가리킬 때 사용한다.
      • IPv6에서는 AAAA를 사용한다.
    • MX: 메일 교환(MailExchange)의 약자로, 이메일을 메일 교환 서버로 보낼 때 사용한다.
    • NS: 네임서버(NameServer)의 약자로, 해당 도메인을 등록하고 있는 DNS 서버의 주소를 가리킬 때 사용한다.
      • 다시 말해, 해당 도메인의 IP를 찾기 위해 방문해야하는 DNS 서버의 주소이다.
      • 안정성을 위해 여러가지 서버 주소를 유지한다.
    • CNAME: 표준 이름(Canonical Name)의 약자로, 표준 도메인에 대한 별명을 등록할 때 사용한다.으로 사용한다.
      • 주로 서브도메인에 활용된다. (sports.[naver.com](http://naver.com) 서브도메인이 naver.com 도메인의 CNAME으로 설정)
      • IP주소를 가리켜서는 안된다.
      • 플랫폼(인증서 발급, 이메일 플랫폼 등)에서 도메인 소유권을 증명할 때 사용한다. 요청하는 URL을 본인의 도메인의 CNAME으로 등록함으로써 도메인의 소유권이 증명된다.
    • SOA: 권한 시작(start of authority)의 약자로, 도메인에 대한 중요 정보를 저장할 때 사용한다.
      • 관리자 메일 주소, 대기시간 등을 표현한다.
    • TXT: 텍스트(Text)의 약자로, 메모 용도로 만들어졌으나 이메일 스팸 방지 및 도메인 소유권 확인 용도로 사용한다. 이외에도 여러 타입들이 존재한다.

DNS 계층 구조

DNS는 URL에 해당하는 IP들을 기억하고 있다가 클라이언트가 요청하면 이를 알려준다. 현실에서 수 많은 URL들의 IP들을 하나의 DNS 서버가 보관하는 것은 불가능하다. 따라서 DNS 서버들은 트리구조로 계층적으로 구성하여, 하나의 서버가 저장하는 양을 분산하고 있다.

하위 계층의 DNS 서버가 가지고 있는 IP를 상위 DNS 서버에 질문한다면, 상위 DNS 서버는 이를 알고 있을 하위 DNS 서버의 IP를 클라이언트에게 알려준다. 클라이언트는 하위 DNS 서버에 질문을 하여 IP를 획득한다.

(하청 방식과 비슷하다.)

image

(도메인 계층 구조가 소개된 모습)

[www.example.co](http://www.example.com)m. 이라는 도메인네임이 있다고 하자. 도메인은 이러한 이름은

  1. . : 루트 도메인
  2. com : 1단계 도메인 (최상위 도메인)
  3. example : 2단계 도메인

…

으로 구성되어 있다.

루트 도메인

루트 도메인은 . 으로 지정하며, 생략하기도 한다. 가장 높은 계층에 속하는 도메인이다. 자세한 설명은 아래에 다룬다.

HOSTNAMEIP ADDRESSESOPERATOR
a.root-servers.net198.41.0.4, 2001:503:ba3e::2:30Verisign, Inc.
b.root-servers.net199.9.14.201, 2001:500:200::bUniversity of Southern California,Information Sciences Institute
c.root-servers.net192.33.4.12, 2001:500:2::cCogent Communications
d.root-servers.net199.7.91.13, 2001:500:2d::dUniversity of Maryland
e.root-servers.net192.203.230.10, 2001:500:a8::eNASA (Ames Research Center)
f.root-servers.net192.5.5.241, 2001:500:2f::fInternet Systems Consortium, Inc.
g.root-servers.net192.112.36.4, 2001:500:12::d0dUS Department of Defense (NIC)
h.root-servers.net198.97.190.53, 2001:500:1::53US Army (Research Lab)
i.root-servers.net192.36.148.17, 2001:7fe::53Netnod
j.root-servers.net192.58.128.30, 2001:503:c27::2:30Verisign, Inc.
k.root-servers.net193.0.14.129, 2001:7fd::1RIPE NCC
l.root-servers.net199.7.83.42, 2001:500:9f::42ICANN
m.root-servers.net202.12.27.33, 2001:dc3::35WIDE Project

(루트 도메인의 주소들)

총 13개의 루트 도메인이 있다. 이러한 루트 도메인을 대상으로 하는 공격이 일어나기도 하였다. (참고: https://community.ibm.com/community/user/security/blogs/gwibin-im2/2022/08/08/20-years-ago-in-cybersecurity-massive-ddos-attack)

DNS 서버 질의 방식

DNS에 의해 URL을 IP로 바꾸는 과정은 두 가지 방식이 있다.

image

(반복 방식과 재귀방식)

반복 질의 방식(Iterative Query)은 내 컴퓨터에서 로컬 DNS서버에 질의한 후, 로컬 DNS 서버가 루트 도메인부터, 1단계, 2단계 도메인에게 반복적으로 질의하여 IP를 찾는 방법이다. 여기서 Authoritative DNS server는 실제 IP를 기억하고 있는 엔드포인트를 의미한다.

재귀 질의 방식(Recursive Query)는 내 컴퓨터에서 로컬 DNS 서버에 질의한다. 여기까지는 반복 질의 방식과 같다. 단, 로컬 DNS 서버가 루트 도메인에게 IP를 찾아올 책임을 넘기고, 루트 도메인은 1단계 도메인에게 넘기고, … 방식으로 다른 DNS 서버에게 자신이 해야하는 책임을 재귀적으로 넘겨 IP를 찾는 방식이다.

재귀 질의 방식은 다양한 DNS 서버가 질의의 정답을 알게되므로 캐시에 유리하여 빠른 응답을 줄 수 있다. 하지만, 책임을 다른 서버에 넘김으로써 여러 보안적 위험(하나의 서버에 수 많은 질의를 던지는 DNS 증폭 공격, 잘못된 IP를 캐시에 저장하도록 유도하는 DNS 캐시 포이즈닝 공격 등)이 존재한다. 따라서 현재는 두 방식을 혼합하여 사용한다고 한다.

DNS 질의 과정과 캐시

보통 인터넷을 사용할 때, 같은 URL에 자주 접근하는 경우가 많다. DNS는 반복적으로 접근하는 URL에 대한 IP주소를 다양한 방식으로 캐싱한다. 이러한 캐싱이 어디에서 일어지는 지를 질의 과정과 함께 살펴보자.

  1. 로컬 DNS 캐시 (캐시 테이블)

메모리에 존재하는 캐시 테이블로, 가장 먼저 조회된다. 내 컴퓨터에서 조회한 DNS 결과들을 테이블로써 가지고 있는다. 여기서 찾지 못한 정보는 Host 파일에 조회된다.

  1. Host 파일

보조기억 장치에 저장되어 있는 파일로 네임서버가 등장하기 이전 호스트 이름(URL)에 대응되는 IP를 가져올 때 사용하였다. 네임서버 등장 이후 사용하지 않지만, 네임서버보다 우선순위가 높다. 여기서 찾지못한 정보는 실제 DNS 서버에 질의를 통해 찾는다.

  1. 라우터 캐시

DNS 서버로 질의한다면, 라우터를 거친다. 이 때 라우터가 알고 있는 IP정보라면 라우터가 반환할 수 있다.

  1. 로컬 DNS 서버

ISP의 DNS 서버를 의미한다. 로컬 DNS 서버가 이미 저장하고 있는 정보라면 바로 반환하고, 아니라면 위에서 살펴봤던 질의방식을 통해 IP 정보를 가져와 반환한다.

참고

어플리케이션이 바라본 소켓

개요

지금까지 브라우저가 URL을 검색한 후 일어나는 과정들을 살펴보고 있었다. DNS 서버에 조회하여 IP를 받아왔다면, 이젠 HTTP 메시지 요청을 보내야 한다. 브라우저를 비롯한 Application은 자체적으로 데이터를 전송할 수는 없으며, 운영체제의 전송 계층에 이를 의뢰해야한다. 다음 챕터에서 소켓에 대해 자세히 다룰 것이므로, 이번 챕터에서는 Application 입장에서 어떻게 데이터 전송을 의뢰하는지를 집중적으로 다룰 것이다.

사실 Application은 이전에도 한 차례 무언가를 의뢰한 적이 있었는데, 이는 DNS 서버에 IP주소를 알려달라고 한 의뢰였다. 이를 되짚어보면, 소켓 라이브러리를 이용하여 통신을 진행하였다. (사실, DNS는 UDP를 데이터 전송은 TCP를 사용한다는 점에서 차이가 있긴하다.)

소켓의 의미

소켓은 구멍, 연결, 콘센트와 같은 의미를 가지고 있다. 즉 서로 다른 계층간의 연결, 통로를 의미한다고 할 수 있다. 네트워크에서 소켓은 Application이 활용하기 위한 운영체제의 인터페이스(기능 모음)들 중에 네트워크 프로토콜(TCP, UDP 같은 전송 계층)에 대한 인터페이스를 의미한다.

image

소켓의 동작 과정 (단순화된)

소켓에 대해 단순하게 설명하자면 (추후 다루니까 단순하게만 설명하겠다.) 소켓은 연결 과정을 거쳐 통로를 생성하고 이 통로를 통해 클라이언트와 서버가 통신을 한다. 과정을 나눠 보면

  1. 소켓 작성 (생성)
  2. 소켓 연결 (접속)
  3. 데이터 송수신
  4. 소켓 연결 끊기

로 나눠볼 수 있다. 각 단계에 대해 알아보자.

1. 소켓의 작성

int sockfd = socket(domain, type, protocol)

코드를 통해 socket 을 호출하면 소켓의 파일 디스크립터(descriptior)를 반환한다. 파일 디스크립터는 여러 개의 파일들을 구분하는 역할을 하며, 이 경우에는 클라이언트의 여러 소켓 중 사용하려는 소켓 파일을 구분한다.

*소켓도 파일이다. 파일을 다루는 것과 마찬가지로 생성, 삭제, 연결, 연결끊기 가 가능하다.

2. 소켓 연결

*connect(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr))*

디스크립터, 서버의 IP와 포트번호를 통해 연결을 생성한다. 운영체제의 커널이 제공하는 네트워크 기능을 호출하여 서버와 연결하는데, 서버를 식별하기 위해 IP, 포트번호를 사용한다.

3. 데이터 송수신

송신

send(socketfd, buffer, sizeof(buffer))

연결이 되었다면 데이터를 송신한다. HTTP에선 Http Request message가 해당될 것이다. 전송하는 단위는 버퍼라고 하는데, 데이터를 일정 크기까지 쌓아서 한꺼번에 전달할 수 있다.

수신

read(socketfd, buffer, sizeof(buffer))

송신 이후 서버에서 데이터룰 수신한다. HTTP에서는 Http Response message가 해당한다. 이 역시 버퍼를 통해 전달받는다.

4. 소켓 연결 끊기

close(socketfd)

원하는 데이터를 송수신이 완료되었다면, 연결을 끊는다. HTTP1.1 부터는 하나의 많은 양의 데이터를 주고받아야 하는 일이 많아, 하나의 송수신만 거친 후 연결을 끊지 않고 여러 송수신을 거친 후 끊기도 한다.

참고

profile
Hansu Park
이전 포스트

브라우저에 URL를 입력하면 생기는 일 (브라우저)

다음 포스트

스프링은 날짜를 어떻게 역직렬화할까? (@DateTimeFormat, @JsonFormat)

post-custom-banner

0개의 댓글