위키원
DNS
개요
DSN는 도메인 네임 시스템(Domain Name System)의 약자로 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다.
특정 컴퓨터나 네트워크로 연결된 임의의 장치의 주소를 찾기 위해, 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호인 IP 주소로 변환해준다. 즉, 인터넷 도메인 주소 체계로서 TCP/IP의 응용에서, www.wiki.hash.kr과 같은 주 컴퓨터의 도메인 이름을 192.168.1.0과 같은 IP 주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템이다.
인터넷은 2개의 주요 이름공간을 관리하는데, 하나는 도메인 네임 계층, 다른 하나는 인터넷 프로토콜 주소 공간이다. 도메인 네임 시스템은 도메인 네임계층을 관리하며 해당 네임 계층과 주소 공간 간의 변환 서비스를 제공한다. 인터넷 네임 서버와 통신 프로토콜은 DNS 시스템을 구현한다. DNS 네임 서버는 도메인을 위한 DNS 레코드를 저장하는 서버이며, 데이터베이스에 대한 쿼리의 응답 정보와 함께 응답한다.[1]
등장배경
DNS의 기원은 1960년대부터 올라온다. 1960년대 말 미국의 아르파넷(ARPANET)이 등장한다. 아르파넷은 미국의 주요 연구기관을 연결한 광역 컴퓨터망으로써 미국 국방부의 ARPA(Advanced Research Project Agency)가 투자하여 개발하였다.
1980년대 초 TCP/IP 프로토콜이 개발되었다. IP는 'Internet Protocol'의 약자로서 산재한 컴퓨터 네트워크 간에 상호 연동을 하기 위한 프로토콜이다. TCP/IP 프로토콜은 빠른 속도로 아르파넷에서 컴퓨터 네트워킹의 표준 프로콜이 되었는데, 이 당시만 해도 DNS는 존재하지 않았다. 버클리 대학의 BSD Unix에 TCP/IP 프로토콜이 탑재되는 동시에 아르파넷에 연결된 호스트 수가 급격하게 증가했다. 1974년 기준 아르파넷은 총 23개의 호스트만이 존재하고 있었는데, 1981년에는 213개, 1983년에는 562개, 1984년에는 1024개, 1985년는 1961개, 1987년에는 28174개로 기하급수적인 증가세를 보였다.
이렇듯 TCP/IP를 기반으로 형성된 지역 및 광역 네트워크를 인터넷(Internet)이라 부르게 되었는데, TCP/IP 표준 프로토콜의 등장과 BSD Unix의 TCP/IP 지원으로 갑작스럽게 증가한 호스트로 인해 문제가 생겼다. 그것은 기하급수적으로 증가해버린 호스트의 네임의 구성 및 관리이다. 초기 아르파넷 환경에서는 각 호스트의 주소를 모두 외울 수 있었고, 호스트 수가 증가함에 따라 니모닉(Nemonic)을 호스트별로 부여해 쉽게 기억할 수 있게 하였지만. 호스트의 이름이 변경되거나 호스트의 수가 증가함에 따라 이런 방법의 변경 및 분배는 한계에 달하게 되었다. 더불어 인터넷의 규모가 날로 커지면서 호스트 이름과 IP주소 레코드를 자동적으로 관리하는 체계가 필요하게 되어 DNS가 등장했다.
DNS 설계 목표와 목적
- 전세계적인, 확장성 뛰어난, 그리고 일관성 있는 네임 공간의 개발
- 로컬 자원에 대한 로컬 제어
- 병목 현상을 막기 위한 분산 설계
- 광범위한 응용을 지원할 수 있도록 일반적이어야 하며, 호스트 식별, 메일 전송 등과 같은 기능을 지원해야 한다.
- 다양한 기본 프로토콜에 대한 지원
- 하드웨어의 일반성[2]
구조
DNS는 도메인 이름과 IP주소의 매핑을 위한 관리 체계로 크게 도메인 네임 스페이스, 네임서버, 리졸버로 구성된다.
도메인 네임 스페이스
도메인 네임 스페이스(Domain Name Space)는 거대한 분산 네이밍 시스템인 DNS가 저장 및 관리하는 계층적 구조를 말한다.
도메인 이름 공간은 도메인 이름이 트리 형태로 구성되어 있다. 트리의 각 노드는 리소스 레코드를 가지며 0개 이상의 레코드를 가질 수 있다. 트리는 최상위에 루트존에서 시작하여서 인터넷에 연결된 모든 노드가 연속해서 이어진 하위 존으로 나누어져있다. 각 DSN존은 하나의 권한 있는 서버에 의해 관리되는 노드들의 집합이다. 각 존과 도메인은 그 하위 도메인에 관한 정보를 관리한다.
하나의 네임 서버가 여러 개의 존을 관리할 수도 있다. 관리 권한은 분할되어 새로운 존을 형성할 수 있으며, 기존의 도메인 이름 공간의 일부분이 서브 도메인 형태로 다른 네임 서버에 권한이 위엄된다. 그리고 기존의 존은 새로운 존에 대한 권한을 잃게된다.
도메인 네임 서버
숫자로 구성된 IP 주소와 함께 사용하기 편리하고 기억하기 쉬운 이유로 도메인 이름을 사용한다. 그러나 실제 웹 클라이언트와 웹 서버 간의 통신은 숫자로 표현된 IP주 주소를 사용하여 통신한다. 이를 위해서 문자열로 표현된 도메인 이름을 컴퓨터가 통신할 때 사용하는 숫자로 변환시켜 주어야 한다. 이러한 동작을 위해 도메인 네임 스페이스의 트리 구조에 대한 정보가 필요하며, 이러한 정보를 가지고 있는 서버를 도메인 네임 서버라고한다.
- 도메인 이름 형성에 관한 규칙으로 도메인 이름은 한 개 이상의 부분(레이블)로 이루어지고, 점으로 구분하여 붙여 쓴다.
- 가장 오른쪽 레이블은 최상위 도메인을 의미한다. 예를 들어, 도메인 이름 www.example.com은 최상위 도메인 com에 속한다.
- 도메인의 계층 구조는 오른쪽부터 왼쪽으로 내려간다. 왼쪽의 레이블은 오른쪽의 서브도메인이다. 예를 들어, 레이블 example은 com 도메인의 서브도메인이며, www는 example.com의 서브도메인이다. 서브도메인은 127단계까지 가능하다.
- 각 레이블은 최대 63개 문자를 사용할 수 있고, 전체 도메인 이름은 253개 문자를 초과할 수 없다. 실제로는 도메인 레지스트리에 더 짧은 제한을 가질 수 있다.
- 도메인 이름은 기술적으로 옥텟으로 표현할 수 있는 모든 문자를 사용할 수 있다. 그러나 DNS 루트 존과 대부분의 서브도메인에서는 제한된 형식과 문자들만 허용한다. 레이블에 사용될 수 있는 문자는 아스키 문자 집합의 부분집합과 알파벳 a부터 z, A부터 Z, 숫자 0부터 9와 하이픈(-)을 포함한다. 이 규칙은 letter(문자), digit(숫자), hyphen(하이픈)의 첫글자를 따서 LDH 규칙이라고 한다. 도메인 이름은 대소문자 구분없이 해석되고, 레이블은 하이픈으로 시작하거나 끝날 수 없다.[1]
리졸버
리졸버는 웹 브라우저와 같은 DNS 클라이언트의 요청을 네임 서버로 전달하고, 네임 서버로부터 도메인 이름과 IP 주소를 받아 클라이언트에게 제공하는 기능을 수행한다.
이 과정에서 리졸버는 하나의 네임 서버에게 DNS 요청을 전달하고, 해당 서버에 정보가 없으면 다른 네임 서버에게 요청을 보내 정보를 받아 온다. 이렇듯 리졸버는 수많은 네임 서버에 접근하여 사용자로부러 요청 받은 도메인의 IP 정보를 조회하는 기능을 수행 할 수 있어야 한다.
하지만 이러한 리졸버의 모든 기능을 PC와 같은 클라이언트 호스트에 구현하는 것은 단말 시스템 자원의 한계와 같은 제약이 있다. 이에 따라 리졸버의 대부분의 기능을 DNS 서버에 구현하고, 클라이언트 호스트는 리졸버의 단순한 기능만을 지닌 리졸버 루틴을 구현하는 옵션이 제시되었다. 이러한 단순화된 기능의 리졸버를 스터브 리졸브라고 하며, 스터브 리졸버는 수 많은 네임 서버의 구조를 파악할 필요 없이 리졸버가 구현된 네임 서버의 IP 주소만 파악하면 된다. 클라이언트 호스트에 설정하는 DNS 서버는 이와 같은 네임 서버를 의미하는 것으로, 도멩니에 대한 질의를 받은 스터브 리졸버는 설정된 네임 서버로 DNS 질의를 전달하고 네임 서버로부터 최종 결과를 응답 받아 웹 브라우저로 전달하는 인터페이스 기능만을 수행한다.
도메인 구성
국가 도메인
- kr, us - 각 국가별 사용을 위해 정의한 도메인으로 ISO3166에서 정의하는 국가 코드에 기반함
일반 도메인
- com - 기업과 같은 상용 조직을 위한 도메인
- edu - 교육 기관들을 위한 도메인
- net - 네트워크 서비스 제공자와 관련된 시스템을 위한 도메인
- org - 다른 TLD에 속하지 않는 비정부 단체를 위한 도메인
- int - 국제 협약에 의해 만들어진 조직을 위한 도메인
- gov - 본래 정부 기관이나 단체를 위한 도메인이었으나, 현재 미국의 주 정부를 비롯한 연방 정부만 등록하도록 결정된 도메인
- mil - 미국 국방성 관련 기관에서 사용하도록 정의한 도메인
특수 도메인
- arpa - IP 주소를 도메인 이름으로 매핑하기 위해 사용되는 특수 도메인
서버 종류
주 DNS 서버(Primary DNS servers)
가장 기본이 되는 DNS 서버로 도메인에 대한 기본적인 데이터 베이스를 저장하고 있으며 네트워크상의 클라이언트들의 질의(Query)에 대한 응답을 목적으로 한다. 자신의 데이터상에 질의에 대한 응답이 없다면 상위 도메인 서버에 다시금 질의를 하거나 클라이언트를 연결해 주는 재귀와 반복의 과정을 통하여 도메인존에 대한 이름을 풀이 과정을 실행하게 된다.
보조 DNS 서버(Secondary DNS servers)
보조 DNS 서버는 주 DNS 서버의 백업서버로 주 DNS 서버의 데이터를 계속적으로 복제하였다가 주 DNS 서버에 장애가 발생할때 DNS 서버로써 역할을 하게 된다. 또다른 하나의 역할은 분산의 역할을 할 수 도 있는데 네트워크내의 클라이언트의 수가 많다면 이들 클라이언트들의 주 DNS 설정을 보조 DNS 서버로 연결을 하는 방법으로 DNS 트래픽에 대한 분산을 할 수 있다.
캐싱서버(Caching-only DNS servers)
네트워크상의 DNS 서버는 클라이언트로 부터 질의된 이름풀기 요청에 대한 정보를 제공할때 자신의 정보데이터베이스로부터 찾아서 보여준다. 이렇게 자신이 보유한 정보 예를 들어서 www.kr.net 의 IP 는 211.52.105.xxx 다 이런식의 정보를 자신이 가지고 있다면 문제가 없지만 이러한 정보가 없을때는 상위 DNS 서버에게 다시금 질의를 하게 된다. 이렇게 외부 도메인 정보를 질문을 하게 되었을때 클라이언트들은 당연히 결과값을 더 느리게 받게 될 뿐만 아니라 네크워크 트래픽도 증가된다.
따라서 이렇게 외부 DNS 를 이용해야 하는 경우의 질의(Query)에 대해서 DNS 서버는 캐싱작업을 하게 되는데 이것은 마치 인터넷 익스플로러의 케싱 기능과 유사하다. 질의와 값을 모두 저장하게 됨으로 네트워크상에서 다시금 같은 질의가 들어오게 되면 케싱상에 저장된 데이터를 바탕으로 그 즉시 결과값을 전달하게 됨으로써 네트워크 상에 트랙픽은 혁신적으로 줄어든다. 대부분의 구성에서 캐시 TTL 값은 영역의 권한 시작(SOA) 리소스 레코드에서 사용되도록 설정된 최소(기본) TTL로 지정된다. 기본적으로 최소 TTL(Time-To-Live)은 3,600초(1시간)지만 조정이 가능하며 필요하면 캐시에 대한 TTL은 수정이 가능하며, 케싱시간을 적게하고 길게 함에 따라서 각각의 장단점이 있다. 케싱시간을 너무 길게 잡게 되면 수정된 DNS 정보에 대한 올바른 적용이 더디게 되며 너무 작게 잡게 되면 트래픽이 증가된다.
케싱 기능은 DNS 서버에서 기본적으로 사용하는 기능으로 이러한 케싱기능을 전문으로 하는 케싱서버를 구성할 수 도 있다. 윈도우 2000 의 DNS 서버도 이러한 케싱서버의 역할을 지원한다. 케싱서버의 사용에서 주의할 점은 케싱서버의 케싱된 정보는 서버가 재 부팅하게 되면 사라진다는 것이다. 따라서 부트 후에는 처음부터 다시금 캐시 백업을 만들어야만 한다.
전달서버(Forwarding DNS servers)
일반적으로 DNS 서버들은 로컬 네트워크상의 클라이언트들이 질의한 요청에 대한 해결은 스스로 처리할 수 없을때 외부 DNS 서버에 다시금 질의를 요청하게 된다. 이렇게 자신이 처리할 수 없는 요청에 대하여 외부에 요청을 하게 될때 네트워크 상에서 이러한 요청만을 전담하는 서버가 바로 전달 서버(Forwarding DNS server)이다. DNS 서버들의 외부로의 요청을 모두 전담하여 전달하기 때문에 마치 프록시(Proxy) 서버와 같은 역할을 한다.
엑티브디렉터리 통합서버(AD integrated servers)
액티브디렉터리 통합서버는 DNS 서버와는 다르게 윈도우 2000 에서 소개하고 있는 DNS 서버이다. 윈도우 2000 서버가 인터넷을 기반으로 하는 최대형 규모의 서버를 표방하면서 들고 나온 카드가 바로 AD(Active Directory) 와 TCP/IP 를 기반으로 하는 네트워크킹이다. 인터넷을 기반으로 도메인을 조직하기 때문에 기존의 NT 상에서의 DNS 와 윈도우 2000 서버상의 DNS의 그 중요성은 많은 차이를 보인다. 이것은 윈도우 2000 서버에서 네트워크상의 자원을 찾는 방식이 도메인을 기반으로 하기 때문이다. AD와 통합된 DNS 서버를 사용하여 얻는 이점으로는 여러가지가 있는데 이중 가장 대표적인 이점이 결함 허용과 보안이다.
- 결함허용
일반적인 DNS 서버의 구성에서 주 DNS 서버의 데이터가 업데이트 되면 보조 DNS 서버는 주 DNS 서버로 부터 변경된 내용을 복제하게 된다.. 이 과정에서 주 DNS 서버의 장애가 발생하게 되면 복제가 실패하게 되며 이로 인해서 DNS 서버를 다시 설치하게까지 되는 문제를 야기한다. 그러나 AD에 통합된 윈도우 2000 서버의 DNS 는 이러한 오류를 방지할 수 있다.
- 보안
DNS 서버의 정보는 텍스트 파일에 저장되며 결론적으로는 이 텍스트 파일을 이용하여 클라이언트에게 DNS 서비스를 제공하는것인데 윈도우 2000은 이러한 정보파일을 텍스트 파일로 저장하지 않는다. 따라서 보안적인 면이 더욱 강화되었다.[3]
특징
- 관리의 위임 및 분산관리 시스템
기존의 중앙 집중적인 호스트 텍스트 파일의 한계점에 대한 대안으로 상위 도메인이 관리하는 부분과 하위 도메인이 관리하는 부분들은 서로 분산되어져 계층적인 구조로 나뉘고 해상 서버가 자신의 관리 영역만을 관리하면 된다.
- 네트워크 확장을 위한 확장성
DNS는 계층적인 트리구조의 형식을 갖고 있어 상당히 유연한 확장성을 가진다.
- 계층적이며, 직관적인 구성
계층적이면서도 직관적이고 알아 보기 쉬운 구조로 설계 되어 있다.[3]
- 인터넷상 대규모 자원에 대한 명칭 부여와 분산화
Hierarchical, Distributed, Scalable 한 데이터베이스, 루트 노드로부터 최대 128개 레벨을 갖는 역 계층구조
- 복잡한 영문이름을 쉽고 상징적인 하나 이상의 별칭(Alias)으로 관리
친숙한 영문이름(www.wiki.hash.kr 등)을 컴퓨터가 이해하는 IP 주소로 변환
동작원리
- DNS 쿼리 (웹 브라우저 --> 로컬DNS) : 사용자의 요청(www.hash.kr)을 받은 웹 브라우저는 www.hash.kr 도메인에 대한 IP 주소를 알아내기 위해 DNS 쿼리 메시지를 로컬 DNS 서버에게 전달한다.
- DNS 쿼리 (로컬 DNS --> 루트 DNS) : 웹 브라우저로부터 DNS 쿼리를 받은 로컬 DNS 서버는 자신이 해당 도메인에 대한 IP 정보가 없음을 인지하고, www.hasj.kr IP 주소를 알아내기 위해 로컬 DNS 서버에 미리 설정된 최상위 루트 DNS 서버에게 DNS 쿼리 메시지를 전달한다.
- DNS Response (루트 DNS --> 로컬DNS) : 로컬 DNS 서버로부터 DNS 쿼리를 받은 루트 DNS 서버는 www.hash.kr의 IP 주소를 가지고 있지는 않지만, 자신이 관리하는 하위 레벨의 네임 서버들 가운데 kr 도메인을 관리하는 네임 서버들의 정보를 담아 보낸다.
- DNS 쿼리 (로컬 DNS --> 도메인) : 루트 DNS 서버로부터 kr 도메인을 관리하는 네임 서버들의 정보를 알아낸 로컬 DNS 서버는 이 가운데 하나를 임의로 선택해 해당 네임서버에게 www.hash.kr 도메인에 대한 IP 주소를 알아내기 위해 DNS 쿼리 메시지를 전달한다.
- DNS Response (도메인 --> 로컬 DNS) : 요청 도메인을 관리하는 네임서버 역시 로컬 DNS 서버로부터 DNS 쿼리를 받은 IP주소를 가지고 있지 않지만, 자신이 관리하는 하위 레벨의 네임 서버들 가운데 hash.kr 도메인을 관리하는 네임 서버의 정보를 담아 보낸다.
- DNS 쿼리 (로컨 DNS --> 도메인) : kr 도메인을 관리하는 네임 서버로부터 hash.kr 도메인을 관리하는 서버들의 정보를 알아낸 로컬 DNS 서버는 이 가운데 하나의 네임 서버를 임의로 선택해 해당 네임서버가 선택되며, www.hash.kr도메인에 대한 IP주소를 알아내기 위해 DNS 쿼리 메시지를 전달한다.
- DNS Response (도메인 --> 로컬DNS) : hash.kr 도메인을 관리하는 네임 서버 역시 www.hash.kr IP주소를 가지고 있지 않지만, 로컬 DNS 서버가 요청한 도메인 이름이 www.q.hash.kr 별칭으로 사용되는 CNAME 정보와 자신이 관리하는 하위 레벨의 네임 서버들 가운데 www.q.hash.kr 도메인을 관리하는 네임 서버들의 정보를 DNS Response 메시지에 담아 보낸다.
- DNS 쿼리 (로컬 DNS --> 도메인) : hash.kr 도메인을 관리하는 네임 서버로부터 q.hash.kr 도메인을 관리하는 네임 서버 정보를 알아낸 로컬 DNS 서버는 이 가운데 하나의 네임 서버를 임의로 선택해 해당 네임 서버에게 www.hash.kr 도메인으 별칭인 www.q.hash.kr에 대한 IP 주소를 알아내기 위해 DNS 쿼리 메시지를 전달한다.
- DNS Response (도메인 --> 로컬DNS) : q.hash.kr 도메인을 관리하는 네임 서버는 자신이 www.q.hash.kr의 IP주소를 가지고 있는 것을 확인하고, 해당 호스트 주소를 DNS Response 메시지에 담아 로컬 DNS 서버에 보낸다.
- DNS Response (로컬DNS --> 웹 브라우저) : q.hash.kr 도메인을 관리하는 네임 서버로부터 www.q.hash.kr 도메인의 IP 주소를 알아낸 로컬 DNS 서버는 이제야 웹 브라우저로 IP 정보를 DNS Response 메시지에 담아 전달한다. 이 메시지에는 웹 브라우저가 요청했던 www.hash.kr.은 www.q.hash.kr이라는 별칭으로 사용된다는 CNAME 정보와 함께 해당 도메인의 IP 주소가 포함되어 있다.[5]
취약점
Recursion Query
도메인 네임서버는 도메인을 IP address와 매핑하는 역할을 한다. 따라서, 접속하고자 하는 도메인이 있다면, 클라이언트는 1차적으로 자신의 cache에서 해당 도메인의 IP address를 질의하고 만일 존재하지 않을 경우 설정한 네임서버로 쿼리를 던진다. 쿼리를 받은 네임서버는 자신이 운영하는 도메인인지 확인하고, 만일 아닌 경우 cache에서 데이터를 검색하게 된다. cache에도 존재하지 않으면 상위 네임서버에 질의하는 과정을 반복한다. 이렇게 순환적으로 질의하는 네임서버 쿼리를 Recursion query라고 한다.
DoS/DDoS
원래 네임서버는 질의 요청을 받으면 자신이 운영하는 도메인들의 데이터를 검색하고, 자신이 운영하는 도메인이 아닌 경우에는 상위 네임서버를 알려주고 해당 쿼리를 종료하여야 한다. 그렇게 되면 recurion이 여러 차례 발생하게 되어 그만큼 시간이 더 소요되므로 검색시간 단축을 위해 많은 네임서버들이 recursion을 허용(opend DNS)하여 외부 네트워크에 속하는 서버 및 호스트에 대해서도 직접 조회하는 경우가 많다. 이러한 open DNS는 네임서버로 들어오는 모든 쿼리에 대해 검색을 시도할 것이고, 따라서 수많은 질의가 한꺼번에 보내는 공격을 한다면 해당 네임서버는 정상적인 요청을 처리하지 못하는 상태에 빠질 수 있다.
Cache Poisoning
공격자는 Recursive query를 허용하고 있는 서버를 목표로 정한 후, 공격자 자신이 운영하는 네임서버에 자신의 도메인을 비롯하여 특정 도메인의 잘못된 값 혹은 수많은 정상적 도메인들에 대한 잘못된 데이터를 저장해 두고 목표 서버를 사용하는 무작위 클라이언트가 자신의 도메인에 접속하도록 유도한다. 또는 공격자가 직접 Recursive query가 허용된 목표 네임서버에 자신의 도메인을 질의할 수도 있다. 목표 서버는 해당 도메인이 자신의 cache에 없는 도메인이므로, 클라이언트의 질의에 대해 응답하기 위하여 공격자의 네임서버로 질의를 하게 된다. 이 때 공격자의 네임서버는 자신이 보유하고 있는 여러 위조된 도메인들도 계속적으로 질의하여 목표서버가 그 데이터를 전송받도록 한다. 따라서 새로운 위조 정보들로 cache를 채우게 된다. 이러한 Cache poisoning 공격이 위험한 이유는, 이로 인해 엉뚱한 사이트로 접속하게 하고 사적인 정보를 훔치는 Parming(파밍) 공격을 유도할 수 있기 때문이다.[6]
각주
- ↑ 1.0 1.1 〈DNS〉, 《위키백과》
- ↑ 〈도메인 네임 시스템(DNS)의 개관, 기능, 특징〉, 《Jung Woo 블로그》, 2014-08-18
- ↑ 3.0 3.1 〈DNS에 대해서〉, 《이글루스》, 2005-06-03
- ↑ 〈정보통신기술용어해설〉, 《ktword》, 2019-03-08
- ↑ 〈DNS 기본 동작 원리〉, 《넷매니아즈》
- ↑ 콩나물, 〈DNS문제점〉, 《네이버 블로그》, 2006-09-16
참고자료
- 고인돌SE, 〈DNS 개요〉, 《네이버 블로그》, 2004-07-28
- 〈DNS〉, 《위키백과》
- Netmanias teach,〈DNS 기본 동작 원리〉, 《넷 매니아즈》
- 로뚱쓰라이더, 〈DNS(Domain Name System)란?〉, 《네이버 블로그》, 2014-03-02
같이보기
