KR101345372B1 - 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법 - Google Patents

사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법 Download PDF

Info

Publication number
KR101345372B1
KR101345372B1 KR1020120024546A KR20120024546A KR101345372B1 KR 101345372 B1 KR101345372 B1 KR 101345372B1 KR 1020120024546 A KR1020120024546 A KR 1020120024546A KR 20120024546 A KR20120024546 A KR 20120024546A KR 101345372 B1 KR101345372 B1 KR 101345372B1
Authority
KR
South Korea
Prior art keywords
information
dns
domain name
client
user information
Prior art date
Application number
KR1020120024546A
Other languages
English (en)
Other versions
KR20130103145A (ko
Inventor
서정환
임영석
Original Assignee
임영석
서정환
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 임영석, 서정환 filed Critical 임영석
Priority to KR1020120024546A priority Critical patent/KR101345372B1/ko
Publication of KR20130103145A publication Critical patent/KR20130103145A/ko
Application granted granted Critical
Publication of KR101345372B1 publication Critical patent/KR101345372B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Abstract

본 발명은 사용자 정보에 기반한 도메인 네임 시스템 및 도메인 네임 서비스 방법에 관한 것으로서, 그 도메인 네임 시스템은 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 출력하는 클라이언트; 클라이언트로부터 도메인 네임 쿼리를 수신하는 DNS; 및 그 DNS로부터 도메인 네임 쿼리를 수신하고, 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 사용자 정보 별로 목적지 경로 정보를 달리 제공하는 데이터베이스를 포함하고, 그 클라이언트는 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 DNS를 통해 수신하는 것을 특징으로 한다.
본 발명에 의하면, 사용자 별로 목적지 경로를 분배 및 제어하여 안정적으로 회선을 관리하고, 서비스에 이용되는 서버 및 장치의 비정상적인 동작 중에서도 사용자들에게 서비스의 연속성을 유지시켜 줄 수 있다. 또한 사용자 별로 목적지 경로를 분배 및 제어함으로써 D-DOS에 의한 대역폭 공격을 막아낼 수 있다.

Description

사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법{System and Method for servicing domain name based on user information}
본 발명은 도메인 네임 서비스에 관한 것으로서, 특히 사용자 별로 목적지 경로를 분배 및 제어하여 안정적으로 회선을 관리하고 서비스에 이용되는 서버 및 장치의 비정상적인 동작 중에서도 사용자들에게 서비스의 연속성을 유지시켜주는, 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법에 관한 것이다.
인터넷은 개체를 구분하기 위해 IP 주소를 사용한다. 그러나 사람들은 주소보다는 이름을 사용하고자 하는 경향이 있다. 그러므로 이름을 주소로 바꿔주고 주소를 이름으로 주는 시스템이 필요하다.
이러한 변환 시스템은 이름과 주소(모든 이름과 주소는 유니크(unique)하다)를 매핑시켜 한 가지를 알고 있으면 다른 한 가지를 알려주는 형태로 이루어지는데, 인터넷의 규모가 점점 커지면서 모든 이름과 주소를 단일 컴퓨터에 저장하고 알려주는 것이 불가능해 졌다.
이에 대한 해결책으로 현재 사용되고 있는 시스템은 아주 많은 정보를 작은 부분으로 나눈 후 서로 다른 컴퓨터에 각 부분을 나누어 저장하는 도메인 네임 시스템 ( DNS : Domain Name System )이다.
도메인 네임은 '.'로 나누어지는 여러 레이블(label)을 가지는데, 각 레이블은 최대 63개의 문자로 이루어진다. 다시 말하면 완전한 도메인 네임은 점(.)을 구분되는 레이블의 연속이다.
예를 들면 Service.com. 은 Service 레이블과 com 레이블 그리고 NULL 레이블로 이루어져 있다.(도메인 네임의 마지막에는 항상 NULL 레이블이 포함된다.)
이름을 주소로 변환하거나 주소를 이름으로 변환하는 것을 이름 주소 해석(name-address resolution)이라 한다.
도 1은 도메인 네임 해석 과정에 대한 일 예를 나타낸 것으로서, 도 1을 참조하여 도메인 네임의 일 예로 'www.Service.com. Domain'을 해석하는 과정을 설명하기로 한다.
일반적으로 사용자들은 브라우저를 통해 도메인 네임으로 서비스를 요청하는데, 주소를 이름으로 변환하기를 원하는 호스트는 해석기(resolver)라 불리는 DNS 클라이언트를 호출한다. 해석기는 해석 요구를 보내기 위해 가장 가까운 DNS 서버로 접속한다. DNS 서버는 호스트의 운영체제(Operating System) 상에 설정되며, 본 명세서에서는 상기 DNS 서버를 '공개 DNS' 라 하기로 한다.
해석은 도메인 네임의 뒤에서부터 시작한다. 도메인 네임의 가장 뒤는 항상 NULL 레이블(115)이 존재하며, 도메인 네임의 마지막에는 항상 점 ( . ) 이 존재한다.
NULL 레이블(115)은 루트 DNS 서버(Root DNS Server, 130)를 의미하며, 사용자의 도메인 요청 메시지를 받은 공개 DNS(125)는 설정된 루트 서버로 www.Service.com 의 IP 주소를 요청한다.
루트 DNS 서버(130)는 해당 도메인에 대한 IP 주소 정보를 가지고 있지 않다면 Com 레이블(110)에 대한 정보를 가진 Com 네임서버(135)의 주소를 응답해준다.
공개 DNS(125)는 응답받은 Com 네임서버(135)에 www.Service.com 의 IP 주소를 요청하고, Com 네임서버(135)는 Service 레이블(105)의 정보(권한)를 가진 DNS 서버(140)를 응답해 준다.
다시 공개 DNS(125)는 응답 받은 DNS 서버로 www.Service.com 에 대한 해석을 요청한다. 요청을 받은 DNS 서버는 Service의 정보를 가진 Zone File(Zone File, 145) 내부에 www 에 대한 매핑된 IP 주소 정보가 있으므로 200.1.1.1 이라는 IP 주소를 응답해주게 된다.
응답 받은 공개 DNS 서버(125)는 클라이언트의 해석기(Resolver, 120)에게 200.1.1.1 을 응답해 주게 되고, Resolver(120)가 응답 메시지를 해석한 뒤 해석을 요구한 클라이언트 프로그램에 그 값을 넘겨준다.
이와 같이 DNS 서버가 도메인에 대한 권한을 가진 DNS 서버의 IP를 넘겨주고 질의를 반복적으로 시도하는 방식을 반복적(iterative) 해석이라 한다.
그리고 DNS 서버가 Zone File에서 도메인 네임과 매칭된 IP 어드레스를 응답해 주는데, 초기에는 주소에 많은 변경이 가해질지 예측하지 못하였다.
도메인 네임과 매핑된 IP 주소 정보를 변경해야 할 때 이를 관리자가 수동적으로 일일이 변경해주는 것은 매우 힘들다. 그 해결책으로 DNS 주 파일을 자동적으로 갱신시켜주는데 이를 동적(Dynamic) DNS 라 부른다
그러나, 사용자 기반의 정보 제공을 위해서는 DNS 요청 메시지에서 사용자정보를 수집해야 하는데, 종래의 DNS 요청 메시지에는 그 정보가 극히 제한적이다. 또한 DNS 서버의 주 마스터 파일의 수정 즉, 매핑된 정보의 추가, 제거 및 변경이 빈번하며, 동기화를 항상 유지시켜줘야 하는 서비스의 경우 종래의 정적 DNS로는 기능을 완벽히 수행하기 힘들다.
뿐만 아니라, 분산 서비스 거부 공격(Distributed denial-of-service attack, D-DOS)은 인터넷상에서 다수의 시스템이 협력하여 하나의 표적시스템을 공격함으로써 서비스 거부(DOS)를 일으키게 만드는 것을 말한다. 표적 시스템은 범람하는 메시지들로 인해 결국 시스템 가동이 멈추어지게 되어, 선의의 사용자들은 정작 그 시스템으로부터 서비스를 받지 못하는 일이 벌어지게 된다. 즉, 목표 시스템의 특정 자원이나 사용이 가능한 회선 트래픽을 독점하여 선의의 사용자들이 목표시스템의 서비스를 받지 못하는 것이다.
그리고, 로드 밸런싱(Load Balancing)이란 병렬로 운용되고 있는 기기 간에 부하가 균등해지도록 처리를 분산하여 할당하는 것을 말한다. 로드 밸런싱은 컴퓨터 내의 여러 마이크로 프로세서에 균등하게 처리를 부여하거나, 접속 요구를 네트워크 상의 여력이 있는 서버로 회송하는 등 다양한 분야에서 폭 넓게 이용되고 있는 개념이다. 로드 밸런싱을 효율적으로 수행하기 위해서는 각 기기의 부하를 계속적으로 측정할 필요가 있는데, 이를 정확하게 적용하려고 하면 로드 밸런싱의 제어 자체가 큰 부하를 발생시킨다. 따라서, 실제로 이용되고 있는 로드 밸런싱은 정확도와 부하의 밸런스를 취하도록 되어 있으며, 이보다도 더 효율적인 수단을 찾기 위해 연구가 계속되고 있다.
그런데, 대역폭 공격의 경우 장비(IPS, Server)의 고도화 만으로는 공격을 막아내기 힘들다. 네트워크 대역폭 공격의 경우 좀비PC(Personal Computer)의 네트워크 성능과 맞물려 공격이 강해진다. 좀비PC에서 이용하는 네트워크와 PC성능이 빠를수록 공격이 강해지는데 이전 ADSL 기준으로 100 Gb/s의 공격을 만들려면 10만개의 좀비PC가 필요했지만 최근 보급된 광랜(업로드 100Mb/s) 경우 1000개의 좀비 PC로도 가능하다. 그리고 앞으로 등장할 기가비트(Giga Bit) 홈 랜(Home LAN)이 보급될 경우 100대의 좀비 PC만으로도 90 Gb/s의 대역폭 공격을 할 수 있다. 앞으로도 IPS장비의 고도화는 진행되겠지만, 대역폭 공격을 막아내기에는 현실상 매우 어렵다.
또한 서버의 IP 주소가 노출되어 공개될 경우 악의적인 이용자에 의해 공격 대상이 될 수 있다. DNS 서버의 경우 도메인 관리 기관을 통해 네임서버(Name Server) 정보가 공개되기 때문에 IP 주소 노출이 불가피 하다. 또한 DNS 서버 자체가 사용불가능 하게 될 경우 해당 DNS에서 관리하던 도메인의 서비스 자체가 불가능하다.
본 발명이 해결하고자 하는 과제는 상술한 문제점을 해결하기 위한 것으로서, 사용자 별로 목적지 경로를 분배 및 제어하여 안정적으로 회선을 관리하고, 서비스에 이용되는 서버 및 장치의 비정상적인 동작 중에서도 사용자들에게 서비스의 연속성을 유지시켜 줄 수 있는, 사용자 정보에 기반한 도메인 네임 시스템 및 도메인 네임 서비스 방법을 제공하는 것이다.
상기 기술적 과제를 이루기 위한 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템은, 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 출력하는 클라이언트; 상기 클라이언트로부터 상기 도메인 네임 쿼리를 수신하는 DNS; 및 상기 DNS로부터 상기 도메인 네임 쿼리를 수신하고, 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 목적지 경로 정보를 달리 제공하는 데이터베이스를 포함하고, 상기 클라이언트는 상기 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 DNS를 통해 수신하는 것을 특징으로 한다.
그리고 상기 데이터 베이스는 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS서버 경로 정보 또는 우회로 프록시 경로 정보 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다. 상기 클라이언트는 도메인 해석을 위해 설정된 DNS에 DNS 요청 메시지를 전송하는 클라이언트 Resolver; 및 상기 DNS 요청 메시지에 사용자 정보를 추가하여 상기 DNS에게 쿼리를 출력하는 에이전트를 포함하는 것이 바람직하다.
상기 기술적 과제를 이루기 위한 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템은, 클라이언트로부터 사용자 정보와 서비스 도메인 네임 정보를 포함하는 상기 도메인 네임 쿼리를 수신하는 DNS; 및 상기 DNS로부터 상기 도메인 네임 쿼리를 수신하고, 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 목적지 경로 정보를 달리 제공하는 데이터베이스를 포함하고, 상기 DNS는 상기 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 클라이언트로 전송하는 것을 특징으로 할 수 있다. 이 때, 상기 데이터 베이스는 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용 가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다.
상기 기술적 과제를 이루기 위한 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템은, 클라이언트로부터 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 수신하는 쿼리 수신부; 상기 쿼리 수신부로부터 수신된 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 목적지 경로 정보를 달리 제공하는 경로제공부; 및 상기 경로제공부로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 클라이언트로 전송하는 쿼리응답부를 포함하는 것을 특징으로 한다. 상기 경로제공부는 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다.
상기 다른 기술적 과제를 이루기 위한 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 방법은, 클라이언트가 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 출력하는 단계; DNS가 상기 클라이언트로부터 상기 도메인 네임 쿼리를 수신하는 단계; 및 상기 DNS로부터 상기 도메인 네임 쿼리를 수신하여 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하는 단계; 및 상기 추출된 사용자 정보에 따라 목적지 경로 정보를 달리 제공하는 단계를 포함한다. 상기 클라이언트는 상기 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 DNS를 통해 수신하는 단계를 더 포함하는 것이 바람직하다.
그리고 상기 기재된 발명을 프로세서에 의해 실행되는 프로그램을 기록한 프로세서에 의해 읽을 수 있는 기록매체를 제공한다.
본 발명에 따른 사용자 정보 기반의 도메인 네임 서비스 시스템에 의하면, 사용자 별로 목적지 경로를 분배 및 제어하여 안정적으로 회선을 관리하고, 서비스에 이용되는 서버 및 장치의 비정상적인 동작 중에서도 사용자들에게 서비스의 연속성을 유지시켜 줄 수 있다.
또한 사용자 별로 목적지 경로를 분배 및 제어함으로써 D-DOS에 의한 대역폭 공격을 막아낼 수 있다. 그리고 공격 또는 장애를 받은 프록시, 게이트웨이 등의 장비를 할당 받은 사용자를 데이터베이스에서 검색하여, 비정상적인 공격 또는 장애를 유발한 사용자를 즉시 인지할 수 있으며, 추가적인 조치를 내릴 수 있다.
도 1은 도메인 네임 해석 과정에 대한 일 예를 나타낸 것이다.
도 2는 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템의 구성에 대한 일실시예를 도시한 것이다.
도 3 및 도 4는 클라이언트의 DNS 해석 요청 과정에 사용되는 클라이언트 PC 또는 장비에 대한 세부 구성을 블록도로 나타낸 것이다.
도 5은 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템의 구성에 대한 다른 실시예를 도시한 것이다.
도 6은 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 시스템에서 클라이언트와 데이터베이스 간의 데이터 전송과정에 대한 일 예를 설명하기 위한 시스템 구성을 블록도로 나타낸 것이다.
도 7은 클라이언트와, 클라이언트가 서비스를 받기 원하는 호스트 서버 간의 서비스 과정을 나타낸 것이다.
도 8는 DNS를 이용한 프로그램 및 장치 정보 제공에 있어서 에이전트에 의한 정보 획득 과정을 나타내고 있다.
도 9은 DNS를 이용한 프로그램 및 장치 정보 제공에 있어서 사용자에 의한 정보획득 과정을 나타낸 것이다.
도 10은 DNS 우회로 경로제어에 대한 일실시예를 나타낸 것이다.
도 11은 DNS 우회로 경로제어에 대한 다른 실시예를 나타낸 것이다.
도 12는 본 발명에 의한, 사용자 정보 기반 도메인 네임 서비스 방법에 대한 일실시예를 나타낸 것이다.
도 13은 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 방법에 대한 일 예를 나타낸 것이다.
이하, 첨부된 도면을 참조로 본 발명의 바람직한 실시예를 상세히 설명하기로 한다. 이에 앞서, 본 명세서에 기재된 실시예와 도면에 도시된 구성은 본 발명의 바람직한 일 실시예에 불과할 뿐이고, 본 발명의 기술적 사상을 모두 대변하는 것은 아니므로, 본 출원시점에 있어서 이들을 대체할 수 있는 다양한 균등물과 변형예들이 있을 수 있음을 이해하여야 한다.
도 2는 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템의 구성에 대한 일실시예를 도시한 것으로서, 그 도메인 네임 서비스 시스템은 클라이언트(200), DNS(220) 및 데이터베이스(240)을 포함하여 이루어진다.
클라이언트(200)는 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 DNS에게 전송한다. 그리고 클라이언트(200)는 데이터베이스(240)로부터 출력되는 사용자 정보별 목적지 경로 정보를 DNS(220)를 통해 수신하다.
DNS(220)는 클라이언트(200)로부터 상기 도메인 네임 쿼리를 수신한다.
데이터베이스(240)는 DNS(220)로부터 상기 도메인 네임 쿼리를 수신하고, 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 목적지 경로 정보를 달리 제공한다. 구체적으로, 데이터 베이스(240)는 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다.
상기 클라이언트(200)는 도메인 해석을 위해 설정된 DNS에 DNS 요청 메시지를 전송하는 클라이언트 Resolver(미도시) 및 상기 DNS 요청 메시지에 사용자 정보를 추가하여 상기 DNS에게 쿼리를 출력하는 에이전트(미도시)를 포함할 수 있다.
한편, 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템은 클라이언트와는 별개로 DNS(220) 및 데이터베이스(240)를 포함하여 이루어질 수도 있다. 이 때 DNS(220)는 클라이언트(200) 로부터 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 수신한다. 그리고 데이터베이스(240)는 DNS(220)로부터 상기 도메인 네임 쿼리를 수신하고, 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 목적지 경로 정보를 달리 제공할 수도 있다.
여기서 DNS(220)는 데이터베이스(240)로부터 출력되는 사용자 정보별 목적지 경로 정보를 클라이언트(220)로 전송한다. 그리고, 데이터 베이스(240)는 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다.
도 3 및 도 4는 클라이언트(200)의 DNS 해석 요청 과정에 사용되는 클라이언트 PC 또는 장비에 대한 세부 구성을 블록도로 나타낸 것이다.
본 발명에 의한 클라이언트(200)는 도 3 및 도 4에 도시된 바와 같이, 사용자 프로그램(300, 400), Resolver(310, 420), 에이전트(320, 410) 및 캐시(330, 340, 430, 440)을 포함하여 이루어진다. 그리고 도 13은 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 방법에 대한 일 예를 나타낸 것이다.
도 3, 도 4 및 도 13을 참조하여 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 시스템 및 방법에 대한 보다 구체적인 실시예를 설명하기로 한다.
사용자 프로그램(300)은 Resolver(310)에게 도메인 네임 해석을 요청한다. (S1300단계) Resolver(310)는 도메인 네임 해석을 위해 설정된 DNS에게 DNS 요청 메시지를 전송한다.(S1310단계) 이 때, 에이전트(320)는 DNS 요청이 발생되면 Question Section의 쿼리 이름(query name) 영역에 사용자 정보를 추가하여 DNS 요청 메시지를 공개 DNS서버(350)에게 전송한다.
공개 DNS 서버(350)는 쿼리 이름의 정보를 요청 메시지의 정보(권한)을 가진 DNS 서버(360)로 전송한다. 정보(권한)을 가진 DNS 서버는(360)는 미리 설정된 데이터베이스(370)에게 문의한다.(S1340단계) DNS(360)는 요청 메시지를 데이터 베이스 추가,수정 및 추출하는 기능을 수행한다. 데이터베이스(370)는 매칭된 정보를 응답한다.(S1355단계) 여기서, 데이터베이스(370)는 에이전트(320)가 추가한 사용자 정보를 추출하여 사용자 정보 별로 목적지 경로정보, 예를 들어 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공할 수 있다.
DNS(360)는 데이터베이스(370)로부터 받은 응답정보를 공개DNS(350)으로 전달한다.(S1365단계) 공개 DNS(350)가 DNS(360)으로부터 받은 응답정보를 에이전트(320)에게 전달하면(S1370단계), 에이전트(320)는 응답 메시지 내용을 확인한 후 DNS 해석을 요청한 Resolver(310)에게 전송한다.(S1375단계) Resolver(310)는 응답 메시지를 분석한 후 캐싱한 후 사용자 프로그램(300)에게 전달하면(S1380단계), 사용자 프로그램은 응답 받은 주소로 접속하여 서비스를 이용한다.(S1385단계) 여기서 Resolver(310)는 응답 메시지에 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보가 있으면 이를 캐싱(caching)할 수 있다.
그리고 도 3의 Resolver(310)와 에이전트(320)는 도 4와 같이 서로 위치를 바꾸어 위치할 수도 있다. 즉, 에이전트(410)는 DNS 쿼리를 Resolver(420)로 전송하고, Resolver(420)로부터 출력되는 응답 메시지를 에이전트(410)로 전송할 수도 있다.
한편, 도 5는 본 발명에 의한 사용자 정보 기반의 도메인 네임 서비스 시스템의 구성에 대한 다른 실시예를 도시한 것으로서, 본 발명에 의한 도메인 네임 서비스 시스템은 쿼리 수신부(500), 경로제공부(520) 및 쿼리 응답부(540)를 포함하여 이루어질 수 있다.
쿼리 수신부(500)는 클라이언트(550)로부터 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 수신한다.
경로 제공부(520)는 쿼리 수신부(500)로부터 수신된 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 목적지 경로 정보를 쿼리 응답부(640)로 제공한다. 경로제공부(520)는 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다.
쿼리응답부(540)는 경로제공부(520)로부터 출력되는 사용자 정보별 목적지 경로 정보를 클라이언트(650)로 전송한다.
상술한 쿼리수신부(500), 경로제어부(520) 및 쿼리 응답부(540)는 하나의 시스템에 구현 및 설치될 수도 있고, 경로제어부(520)를 별도의 장치, 예를 들어 데이터 베이스를 이용하여 구현 및 설치할 수도 있다.
도 6은 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 시스템에서 클라이언트와 데이터베이스 간의 데이터 전송과정에 대한 일 예를 설명하기 위한 시스템 구성을 블록도로 나타낸 것이다.
에이전트(620)는 사용자의 정보를 수집하고 사용자의 프로그램(브라우저)의 DNS 해석 요청시 해당 메시지에 사용자 정보를 포함시키는 기능을 수행하는 프로그램 또는 장치이다.
DNS 서버(640)는 DNS 요청메시지의 호스트를 미리 설정된 데이터베이스(650)에 매칭된 정보를 요청하고, 데이터베이스(650)로부터 응답받은 정보를 공개 DNS를 통해 에이전트에게 전송한다. DNS 1(640)은 네임서버(Name Server) 정보가 공개된 DNS 서버이며 도 10의 DNS 1(1030)과 동일하다. 그리고 도 10의 DNS 2(1070)는 네임서버(Name Server) 정보가 공개되지 않은 DNS 서버를 말하며, DNS 1과 동일한 데이터 베이스를 이용하며 동일한 역할을 한다.
데이터베이스(650, 1040)는 도메인 네임 시스템의 서비스 또는 관리에 이용되는 데이터가 저장되어 있으며, 사용자 별로 다른 목적지 경로를 설정한 것을 저장하고 있다.
도 6에 도시된 사용자 정보 기반 도메인 네임 서비스 시스템은 다음과 같은 조건을 갖는 것으로 가정한다.
1) DNS 1(640)를 통하여 Service.com 이라는 도메인을 사용자정보 기반으로 경로제어를 한다.
2) 사용자는 브라우저 등의 프로그램을 통해 Service.com 도메인을 사용하는 웹 서버로 접속하길 원한다.
3) Service.com 도메인은 사전에 등록되어 있다.
4) 데이터베이스(650)에는 클라이언트의 정보 별로 Service.com 의 호스트 서버로 가기 위한 프록시 혹은 게이트웨이 경로 정보(IP 주소, 도메인 등), 게이트웨이의 경로 정보(IP 주소, 도메인 등) 또는 호스트 서버 경로 정보(IP 주소, 도메인 등)가 저장되어 있다.
5) 클라이언트 정보로는 상기 IP주소 뿐 아니라 Mac ID, Login ID 등 사용자를 인증해줄 수 있는 여러 정보가 단독 혹은 복합적으로 사용될 수도 있지만, 도 6에서는 IP 주소만을 사용한다고 가정한다.
6) 클라이언트의 공인 IP 는 100.100.100.1 이라고 가정한다.
7) 목적지(Service.com 의 프록시 또는 게이트웨이) IP 주소는 200.0.0.1 이라고 가정한다.
DNS를 이용한 사용자 기반 목적지 경로제공은 다음과 같이 이루어진다. 먼저, 사용자의 요청을 에이전트가 전달 받는 과정은 다음과 같다. 최초 사용자는 클라이언트 프로그램(600)을 통해 domain-name(“Service.com”)에 대한 IP 주소를 DNS 클라이언트인 Resolver(610)에게 요청한다. 요청받은 Resolver(610)는 해당 도메인 네임을 운영체제(OS)에 설정된 DNS 서버 주소로 DNS 요청 메시지를 전송하게 되는데, 미리 설치된 에이전트(620)는 DNS 요청메시지를 다음과 같이 변조한다.
변경 전 : “Service.com
변경 후 : “100_100_100_1.Service.com
여기서, "100_100_100_1"은 클라이언트의 IP 주소를 알기 쉽도록 표기한 내용이며, 해당정보는 암호화 되지 않은 클라이언트 IP 주소를 의미한다.
에이전트(620)가 변경된 메시지를 운영체제(OS)에 설정된 DNS 서버 주소로 전송한다.
공개 DNS(630)는 “100_100_100_1.Service.com" 도메인을 해석하기 위해 root 네임서버에 해석 요청을 보내고, root 네임서버는 com 네임서버의 주소를 알려준다. Com 네임서버는 Service.com 도메인 정보가 등록된 DNS 서버 의 주소를 다시 알려준다. Com 네임서버는 Service.com 도메인 정보가 등록된 DNS 서버 의 주소를 다시 알려준다. DNS 서버는 "100_100_100_1.Service.com"을 해석하게 되는데, 미리 설정된 데이터베이스(650)로 해당 도메인 내용을 질의한다.
데이터베이스(650)는 해당 데이터에 매칭된 정보 IP 어드레스: 200.0.0.1 을 DNS 네임서버에 다시 응답해 준다.
만일 매칭된 정보가 없다면 DNS 1(640)는 미리 설정된 정책에 따라 클라이언트 100_100_100_1 에 대한 정보를 데이터베이스(650)에 삽입(insert) 한다.
DNS(640)는 전달받은 정보 즉, 목적지 경로를 공개 DNS(630)에 응답해준다. 공개 DNS(630)는 에이전트(620)에게 도메인 해석 결과를 응답한다.
에이전트(620)는 응답 메시지를 분석하고, 응답 받은 정보가 IP 어드레스라면 캐싱한다. 그리고 나서 도메인 네임 해석 결과를 resolver(610)에게 응답해준다.
Resolver(610)는 도메인 해석을 요청한 클라이언트 프로그램(600)에게 해당 경로를 응답해준다. 클라이언트 프로그램(600)은 목적지 IP 주소가 200.0.0.1 인 서버에 접속한다.
도 7은 클라이언트와 상기 클라이언트가 서비스를 받기 원하는 호스트 서버 간의 서비스 과정을 나타낸 것이다.
도 7에 나타낸 바와 같이, 클라이언트(700)는 DNS 쿼리를 출력하면, 에이전트(710)가 상기 DNS 쿼리에 사용자 정보를 추가하여 공개 DNS(720)을 통해 DNS 1(730)에게 사용자 정보와 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 전송한다. 그러면, DNS 1(730)은 상기 도메인 네임 쿼리로부터 사용자 정보를 추출하여 추출된 사용자 정보에 해당하는 목적지 경로정보, 예를 들어 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 공개 DNS(720)를 통해 에이전트(710)에게 전달한다. 에이전트(710)는 클라이언트(700)에게 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보를 전달하면 클라이언트(700)는 자신의 정보를 기반으로 미리 배정된 호스트 서버, 프록시 또는 게이트웨이(740)를 통하여 목적지인 호스트 서버(750)로 접근하게 된다.
도 8는 DNS를 이용한 프로그램 및 장치 정보 제공에 있어서 에이전트에 의한 정보 획득 과정을 나타내고 있다.
프로그램 및 장치가 스스로 DNS 1(830)에 질의를 전송하여 정보를 제공받는 방식이다. 에이전트(810)가 주기적으로 혹은 특정 이벤트 발생시 DNS에 장치 정보가 포함된, 예를 들면 프로그램 버전, 설정 버전 등의 DNS 질의를 요청하여 데이터 베이스로부터 정보를 제공받는다.
상기 DNS 질의는 텍스트 방식으로 요청할 수 있으며, 텍스트 방식뿐 아니라 DNS 문의 레코드의 질의 종류(Query type)에 적용될 수 있는 모든 형식으로 응답 가능하다.
에이전트는 10초 마다 한번씩 자신의 프로그램 버전이 포함된 DNS 질의 "configversion00002.Service.com"를 텍스트 형식으로 공개 DNS에 전송하여 Service.com 의 정보를 가진 DNS 1 서버로 요청을 보내면 DNS1 서버는 데이터베이스에서 매칭된 정보를 텍스트 형식으로 응답해준다.
이 응답 메시지에 포함된 정보를 적용 또는 가공하여 에이전트는 2차적인 정보의 이용이 가능하다.
도 9은 DNS를 이용한 프로그램 및 장치 정보 제공에 있어서 사용자에 의한 정보획득 과정을 나타낸 것으로서, 도 8의 에이전트에 의한 정보 획득과 유사하지만 클라이언트(900)의 요청에 의해 에이전트(910) 및 공개 DNS(920)를 거쳐 DNS1(930)에 질의를 전송하여 정보를 제공받는다.
한편, 도 10은 DNS 우회로 경로제어에 대한 일 예를 나타낸 것으로서, DNS 우회로 경로제어는 다음과 같이 이루어진다.
DNS는 네임서버(Name Server) 정보, 예를 들어 DNS 서버의 IP 및 기타 등록 정보를 공개함으로 인하여 직접적인 공격, 예를 들면 D-Dos 공격에 노출된다.
DNS 1(1030)는 비정상적인 상황, 예를 들어 DNS 의 네임서버 정보 공개로 인한 악의적 사용자의 공격 또는 자체 DNS 서버의 자체 오류 등으로 정상적인 DNS 서비스가 불가능 할 경우, 제 2의 DNS(1070)로 DNS 요청 경로를 제어하여 에이전트(1010)가 설치된 사용자에게 DNS 서비스의 연속성을 유지시켜 주는데 이러한 기능을 DNS 우회로 경로 제어라 한다.
즉, DNS 우회로 경로 제어란 DNS 1(1030)가 사용 불가능 할 때, 동일한 기능, 예를 들어 동일한 데이터 베이스를 사용하는 또 다른 DNS 2(1070)로 경로를 제어해 주는 것이다.
우회로 경로 제어의 올바른 사용 예를 들기 위해 서비스 상황을 두 가지로 나누어 설명하기로 한다.
첫번째 상황은 정상적인 서비스 과정이고, 두 번째 상황은 비상시 즉 정상적인 서비스 과정 시 사용되는 DNS 1 서버(1030)가 사용 불가능 할 때의 서비스 과정이다.
정상적인 서비스 과정은 상기 DNS 서비스 모델에서 표현된 도 6, 도 7과 동일하다. 다만, 한가지 정보가 추가적으로 운용되는데, 그것은 비상시 DNS 2(1070) 의 정보를 가진 프록시 혹은 게이트웨이의 경로 정보 또는 DNS 2의 경로 정보, 즉 공개 DNS와 동일한 역할을 담당하는 프록시 혹은 게이트웨이의 IP 주소 정보 또는 DNS 2의 IP 주소 정보이다.
클라이언트의 DNS 해석 요청에 의해 Resolver 가 DNS 요청 패킷을 생성하고 에이전트(1010)가 이 메시지를 변조한 뒤 공개 DNS(1020)를 통해 DNS1(1030)에 요청하게 된다. DNS 1(1030)은 해당 도메인 정보에 포함된 사용자 정보를 기반으로 목적지 또는 그 경로에 대한 정보를 내려주게 되는데, 이때 사용자 정보를 기반으로 하는 DNS 2(1070)의 경로 정보, 예를 들어 프록시 혹은 게이트웨이 IP주소 혹은 도메인 네임을 동시에 또는 순차적으로 DNS 응답 메시지에 포함시켜 전송해 준다.
공개 DNS(1020)는 응답 받은 메시지를 에이전트(1010)에게 다시 응답하게 되며, 에이전트(1010)는 해당 DNS 응답 메시지를 분석하게 되며 여기서 두 가지 상황으로 나누어진다.
첫 번째는 정상적인 응답 메시지 일 경우이다. 에이전트(1010)는 DNS 응답 메시지에서 DNS 요청에 대한 응답과 우회로 DNS 정보로 분리한 뒤 우회로 정보( DNS 2 정보)는 클라이언트(1000)의 메모리에 캐싱(caching)한다. 만약 이미 캐싱된 정보가 있다면 변경해주며, DNS 응답 메시지는 Resolver를 통해 클라이언트(1000)에게 전달되며 클라이언트 프로그램은 전달 받은 경로를 통해 원하는 서비스를 이용하게 된다.
두 번째는 비 정상적인 응답 메시지 일 경우이다. 에이전트(1010)는 DNS 1(1030)가 정상적인 서비스가 불가능하다고 판단하며, 캐싱된 우회로 정보, 예를 들어 프록시 혹은 게이트웨이의 IP 주소 혹은 도메인 네임으로 DNS 요청 메시지를 전송한다.
프록시 또는 게이트웨이(1060)는 미리 설정된 DNS 2(1070) 또는 동일한 역할을 하도록 구현된 장치에게 도메인 네임에 매칭된 정보를 요청하게 되며, 응답을 받아서 에이전트(1010)에게 전송한다. 이때 DNS 요청 메시지는 최초에 전송된 DNS 요청 메시지와 동일하며, 응답 또한 같은 데이터 베이스를 참조하기 때문에 동일하다. UDP 뿐만 아니라 TCP 통신도 지원되며, 프로토콜의 변조 또한 가능하다. 다만 우회로의 경로는 제3의 DNS, 예를 들면 도면상에서는 존재하지 않는 DNS 3의 경로 정보를 전송하게 된다.
즉, DNS 는 도메인 네임에 대한 정보 뿐 아니라, DNS 우회로 정보를 동시에 내려주며, 에이전트(1010)는 우회로 정보를 캐싱하여 저장하고 있다가 DNS 1(1030) 이용이 불가능할 때, 해당 우회로 주소를 통해 네임서버 정보가 노출되지 않은 또 다른 DNS 2(1070)를 이용하여 DNS 서비스를 받게 된다.
도 11은 DNS 우회로 경로제어에 대한 다른 예를 나타낸 것으로서, 도 10에서 공개 DNS(1020) 및 프록시 또는 게이트웨이(1060)이 없을 경우를 나타낸 것이다. 클라이언트(1110), 에이전트(1110), DNS1(1120), 데이터베이스(1130), 캐시(1140) 및 DNS2(1150)은 도 10의 에이전트(1010), DNS1(1020), 데이터베이스(1030), 캐시(1040) 및 DNS2(1050)과 그 기능이 동일하다.
또한 도 10의 공개 DNS(1020) 및 프록시 또는 게이트웨이(1060) 중 어느 하나만 없이도 도 10에서 설명한 DNS 우회로 경로제어가 가능하다.
한편, 도 12는 본 발명에 의한, 사용자 정보 기반 도메인 네임 서비스 방법에 대한 일실시예를 나타낸 것이다.
도 2와 도 12를 참조하면, 먼저 클라이언트(200)가 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 DNS(220)으로 전송한다.(S1200단계) DNS(220)는 클라이언트(200)로부터 상기 도메인 네임 쿼리를 수신하여 데이터베이스(240)로 전달한다.(S1210단계) 데이터베이스(240)는DNS(220)로부터 상기 도메인 네임 쿼리를 수신하여 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여 상기 사용자 정보에 따라 목적지 경로 정보를 달리 제공한다.(S1220단계) 여기서, 상기 목적지 경로 제공은 사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것이 바람직하다. 그리고 클라이언트(200)는 데이터베이스(240)로부터 출력되는 사용자 정보별 목적지 경로 정보를 DNS(220)를 통해 수신한다.(S1230단계)
상술한 바와 같이, 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 시스템 및 방법은 DDOS 공격 같은 외부로부터의 공격이 있을 경우, 각 사용자 마다 다른 호스트 정보를 응답하여 공격자와 일반사용자를 분리해 낸다. 이를 위해 클라이언트가 도메인 네임 해석을 요청하면 사용자 정보를 같이 전송해 주기 위한 프로그램 및 장비를 이용할 수 있다.
그리고 공격의 대상이 되는 서버의 IP 어드레스를 노출시키지 않으며, DNS 서버가 사용 불가능하게 되었을 경우 임시적으로 IP 주소가 노출되지 않는 DNS를 사용자 별로 또는 사용자가 속한 그룹별로 다르게 이용할 수 있는 우회로를 제공한다. 이를 위해 DNS 서버는 도메인 정보를 Zone File이 아닌 데이터 베이스를 통해 관리한다. 상기 데이터 베이스는 DNS 내부 또는 외부에 존재한다. 또한 도메인을 등록할 때 TTL(Time to Live)을 최저 값으로 설정하여 캐시(Cache)되지 않도록 한다.
한편, 상술한 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 시스템 및 방법에서 사용되는 세부적인 데이터 포맷은 다음과 같다.
먼저, 클라이언트가 DNS 메시지의 데이터 포맷은 표 1과 같다.
Mac 헤더 IP헤더 TCP/UDP 헤더 DNS 헤더 데이터
상기 DNS 메시지 데이터 포맷은 OSI(Open Systems Interconnection Reference Model) 하위 계층 헤더가 포함된 Decapsulation 되기 전의 DNS 메시지이다.
하위계층의 헤더를 통해 단편적인 사용자, 즉 DNS 메시지를 요청한 클라이언트 정보를 알 수 있는데, 예를 들면 Mac 헤더를 통해 해당 패킷을 송신하는 측의 Mac 주소를 알 수 있고, IP 헤더에서는 패킷의 출발지 주소, 즉 소스 어드레스를 알 수 있으며, TCP | UDP 헤더를 통해 사용된 포트(Port)를 알 수 있다.
하지만 도 1에서 설명한 바와 같이 현재 사용되는 도메인 네임 시스템 상 DNS가 수신하는 패킷의 출발지는 사용자(클라이언트)의 정보가 아닌 공개 DNS 의 정보인 것이다.
그리고 DNS 요청 메시지는 표 2와 같으며, DNS 응답 메시지 포맷은 표 3과 같다.
헤더
Question section
헤더
Question section
Answer section
Authoritative section
Additional section
에이전트는 기존에 사용되고 있는 DNS 에서 사용되는 공통된 규약인 RFC (Request for comment) 규약을 준수하기 위해 DNS 요청 및 응답 메시지의 헤더를 수정하지 않는다.
또한 DNS 문의 레코드의 포맷은 표 4와 같다.
쿼리 이름(Query Name)
쿼리 종류(Query Type) 쿼리 클래스(Query Class)
Query name(질의 이름) 필드는 가변 길이를 가지며 도메인 네임을 포함한다.
Query type(질의 종류)필드는 16비트로 이루어지며, 질의 종류를 나타낸다.
본 발명에서 자주 사용되는 쿼리 종류는 표 5와 같다.
Type Mnemonic 설명
1 A IPv4 어드레스
2 NS Name Server
5 CNAME Canonical name
28 AAAA IPv6 어드레스
16 TXT 텍스트
에이전트는 상술한 DNS 문의 레코드 형식 중 Query name 과 Query type 을 수정하여 DNS 문의 메시지를 전송한다. 그리고 Query type 을 변경하는 것 또한 가능한데 이는 IP 주소 뿐 아니라 Text형 정보, 예를 들면 클라이언트 모듈에 필요한 정보를 전송 받기 위함이다.
그리고, 본 발명에 의한 사용자 정보 기반 도메인 네임 서비스 시스템 및 방법에서 사용자 정보 추가 전후의 쿼리 이름 변화에 대한 예를 들면 다음과 같다.
하나의 레이블을 통해 사용자 정보를 추가할 경우의 변경 전과 변경 후는 다음과 같다.
변경전 : www.Service.com.
변경 후 : IPAddressUserID.www.Service.com.
다수의 레이블을 통해 사용자정보를 추가하는 경우
변경 전 : www.Service.com.
변경 후 :Ipaddress.UserID.www.Service.com
위의 방법으로 클라이언트 모듈의 정보를 추가하는 경우
변경 전 : www.Service.com.
변경 후 : ModuleVersion.UserID.www.Service.com
위의 방법으로 장비 정보를 추가하는 경우
변경 전 : www.Service.com
변경 후 : DevInfo.www.Service.com
즉, 도메인 네임의 앞에 정보를 추가하여 DNS 서버가 이를 수신할 수 있도록 한다.
Servicedomain www.Service.com 을 수정하여 타 DNS 서버가 이를 수신할 수 있도록 하는 경우
변경 전 : www.Service.com.
변경 후 : Ipaddress.UserID.Service.OtherDNS.com
즉, OtherDNS.com 이라는 도메인정보를 등록한 DNS 서버가 변경 후에 해당하는 도메인정보를 해석하게 된다.
그리고 데이터 베이스 연결의 예를 들면 표 6과 같다.
설명 예 매칭된 정보
A 사용자의 정보 AClientInfo.Service.com 200.0.0.1
B 사용자의 정보 BClientInfo.Service.com 200.10.10.10
A 장비 정보 ADevInfo.Service.com 정보(text 형식)
B 장비 정보 BDevinfo.Service.com 정보(text 형식)
표 6 예는 설명을 위한 단순한 예 이며, 요청한 도메인 네임과 일치하는 정보를 표 1과 같이 다양한 타입으로 응답할 수 있다. 보안이 요구되는 DNS 서비스에 대해서는 DNSSEC 방식도 적용 가능하다.
한편, 본 발명에 의한 DNS의 응답 데이터의 예는 다음과 같다. 본 발명의 실시예에서 사용되는 응답 데이터로서, DNS 해석을 요청 시 사용자 정보(클라이언트)별 목적지 경로와 DNS 우회로 정보를 함께 응답해 준다. DNS 응답은 표 7과 같이, 정책에 따라 하나의 DNS 응답 메시지 내에 목적지 IP 주소와 우회 DNS 주소가 포함되거나, 두 개의 DNS 응답 메시지로 나눠 응답해줄 수 있다.
목적지 IP 주소 우회로 DNS 주소
정보 입력 또는 정보 획득의 경우에도 표 8에서와 같이 마찬가지로 DNS 우회로 정보를 함께 응답해 준다.
장비정보 우회로 DNS 주소
본 발명은 컴퓨터로 읽을 수 있는 기록 매체에 컴퓨터(정보 처리 기능을 갖는 장치를 모두 포함한다)가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다. 컴퓨터가 읽을 수 있는 기록 장치의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광데이터 저장장치 등이 있다.
본 발명은 도면에 도시된 실시예를 참고로 설명되었으나 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.
200 : 클라이언트 220 : DNS 240 : 데이터베이스
300, 400 : 사용자 프로그램 310, 420 : Resolve
320, 410 : 에이전트 330, 340, 430, 440 : 캐시
350, 450 : 공개 DNS 서버 360, 460 : DNS 서버
370, 470 : 데이터베이스
500 : 쿼리 수신부 520 : 경로제공부
540 : 쿼리 응답부 550 : 클라이언트
600, 700,800,900, 1000, 1100 : 클라이언트 610 : Resolver
620, 710, 810, 910, 1010, 1110 : 에이전트
630, 720, 820, 920, 1020: 공개 DNS
640, 730, 830, 930, 1030, 1120 : DNS 1
650, 1040, 1130 : 데이터베이스 740 : 프록시 또는 게이트웨이
750 : 호스트 서버 1050, 1140 : 캐시
1060 : 프록시 1070, 1150 : DNS 2

Claims (10)

  1. 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 출력하는 클라이언트;
    상기 클라이언트로부터 상기 도메인 네임 쿼리를 수신하는 DNS; 및
    상기 DNS로부터 상기 도메인 네임 쿼리를 수신하고, 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로, 상기 클라이언트에게 서비스를 제공하는 호스트 서버로의 경로를 분배 및 제어하는 목적지 경로 정보인 프록시 정보 또는 게이트웨이 정보를 달리 제공하는 데이터베이스를 포함하고,
    상기 클라이언트는 상기 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 DNS를 통해 수신하고,
    상기 클라이언트와 상기 호스트서버 간에는 복수의 프록시 또는 게이트웨이가 존재하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 시스템.
  2. 제1항에 있어서, 상기 데이터 베이스는
    사용자 정보 별로 호스트서버 경로 또는 프록시 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 시스템.
  3. 제1항에 있어서, 상기 클라이언트는
    도메인 해석을 위해 설정된 DNS에 DNS 요청 메시지를 전송하는 클라이언트 Resolver; 및
    상기 DNS 요청 메시지에 사용자 정보를 추가하여 상기 DNS에게 쿼리를 출력하고, 상기 DNS가 정상적인 서비스가 불가능할 때에는 우회로 정보를 이용하여 대체 DNS에게 DNS 요청 메시지를 전송하는 에이전트를 포함하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 시스템.
  4. 클라이언트로부터 사용자 정보와 서비스 도메인 네임 정보를 포함하는 상기 도메인 네임 쿼리를 수신하는 DNS; 및
    상기 DNS로부터 상기 도메인 네임 쿼리를 수신하고, 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 상기 클라이언트에게 서비스를 제공하는 호스트 서버로의 경로를 분배 및 제어하는 목적지 경로 정보인 프록시 정보 또는 게이트웨이 정보를 달리 제공하는 데이터베이스를 포함하고,
    상기 DNS는 상기 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 클라이언트로 전송하고,
    상기 클라이언트와 상기 호스트서버 간에는 복수의 프록시 또는 게이트웨이가 존재하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 시스템.
  5. 제4항에 있어서, 상기 데이터 베이스는
    사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 혹은 게이트웨이 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 시스템.
  6. 클라이언트로부터 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 수신하는 쿼리 수신부;
    상기 쿼리 수신부로부터 수신된 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하여, 상기 사용자 정보 별로 상기 클라이언트에게 서비스를 제공하는 호스트 서버로의 경로를 분배 및 제어하는 목적지 경로 정보인 프록시 정보 또는 게이트웨이 정보를 달리 제공하는 경로제공부; 및
    상기 경로제공부로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 클라이언트로 전송하는 쿼리응답부를 포함하고,
    상기 클라이언트와 상기 호스트서버 간에는 복수의 프록시 또는 게이트웨이가 존재하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 시스템.
  7. 제6항에 있어서, 상기 경로제공부는
    사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 경로 정보 정보와 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 시스템.
  8. 클라이언트가 사용자 정보와 서비스 도메인 네임 정보를 포함하는 도메인 네임 쿼리를 출력하는 단계;
    DNS가 상기 클라이언트로부터 상기 도메인 네임 쿼리를 수신하는 단계; 및
    데이터 베이스가 상기 DNS로부터 상기 도메인 네임 쿼리를 수신하여 상기 도메인 네임 쿼리에 포함된 사용자 정보를 추출하는 단계;
    상기 데이터 베이스가 상기 추출된 사용자 정보에 따라 상기 클라이언트에게 서비스를 제공하는 호스트 서버로의 경로를 분배 및 제어하는 목적지 경로 정보인 프록시 정보 또는 게이트웨이 정보를 달리 제공하는 단계를 포함하고,
    상기 클라이언트와 상기 호스트서버 간에는 복수의 프록시 또는 게이트웨이가 존재하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 방법.
  9. 제8항에 있어서,
    상기 클라이언트는 상기 데이터베이스로부터 출력되는 사용자 정보별 목적지 경로 정보를 상기 DNS를 통해 수신하는 단계를 더 포함하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 방법.
  10. 제8항에 있어서, 상기 목적지 경로 제공은
    사용자 정보 별로 호스트 서버 경로 정보 또는 프록시 경로 정보와 상기 DNS가 동작하지 않을 때 상기 DNS대신 사용가능한 우회 DNS 서버 경로 정보 또는 우회로 프록시 혹은 게이트웨이 경로 정보를 제공하는 것을 특징으로 하는 사용자 정보 기반 도메인 네임 서비스 방법.
KR1020120024546A 2012-03-09 2012-03-09 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법 KR101345372B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020120024546A KR101345372B1 (ko) 2012-03-09 2012-03-09 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020120024546A KR101345372B1 (ko) 2012-03-09 2012-03-09 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법

Publications (2)

Publication Number Publication Date
KR20130103145A KR20130103145A (ko) 2013-09-23
KR101345372B1 true KR101345372B1 (ko) 2013-12-24

Family

ID=49452621

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120024546A KR101345372B1 (ko) 2012-03-09 2012-03-09 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법

Country Status (1)

Country Link
KR (1) KR101345372B1 (ko)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101569857B1 (ko) 2014-06-20 2015-11-27 서정환 클라이언트 경로 제어 시스템을 활용한 장애유발 클라이언트 검출 방법 및 시스템
US9712485B2 (en) 2014-07-30 2017-07-18 Cisco Technology, Inc. Dynamic DNS-based service discovery
US10057208B2 (en) 2014-10-31 2018-08-21 Cisco Technology, Inc. Visibility control for domain name system service discovery
KR102232761B1 (ko) * 2019-08-21 2021-03-26 주식회사 이노지에스코리아 장애대응 에지서버 그루핑을 이용한 장애유발 클라이언트 검출 방법 및 시스템

Also Published As

Publication number Publication date
KR20130103145A (ko) 2013-09-23

Similar Documents

Publication Publication Date Title
JP5976232B2 (ja) ユーザ情報に基づいた、ドメインネーム・システム及びドメインネーム・サービス方法
US9935921B2 (en) Correlating nameserver IPv6 and IPv4 addresses
US9712422B2 (en) Selection of service nodes for provision of services
EP2556438B1 (en) Reverse dns lookup with modified reverse mappings
US7454489B2 (en) System and method for accessing clusters of servers from the internet network
US10009271B2 (en) Routing method and network transmission apparatus
US8861525B1 (en) Cloud-based network protocol translation data center
JP4328753B2 (ja) Ｉｐネットワークにおいて、あらゆるタイプのアプリケーションでネットワーク・アドレス変換（ｎａｔ）を用いる方法、システム及びコンピュー
US8458303B2 (en) Utilizing a gateway for the assignment of internet protocol addresses to client devices in a shared subset
US9697173B2 (en) DNS proxy service for multi-core platforms
KR101345372B1 (ko) 사용자 정보에 기반한, 도메인 네임 시스템 및 도메인 네임 서비스 방법
JP5815045B2 (ja) マルチコア・プラットフォームのためのｄｎｓ転送器
US20030225910A1 (en) Host resolution for IP networks with NAT
Dragolov et al. Anycast DNS System in AS5421
JP2007208480A (ja) Ｄｄｎｓクライアント

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20161116

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20171110

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20181025

Year of fee payment: 6