[컴퓨터 네트워크] 12. Application Layer (5) : DNS

DNS

Domain Name System

인터넷 상에서 컴퓨터(호스트) 를 식별할 때 IP Address 를 이용한다. (정확히는 포트까지 이용한다.)

현재 가장 널리 쓰이는 체계는 32bit 주소 체계인 IPv4 이다.

 

IP주소는 dotted decimal (점으로 구분한 십진수 4개) 으로서 사용되기 때문에 사람들이 이를 직접 기억하기 힘들다.

그래서 사람들이 기억하기 쉽게 문자열로 된 도메인 네임을 부여하였다.

하지만 실제 컴퓨터가 네트워크 상에서 통신을 하려면 결국 숫자로 된 IP주소를 이용해 통신해야해서, 이 도메인 네임을 아이피 주소로 변환할 필요가 있다.

DNS 는 도메인 이름을 IP주소로 변환해주는 서비스를 일컫는다.

(경우에 따라 그 반대를 할 수도 있다.)

 

그래서 결국 DNS는 도메인주소와 IP주소를 매핑한 DB라고 볼 수 있다.

특히, 분산된 DB로 볼 수 있는데, 그 이유는 이 DB의 구현이 여러 name server 의 계층 구조로 이루어져있기 때문이다.

name server 는 도메인 이름을 쿼리로 보내면, 이에 대해 매핑된 IP 주소를 응답하는 서버를 말한다.

(역할상 DNS server 라고도 한다)

 

DNS는 이름상 System 이라는 표현을 쓰지만, 사실은 어플리케이션 계층에서 구현된 프로토콜이다.

분산 데이터베이스를 만들어놓고 분산 데이터베이스에 접근하는 사용자들에게 host name 에 대해 IP주소라는 답을 제공해주는 서비스를 구현한 프로토콜이라고 생각할 수 있다.

(답을 제공하는 것을, resolve / resolution 이라고 한다)

 

DNS는 인터넷에서 매우 중요한 core function 이다.

사람들은 모두 도메인 네임을 이용해서 웹 서비스를 이용하기 때문이다.

꼭 이 이유 말고도, 같은 amazon.com 이라도 수십억의 사용자를 하나의 서버가 받을 수 없기에, 같은 도메인에 대해 여러 서버로 연결될 수 있다. 따라서 네임서버는 같은 도메인 네임에 대해 접속한 사용자의 상황에 맞는 서로 다른 IP주소를 돌려줄 수도 있다.

 

DNS 서비스와 구조

DNS가 제공하는 서비스

1. hostname 을 IP 주소로 변환한다.

 

2. host aliasing (별칭 붙이기) 기능을 제공한다.

회사 내부에서 서버에 붙인 이름과 실제 웹 도메인 이름이 달라도 된다.

또는 하나의 컴퓨터로 웹서버, 메일서버 등 다양한 서버의 역할을 할 때도, 각 기능마다 접근하는 도메인이 다를 수 있다.

이때 회사 내부에서 진짜로 사용하는 이름을 canonical name 이라고 한다.

그리고 위 상황에서 각 기능에 접근하는 도메인을 alias name 이라고 한다.

DNS는 alias name 을 canonical name 에 연결하는 서비스를 제공한다.

 

3. 부하 분산 (load distribution)

인기있는 웹 사이트의 웹서버가 있다고 하자.

그렇다면 이 서버로 몰리는 트래픽이 매우 많을 것이다.

이러면 한대의 서버에게 부담이 가기 때문에, 같은 일을 하는 서버를 여러대 두고, 여러대의 서버가 task를 분산해서 클라이언트의 요청을 처리하도록 만들 수 있다.

이때 dns 를 이용하면, 같은 IP 주소로 접속해도 서로 다른 웹서버로 보내서 한대의 서버에 트래픽이 몰리는 상황을 막도록 할 수 있다.

 

Centralize DNS 를 사용하지 않는 이유는, 당연히 중앙에 있는 Single DNS 서버에서 장애가 발생하면 모든 DNS 서비스가 막힐 수 있고, 유지보수 하기 어렵고, 트래픽이 모리는 문제가 있다.

따라서 DNS는 계층구조를 가지되, 하나의 중앙화된 DNS 서버를 갖고 있지는 않다.

 

DNS의 특징

DNS는 거대한 분산 데이터베이스이다.

지리적으로 가까운 위치에 있는 분산된 DNS 서버가 바로 응답해서 더 빠르게 응답할 수 있다.

 

DNS는 하루에 수십조의 쿼리를 처리한다.

쿼리의 대부분은 DB에 있는 내용을 읽는 행동이고, 쓰는 행동은 드물게 존재한다.

이것이 DNS 서버의 성능에 매우 중요한 영향을 끼친다.

 

DNS는 조직적으로, 물리적으로 분산되어 있다.

수백만개의 다른 조직들이 자신들의 레코드를 관리한다.

 

DNS 는 신뢰성과 보안이 매우 중요하다.

hostname을 쳐서 들어간 사이트가 위변조 되지 않은 사이트여야 하기 때문이다.

이와 관련해서는 DNS sec 이라는 개념에 대해 뒤에 정리한다.

---

DNS의 분산/계층적 데이터베이스

 

Root DNS Server

DNS는 위 이미지에서 보는 것처럼 계층적으로 구분된 네임서버들로 구성되어 있다.

Root DNS 서버는 전세계에 13군데가 있다.

그리고 각 군데마다 여러 서버컴퓨터가 모여 하나의 루트 서버를 이루고 있다.

(우리나라는 root server가 없다. 다만 일본 루트 서버의 카피 서버를 갖고 있다.)

 

루트서버는 가장 중요한 일을 하지만, 모든 DNS 쿼리가 루트까지 오지는 않는다.

대부분 자신 주변의 로컬 DNS 서버에 쿼리를 요청하면, 해당 서버들이 자기가 알고 있는 IP주소를 리턴한다.

그런 점에서, 루트서버는 해결하지 못한 도메인 네임에 대해 마지막으로 요청을 보내는 서버이다.

(contact-of-last-resort)

 

Root DNS Server 는 매우 중요한 인터넷 기능을 수행한다.

따라서 보안이 매우 중요하기 때문에 DNSSEC 이라고 하는 보안이 추가된 프로토콜을 사용한다.

이 프로토콜을 사용하면 authentication, message integrity 라는 인증과 무결성 보장 기능을 제공한다.

루트 DNS domain 은 ICANN 이라는 단체에 의해 관리된다.

(이 조직은 IP 주소의 대역 부여, 도메인 이름 등을 관리한다.)

 

Top Level Domain (TLD) server

루트 서버 밑에는 Top Level Domain 에 대한 DNS 서버가 있다.

Top Level Domain 은 도메인 네임에서 제일 뒤에 있는 부분을 말한다.

xyz.com 에서 .com 이 top level domain 이다. (TLD 라고도 한다.)

 

top level domain 에는 .com, .net, .org 같은 것들 외에도 국가 코드 같은 것들이 들어간다.

이 경우에는 CCTLD (Country Code Top Level Domain) 이라고 부른다.

우리나라 같은 경우는 kr 이다.

TLD 서버들은 전세계적으로 쿼리를 받기 때문에 서버가 매우 많다.

 

Authoritative server

TLD server 아래에 있는 DNS 서버들을 Authoritative server 라고 한다.

이 서버들은 자신의 도메인에 대해서 authoritative 하다.

authoritative 하다는 말은 amazon.com 으로 끝나는 도메인들에 대해서는 확실하게 답을 할 수 있다는 것을 의미한다.

기업들이 자체적인 DNS 서버를 두거나, 이를 ISP에 대신 운영해달라고 할 수도 있다.

 

실제로 구체적인 예시를 들어보자.

브라우저에 amazon.com 을 입력하고 엔터를 쳤다.

그러면 내부적으로 amazon.com 의 IP 주소를 얻어와야 하기 때문에, DNS name resolution 이 진행된다.

우선 쿼리가 루트 네임 서버로 간다. (실제로는 갈 일이 거의 없다.)

그러면 루트 서버에게 www.amazon.com  의 IP 주소를 알고 있을만한 서버를 알려달라고 질의한다.

루트 네임서버는 그 밑에 있는 TLD 네임서버들의 정보를 알고 있기 때문에, 요청한 도메인이 .com 으로 끝나는 것을 보고, .com 에 대한 정보를 갖는 네임서버를 알려준다.

 

브라우저는 다시 .com 에 대한 정보를 갖는 네임서버에 쿼리를 보내 amazon.com 에 대해 질의한다.

그러면 이 네임서버는 amazon.com 의 IP 주소에 대해 알고 있으니 그 IP주소를 알려준다.

웹브라우저는 최종적으로 amazon.com 의 IP주소로 원하는 HTTP 요청을 보내게 된다.

 

Local DNS Server

예를 들어 홍대 내부의 네트워크에 접속한 노트북에서 다른 웹사이트에 접속한다고 하자.

그러면 해당 노트북은 홍익대 Local DNS Server에 DNS 쿼리를 보낸다.

만약 홍익대 Local DNS Server 가 답을 알고 있다면 바로 IP 주소를 알려주고, 만약 모른다면 그 답을 알만한 다른 네임서버에게 물어보든가, 그 서버의 IP주소를 전달해준다.

 

그래서 로컬 DNS 서버는 자신이 답을 갖고 있는 경우, 사용자에게 매우 빠르게 답을 알려줄 수 있다.

답을 모른다면 그때부터 DNS 계층에 따라 name resolution 과정을 시작한다.

 

어떤 컴퓨터가 최초로 확인하는 로컬 DNS 서버의 정보는 윈도우 기준 ipconfig /all 명령어를 통해 알 수 있다.

(기숙사 네트워크에서 접속한 뒤 내 노트북에서 실행했을 땐 DNS 정보가 비어있었다.)

 

그런데 로컬 DNS 서버는 이 계층 구조에 속하지 않는다.

정확히 말하면, 로컬 DNS 서버는 이 계층 구조 내에 어떤 단계에 추가될 지 모른다.

따라서 이 계층에 정확히 포함시키지 않는다.

 

예시를 보면, 홍대 컴공에 학부생이 너무 많이 왔다고 하자.

그래서 홍대 컴공에 대해 자체적으로 DNS 서버를 운용한다고 하자.

그러면 홍대 컴공의 로컬 DNS 서버는 루트 DNS 서버로 부터 한단계 더 떨어진 곳에 위치한다.

 

만약 외부인이 홍대 컴공에 속한 어떤 도메인 접속한다면, 루트 서버 -> TLD 서버 -> authritative 서버 -> 홍대 컴공 DNS 서버 이렇게 한 단계를 더 거쳐서 질의를 해야한다.

자체 네임서버를 두면, authoritative 서버가 바로 IP 주소를 알려주는게 아니라 홍대 컴공 DNS 서버의 IP주소를 알려주기 때문이다.

 

DNS name resolution 의 2가지 방식

iterated query

쿼리를 반복적으로 날린다.

클라이언트가 최초로 루트 네임 서버에 질의를 보내면, 루트 네임서버는 TLD 서버의 IP주소를 응답한다.

클라이언트는 다시 전달받은 TLD 서버의에 질의를 보내면, TLD 네임서버는 authoritative 서버의 IP 주소를 응답한다.

클라이언트는 최종적으로 authorative 서버의 IP 주소에 질의를 보내서 원하는 IP 주소를 받는다.

 

위 그림에서는 '클라이언트' 의 역할을 local DNS 서버가 맡았다.

 

recursive query

쿼리를 재귀적으로 하는 방식이다.

먼저 클라이언트가 루트 네임서버에 질의를 보낸다.

그러면 루트 네임서버가 TLD 서버에 대신 또 질의를 보낸다.

TLD 서버는 다시 authoritative 서버에 대신 질의를 보내서 IP 주소를 알아내고, 이를 루트 네임 서버에게 알려준다.

루트 네임서버는 알아낸 최종 IP 주소를 클라이언트에게 알려준다.

 

이 방식은 쿼리를 받는 서버 입장에서, 그 답을 명확히 알아낼 책임이 있기 때문에 부담이 커진다.

따라서 보통은 iterated 방식으로 처리한다.

 

DNS Caching

DNS 는 결국 데이터베이스다.

이 데이터베이스에 저장된 도메인-IP 매핑 정보를 쿼리에 따라 알려주는 것이 DNS 서버의 역할이다.

캐시는 DNS 서버가 저장하고 있는 내용을 의미한다.

만약 어떤 DNS 서버가 자신이 처음에 몰랐던 매핑정보를 다른 DNS 서버에 질의해서 알아낸 뒤, 자신이 보관을 하고 있으면, 캐싱했다고 말할 수 있다.

 

물론 캐시 엔트리의 유효기간이 무한대일 수 는 없다.

DNS 정보는 자주 바뀌지 않지만, 그렇다고 절대 영구 불변한 정보도 아니기 때문이다.

그래서 DNS 정보를 캐싱할 때 TTL 값을 같이 집어넣게 된다.

TTL은 Time to Label 의 줄임말로, 이 시간이 지나면 캐싱한 정보는 원칙적으로 의미가 없는 정보로 해석한다.

 

이를 이용하면, 쿼리를 보냈을 때, 해당 쿼리가 루트 네임 서버로 갈 일이 거의 없다는 것을 이해할 수 있다.

처음 요청을 받은 로컬 DNS 서버는 최초에 루트 네임 서버로부터 TLD 네임 서버의 정보를 얻어온 뒤, 이 정보를 캐싱해둘 것이다. 그러면 이후에도 모르는 도메인에 대한 resolution을 할 때는, 루트서버에게 질의하는 것이 아니라, 캐싱해둔 TLD 서버에 바로 질의할 수 있다.

이를 통해 루트 네임 서버로 가는 트래픽을 줄일 수 있다.

 

그리고 TTL은 갱신이 하루, 이틀 정도로 매우 느리게 된다.

따라서 어떤 회사가 망해서 그 회사의 도메인이 유효하지 않게 되었다고 하더라도, 바뀐 정보가 전세계에 즉시 전파되지 않는다. 따라서 이 경우, 예전 정보로 resolution 될 가능성이 충분히 있다.

실시간으로 정보를 갱신해야 하는 오버헤드를 감수하지 않는 것이다.

이를 가리켜, DNS 서버는 best-effort (최선의 노력) 를 다해서 도메인을 IP 주소로 변환한다고 한다.

 

DNS Record

DNS 설정을 할 때 들어가는 하나의 정보를 Record 라고 한다.

그 포맷은 아래와 같다.

 

name 과 value는 type에 따라 달라지고, TTL 값은 이 레코드의 정보가 유효한 기간을 의미한다.

레코드의 타입은 아래와 같은 종류가 있다.

type A

name : host name

value = : IP address

 

가장 널리 사용하는 리소스 레코드 (RR) 의 종류이다.

 

type NS

name : domain

value : authoritative name server's host name

 

Name Server 의 줄임말이다.

주어진 도메인으로 끝나는 요청에 대해 모르는 요청이 오면, 이를 관리하는 DNS 서버를 명시하는 정보이다.

 

type CNAME

Canonical NAME 의 줄임말로, 접속하려는 서버의 실제 machine 주소이다.

 

name : alias domain name

value : canonical domain name

 

type MX

메일서버를 의미한다..

나에게 이메일을 보내면 이메일 agent 를 이용해서 받은 이메일을 확인한다.

이때 이메일이 도착하려면 홍익대학교 메일 서버까지는 이메일 데이터가 도착해야 한다.

MX 타입은 이메일 주소에서 @ 뒤에 붙은 주소를 이용해, 그 도메인의 IP주소를 알려달라고 요구한다.

(홍익대같은 경우, 다른 도메인 네임과 다르게 mail.hongik.ac.kr 을 쓴다. MX 레코드 정보를 통해 mail.hongik.ac.kr 의 IP주소를 얻는 것이다.)

 

DNS Query & Reply 포맷

DNS 는 request, response 대신 query, reply 라고 한다.

HTTP와 마찬가지로 이렇게 2개의 포맷이 존재하며, 각각의 포맷은 아래와 같다.

 

 

identification : 16bit 정보로, 내가 쿼리를 보낼 때 이 필드에 지정한 넘버 아이디를 이 질문에 대한 응답의 id에 복사해서 보내게 된다.

그래서 reply 를 받았을 때, 이 id 값을 보고 어떤 질문에 대한 응답인지를 식별할 수 있다.

 

flag : 16bit 정보로 아래 정보들이 담긴다.

- 이 flag 정보로 현재 주고받는 데이터가 query인지 reply이인지 구분한다.

- recursion 을 원하는지 결정한다. (recursion desired)

- 물론 쿼리에서 리커젼을 원한다고 표시해서 보내도, 서버는 거절할 수 있다. (recursion available )

- reply authoritative : DNS 서버가 갖고 있는 레코드 정보의 유효기간 (TTL) 이 지났을 때, TTL이 지난 데이터를 지우지 않고 갖고 있기도 하다. 이 경우, 응답하는 입장에서는 답을 모른다고 하거나, 답을 알지만 이건 유효기간이 지나서 확실하진 않다고 알려줄 수도 있다.

이때 이 필드를 사용하여 '이 답은 권위있는 답은 아니다' 라고 명시해서 보낼 수 있다.

 

question : 32bit 정보로, 쿼리 정보가 들어간다.

한번에 2개 이상의 도메인 네임에 대한 쿼리를 보낼 수 있다.

 

answer : 32bit 정보로, reply 정보가 들어간다.

즉, DNS 서버가 캐시에 갖고 있는 Resource Record 가 들어간다.

 

authority, additional info : TTL이 지난 레코드를 돌려줄 때, 권위가 지난 레코드라는 정보를 추가적으로 담아서, 클라이언트가 선택적으로 원하면 사용할 수 있도록 한다.

보통 클라이언트는 유효기간이 지나도 그 정보를 그냥 사용하긴 한다.

 

DNS에 등록해야 하는 정보

만약 창업을 해서 회사를 만든다면, 회사의 도메인과 메일 서버 등을 설정하는 과정에서 DNS에 어떤 정보를 등록해야 하는지 알아보자.

우선 도메인 네임을 어딘가에 등록해야 한다.

도메인 네임을 대신 등록해주는 회사를 registrar 라고 한다. (레지스터 x, 레지스트라 o)

레지스트라는 .com 과 같은 TLD 네임 서버에 새로 등록한 도메인 정보를 추가한다.

 

제일 중요한 것은 회사의 authoritative name server 를 만들어서 등록하는 것이다.

네임서버가 등록되면 외부에서 회사로 어떤 쿼리가 들어왔을 때, 이 네임서버로 쿼리가 넘어오게 된다.

그래서 이 네임서버에서 도메인 이름에 대한 정확한 IP 주소를 알려줄 수 있다.

 

 

이에 대한 내용이 위 이미지 내용이다.

여기에서는 타입 A 레코드에 dns 의 도메인 이름에 IP 주소를 연결해두고, 서비스 도메인은 네임서버 도메인과 연결시켜두었다.

(나는 내 웹사이트 도메인을 연결할 때 그냥 everdu.com 을 바로 타입 A로 IP주소와 매핑했다.

이 상위에 네임서버를 두는 이유는 지금 바로 와 닿지는 않았으나, 서브 서비스가 많아지거나, 하나의 도메인에 연결된 서버 컴퓨터가 많을 경우 IP주소가 여러개가 될 수 있어서 네임서버를 앞단에 둔 것 같다.)

근데 지금보니 이 정보는 내가 세팅하는게 아니라, 레지스트라가 TLD 에 등록하는 레코드였다.

 

 

내가 등록할 때는 www.사이트 도메인을 바로 A 레코드로 연결하고, 메일 주소에 사용할 도메인을 MX 타입으로 연결해둔다.

 

그럼 www.networkuptopia.com  에 접속하면 먼저 TLD 서버로 가서 dns1.networkutopia.com 을 알려주고, 이에 대해  212.212.212.1 이라는 주소를 알려준 뒤, 브라우저는 다시 212.212.212.1에 요청을 보내는 걸까?

아니면 authoritative server 가 A타입으로 바로 알려주는 걸까?

흠...

 

DNS Sequrity (DNSSEC)

1. DDos 공격

루트 서버에 매우 많은 쿼리를 집중시켜 보내는 경우다.

하지만 성공한 적은 없다고 한다.

보통은 트래픽 필터링을 통해 악성 IP주소를 차단해서 막을 수 있다.

그리고 보통은 root name server까지 쿼리가 올 일이 많이 없기 때문에 힘든 것도 있다.

 

그래서 TLD 네임 서버에 공격을 가하기도 한다.

이런 시도도 굉장히 많았는데, 이것도 성공하기 힘든 이유는 TLD 네임 서버가 한군데만 있는게 아니라 매우 많기 때문에 쉽지 않다고 한다.

그래도 root name server 에 대한 공격보다는 더 위협적인 공격이 맞다.

 

2. Spoofing 공격

정상적인 쿼리를 가로채서 그 응답을 조작하는 방식이다.

naver.com 을 쳤는데, 실제 네이버의 IP주소가 아니라 조작된 네이버 사이트의 IP 주소를 반환하여, 사용자를 속이고 사용자가 입력한 개인정보를 탈취하는 방식이다.

 

이 방식은 도메인을 아무리 정확하게 입력하고, 북마크에 등록해놔도, 도메인 네임으로부터 잘못된 IP주소를 매핑하기 때문에 당할 수 밖에 없다.

 

또는 응답을 조작하는 것을 넘어 아예 DNS 서버 캐시를 바꿔버릴 수도 있다.

이게 더 위험한 방식이다. 특정 쿼리 하나의 응답을 조작하는 것이 아니라, 이 도메인에 접근하는 모든 쿼리에게 잘못된 응답을 보낼수도 있기 때문이다.

이를 DNS chache poisoning 이라고 하는데, 이걸 유명 해킹 컨퍼런스에서 실제로 가능하다는 걸 입증하는 바람에 난리가 난 적이 있다고 한다..

그래서 바로 패치해서 프로토콜과 구현하는 방법을 수정하였으며, DNS SEC 이라는 새로운 프로토콜의 등장으로 위험이 많이 완화됐다. 하지만 DNS SEC 은 암호화를 사용해야해서 암호를 해독하는 시간과 메세지의 정합성을 확인하는 시간이 추가되어 성능에 부담이 생겼다.