KR101485764B1 - 오픈 api를 사용한 도메인 네임 관리 서비스 제공방법 - Google Patents

오픈 api를 사용한 도메인 네임 관리 서비스 제공방법 Download PDF

Info

Publication number
KR101485764B1
KR101485764B1 KR20130042632A KR20130042632A KR101485764B1 KR 101485764 B1 KR101485764 B1 KR 101485764B1 KR 20130042632 A KR20130042632 A KR 20130042632A KR 20130042632 A KR20130042632 A KR 20130042632A KR 101485764 B1 KR101485764 B1 KR 101485764B1
Authority
KR
South Korea
Prior art keywords
domain
auth
token
api
open api
Prior art date
Application number
KR20130042632A
Other languages
English (en)
Other versions
KR20140125042A (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 KR20130042632A priority Critical patent/KR101485764B1/ko
Publication of KR20140125042A publication Critical patent/KR20140125042A/ko
Application granted granted Critical
Publication of KR101485764B1 publication Critical patent/KR101485764B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

본 발명은 IPv4 호스트 혹은 IPv6 호스트에 대하여 도메인 네임을 등록하기 위해서는 사전에 터미널을 통한 명령어 방식, 스탠드얼론 그래픽 유저 인터페이스 화면 혹은 웹 유저 인터페이스 화면을 통하여 수행할 수 있는 도메인 관리 업무 대신 REST기반 HTTP 프로토콜을 통하여 도메인을 관리하도록 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공 방법에 관한 것이다.

Description

오픈 API를 사용한 도메인 네임 관리 서비스 제공방법 {Domain Name Management Method Using Open API}
본 발명은 도메인 네임을 관리함에 있어 필요한 기능을 외부로 공개함으로써 기계와 기계와의 연동을 통하여 도메인 네임 관리 작업에서 나타날 수 있는 여러 가지 어려움을 해소하고, 편리함과 자동화 기능을 제공할 뿐 만 아니라, 사용성을 높일 수 있는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법에 관한 것이다.
인터넷 서비스에 대한 새로운 변화로서 '공유가 사용자에게 보다 나은 가치를 제공한다' 라는 인식이 웹 2.0 패러다임으로 부터 시작되었다. 이러한 흐름을 타고 구글, 아마존, 트위터, 야후, 네이버, 다음등 수 많은 서비스들은 자신이 보유한 서비스와 데이터를 오픈 API의 형태로 제공하고 있다.
오픈 API 서비스를 구현할 수 있는 기술로 SOAP과 REST기술이 있다. REST 기술은 웹 포탈 혹은 정보 서비스 제공업체의 오픈 API(Application Programming Interface, Open API)를 제공함에 있어서, 개발이 어렵고, 이해가 복잡한 WSDL(Web Services Description Language), SOAP(Simple Object Access Protocol) 기반의 웹 서비스(Web Services) 접근 방식에 대한 대안으로 널리 활용되고 있다.
SOAP이 갖는 장점으로는 언어, 플랫폼 그리고 통신에 중립적, 분산 컴퓨팅 환경을 다루기 위해 설계, 웹서비스 표준(WSDL, WS-*)과 벤더의 준비된 도구들, 에러 처리 등이 있다.
SOAP이 갖는 단점으로는 SOAP은 웹서비스를 만들기 위한 많은 표준들이 있으나 REST에 비하여 SOAP의 복잡성이다. SOAP이 갖는 SOAP 헤더, 바디, FAULT 등의 ENVELOPE, 보안, 트랜잭션 등 문제해결을 위한 다양한 표준은 개발자가 이해하기에 어려움이 많다. 또한 통신기술에 의존하지 않는 표준이라는 특성으로 인하여 개념적으로 REST 보다 무겁다는 것이다. 제반사항을 모두 고려한 복잡함 등으로 개발 도구를 기본적으로 필요로 하고 있다.
원래 REST(Representational State Transfer) 는 HTTP(Hypertext Transfer Protocol) 의 주요 저자인 Roy Fielding의 2000년 논문에 의해 소개된 네트워크 아키텍처를 위한 구조인데(참조 The Resource-Oriented Architecture) 여기서 이야기하는 REST는 HTTP의 기본 개념에 충실히 따르는 웹서비스를 이야기한다.
REST 은 인터넷을 기반으로 한 정보 교환에 있어 기본 원칙을 제시하고 있다. 즉, 사람과 기계와의 정보 교환뿐만 아니라 기계와 기계간의 상호 정보교환이 가능하도록, URL로 식별 가능한 자원을 구성하고, 자원과 자원 간의 연결(링크)를 구성한 다음, 해당 자원에 대한 HTTP 기반의 정보 생성(POST), 질의(GET), 삭제(DELETE), 업데이트(PUT), 동작(Operation)을 기본으로 자원과의 상호정보교환을 하는 원칙을 제시하고 있다.
REST 의 강점은 단순함과 간결함이다. 잘 구현된 REST 웹서비스는 간결하고 일관된 인터페이스 구조를 지니고 있어 어려움 없이 쉽게 사용이 가능하다. 또한 언어, 플랫폼에 중립적, SOAP보단 단순함, 학습곡선이 작고, 추가적인 메시징 계층이 없고, 웹에 가까운 설계와 철학 등이 있다.
REST 의 단점으로는 point-to-point 통신 모델을 기반으로 하며, 둘 이상을 대상으로 상호작용하는 분산 환경에는 유용하지 않고, 보안이나 에러처리등과 같은 부수적인 문제는 직접 해결해야 한다.
단순함 간결함은 직관적이며 쉽게 개발하거나 사용할 수 있어 기술의 전파 속도가 굉장히 빠르고, 배우지 않더라도 바로 사용할 수 있어 최근 많은 기업들이 REST기반 오픈 API를 제공하고 있다.
국내등록특허공보 등록번호 제1011508150000 (2012.05.22.)호에는 인터넷 단말에서 실행 중인 웹 브라우저에 대한 제 1 네트워크 연결을 생성하는 단계, 상기 제 1 네트워크 연결을 통해, 상기 인터넷 단말의 고유 아이디와 웹-투-폰 메시지를 수신하는 단계, 모바일 단말에서 실행 중인 메시지 애플리케이션에 대한 제 2 네트워크 연결을 생성하는 단계, 상기 제 2 네트워크 연결을 통해, 상기 인터넷 단말의 고유 아이디와 상기 웹-투-폰 메시지를 전송하는 단계, 상기 제 2 네트워크 연결을 통해, 상기 인터넷 단말의 고유 아이디와 폰-투-웹 메시지를 수신하는 단계, 상기 제 1 네트워크 연결을 통해, 상기 폰-투-웹 메시지를 전송하는 단계, 상기 제 1 네트워크 연결을 통해, 상기 폰-투-웹 메시지에 대한 수신 완료 응답을 수신하지 못한 경우, 상기 폰-투-웹 메시지를 상기 인터넷 단말의 고유 아이디에 대응하여 저장하는 단계, 상기 인터넷 단말에서 실행 중인 웹 브라우저에 대한 제 3 네트워크 연결을 생성하는 단계 및 상기 제 3 네트워크 연결을 통해, 상기 인터넷 단말의 고유 아이디에 대응하여 저장되는 메시지 서버가 폰-투-웹(Phone-to-Web) 메시지를 재전송하는 방법이 공개되어 있고,
동 공보 등록번호 제1011741090000(2012.08.08.)호에는 인터넷 단말에서 실행 중인 웹 브라우저에 대한 네트워크 연결을 생성하는 단계, 모바일 단말에서 실행 중인 메시지 애플리케이션에 대한 네트워크 연결을 생성하는 단계, 상기 인터넷 단말의 고유 식별 아이디를 독출하는 단계, 미리 설정된 시간 이내에 상기 인터넷 단말로부터 기 수신한 복수개의 전송 메시지가 미리 설정된 수 이상의 수신자 정보를 갖는 경우, 상기 인터넷 단말의 고유 식별 아이디를 스팸 목록에 등록하는 단계 및 상기 인터넷 단말의 고유 식별 아이디가 스팸 목록에 포함되지 않은 경우, 상기 인터넷 단말에서 실행 중인 웹 브라우저에 대한 네트워크 연결을 통해, 상기 모바일 단말로 전송할 전송 메시지를 수신하고, 상기 모바일 단말에서 실행 중인 메시지 애플리케이션에 대한 네트워크 연결을 통해, 상기 전송 메시지를 전송하는 단계를 포함한 기술이 기재되어 있으며,
동 공보 등록번호 제1011109790000(2012.01.20.)호에는 DNS 정보를 관리하는 1차 네임서버의 최적 배치 형태를 찾고, 읽기 기능만 부여된 2차 네임서버를 이동 IP 네트워크(MINET)의 최하단 계층 존에 해당하는 무선 Ad hoc 네트워크에 배치하고, 이동 IP 네트워크의 DNS 체계가 정상 동작하도록 하기 위하여 1차 및 2차 네임서버들에게 각 존의 DNS 정보 갱신을 위한 우선 연결경로 형성의 책임을 분담시켜 부여하고, 이동 IP 네트워크이 이동하거나 불안정한 상황에서도 DNS 정보 갱신을 안정적으로 수행하게 하기 위하여 예비 경로인 보조 연결경로를 형성하며, 이동 중인 특정 존이 DNS 정보 갱신을 위한 우선 연결이나 보조연결경로로부터 모두 두절되어 있는 경우에 새로운 IP 주소를 할당해 주기 위한 DHCP 역할을 2차 플랫폼 네임서버가 1차 네임서버의 역할을 대행하도록 구성된 이동 IP 통신망을 지원하기 위한 도메인네임 장치 및 방법이 공개되어 있고,
동 공보 등록번호 제1004704930000(2005.01.28.)호에는 웹브라우저를 포함하는 사용자 컴퓨터, 컨텐츠 제공서버(CP 서버) 및 특수 도메인 네임 서비스 서버(x-DNS 서버)를 이용한 방법으로서, 사용자 컴퓨터는 CP 서버 또는 x-DNS서버로부터 상기 x-DNS 서버와의 통신에 필요한 프로그램인 x-DNS 클라이언트 모듈 및 x-DNS 서비스가 가능한 도메인 네임에 관한 정보가 포함된 x-DNS DB를 포함하는 구성요소를 전송받아 설치하는 제1단계와; 사용자 컴퓨터는 특정 CP에 접속하고자 하는 사용자에 의하여 입력된 도메인 네임을 후킹(Hooking)한 후, 해당 도메인 네임이 상기 x-DNS DB에 포함되어 있는지 확인하는 제2단계와; 상기 제2단계에서 해당 도메인 네임이 x-DNS DB에 포함되어 있는 경우에는 상기 x-DNS 서버로 해당 도메인 네임을 질어의로 하는 IP어드레스 요청신호를 전송하고, 포함되어 있지 않은 경우에는 기설정된 일반 DNS 서버로 상기 IP 어드레스 요청신호를 전송하는 제3단계와; 상기 사용자 컴퓨터는 상기 x-DNS 서버 또는 일반 DNS 서버로부터 전송되는 특정 IP어드레스 정보를 수신한 후, 해당 IP 어드레스를 이용하여 해당 CP서버로 접속하는 제4단계;로 이루어지며, x-DNS서버는 제3단계에 의하여 전송된 도메인 네임에 해당되는 IP어드레스를 추출하며, IP 어드레스 추출시 광역분산(GLB) 및 서버분산(SLB) 방식에 의하여 다수의 해당 CP 서버의 IP어드레스 중 최적의 조건에 있는 CP의 IP 어드레스를 추출한 후 사용자 컴퓨터로 전송하는 기술이 공개되어 있음을 알 수 있다.
1. 국내등록특허공보 등록번호 제1011508150000 (2012.05.22.)호 2. 국내등록특허공보 등록번호 제1011741090000(2012.08.08.)호 3. 국내등록특허공보 등록번호 제1011109790000(2012.01.20.)호 4. 국내등록특허공보 등록번호 제1004704930000(2005.01.28.)호
도메인 네임 관리 업무에 있어 여러 가지 형태의 관리 방법이 있으며, 각각은 다음과 같다.
방법1) 리눅스 및 유닉스 운영제제를 도메인 네임서버로 사용하는 경우 도메인 관리 시스템의 운영에 있어 도메인 네임 및 호스트 정보를 ZONE이라는 파일형태로 관리되고 있으며, 관리자는 도메인 네임 및 호스트 정보를 추가/삭제/변경/열람하고자 할 때 해당 ZONE 파일을 에디터를 통하여 편집한 후 리로드(RELOAD)하여 사용하는 관리 방법이 있다.
방법2) 리눅스 및 윈도우즈 도메인 네임 서버로 사용하는 경우 운영체제에서 제공하고 있는 도메인 네임 관리 스탠드 얼론 사용자 인터페이스 화면을 사용하여 도메인 네임 및 호스트 정보를 추가/삭제/변경/열람하여 저장 후 자동 리로드(RELOAD)하여 사용하는 관리 방법이 있다.
방법3) 기타의 경우로서 도메인 관리 시스템에서 제공하고 있는 웹 사용자 인터페이스 화면을 통하여 도메인 네임 및 호스트 정보를 추가/삭제/변경/열람하여 저장 후 자동 리로드(RELOAD)하여 사용하는 관리 방법이 있다.
위에서 제시한 여러 가지 방법은 사람에 의한 수동 작업을 필요로 하며, 모바일 앱, 매쉬업 서비스 및 자동화를 필요로 하는 클라우드 서비스와 같은 기계와 기계간의 연계하여 사용하는데 어려움이 존재하여 이러한 어려움의 해결이 본 발명의 해결과제인 것이다.
본 발명은 본 출원인이 선출원한 국내특허출원번호 제10-2008-0051364호(등록번호 제10-994764호) 발명의 명칭 도메인 네임 웹 관리시스템을 개량한 도메인 네임 관리시스템에 관한 것으로서,
도메인 네임 관리에 필요한 기능을 정의하고 이를 오픈 API화 하여 서비스함으로써, 오픈 API 사용법을 파악한 사용자가 기계(정보기기)에 프로그램을 내장한 후 관리하고자 하는 도메인 및 IPv4 및 IPv6 주소를 갖는 호스트를 오픈 API를 통하여 쉽게 등록할 수 있고, 필요에 따라 자동화할 수 있도록 한 오픈 API를 사용한 도메인 네임 관리 서비스 제공 방법을 제공하는 것이 본 발명의 과제 해결 수단인 것이다.
본 발명은 도메인 소유자가 도메인 네임 관리 시스템에서 제공하는 터미널을 통한 명령어 방식, 스탠드얼론 그래픽 유저 인터페이스 화면 혹은 웹 유저 인터페이스 화면을 통하여 수행할 수 있는 도메인 관리 업무를 오픈 API를 통하여 수행할 수 있도록 함으로써 도메인 관리 혹은 호스트관리를 자동화하고자 하는 모바일 앱, 매쉬업 응용서비스 그리고 많은 수의 도메인/호스트 자동화 관리가 필요한 클라우드 서비스 산업등에 파급효과가 나타날 수 있으며, 앞으로 gTLD 도메인의 다변화 및 IPv6시대에 확산이 예상되며,
오픈 API 사용법을 파악한 사용자가 기계(정보기기)에 프로그램을 내장한 후 관리하고자 하는 도메인 및 IPv4 및 IPv6 주소를 갖는 호스트를 오픈 API를 통하여 쉽게 등록할 수 있고, 필요에 따라 자동화할 수 있는 장점이 있는 것이다.
도1 본 발명의 도메인 네임 관리 서비스를 위한 오픈 API 구성도
도2 오픈 API 사용을 위한 AUTH-TOKEN 획득 처리
도3 도메인 관리 서비스를 위한 오픈 API 처리
도4 RR(Resource Record) 관리 서비스를 위한 오픈 API 처리
본 발명은 IPv4 호스트 혹은 IPv6 호스트에 대하여 도메인 네임을 등록하기 위해서는 사전에 터미널을 통한 명령어 방식, 스탠드얼론 그래픽 유저 인터페이스 화면 혹은 웹 유저 인터페이스 화면을 통하여 수행할 수 있는 도메인 관리 업무 대신 REST기반 HTTP 프로토콜을 통하여 도메인을 관리하도록 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공 방법에 관한 것이다.
본 발명을 도면을 참고하여 설명하면 다음과 같다. <도1> 1A 는 전체 시스템에 대한 구성도로서 DNS Management Service 오픈 API 블락, DNS Management Service Web Pages 블락, Authentication Logic 블락, Domain Process Logic 블락, Database Connector 블락, Web Application Server 블락, 데이터베이스 그리고 DNS Executor로 이루어 진다.
여기서 Auth 오픈 API, Domain 관리 오픈 API, RR 관리 오픈 API로 구성되는 DNS Management Service 오픈 API 블락과 Authentication Logic 블락이 특허 청구 범위에 해당된다. <도1> 1B 는 1A에서 특허 청구 범위에 해당하는 DNS Management Service 오픈 API 블락을 중심으로 작성된 구성도이다.
도메인 네임 관리 서비스 오픈 API를 사용하기 위한 AUTH-TOKEN 및 API-KEY에 의한 인증 획득 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 획득 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 획득 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 삭제 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 등록 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 변경 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 획득 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 삭제 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 등록 단계;와
상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 변경 단계;를 포함하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법에 관한 것이다.
API란 'Application Programming Interface'의 약어로, 웹에서 API의 의미는 웹 서비스를 개발할 때 웹 서비스를 사용하기 위한 규약 혹은 규칙을 말한다. 웹 2.0이라는 개념이 등장하면서 내부적으로 혹은 제한된 사용자에게만 제공했던 API를 일반인에게도 공개하기 시작했다. 누구나 사용할 수 있도록 공개된 API를 오픈 API라고 하며, 대부분의 매쉬업은 오픈 API를 활용해 만들어지므로 API를 얼마나 잘 활용하느냐가 매쉬업의 성공여부가 결정되기도 한다.
웹 사이트가 API를 제공한다는 것은 웹 서비스 플랫폼을 제공하는 것으로서, 사용자가 오픈 API를 사용함으로써 플랫폼 제공자에게 다음과 같은 이익이 돌아오게 된다.
첫 번째로 API가 공개되어 서비스의 활용도가 높아지면서 자동적으로 서비스가 더욱더 활성화되고 서비스의 품질도 높아지게 된다.
두 번째로 전체적으로 서비스 지향적인 구조가 형성되어 차후 유지보수나 서비스의 통폐합이 용이해진다.
세 번째로 오픈 API를 구축해 놓으면 B2C, B2B간의 제휴나 서비스의 사용이 용이해진다.
네 번째로 기업이 제공한 오픈 API로 개발된 매쉬업 애플리케이션의 선호도가 높아짐에 따라 API 제공만으로도 훌륭한 파트너를 얻게 된다. 또한 오픈 API 제공으로 트래픽이 중가하면 증가한 트래픽이 수익으로 연결된 된다.
다섯 번째로 자사의 API 로 개발된 매쉬업 애플리케이션 사용에 대한 실시간 통계 수집을 통하여 어떤 부분이 자신의 서비스에 도움이 될 것인지를 쉽게 파악할 수 있다.
여섯 번째로 다양한 플랫폼에서 자원을 사용될 수 있게 함으로써 다양한 채널로 부터의 서비스 활용이 풍부해진다.
본 발명은 첫 번째, 도메인 네임 관리 서비스 오픈 API를 사용하기 위한 AUTH-TOKEN 및 API-KEY에 의한 인증 획득 단계는 다음과 같다.
도메인 네임 관리 시스템에 대하여 AUTH-TOKEN 및 API-KEY 요청 메시지 포맷은 아래와 같이하며,
GET /api/v1/auth HTTP/1.1
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-USER-ID:USER-ID
X-USER-PASSWD:USER-PASSWORD
위의 요청메시지를 받은 서버는 전달 받은 USER-ID, USER-PASSWORD를 Authentication Logic 블락으로 전달하고 Authentication Logic 블락은 Database Connector를 이용하여 데이터베이스 질의하여 인증을 확인하게 된다. 인증 완료 후 리턴하는 응답 메시지 포맷은 다음과 같고,
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
X-SERVICE-URL:SERVICE-URL
X-AUTH-TOKEN:AUTH-TOKEN
X-API-KEY:API-KEY
Content-Type: application/json;charset=UTF-8
위의 응답메시지 포맷을 통하여 인증된 사용자를 위한 오픈 API SERVICE-URL과 AUTH-TOKEN과 API-KEY값을 획득하게 된다. 여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
두 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 획득 단계는 현재 등록된 도메인 목록을 요청하는 단계로서 도메인 네임, 이메일 주소, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL범위, 리버스 DNS 사용여부에 대한 데이터 목록을 요청하게 된다.
AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인 목록을 요청하기 위한 메시지 포맷은 다음과 같다.
GET /api/v1/domain/API-KEY
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
응답 메시지 포맷은 다음과 같다. 여기서 ID를 도메인 정보 고유 식별자이다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
........
Content-Length:N
[{"id":ID,
"ttl":TTL,
"levelName":"DOMAIN-NAME",
"useReverseDns":BOOLEAN,
"apiKey":"API-KEY",
"soaRecord":"minimum":MINIMUM-VALUE,
"serialNumber":SERIAL-NUMBER,
"email":"EMAIL",
"refresh":REFRESH-VALUE,
"retry":RETRY-VALUE,
"expire":EXPIRE-VALUE,
"primaryServer":PRIMARY HOSTNAME }
}
여러 개가 올 수 있음
]
세 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 획득 단계는
현재 등록된 특정 도메인 정보을 요청하는 단계로서 도메인 네임, 이메일 주소, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL범위, 리버스 DNS 사용여부에 대한 데이터를 요청하게 된다.
AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 특정 도메인 정보를 요청하기 위한 메시지 포맷은 다음과 같다.
GET /api/v1/domain/API-KEY/ID
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Content-Length:N
"id":ID,
"ttl":TTL,
"levelName":"DOMAIN-NAME",
"useReverseDns":BOOLEAN,
"apiKey":"API-KEY",
"soaRecord":"minimum":MINIMUM-VALUE,
"serialNumber":SERIAL-NUMBER,
"email":"EMAIL",
"refresh":REFRESH-VALUE,
"retry":RETRY-VALUE,
"expire":EXPIRE-VALUE,
"primaryServer":PRIMARY HOSTNAME }
}
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
네 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 삭제 단계는 AUTH-TOKEN과 API-KEY를 사용하여 등록된 도메인 삭제하기 위한 메시지 포맷은 다음과 같다.
DELETE /api/v1/domain/API-KEY/ID
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
........
Content-Length:N
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
다섯 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 등록 단계는 도메인 네임을 등록하기 위해서 사용하고자 하는 도메인 네임, 이메일 주소, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL범위, 리버스 DNS 사용여부에 대한 데이터를 입력하여 도메인네임을 등록하는 단계이며, 각 항목에 대한 세부 내용은 아래의 표와 같다.
등록항목 내용
도메인 네임 사용자가 사용하고자 하는 도메인명.
관리자 이메일 도메인을 관리하는 유저의 이메일 정보.
SERIAL NUMBER ZONE 파일의 버전을 의미합니다. 보통 zone 파일을 수정하거나 생성한 날짜를 숫자로 설정.
1차 네임 서버의 이 값을 확인하고 2차 네임 서버의 사본을 나타내는 일련번호보다 크면 1차 네임 서버로부터 zone 파일을 전송해서 2차 네임 서버 정보를 갱신.
REFRESH 2차 네임 서버가 1차 네임 서버의 갱신 내용을 확인하기 위해 주기적으로 체크하는 시간.
RETRY 2차 네임 서버가 refresh값에 의해 1차 네임 서버로 접속시도 할 때 1차 네임 서버의 문제로 접속을 못한 경우 다시 접속 시도할 시간을 설정.
EXPIRE 2차 네임 서버가 1차 네임 서버의 정보를 얼마나 오랫동안 신임 할 것인가를 설정.
만약 2차 네임 서버가 1차 네임 서버에 접속할 수 없을 때 전에 백업 받아온 1차 네임 서버 정보를 이 값이 초과 할 때까지 신임.
MINIMUM TTL과 같은 부분
TTL 특정 네임 서버가 도메인을 질의하고 그 정보를 가져간 후 그 정보를 보유하고 있을 시간을 지정.
AUTH-TOKEN과 API-KEY를 사용하여 신규 도메인 추가하기 위한 메시지 포맷은 다음과 같다. ID값이 자동할당 됨으로 입력하지 않는다.
PUT -d
'"ttl":TTL,
"levelName":"DOMAIN-NAME",
"useReverseDns":BOOLEAN,
"apiKey":"API-KEY",
"soaRecord":"minimum":MINIMUM-VALUE,
"serialNumber":SERIAL-NUMBER,
"email":"EMAIL",
"refresh":REFRESH-VALUE,
"retry":RETRY-VALUE,
"expire":EXPIRE-VALUE,
"primaryServer":PRIMARY HOSTNAME }
}' /api/v1/domain
Host: localhost
X-AUTH-TOKEN:AUTH-TOKEN
도메인 네임 관리 시스템은 입력 값에 대한 유효성을 확인한다. 도메인 네임 유효성, 이메일 유효성, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL 범위등이다.
입력 값에 대한 유효성이 확인이 된 후, 이미 같은 이름을 갖는 도메인 네임이 등록이 되어 있는지를 데이터베이스 처리 로직을 통하여 확인한다.
신규 도메인 네임인 경우, 도메인 네임 테이블을 만들고, 여기에 SOA 레코드와 NS 레코드를 자동 생성하여 저장한다.
관리자의 입력 항목중 리버스 DNS 사용 여부를 확인한 뒤 사용하는 경우, 리버스 도메인 테이블을 생성한 후, SOA 레코드와 NS 레코드를 위와 같이 자동 생성하여 리버스 도메인 테이블에 저장한다.
SOA 레코드와 NS 레코드의 저장이 완료되면 도메인 네임 서버가 SOA 레코드와 NS 레코드의 저장 완료를 인지하여 서비스하기 위해서, 도메인 네임 서버 구성화일을 저장된 도메인 네임 리스트를 통하여 생성 저장한다.
네임서버 구성화일이 생성되면 도메인 네임서버를 재 시작함으로써 등록과정이 완료된다.
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
........
Content-Length:N
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
여섯 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 변경 단계 는 AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인 정보 변경 하기 위한 메시지 포맷은 다음과 같다. ID값이 입력되어야 한다.
POST -d
'{"id":ID,
"ttl":TTL,
"levelName":"DOMAIN-NAME",
"useReverseDns":BOOLEAN,
"apiKey":"API-KEY",
"soaRecord":"minimum":MINIMUM-VALUE,
"serialNumber":SERIAL-NUMBER,
"email":"EMAIL",
"refresh":REFRESH-VALUE,
"retry":RETRY-VALUE,
"expire":EXPIRE-VALUE,
"primaryServer":PRIMARY HOSTNAME }
}' /api/v1/domain
User-Agent: USER-AGENT
Host: HOSTNAME
Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
........
Content-Length:N
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
일곱 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 획득 단계는
AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 호스트 정보를 열람 요청하기 위한 메시지 포맷은 4 종류가 있으며 그것은 각각 다음과 같다.
지정된 도메인에 대하여 등록된 전체 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같다.
GET /api/v1/rr/API-KEY/DOMAIN-NAME
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
지정된 도메인에 대하여 등록된 전체 호스트중 ID 값과 일치하는 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같다.
GET /api/v1/rr/API-KEY/DOMAIN-NAME/ID
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
지정된 도메인에 대하여 등록된 전체 호스트중 RESOURCE-TYPE과 일치하는 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같다.
GET /api/v1/rr/API-KEY/DOMAIN-NAME/RESOURCE-TYPE
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
지정된 도메인에 대하여 등록된 전체 호스트중 RESOURCE-TYPE와 HOST-NAME이 일치하는 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같다.
GET /api/v1/rr/API-KEY/DOMAIN-NAME/RESOURCE-TYPE/HOST-NAME
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
위의 4 종류의 요청에 대한 응답 메시지는 다음과 같다.
[
{"id":ID,
"name":"HOST-NAME",
"data":"IP-ADDRESS OR RESOURCE-DATA",
"ttl":TTL,
"apiKey":"API-KEY",
"levelName":"LEVEL-NAME",
"rrType":"RESOURCE-TYPE",
"dclass":DCLASS}
여러 개가 올 수 있음
]
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
여덞번째 , 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 삭제 단계는
AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 특정 호스트 정보 삭제 요청하기 위한 메시지 포맷은 다음과 같다.
DELETE /api/v1/rr/API-KEY/ID
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
........
Content-Length:N
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
아홉 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 등록 단계는 현재 등록된 특정 도메인에 대한 IPv4 혹은 IPv6 주소를 갖는 호스트 등록단계로서 호스트 이름, 레코드 타입, 레코드 데이터를 필요로 하면 레코드 타입은 A(Address), AAAA(Address), NS(Neighbor Server), MX(Mail exchange), CNAME(Canonical Name), SPF(Sender Policy Framework) 등등이 있다. 여기서 A 레코드 타입을 입력하는 경우를 예로 들면 다음과 같다.
다음은 A레코드 추가시 필요한 사항이다.
등록항목 내용
호스트명 사용자가 사용하고자 할 하위 도메인명.
TTL 특정 네임 서버가 도메인을 질의하고 그 정보를 가져간 후 그 정보를 보유하고 있을 시간을 지정.
데이타 해당 하위도메인의 IPv4를 설정.
다음은 AAAA 레코드 추가시 필요한 사항이다.
등록항목 내용
호스트명 사용자가 사용하고자 할 하위 도메인명.
TTL 특정 네임 서버가 도메인을 질의하고 그 정보를 가져간 후 그 정보를 보유하고 있을 시간을 지정.
데이타 해당 하위도메인의 IPv6를 설정.
아래는 IETF RFC 문서의 A RR과 AAAA RR 포맷의 예시.
Name TTL CLASS TYPE DLENGTH RDATA
www.test.co.kr 1800 IN A 4 192.168.0.1
www.test.co.kr 1800 IN AAAA 16 2001:2b8:5c0:1:0:0:0:1
메일 도메인을 추가시키기 위해서는 하나의 MX레코드와 하나이상의 MX레코드에 대한 A레코드가 필요하다. MX레코드 추가시 필요한 사항
등록항목 내용
호스트명 사용자가 사용하고자 할 하위 도메인명.
TTL 특정 네임 서버가 도메인을 질의하고 그 정보를 가져간 후 그 정보를 보유하고 있을 시간을 지정.
Preference 여러 값이 존재할 시 값이 작을수록 우선순위가 높다.
AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 신규 호스트 정보 추가 요청하기 위한 메시지 포맷은 다음과 같다. 여기서 ID값은 자동 부여됨으로 입력하지 않아도 된다.
PUT -d
'{"name":"HOST-NAME",
"data":"IP-ADDRESS OR RESOURCE-DATA",
"ttl":TTL,
"apiKey":"API-KEY",
"levelName":"LEVEL-NAME",
"rrType":"RESOURCE-TYPE",
"dclass":DCLASS}' /api/v1/rr
User-Agent: USER-AGENT
Host: HOSTNAME

Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
도메인 네임 관리시스템은 입력한 값에 대한 유효성을 점검한다. 즉 호스트명의 유효성, IPv4 주소 유효성, TTL 값 범위 등이다.
입력 값이 유효한 경우 도메인 관리 처리 로직에서 각 레코드 타입에 맞는 레코드를 생성한다.
이렇게 생성된 레코드를 데이터베이스 처리 로직중 저장 로직을 통하여 도메인 테이블에 저장한다.
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
........
Content-Length:N
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403
열 번째, 본 발명의 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 변경 단계는 AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 특정 호스트 정보 변경 요청하기 위한 메시지 포맷은 다음과 같다. 여기서 ID값을 입력하여야 한다.
POST -d
'{"id":ID,
"name":"HOST-NAME",
"data":"IP-ADDRESS OR RESOURCE-DATA",
"ttl":TTL,
"apiKey":"API-KEY",
"levelName":"LEVEL-NAME",
"rrType":"RESOURCE-TYPE",
"dclass":DCLASS}' /api/v1/rr
User-Agent: USER-AGENT
Host: HOSTNAME
Content-Type: application/json
X-AUTH-TOKEN:AUTH-TOKEN
응답 메시지 포맷은 다음과 같다.
HTTP/1.1 Http-Status-Code
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
........
Content-Length:N
여기서 Http-Status-Code 값은 다음과 같다.
설명 HTTP Status Code
요청처리 완료 200
인증 실패(AUTH-TOKEN ERROR) 401
권한 없음 403

Claims (11)

  1. 삭제
  2. 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법에 있어서,
    도메인 네임 관리 서비스 오픈 API를 사용하기 위한 AUTH-TOKEN 및 API-KEY에 의한 인증 획득 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 획득 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 획득 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 삭제 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 등록 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 변경 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 획득 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 삭제 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 등록 단계;와
    상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 변경 단계;로 구성되며,

    상기 도메인 네임 관리 서비스 오픈 API를 사용하기 위한 AUTH-TOKEN 및 API-KEY에 의한 인증 획득 단계는
    도메인 네임 관리 시스템에 대하여 AUTH-TOKEN 및 API-KEY 요청 메시지 포맷은 아래와 같이하며,
    Figure 112014044714986-pat00001

    응답 메시지 포맷은 다음과 같고,
    Figure 112014044714986-pat00002

    여기서 Http-Status-Code 값은 다음과 같으며,
    Figure 112014044714986-pat00003

    위의 응답메시지 포맷을 통하여 인증된 사용자를 위한 오픈 API SERVICE-URL과 AUTH-TOKEN과 API-KEY값을 획득함을 특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법
  3. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 획득 단계는 현재 등록된 도메인 목록을 요청하는 단계로서 도메인 네임, 이메일 주소, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL범위, 리버스 DNS 사용여부에 대한 데이터 목록을 요청하게 되며, AUTH-TOKEN과 API-KEY고,
    Figure 112014088919666-pat00004

    응답 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00005

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  4. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 획득 단계는
    현재 등록된 특정 도메인 정보을 요청하는 단계로서 도메인 네임, 이메일 주소, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL범위, 리버스 DNS 사용여부에 대한 데이터를 요청하며, AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 특정 도메인 정보를 요청하기 위한 메시지 포맷은 다음과 같고,
    Figure 112014088919666-pat00006

    응답 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00007

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  5. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 삭제 단계는 AUTH-TOKEN과 API-KEY를 사용하여 등록된 도메인 삭제하기 위한 메시지 포맷은 다음과 같으며,
    Figure 112014088919666-pat00008

    응답 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00009

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  6. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 등록 단계는 도메인 네임을 등록하기 위해서 사용하고자 하는 도메인 네임, 이메일 주소, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL범위, 리버스 DNS 사용여부에 대한 데이터를 입력하여 도메인네임을 등록하는 단계이며, 각 항목에 대한 세부 내용은 아래의 표와 같으며,
    Figure 112014088919666-pat00010

    AUTH-TOKEN과 API-KEY를 사용하여 신규 도메인 추가하기 위한 메시지 포맷은 다음과 같고. ID값이 자동할당 됨으로 입력하지 않으며,
    Figure 112014088919666-pat00011

    도메인 네임 관리 시스템은 입력 값에 대한 유효성을 확인하며, 도메인 네임 유효성, 이메일 유효성, 갱신 주기 범위, 재시도 주기 범위, 해제 주기 범위, 최소값 범위, TTL 범위이고,
    입력 값에 대한 유효성이 확인이 된 후, 이미 같은 이름을 갖는 도메인 네임이 등록이 되어 있는지를 데이터베이스 처리 로직을 통하여 확인하며,
    신규 도메인 네임인 경우, 도메인 네임 테이블을 만들고, 여기에 SOA 레코드와 NS 레코드를 자동 생성하여 저장하고,
    관리자의 입력 항목중 리버스 DNS 사용 여부를 확인한 뒤 사용하는 경우, 리버스 도메인 테이블을 생성한 후, SOA 레코드와 NS 레코드를 위와 같이 자동 생성하여 리버스 도메인 테이블에 저장하며,
    SOA 레코드와 NS 레코드의 저장이 완료되면 도메인 네임 서버가 SOA 레코드와 NS 레코드의 저장 완료를 인지하여 서비스하기 위해서, 도메인 네임 서버 구성화일을 저장된 도메인 네임 리스트를 통하여 생성 저장하고,
    네임서버 구성화일이 생성되면 도메인 네임서버를 재 시작함으로써 등록과정이 완료되며,
    응답 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00012

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  7. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인 정보 변경 단계는 AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인 정보 변경 하기 위한 메시지 포맷은 다음과 같으며, ID값이 입력되어야 하고,
    Figure 112014088919666-pat00013

    응답 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00014

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  8. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 획득 단계는
    AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 호스트 정보를 열람 요청하기 위한 메시지 포맷은 4 종류가 있으며 그것은 각각 다음과 같으며, 지정된 도메인에 대하여 등록된 전체 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같고,
    Figure 112014088919666-pat00015

    지정된 도메인에 대하여 등록된 전체 호스트중 ID 값과 일치하는 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같으며,
    Figure 112014088919666-pat00016

    지정된 도메인에 대하여 등록된 전체 호스트중 RESOURCE-TYPE과 일치하는 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같고,
    Figure 112014088919666-pat00017

    지정된 도메인에 대하여 등록된 전체 호스트중 RESOURCE-TYPE와 HOST-NAME이 일치하는 호스트 정보를 열람하기 위한 메시지 포맷은 아래와 같으며,
    Figure 112014088919666-pat00018

    위의 4 종류의 요청에 대한 응답 메시지는 다음과 같음을
    Figure 112014088919666-pat00019

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  9. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 삭제 단계는 AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 특정 호스트 정보 삭제 요청하기 위한 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00020


    Figure 112014088919666-pat00021


    Figure 112014088919666-pat00022

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
  10. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 등록 단계는 현재 등록된 특정 도메인에 대한 IPv4 혹은 IPv6 주소를 갖는 호스트 등록단계로서 호스트 이름, 레코드 타입, 레코드 데이터를 필요로 하면 레코드 타입은 A(Address), AAAA(Address), NS(Neighbor Server), MX(Mail exchange), CNAME(Canonical Name), SPF(Sender Policy Framework)이 있으며, 여기서 A 레코드 타입을 입력시 필요한 사항으로서,
    Figure 112014088919666-pat00023

    다음은 AAAA 레코드 추가시 필요한 사항이며,
    Figure 112014088919666-pat00024

    아래는 IETF RFC 문서의 A RR과 AAAA RR 포맷은 다음과 같고,
    Figure 112014088919666-pat00025


    메일 도메인을 추가시키기 위해서는 하나의 MX레코드와 하나이상의 MX레코드에 대한 A레코드가 필요하며, MX레코드 추가시 필요한 사항은 다음과 같고,
    Figure 112014088919666-pat00026

    AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 신규 호스트 정보 추가 요청하기 위한 메시지 포맷은 다음과 같으며, 여기서 ID값은 자동 부여됨으로 입력하지 않아도 되며,
    Figure 112014088919666-pat00027

    도메인 네임 관리시스템은 입력한 값에 대한 호스트명의 유효성, IPv4 주소 유효성, TTL 값 범위의 유효성을 점검하고,
    입력값이 유효한 경우 도메인 관리 처리 로직에서 각 레코드 타입에 맞는 레코드를 생성하며, 생성된 레코드를 데이터베이스 처리 로직중 저장 로직을 통하여 도메인 테이블에 저장하고, 응답 메시지 포맷은 다음과 같음을
    Figure 112014088919666-pat00028

    Figure 112014088919666-pat00029


    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.

  11. 청구항 2에 있어서, 상기 오픈 API Auth-Token를 포함하는 도메인 정보 목록 중 특정 도메인에 대한 호스트 정보 목록 중 특정 호스트 정보 변경 단계는 AUTH-TOKEN과 API-KEY를 사용하여 현재 등록된 도메인에 대하여 특정 호스트 정보 변경 요청하기 위한 메시지 포맷은 다음과 같으며, 여기서 ID값을 입력하여야 하며,
    Figure 112014088919666-pat00030

    응답메세지 포맷은 다음과 같음을
    Figure 112014088919666-pat00031

    Figure 112014088919666-pat00032

    특징으로 하는 오픈 API를 사용한 도메인 네임 관리 서비스 제공방법.
KR20130042632A 2013-04-18 2013-04-18 오픈 api를 사용한 도메인 네임 관리 서비스 제공방법 KR101485764B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR20130042632A KR101485764B1 (ko) 2013-04-18 2013-04-18 오픈 api를 사용한 도메인 네임 관리 서비스 제공방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR20130042632A KR101485764B1 (ko) 2013-04-18 2013-04-18 오픈 api를 사용한 도메인 네임 관리 서비스 제공방법

Publications (2)

Publication Number Publication Date
KR20140125042A KR20140125042A (ko) 2014-10-28
KR101485764B1 true KR101485764B1 (ko) 2015-01-26

Family

ID=51995007

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20130042632A KR101485764B1 (ko) 2013-04-18 2013-04-18 오픈 api를 사용한 도메인 네임 관리 서비스 제공방법

Country Status (1)

Country Link
KR (1) KR101485764B1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101647278B1 (ko) * 2015-04-29 2016-08-23 (주)유미테크 Dns패킷 json 변환 및 순위 추출 방법
CN115412611B (zh) * 2022-08-29 2024-03-01 北京新唐思创教育科技有限公司 基于dns服务器的查询方法、装置、设备及介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090061503A (ko) * 2007-12-11 2009-06-16 한국전자통신연구원 인터넷 프로토콜 멀티미디어 서브시스템 및 그 시스템의라우팅 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090061503A (ko) * 2007-12-11 2009-06-16 한국전자통신연구원 인터넷 프로토콜 멀티미디어 서브시스템 및 그 시스템의라우팅 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
카달로그 *

Also Published As

Publication number Publication date
KR20140125042A (ko) 2014-10-28

Similar Documents

Publication Publication Date Title
RU2409846C2 (ru) Организация ресурсов в коллекции, способствующая более эффективному и надежному доступу к ресурсам
EP2266064B1 (en) Request routing
US7251689B2 (en) Managing storage resources in decentralized networks
US7958246B2 (en) Establishing unique sessions for DNS subscribers
CN100484125C (zh) 对地址询问的回答方法和回答装置
US7181536B2 (en) Interminable peer relationships in transient communities
US20030188019A1 (en) Providing management functions in decentralized networks
CN105991796B (zh) 一种用于部署网络中的用户终端的配置服务的方法和系统
US20100312851A1 (en) Systems and methods for creating virtual universal plug-and-play systems
CN101355565B (zh) 为不同类型浏览器提供页面服务的方法及服务器
CN101103354A (zh) 基于对共享式数据的访问权限来提供服务
US9258377B2 (en) Publish information on website
EP3447996A1 (en) Resource subscription method, resource subscription device, and resource subscription system
CN109729187B (zh) 一种代理通信方法、系统、装置及存储介质
JP3899076B2 (ja) 一時的ネットワーク
WO2017161965A1 (zh) 一种动态域名系统dns重定向方法、装置及系统
JP2017201776A (ja) 不均一ネットワークにまたがるコンテンツ配送
JP2011129005A (ja) 認証方法、変換装置、中継装置、及び該プログラム
US8861503B2 (en) Method and system for synchronizing data between mobile terminal and internet phone
US9237206B2 (en) Method and apparatus for updating personal information in communication system
KR101485764B1 (ko) 오픈 api를 사용한 도메인 네임 관리 서비스 제공방법
CN115840754A (zh) 虚拟资源管理方法、装置及电子设备
JP2011071870A (ja) 通信装置、通信システムおよび通信方法
US9336261B2 (en) Method and apparatus for updating personal information in communication system
Pöhlsen et al. Integrating a decentralized web service discovery system into the internet infrastructure

Legal Events

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

Payment date: 20180110

Year of fee payment: 4

LAPS Lapse due to unpaid annual fee