[Network] IP 주소와 DNS 서버의 동작 원리

✔️ 들어가기 전

저번 게시글에서는 HTTP 메시지를 어떤 식으로 만드는지 배웠다.

브라우저는 URL을 해독하거나 HTTP 메시지를 만드는 것까지는 진행하지만, 네트워크에 송출하는 기능이 없기 때문에 OS에 의뢰하여 송신하게 된다. 이때, URL 내부에 있는 서버의 도메인명에서 IP 주소를 조사하는데, OS에게 송신할 때는 IP 주소로 메시지를 받을 상대를 지정하기 때문이다. 어떻게 IP 주소를 조사하는지 간략하게 정리해보자.

또한, IP 주소를 도메인 주소로 변환하기 위해 어떻게 하는지 알아보자.

 

 

---

✔️ TCP / IP 네트워크

TCP/IP 네트워크는 작은 서브넷을 라우터로 연결하여 전체 네트워크를 완성한다. 

서브넷이란 패킷을 중계하는 장치인 허브와 여러 PC가 연결된 형태라고 생각해도 된다. 

XX동 YY번지가 있다면, XX동을 서브넷에 할당하고, YY번지는 컴퓨터에 할당한 것이 네트워크 주소이다.

여기서 XX동은 네트워크 번호, 번지를 호스트 번호라고 하며 둘을 합쳐서 IP 주소라고 한다.

 

우리는 이러한 IP 주소를 바탕으로 메시지를 운반한다.

송신 측이 메시지를 보내면 서브넷의 허브가 가장 가까운 라우터까지 보내고, 라우터는 메시지를 보낸 상대를 확인하여 다음 라우터를 판단한다.

그리고, 라우터는 수신자를 확인하여 다음 라우터를 판단하고, 거기에 보내도록 지시해서 송신 동작을 실행하여, 다시 서브넷의 허브가 라우터까지 메시지를 보낸다. 이런 식으로 계속 반복해서 데이터를 전달하는 것이다.

 

그렇다면, IP 주소는 어떻게 표기할까?

IP 주소는 32비트의 숫자로, 마침표로 구분된 4개의 숫자가 있는, 점으로 분리된 10진수 형식으로 표시된다.

10.11.12.13

하지만, IP 주소의 경우 고정되어 있지 않기 때문에 어느 부분이 네트워크 번호고 어느 부분이 호스트 번호인지 구분이 안 된다.

그저 네트워크 번호와 호스트 번호를 합쳐 32비트로 IP 주소를 결정한다는 사실만 알고 있기 때문에, 사용자가 네트워크 구축 시 직접 내역을 결정할 수 있게 된다. 우리는 필요에 따라 이러한 정보를 IP 주소에 덧붙이는데, 이를 '넷마스크'라고 한다.

// IP 주소 본체처럼 표현하기
10.11.12.13/255.255.255.0

// 네트워크 번호의 비트 수로 표현하기
10.11.12.13/24

넷마스크는 왼쪽에는 1, 오른쪽에는 0이 나열된 값으로서 1인 부분은 네트워크 번호, 0인 부분은 호스트 번호이다.

넷마스크를 8비트씩 구분하여 나타낸 게 첫 번째 표기법이며, 비트수를 10진수로 나타낸 게 두 번째 표기법이다.

// IP 주소 = 10진수 표기 || 비트로 표현한 방법
10.1.2.3 || 00001010.00000001.00000010.00000011

// 넷마스크 = 10진수 표기 || 비트로 표현한 방법 (1로 구성된 부분은 네트워크 번호, 0으로 구성된 부분은 호스트 번호)
255.255.255.0 || 11111111.11111111.11111111.00000000

// 1로 표시된 부분의 비트만큼이 네트워크 번호
네트워크 번호: 00001010.00000001.00000010.00000000

// 0으로 표시된 부분의 비트만큼이 호스트 번호
호스트 번호: 00000000.00000000.00000000.00000011

호스트 번호 비트값이 모두 0인 IP 주소는 서브넷 자체를 나타내며, 호스트 번호 부분이 모두 1이면 브로드캐스트이다.

10.11.12.0/24 : 호스트 번호의 비트가 0이면 서브넷 자체
10.11.12.255/25 : 호스트 번호의 비트가 1이면 서브넷 전체에 대한 브로드캐스트

 

---

 

✔️ 도메인명과 IP 주소의 구분 - DNS 서버와 Socket 라이브러리

이 부분에 대해서 자세히 알아보자.

왜 도메인명을 사용하는 걸까? 주로 도메인 이름의 경우, 문자로 되어 있다. 반면에 IP 주소는 숫자로 되어 있다.

둘 중에 어떤 방향이 더 사람이 기억하기 좋을까? 당연히 도메인 이름일 것이다.

하지만 IP 주소는 32비트, 즉 4바이트에 해당하는 개수밖에 없지만 도메인명은 적어도 수십 바이트 ~ 최대 255 바이트나 있기 때문에 더 많은 내용을 담을 수 있다. 라우터는 더 큰 데이터를 운반하기 위해서는 속도가 더 느려질 것이다.

 

사람은 이름을 사용하고, 라우터는 IP 주소를 사용하도록 하려먼 어떻게 해야 할까?

이름을 알면 IP 주소를 알 수 있고, IP 주소를 알면 이름을 알 수 있도록 DNS를 사용하게 되었다.

 

DNS 서버에 조회하는 것은 DNS 서버에 조회 메시지를 보내고, 거기에서 반송되는 응답 메시지를 받는 것이다.

이러한 DNS 클라이언트가 DNS 리졸버라고 하며 DNS 원리를 사용하여 IP 주소를 사용하는 것이 name resolution이라고 한다.

 

이러한 리졸버에 대해 알기 위해서는 Socket 라이브러리를 우선 이해해야 한다.

Socket 라이브러리 내부에는 여러 부품화된 프로그램이 있으며, 아래와 같이 호출이 가능하다.

// C언어에서 예시 - 리졸버 호출하기
<메모리 영역> = getHostByName("www.naver.com");  // 리졸버의 프로그램명(도메인명)

이렇게 리졸버를 호출하면 리졸버가 DNS 서버에 조회 메시지를 보내고, DNS 서버에서 응답 메시지가 돌아온다.

응답 메시지 안에 IP 주소가 있기 때문에 리졸버는 이를 추출해서 메모리 영역에 넣어준다. 

 

리졸버의 동작 과정을 간단하게 확인해보자.

리졸버는 DNS 서버에 문의하기 위한 메시지를 만들고 보낸다.

그리고 메시지의 송신은 OS 내부에 포함도니 프로토콜 스택을 호출하여 실행을 의뢰한다.

이후, LAN 어댑터를 통해 메시지가 DNS 서버를 향해 송신된다.

 

조회 메시지가 DNS 서버에 도착하고 DNS 서버는 메시지의 내용에 따라 답을 찾게 된다.

만약 액세스 대상의 웹 서버가 DNS 서버에 있으면 응답 메시지에 써서 반송하는데, 이는 클라이언트에게 도착하고, 프로토콜 스택을 경유하여 리졸버에 건네져서, 리졸버는 다시 내용을 해석하여 IP 주소를 추출하여 애플리케이션에게 건네준다.

 

그리고, 리졸버 호출 시 지정한 메모리 영역에 IP 주소를 저장하게 된다.

이렇게 리졸버 동작이 끝나면 제어는 다시 애플리케이션 (브라우저)에게 돌아오고, 이제 메모리 영역에서 IP 주소를 꺼내어 필요할 때 애플리케이션에게 건네줄 수 있게 된다.

 

---

 

✔️ 구체적으로 DNS 서버는 뭘 하는데?

위에서는 리졸버와 DNS 서버의 상호작용을 공부하였다. 그렇다면 DNS 서버는 내부적으로 무슨 일을 할까?

DNS 서버에 등록된 정보는 '리소스 레코드'라고 한다.

이름에 대응되는 클래스, 타입, 그리고 클라이언트에게 보내는 응답 메시지 안에 기입하는 정보가 들어간다.

 

클라이언트는 이름, 클래스, 타입 정보와 함께 조회 메시지를 DNS 서버에게 보낸다.

DNS 서버는 등록된 정보를 찾아서 3가지 모든 정보가 일치하는 것을 찾는다.

 

타입의 경우 대표적으로 A, CNAME이 있다. (위에서는 MX가 쓰였는데 이는 메일 배송 관련 타입이다)

- 물론 그외에도 PTR, NS, SOA 등이 있다.

 

🌱 A record

IP 주소 조회 시 주로 사용하며, 도메인 이름과 IPv4 주소를 매칭시킬 때 사용한다. (가장 기본적인 타입)

웹 브라우저는 DNS resolver를 통해 DNS 쿼리를 전송하여 이 작업을 자동으로 수행한다.

 

🌱 CNAME record

도메인이나 하위 도메인이 다른 도메인의 별칭으로 있을 경우, A 레코드 대신에 사용한다.

별칭으로 사용되기 때문에 IP 주소가 아닌 도메인을 가리키고 있어야 한다.

ex. aaa.example.com이 있다면 example.com을 IP 주소를 A 레코드를 통해 반환한다.

 

CNAME 레코드는 오직 클라이언트를 루트 도메인과 동일한 IP 주소로만 가리키기 때문에, 클라이언트가 해당 IP 주소에 도달했다면 웹 서버는 그에 따라 URL을 처리하게 된다. 만약, aaa.example.com이 example.com을 가리키는 CNAME을 가졌다면, example.com이 향하는 IP 주소로 향하게는 할 수 있다. 하지만, 실제로 해당 IP 주소에 클라이언트가 연결하면 해당 URL이 example.com이 아닌 aaa.example.com으로도 갈 수 있다.)

 

cf) MX, NS 레코드는 CNAME 레코드를 가리킬 수 없다!

 

실제 인터넷에는 엄청 많은 수의 서버가 있기 때문에 1대의 DNS 서버에 등록되는 것은 불가능하다.

그렇기 때문에 조회 메시지를 받은 DNS 서버에 정보가 등록되어 있지 않은 경우도 있다.

결과적으로는 정보를 분산시켜 다수의 DNS 서버를 등록하고, 다수의 서버가 서로 어디에 정보가 등록되어 있는지 찾아내는 구조다.

 

---

✔️ 다수의 DNS 서버

우선 DNS 서버에 등록한 정보에는 '도메인명'이라는 구조를 가진 이름이 붙어있다.

그리고, 도메인명은 기본적으로 계층적 구조로 이루어져 있다.

또한, DNS 서버와 도메인은 1:1이 아니라 1:N도 가능하다!

 

먼저 1:1 관계로 등록한다고 가정해보자.

도메인의 계층 구조와 동일한 형태로 DNS 서버가 배치되며, 각 도메인의 정보는 도메인이 있는 DNS 서버에 등록된다.

또한, 도메인 아래에 하위 도메인을 만들고 그것을 각각 할당하는 것도 가능하다.

DNS 서버는 수만 대가 존재하기 때문에, 효율적으로 탐색하기 위하여 계층형 구조를 사용한다.

(하나하나씩 다 탐색한다고 생각하면 너무 아찔하다 ㅠㅠ)

 

결론부터 말하자면, DNS는 다음과 같이 동작한다.

1. 웹 브라우저에 www.google.com을 입력하면, PC에 저장된 Local DNS 서버에게 해당 IP 주소를 요청한다.
- 보통 Local DNS는 인터넷이 연결되었을 때, 각 통신사의 기지국 DNS 서버가 된다.

2. 이 과정에서 이전에 정보가 있었다면, 캐싱된 데이터를 바로 넘겨준다.

3. 없다면, Root nameserver에게 www.google.com의 IP 주소를 요청한다.
- 여기서도 찾지 못했다면, Local DNS에게 찾을 수 없다고 응답한다.

4. Local DNS는 TLD nameserver에게 www.google.com의 IP 주소를 요청한다.
- 여기서도 찾지 못했다면, Local DNS에게 찾을 수 없다고 응답한다.

5. Local DNS는 SLD nameserver에게 www.google.com의 IP 주소를 요청한다.
- 여기서 찾은 값을 캐싱한 다음, IP 주소를 응답한다.

그리고 이러한 과정을 보통 Recursive Query라고 한다.

 

🌱 Root nameserver

ICANN (국가 인터넷 주소 자원 관리 기구)가 직접 관리하는 서버이다.

recursive DNS가 가장 먼저 방문하는 곳이며, 도메인 이름이 포함된 DNS 쿼리를 받아 해당 도메인의 확장자를 기준으로 (.com, .net 등등) recursive DNS를 TLD로 안내하여 응답한다.

총 13개가 있지만, 각 nameserver의 복사본이 전세계에 여러 개 있으며, anicasting을 진행하기 때문에 빠르게 응답이 가능하다. (다 합치면 거의 600개가 넘는다고 한다...)

나는 www.google.com의 IP 주소는 없어. 대신 .com을 알려줄게, 걔한테 물어봐.

 

🌱 Top Level Domain (TLD) nameserver

도메인 등록 기관이 관리하는 서버이다. 보통 URL의 마지막 점 뒤에 오는 모든 공통 도메인 확장자에 대한 정보를 관리한다.

(ex. .com TLD의 경우 .com으로 끝나는 모든 정보 - google.com 같은 정보들을 포함하고 있다)

TLD에 쿼리를 보내면 권한있는 네임서버를 가리키며 응답하게 된다. 

 

보통 2가지로 나눈다.

- Generic top-level domain: 국가별로 구분하지 않는 도메인. ex) .com, .org, .net

- Country code top-level domain: 특정 국가나 주에 따른 도메인 ex) .uk, .kr

나는 www.google.com의 IP 주소는 없어. 대신 .google.com을 알려줄게, 걔한테 물어봐.

 

🌱 Second-Level Domain (SLD) = Authoritative nameserver

TLD로부터 받은 응답이 마지막으로 들리는 곳이다. 일반적으로 resolver가 마지막으로 IP 주소를 찾기 위해 들리는 곳이다.

서비스하는 도메인 이름에 대한 정보를 포함하며, recursive resolver에게 DNS A record에서 찾은 IP 주소를 제공하거나, CNAME 레코드가 있는 경우 제공할 수 있다. 

보통 도메인 / 호스팅 업체의 네임서버나 개인 DNS가 여기 속한다.

www.google.com의 IP 주소를 줄게!

 

🌱 권한 없는 DNS 서버 (= DNS recursor, DNS resolver, recursive DNS)

권한 없는 DNS 서버의 경우 질의를 통해서 IP 주소를 알아낸다.

(정확하지는 않지만) DNS 쿼리의 첫 번째 종착지로, 클라이언트와 DNS nameserver의 중개자 역할을 한다.

웹 클라이언트로부터 DNS 쿼리를 받은 다음, 캐시된 데이터로 응답하거나, 루트에 요청을 보낸 다음, TLD 서버에 또 다른 요청을 보내고, 마지막으로 권한 있는 네임서버에게 요청을 보내게 된다. 권한 있는 서버로부터 응답을 받아서 클라이언트에게 내려주는 형태이다.

 

cf)

- Hostname: 자유롭게 선택할 수 있으며, www가 일반적으로 사용된다. (뭐 mail, dev 같은 것도 들어간다.)

- Fully Qualified Domain Name (FQDN): 전체 도메인의 이름을 의미한다.

 

정리하자면, 하위의 도메인을 담당하는 DNS 서버의 IP 주소를 상위의 DNS 서버에 등록하고, 상위의 DNS 위에 또 상위의 DNS 서버를 등록하는 식으로 한 것이다. 그래서 www.google.com을 DNS 서버에 등록 -> google.com의 DNS 서버를 com 도메인에 등록... -> ... 

이렇게 하기 때문에 상위의 DNS 서버에 가면 하위의 DNS 서버의 IP 주소를 알 수 있게 되고, 쿼리를 보낼 수 있게 된다.

 

하지만 하위의 DNS 서버를 상위의 DNS 서버로 등록한다고 끝나지는 않는다.

루트 도메인의 DNS 서버를 인터넷에 존재하는 모든 DNS 서버에 등록하여, 모든 곳에서 루트 도메인을 참조할 수 있도록 해야 한다.

그럼 어떤 요청이 와서 엑세스를 하더라도 루트 도메인으로부터 찾아서 갈 수도 있게 된다.

위의 그림을 조금 더 정확하게 표현하자면 다음과 같다.

실제로는 이런 식으로 가장 가까운 DNS 서버에게 물어보고 -> 가장 가까운 DNS 서버는 루트 도메인이 등록되어 있기 때문에, 루트 도메인으로부터 받은 조회 메지를 전송한다. 이때, 루트 도메인이 www.google.com에서 .com 도메인의 DNS 서버의 IP 주소를 반송하고, 또 다시 가장 가까운 DNS 서버는 com 도메인의 DNS 서버에게 또 다시 메시지를 보낸다.

이런 식으로 위의 과정을 반복하다가 IP 주소를 알게 되면, 거기에 액세스하게 된다.

 

하지만, 현실에서는 다수의 도메인이 한 개의 DNS 서버에 존재할 수도 있다.

= 상위, 하위의 도메인을 같은 DNS 서버에 등록할 수도 있다.

이렇게 되면 상위의 DNS 서버에 조회했을 때 하위 DNS 서버는 건너뛰고, 다시 그 아래의 DNS 서버에 관한 정보가 돌아오게 된다.

 

추가적으로, DNS 서버는 한 번 조사한 이름을 캐시에 기록할 수 있다.

이렇게 되면 해당 위치부터 계층 구조를 아래로 향하여 찾을 수 있기 때문에 루트부터 찾는 것보다 편리해진다.

하지만, 캐시를 사용하면 정보의 변경 가능성을 항상 염두해야 하기 때문에 캐시 정보에 대한 유효 기간을 설정하고, 유효 기간이 지나면 삭제되도록 만들어야 한다.

또한, 조회된 정보가 캐시에 저장된 것인지, 혹은 DNS 서버에서 응답한 것인지도 구분해서 알려줘야 한다.

---

✔️ 정리

DNS의 동작 구조를 담은 그림이다 :D