KR20120005016A

KR20120005016A - 현존하는 도메인 명칭 ｄｎｓ 트래픽 캡처 및 분석

Info

Publication number: KR20120005016A
Application number: KR1020117026312A
Authority: KR
Inventors: 알렉스 홀메스; 앤드류 심슨; 카르틱 시암선더; 스리니바스 선카라; 에이알 란스너; 니르 조하; 레오나드 오렌타스; 매트 라르손; 마크 코스터스; 세벡 만킨; 타미르 카마라
Original assignee: 베리사인 인코포레이티드
Priority date: 2009-04-07
Filing date: 2010-04-07
Publication date: 2012-01-13
Also published as: KR101640034B1; EP2417537A4; JP2012523625A; RU2011144861A; US8527658B2; US8909760B2; EP2417537A1; CN102549562A; US20150058139A1; AU2010234491B2; AU2010234491A1; US20150089056A1; US20100257266A1; CA2757832A1; CA2757832C; CN102460416B; US20100257024A1; WO2010118111A1; WO2010118118A1; BRPI1014234A2

Abstract

도메인 명칭을 리졸브하려는 권한 있는 명칭 서버에서 수신된 DNS 트래픽 요청에 기초하여 도메인 웹 트래픽에 스코어를 결정하기 위한 시스템 및 방법이다. 도메인 명칭을 리졸브하려는 요청이 권한 있는 명칭 서버에서 수신된다. 도메인 명칭에 대한 서버 카운터 또는 히트 카운터와 같은 카운터는 수신된 요청에 기초하여 증가된다. 도메인 트래픽 스코어 또는 도메인 순위와 같은 스코어는 카운터의 카운트에 기초하여 계산된다. 또한 스코어를 계산하는 것은 요청하는 리졸버 세트 및 트래픽 스코어가 계산되고 있는 도메인에 링크하여 트래픽을 구동하고 있을 수 있는 그밖의 도메인/웹 사이트에 관한 정보에 기초하여 카운터에 가중치를 적용하는 것을 포함할 수 있다. 관계된 리졸버 세트 정보의 예들은 리졸버 세트의 위치, 트래픽 레벨, 트래픽 유형 및 아키텍처를 포함할 수 있다.

Description

현존하는 도메인 명칭 ＤＮＳ 트래픽 캡처 및 분석{EXISTENT DOMAIN NAME DNS TRAFFIC CAPTURE AND ANALYSIS}

인터넷 상에서 사용자 활동을 이해하는 것이 더욱 중요해지고 있고, 인터넷이 계속하여 팽창하기 때문에, 더 어려워지고 있다. 인터넷의 상업적 이용은 지난 10년동안 극적으로 팽창한 하나의 영역이며, 사용자 활동을 이해하고, 모니터링하고 예측하는데 특히 관심을 갖는 영역이다. 인터넷의 상업적 이용에 관한 하나의 중요한 측면은 광고이다. 광고주들은 특정 내용을 광고하기 위해 적합한 웹 사이트 또는 도메인을 결정함에 있어 트래픽 순위와 같은 요소들을 사용할 수 있다.

마찬가지로 웹 사이트 소유자들은 이들의 웹 사이트 상에 광고에 대해 적합한 요금을 정하기 위해 트래픽 순위를 사용할 수 있다. 당업자에게 알려진 바와 같이, 인터넷 광고는 클릭당 광고료 지불(pay per click; PPC) 적용들과 같은 특정 광고의 효과를 직접적으로 보여줄 수 있는 많은 서로 다른 형태들을 취하였다. 그러나 트래픽 순위는 여전히, 인터넷 기반구조 관리의 다른 측면들뿐만 아니라, 인터넷 광고의 중요한 측면이다. 예를 들면, 인터넷상에 활동적인 웹 사이트들의 수가 늘어남에 따라, 서버 관리, 웹 개발, 광고 포커스 및 광고료와 같은 결정을 알려주기 위한 정확한 트래픽 레이트에 대한 요구가 증가하였다. 그러나 전형적으로 트래픽 스코어를 계산하기 위해 사용자 또는 웹 사이트의 트래픽을 모니터링하는 종래의 트래픽 모니터링 서비스의 능력에는 한계가 있다.

인터넷이 내재적으로 구성되는 방법에 대한 설명은 인터넷 상에 특정 웹 사이트들에 있어 트래픽을 효율적으로 모니터링하고 레이트하는 것에 관계된 문제를 이해하는데 도움이 될 수 있다.

인터넷 상에 웹 사이트를 만드는 프로세스는 전형적으로 등록자가 등록처를 통해 특정 도메인 명칭을 등록하는 것으로 시작한다. 등록자는 전형적으로 "example.com"와 같은 도메인 명칭을 나타내는 개인이거나 기관이다. 등록자는 명칭 등록을 처리하기 위해 등록처에 연락한다. 등록처는 필요한 도메인 명칭 서비스(DNS) 정보를 레지스트리에 보낸다. 등록처는 레지스트리에 보내진 것 외에 추가의 고객 정보를 내포한 데이터베이스를 유지 관리할 수 있다.

레지스트리는 등록처들로부터 DNS 정보를 수신하고, 이 정보를 중앙 데이터베이스에 삽입하고, 도메인 명칭들이 전 세계에 사용자들에 의해 발견될 수 있도록 정보를 인터넷 상에 전파시킨다.

일반적으로 DNS는 사람이 읽을 수 있는 도메인 명칭들을 인터넷을 통해 TCP/IP 통신을 설정하는데 필요한 인터넷 프로토콜(IP) 숫자들로 바꾸는 인터넷 기반구조의 부분이다. 즉, DNS는 인터넷 상에 컴퓨터들에 할당되는 "123.4.56.78"과 같은 숫자로 된 IP 어드레스들보다는, "www.example.com"같은 기억하기 쉬운 도메인 명칭들을 사용하여 사용자들이 웹 사이트, 및 다른 자원들을 참조할 수 있게 한다.

각각의 도메인 명칭은 점들에 의해 분리된 일련의 문자 스트링들(라벨)로 구성된다. 도메인 명칭에서 맨 우측 라벨은 "탑-레벨 도메인"(TLD)으로서 알려져 있다. 공지된 TLD들의 예들은 ".com"; ".net"; ".org." 등이다. 각각의 TLD는 예를 들면 "www.example.com"에서 "example" 레벨과 같이, TLD의 바로 좌측에 열거된, 두 번째-레벨 도메인을 지원한다. 각각의 두 번째-레벨 도메인은 예를 들면 "www.example.com"에서 "www" 레벨과 같이, 두 번째-레벨 도메인의 바로 좌측에 위치된 다수의 세 번째 레벨 도메인을 포함할 수 있다. 실질적으로 아무 제한이 없는 또 다른 레벨 도메인도 있을 수 있다. 예를 들면, 추가적인 도메인 레벨들을 가진 도메인은 "www.photos.example.com"일 수도 있을 것이다.

추가적인 비-도메인 정보는 도메인 명칭을 포함하는 URI(Uniform Resource Identifier) 구조에 포함될 수 있다. 예를 들면, "경로" 부분은 사선("/")에 의해 분리되는 일련의 세그먼트들(반드시 디렉토리들을 나타내는 것은 아닐지라도, 개념적으로 이들과 유사하다)이다. 이 정보는 "www.example.com/blog"에서 "blog"와 같이, 도메인 명칭의 바로 우측에 포함될 수 있고, 특정한 콘텐트를 확인하여 전달하거나 특정 코드를 실행하기 위해 서버 또는 다른 수신 디바이스에 의해 사용될 수 있다. 비-도메인 정보의 다른 예들은 쿼리(queries) 및 프래그먼트들을 포함할 수 있는데, 이들의 상세는 당업자들이 알고 있는 것으로 여기에서는 상세히 다루지 않는다. 이정보의 조합들은 사용자를 동일 페이지의 또 다른 부분에 혹은 동일, 혹은 다른 도메인의 부분일 수 있는 또 다른 웹 페이지에 내비게이트하는 웹 페이지 하이퍼링크들에 포함될 수 있다.

관계된 도메인 명칭들, 및 콘텐트는 "www.example.com"; "www.blog.example.com"; "www.example.com/blog"; 또는 "blog.example.com" 등과 같이 각각은 다른 의미를 갖는 계층적, 혹은 네스트(nest)되는 방식으로 구성될 수 있다. 이러한 관계된 도메인은 다양한 도메인 명칭들을 리졸브하는 실제 IP 어드레스에서 유사성들을 공유할 필요가 없다. 이에 관하여, 도메인 명칭의 부분은 요망되는 한 특정한 서버를 의미할 수 있는데, 예를 들면, "mail.example.com" 및 "www.example.com"은 동일한 두 번째-레벨 도메인에 대해서, 다른 기능들을 가진, 서로 다른 서버들에 리졸브할 수 있다.

인터넷의 상기 등록 및 구조적 특징들은 DNS 분해(resolution) 프로세스를 사용함으로써 인터넷상에서 특정한 자원들을 발견하기 위해 최종-사용자 애플리케이션들에 의해 사용된다. DNS 분해 프로세스의 측면들을 이하 본원의 요지를 이해하는데 도움이 되도록 설명한다.

각각의 TLD를 동작시키는(TLD 내에 두 번째-레벨 도메인의 레지스트리를 유지관리하는 것을 포함한) 임무는 하나의 특정한 도메인 명칭 레지스트리에 위임된다. 레지스트리는 이러한 정보를 큰 데이터베이스들에서 유지관리하는 DNS 서버들을 통해 도메인 명칭들을 IP 어드레스들로 변환하고("리졸빙(resolving)") 이의 탑-레벨 도메인을 운영하는 임무를 맡는다. DNS는 IP 어드레스들 및 도메인 명칭들을 저장하고 있어 .com, .net, .edu, .tv와 같은 TLD들 내 어드레스들에의 서비스를 용이하게 한다. 리졸빙은 도메인 명칭들이 대응하는 IP 숫자들에 맞추게 하는 프로세스이다. 리졸빙은 어느 IP 숫자들이 하나의 특정한 도메인 명칭에 대응하는지를 판정하기 위해 DNS 내 데이터를 사용하는 명칭 서버들이라고 하는 컴퓨터들 및 소프트웨어의 조합에 의해 달성된다. 여기에서는 다음의 일반적인 정의들이 사용될 것이다.

리졸브: 도메인 명칭을 IP 어드레스로 전환하는 것.

리졸버: 도메인 명칭을 리졸브하기 위해서 쿼리를 발행하는 컴퓨터.

명칭 서버: 쿼리를 수신하고 이들에 대해 직접 혹은 다른 명칭 서버들에 대한 리졸브를 통해 응답하는 컴퓨터.

서브네트: IP 어드레스의 옥텟들을 공유하는 일 그룹의 IP 어드레스들.

인터넷 도메인은 서로 다른 레지스트리들이 그들 각각을 맡고 있는 그들의 TLD 서픽스(suffix)(예를 들면 .com, .net, xo.uk...)에 따라 다수 그룹들로 분할될 수 있다. .com 및 .net 도메인을 담당하는 VeriSign 레지스트리와 같이, 단일의 레지스트리가 이들 그룹들 중 몇개를 담당할 수도 있다.

DNS는 클라이언트-서버 모델을 사용하는 분산 데이터베이스 시스템에 의해 유지 관리된다. 이 데이터베이스의 노드들이 명칭 서버들이다. 각각의 도메인 또는 서브-도메인은 이 도메인에 관한 정보를 공포하는 하나 이상의 권한 있는(authoritative) DNS 서버들 및 이에 부속된 임의의 도메인의 명칭 서버들을 갖는다. 계층의 최상위는 루트 명칭 서버들에 의해 서비스되며, 이들 서버들은 TLD을 참조(리졸빙)할 때 쿼리한다.

DNS는 각각의 도메인에 대해 권한 있는 명칭 서버들을 지정함으로써 도메인 명칭들을 할당하고 이들 명칭들을 IP 어드레스들에 매핑하는 임무를 분산한다. 권한 있는 명칭 서버들은 이들의 특정한 도메인을 담당하게 할당된다.

이론적으로, 전체 어드레스 도메인 명칭은 몇개의 명칭 세그먼트들을 가질 수 있다(예를 들면 "www.one.type.example.com"). 쿼리 목적을 위해서, 명칭 세그먼트는 전형적으로 우측에서 좌측으로 세그먼트별로 해석된다. 해석 과정의 각 단계에서, 참조해야 할 다음 서버에의 포인터를 제공하기 위해 대응하는 DNS 서버가 쿼리된다.

DNS에 의해 발생되는 방대한 분량의 요청들 때문에, 리졸브 프로세스는 성공적 응답후에 소정 기간 동안 캐시해 둔다(즉, DNS 쿼리 결과들을 한 곳에 기록해두고 차후에 참조한다). 리졸버가 DNS 응답을 얼마나 오래동안 캐시할 것인가는(즉, 얼마나 오fot동안 DNS 응답이 유효한 것인가 고려하는 것) 유효시간(time to live; TTL)이라고 하는 값에 의해 결정된다. TTL은 일반적으로 응답을 취급하는 DNS 서버의 관리자에 의해 설정된다. 유효성 기간은 단 몇 초 내지 몇 일 또는 심지어 몇 주로 다양할 수 있다.

캐시 기능 뿐만 아니라 DNS 구조에 기초하여, 통상적으로 명칭 서버들에 적용되는 두 유형으로서, 권한 있는(authoritative) 명칭 서버와 재귀적(recursive)(캐싱) 명칭 서버가 있다. 권한 있는 명칭 서버는 원래의 확정적 응답들("권한 있는" 응답들)을 DNS 쿼리에 제공하는 명칭 서버이다. 모든 도메인 명칭에는 도메인 명칭을 리졸빙하는 한 세트의 권한 있는 명칭 서버들이 할당되어야 한다.

전술한 바와 같이, DNS는 또한, 관계된 도메인 명칭 기록의 DNS 쿼리 결과들을 기간이 결정된 TTL 동안 저장하는 재귀적 캐시 서버들을 사용한다. 전형적으로, 이러한 캐시 DNS 서버들은 주어진 명칭에 대해 권한 있는 명칭 서버들에 이르기까지 DNS를 모두 검색하는 것부터 시작하여 주어진 명칭을 리졸브하는데 필요한 재귀적 알고리즘을 구현한다. 인터넷 서비스 제공자들(ISPs)은 전형적으로 이들의 고객들을 위해 재귀적 및 캐시 명칭 서버들을 제공한다. 또한, 많은 홈 네트워킹 라우터들은 국부적인 네트워크에서 효율을 개선하기 위해 DNS 캐시들 및 리커서(recursor)들을 구현한다.

DNS 명칭들을 IP 어드레스들로 리졸브하기 위해 근본적으로 캐시가 없는 애플리케이션으로서 동작하는 DNS "스터브(stub)" 리졸버 또한 공지되어 있다. DNS 스터브 리졸버는 워크스테이션(또는 서버)용으로 구성된 DNS 서버에 DNS 쿼리를 보내고 DNS 서버의 응답을 요청하는 소프트웨어에 보낸다. TTL이 만기가 되기 전에 캐시 서버에 의해 유지되고 있는 기록에 대해 스터브 리졸버가 캐시 명칭서버에 쿼리를 한다면, 캐시 서버는 권한 있는 명칭 서버로부터 다시 인출해오지 않고 캐시된 자원 기록으로 응답할 것이다.

현재 웹 트래픽 정보를 제공하기 위해 사용되는 몇 가지 접근 방법이 있다. 공지된 방법은 사용자들 중 선택된 표본들의 웹 트래픽 사용을 모니터링하는 클라이언트 에이전트가 이들 표본 사용자들에 제공되는 패널-중심적 접근 방법을 포함한다. 또한, 웹 사이트에 대해 웹 서버로부터 직접 웹 트래픽 통계들이 수집되는 사이트-중심적 수법들이 있다. 그외 방법은 ISP에 집중하며, 클라이언트에 웹 데이터를 제공하고 있는 ISP의 로그들로부터 웹 사용 트래픽을 수집한다. 그러나, 공지된 방법 각각은 데이터가 수집되는 시점, 수집된 데이터량 및/또는 수집된 데이터의 자료성에 관계된 결점들을 안고 있다. 예를 들면, 패널-중심적 애플리케이션들은 모니터링되고 있는 선택된 사용자들로 제한되기 때문에 인터넷 상에서 활동의 총체적 관점들을 얻는 능력에 한계가 있다. 또한, 수 십억 개개의 인터넷 사용자들의 활동들을 분류하려는 어떠한 시도이든, 가능하다할지라도, 급속히 관리불가한 레벨에 이르게 되는 막대한 데이터량을 야기할 것이다. ISP들은 이들의 특정한 클라이언트 기반, 지리적 관심, 및 특정 ISP가 알아도 되는 트래픽을 본질적으로 또는 암묵적으로 제약하는 그외 요인들에 의해 인터넷의 전체적 활동을 특징짓는 능력에 한계가 있다.

도메인에 대해 정확하고 의미있는 트래픽 순위를 결정하는데 있어 문제들이 더 있다. 일반적으로, 인터넷 트래픽은 2개의 그룹들로서, 사용자 본위의 트래픽, 및 기계 본위의 트래픽으로 분할될 수 있다. 사용자 본위의 트래픽은 웹 사이트들을 열람하는 사용자들에 의해 생성되는 활동으로서 간주될 수 있다. 기계 본위의 트래픽은 자동적 프로세스들 및 서비스들(예를 들면 안티바이러스 업데이트들, 운영 시스템 업데이트들, 웹 서비스들, 등)에 의해 발생되는 활동으로서 간주될 수 있다. 온라인 광고를 포함한, 상업적 목적을 위해서, 웹 사이트들에 구동된 사용자 발생 트래픽을 확인하는 것이 특히 중요하다. 그러므로, 사용자 본위의 트래픽을 측정하는 방법이 바람직하다. 그러나, 이것은 예를 들면, 요청자의 특성에 관한 정보가 인입 DNS 쿼리 자체들로부터 얻어질 수 없기 때문에 상당한 문제가 된다. 트래픽 유형들 간을 구별하는데 있어 또 다른 문제는 중간 DNS 리졸버에 의해 개시된 쿼리를 참조하는 인터넷 DNS 시스템의 아키텍처에 의해 야기된다. 이것은 요청을 개시한 최종-사용자의 특성을 모호하게 할 수 있다.

본 발명은 TLD DNS 서버들과 같은 권한 있는 명칭 서버들에서 얻어지는 DNS 트래픽 데이터를 사용하는 다양한 메커니즘들을 통해 위의 문제들 대다수를 해결한다. 발명의 여러 측면들에 따라서, 인터넷 전역에 걸쳐 있는 도메인은 공지된 시스템들이 구상하거나 달성하지 못한 방법로 순위될 수 있다. 실시예에서, 몇몇 속성들 및/또는 측정들은 여러 도메인에 대한 TLD DNS 서버와 같은 권한 있는 명칭 서버들에서 파악되고 있고 트래픽 스코어를 계산하기 위해 사용되는 DNS 트래픽으로부터 얻어질 수 있다. 계산된 스코어는 도메인을 순위하기 위해 사용될 수 있다.

발명자들은 DNS 데이터를 의미있고 유용한 형태로 변환하는데 있어 과제는 DNS 데이터의 크기임을 알았다. 레지스트리들은 세계의 서로 다른 부분들에 위치된 몇몇 리졸브 사이트들을 운영할 수 있다. 하나의 레지스트리를 위한 사이트들은 하루에 340억 쿼리에 대해 응답할 수 있다. 이 막대한 수의 쿼리는 데이터 자체를 해석하려 하지만 막대한 과제가 된다. 본원은 전체 데이터량을 더욱 관리가능한 크기로 줄일 수 있는 데이터 집성을 위한 시스템들 및 방법을 제공한다. 이들 방법에 따라서, 트래픽 데이터 그대로를 사용하는 종래의 방법에 의해 달성되었던 것 이상으로 인터넷 상에 의미있는 활동의 더욱 정확한 묘사가 개발될 수 있음이 발견되었다.

개시된 방법은 예를 들면, 하루에 도메인당 몇몇 통계들을 나열할 수 있는 도메인이 요약된 트래픽 정보, 및 DNS 쿼리에 관한 더욱 상세한 정보를 나열할 수 있는 도메인의 상세한 트래픽 정보를 포함하는 서로 다른 집성된 포맷들을 포함할 수 있다. DNS 쿼리 정보의 특히 유용한 예는 쿼리를 발생하는 한 세트의 리졸버의 식별번호들이라는 것을 알게 되었다.

발명의 실시예는 도메인 명칭을 리졸브하라는 요청이 TLD DNS와 같은 권한 있는 명칭 서버에 수신되는, 도메인을 스코어링하기 위한 자동화된 방법을 포함할 수 있다. 수신된 요청에 기초하여, 도메인 명칭에 대해 서버 카운터가 증가될 수 있으며, 도메인 트래픽 스코어는 서버 카운터에 기초하여 계산될 수 있다. 실시예에서, 도메인 트래픽 스코어를 계산하는 단계는 요청하는 한 세트의 리졸버에 관한 정보에 기초하여 서버 카운터에 가중치를 적용하는 단계를 포함할 수 있다.

또한, 실시예는 서버 카운터가 미리 결정된 기간 내에서 하나의 특정한 요청하는 리졸버의 세트에 대해 소정 수의 카운트들로 제한되는 것을 포함할 수 있다. 예를 들면, 한 세트의 리졸버에 대한 카운터는 24 시간마다 한 카운트로 제한될 수도 있다. 실시예는 미리 결정된 기간 후에 카운터를 리셋하는 단계를 포함할 수 있다.

실시예는 도메인 명칭을 리졸브하라는 요청을 권한 있는 명칭 서버가 수신할 때마다 히트 카운터를 증가시키는 단계를 포함할 수 있다. 또한, 도메인 트래픽 스코어를 계산하는 단계는 히트 카운터에 기초할 수도 있다.

실시예는 예를 들면 요청하는 한 세트의 리졸버의 지리적 위치, 요청하는 한 세트의 리졸버의 네트워크 트래픽 레벨, 네트워크 트래픽 유형, 및/또는 요청하는 한 세트의 리졸버의 아키텍처와 같은 다양한 기준들에 기초하는 가중치를 포함할 수 있다.

실시예는 도메인 명칭을 리졸브하라는 요청이 사용자에 의해 개시된 것인지 여부를 판단하는 단계; 및 판단에 기초하여 가중치를 결정하는 단계를 포함할 수 있다.

실시예는 권한 있는 명칭 서버에 의해 서비스되는 다수의 도메인에 대한 도메인 트래픽 스코어를 자동으로 계산하는 단계를 포함할 수 있다. 또한, 다수의 도메인은 도메인 트래픽 스코어에 기초하여 자동으로 순위될 수 있다. 실시예는 미리 결정된 카테고리의 도메인 중 하나의 도메인에 대한 상대적 트래픽 스코어에 기초하여 순위 스코어를 계산하는 단계를 포함할 수 있다. 이것은 도메인의 도메인 트래픽 스코어를 미리 결정된 카테고리의 도메인로부터 다른 도메인 트래픽 스코어를 비교하는 단계를 포함할 수 있다. 계산된 트래픽 및/또는 순위 스코어는 요금 서비스의 부분으로서 자동으로 분배되거나, 광고 요율 등과 같은 다른 항목들을 결정하는데 사용될 수 있다.

실시예는 예를 들면, 광고료, 호스팅 값, 및/또는 도메인의 인기도 레이트와 같은 도메인의 순위에 기초하여 여러 2차적인 값들을 결정하는 단계를 포함할 수 있다. 여기에서 사용되는 바와 같이, 광고료는 도메인에 광고하는 것을 판매를 위해 이에 값을 매기는 요금으로서 이해된다. 광고료는, 예를 들면, 광고 거래를 제의 또는 완료하는 및/또는 도메인 소유자에게 평가액을 제공하는 맥락에서 사용될 수 있다. 여기에서 사용되는 바와 같이, 호스팅 값은 스코어를 매기는 기술된 방법에 기초하여 도메인의 값을 나타내는 계산된 값이다.

호스팅 값은, 예를 들면, 도메인의 판매 및/또는 도메인 소유자에게 도메인의 평가액을 제공하는 것과 같은 거래들에서 사용될 수 있다. 인기도 레이트는 도메인의 인기도를 나타내는 계산된 값이며, 예를 들면, 지리적 인기도, 사용자 유형 인기도, 트래픽 유형 인기도, 등과 같은 다양한 유형들의 인기도를 나타내는 것을 목표로 할 수 있다. 전술한 요소들의 다양한 조합들을 통해서, 광범한 네트워크의 도메인에 대해 다양한 목적들을 위해 사용되는 정확한 레이트 테이블들이 개발될 수 있다. 이것은 TLD 제공자에 기초하거나 이에 의해 후원되는 신뢰성 있고 중앙 광고 요금 서비스, 도메인 재판매 시장, 등에 다른 실체들이 이용하지 못할 수 있는 정보를 제공하는데 있어 유리할 수 있다.

실시예는 서로 다른 카운터들을 사용하여 미리 결정된 기준을 충족시키는 요청들을 카운트하는 것을 포함할 수 있다. 예를 들면, 미리 결정된 포맷을 충족시키는 요청은 특정 카운터에 의해 카운트될 수 있는데, 예를 들면 "www" 스트링을 포함하는 요청들은 "www" 스트링을 포함하지 않는 요청들과는 별도의 카운터로 카운트된다. 실시예에서 한 도메인에 대한 서로 다른 카운터들은 서로 다르게 가중될 수 있는데, 예를 들면, "www" 스트링을 포함하는 요청들의 카운트들은 스코어 계산들에서 www" 스트링을 포함하지 않는 요청들의 카운트와는 다르게 가중될 수 있다.

실시예는 DNS 쿼리에서 요청된 어드레스들의 유형들 간을 구별하는 것을 포함할 수 있다. 예를 들면, 실시예는 개별적으로 정확한(exact) 요청들, "www" 요청들, 및 기타 요청들을 인식할 수 있다. 여기에서 사용되는 바와 같이, 정확한 요청은 특정한 개수의 라벨과 같은 미리 결정된 기준에 부합하는 요청이다. 정확한 요청들은 이를테면 어떠한 프리픽스(prefix)도 없이 요청된 정확한 두 번째 레벨 도메인 명칭과 같이 2개의 라벨을 포함하는 것으로서 실시예에서 확인될 수 있다. 예를 들면, 도메인 "example.com"에 대한 정확한 요청은 "http://example.com/"일 수 있다.

"www" 요청은 문자 스트링 "www"이 프리픽스에 포함되는 요청이다. 예를 들면, "http://www.example.com/", "http://wwwl.example.com/", 및 "http://AAA-www.example.com/"로 나타난 요청은 "www" 요청들로서 인식된다. 여기에서 사용되는 바와 같이, "기타" 요청은 "정확한" 또는 "www" 기준 어느 것도 충족하지 않는 요청이다. 이것은 요청의 부분으로서 다른 프리픽스들을 포함할 수 있다. 예를 들면, "http://jobs.example.com/", "http://mail.example.com/", 및 "http://AAA.BBB.example.com/"은 어떤 대응하는 정확한 일치도 확인되지 않았다면 "기타" 요청들로서 인식될 것이다.

실시예에서, 도메인에 대한 DNS 쿼리에 관한 다음 예시적 속성들이 얻어져 순위를 계산하는데 사용될 수 있다:

ⅰ) WWW 요청 히트. 첫 번째 라벨에 "www"을 가진 DNS 기록들 상에 히트의 카운트; ⅱ) 정확한 요청 히트. 단지 2개의 라벨, 예를 들면 "example.com"만을 가진 DNS 기록들 상에 히트의 카운트; ⅲ) 기타 요청 히트. 위에 어느 카테고리에도 속하지 않는 DNS 기록들 상의 히트의 카운트.

이하 더 설명되는 바와 같이, 실시예는 트래픽 및/또는 순위 스코어를 결정함에 있어 도메인에 대한 각종의 요청 히트에 적합한 가중치를 적용하는 것을 포함할 수 있다.

실시예는 발원 IP 어드레스 및/또는 DNS 쿼리의 한 세트의 리졸버에 관계된 다음의 속성들을 고려하고, 순위를 계산하기 위해 이들을 사용하는 것을 포함할 수 있다:

WWW 서버 카운트. 첫 번째 라벨에 "www"에 DNS 기록이 일치하는 고유한 하향 IP 어드레스들 또는 한 세트의 리졸버의 카운트.

정확한 서버 카운트. 단지 두 라벨에 DNS 기록이 일치하는 고유한 하향 IP 어드레스들 또는 한 세트의 리졸버의 카운트.

기타 서버 카운트. 위에 어느 카테고리에도 속하지 않는 DNS 기록들에 일치하는 고유한 하향 어드레스들 또는 한 세트의 리졸버의 카운트.

이하 더 설명되는 바와 같이 실시예는 트래픽 및/또는 순위 스코어를 결정함에 있어, 도메인에 대한 각종의 서버 카운트들에, 적합한 가중치들을 적용하는 것을 포함할 수 있다.

실시예는 도메인에 대한 DNS 기록들의 TTL에 기초하여 트래픽 및/또는 순위 스코어를 계산하는 것을 포함할 수 있다.

본 발명의 다른 장점들은 바람직한 실시예의 다음 상세한 설명을 읽고 이해했을 때 당업자들에게 명백하게 될 것이다.

도 1은 본 발명의 일 실시예에 따른 예시적인 시스템 및 관계된 네트워크를 도시한 것이다.
도 2는 본 발명의 일 실시예에 따른 예시적인 시스템 및 관계된 네트워크를 도시한 것이다.
도 3은 본 발명의 일 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 4는 본 발명의 일 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 5는 본 발명의 일 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 6은 본 발명의 일 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 7은 본 발명의 일 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 8은 본 발명의 일 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 9는 본 발명의 일 실시예에 따른 예시적인 시스템 및 관계된 네트워크를 도시한 것이다.
도 10은 도메인 트래픽 크기와 "기타" 타겟들로 가는 트래픽의 퍼센티지 간에 관계를 반영하는 차트를 도시한 것이다.
도 11은 도메인 트래픽 크기와 "WWW" 및 "정확한" 타겟들로 가는 트래픽의 퍼센티지 간에 관계를 반영하는 차트를 도시한 것이다.
도 12는 발명의 측면들에 따라 그룹화된 도메인의 수를 반영한 차트를 도시한 것이다.

다음 상세한 설명은 설명 및 이해를 쉽게 하기 위해 예시적 실시예에 관련하여 제공된다. 출원인의 발명은 개시된 실시예로 제한되지 않으며, 여기에 제공된 설명의 전체 범위 내에 속하는 다른 변형예들을 포함한다.

전술한 바와 같이, 본 발명의 실시예는 도 1에 도시된 인터넷 환경과 같은 네트워크 상에서의 동작들을 포함할 수 있다. 클라이언트 계산장치(110)는 재귀적 명칭 서버(130)에 DNS 요청(103)을 개시할 수 있다. 도 1에 제안된 바와 같이, DNS 요청들(103)은 모바일 디바이스(120), 무선 계산장치(122), 그외 통신 링크(124), 및/또는 중간 네트워크 서버들(126)과 같은 다양한 소스들로부터 비롯되거나 재귀적 명칭 서버(130)에 송신될 수 있다. 도메인 명칭을 리졸브하라는 DNS 요청은 전형적으로 마침점들에 의해 분리된 n 라벨을 갖는다. 이들 라벨은 일반적으로 희망하는 인터넷 자원, 예를 들면 웹 페이지에 대한 숫자로 된 IP 어드레스보다는 기억하기 쉬운 어떤 형태로 되어 있다.

설명의 편의를 위해서, 맨 왼쪽에 라벨은 첫 번째 라벨로 간주될 수 있고 TLD은 제 n 라벨이다. 따라서, "www.example.com"에 대한 요청에서, n = 3이며, 첫 번째 라벨은 "www"가 될 것이며 TLD는 ".com"이 될 것이다. 위에 기술된 바와 같이, 재귀적 명칭 서버(130)는 DNS 요청을 재귀적 명칭 리졸브의 부분으로서 여러 권한 있는 서버들(140, 150, 160)에 송신할 수 있다. 대안적으로, 요청된 DNS 정보는 DNS 기록의 TTL이 적용되는 재귀적 명칭 서버(130)의 캐시 내에 넣어둘 수 있는데, 이 경우, 쿼리는 권한 있는 명칭 서버들(140, 150, 160)을 참조함이 없이 응답될 수 있다.

도 2는 재귀적 명칭 서버(220) 및 이것이 권한 있는 명칭 서버들(230, 240, 250)과 상호작용하는 것을 더 상세히 도시한 것이다. 도 2에서, 권한 있는 서버들(230)은 루트 레벨 권한 있는 서버들이다. 이들 서버들 각각은 인터넷 상에 특정 TLD들에 대한 정보를 내포한다. 루트 레벨 서버들은 이들의 TLD 내에서 도메인에 대한 요청들을 이 TLD 레지스트리에 의해 관리되는 다른 권한 있는 서버들에 보낼 수 있다.

예를 들면, 클라이언트(210)로부터 DNS 요청(202)은 "www.example.com"에 대한 요청을 포함할 수 있다. 재귀적 명칭 서버(220)는 먼저 대응하는 DNS 기록에 대해 내부 캐시를 체크할 수 있다. 발견되는 것이 없다면, DNS 요청은 203에서 루트 레벨 권한 있는 명칭 서버들(230)에 보내질 수 있다. 서버들(230) 가운데 ".com"을 담당하는 권한 있는 루트 레벨 서버는 요청자를 권한 있는 명칭 서버들(240)에 보내는 "example.com"에 대한 DNS 정보를 보낼줄 수 있는데, 이 경우, 이들 서버들은 ".com"의 레지스트리에 대한 일단의 서버들을 나타낸다. 여기에 기술된 바와 같이, DNS 요청들, 예를 들면, 203, 204, 205는 여러 권한 있는 서버들, 예를 들면 230, 240, 250에서 카운트될 수 있다.

실시예에서, 카운트하는 것은 예를 들면, 230과 같은 TLD 명칭 서버에서 행해질 수 있다. 다른 권한 있는 명칭 서버들(240, 250)은 각각의 서버에 의해 취급되는 기록들에 대한 DNS 히트들을 카운트할 수도 있다. 실시예는 조합된 순위에 도달하기 위해서 여러 서버들, 및/또는 TLD들, 예를 들면 ".com.", ".net", ".edu", ".uk"로부터 스코어를 조합하는 것을 포함할 수 있다.

실시예에서, 주어진 카운터로 요청을 카운트할지 하지 않을지에 대해 판정이 행해질 수 있다. 예를 들면, "서버 카운터"와 같은 어떤 카운터들은 미리 결정된 기간당 단일 카운트로 제한될 수 있다.

도 3에 도시된 바와 같이, 요청이 S3100에서 수신될 수 있다. 관계된 히트 카운터가 S3200에서 증가(increment)될 수 있다. S3300에서 서버 카운터를 증가시킬지에 대해 판정이 행해질 수 있다. 이 예에서, 서버 카운터의 현재 카운트는 미리 결정된 값 "X"와 비교될 수 있다. 서버 카운트가 X보다 크거나 같다면, 서버 카운터를 다시 증가시킬지에 대한 판정이 행해지고 방법은 S3500로 갈 수 있다. 서버 카운트가 X 미만이라면, 방법은 서버 카운터가 증가되는 S3400로 진행한다. 서버 카운트는 미리 결정된 기간 후에 자동으로 리셋될 수 있다. 서버 카운터 맥락에서 기술되었을지라도, 특정한 IP 어드레스, 한 세트의 리졸버, 등에 연관된 카운터들과 같이 다른 카운터들이 유사한 방식으로 제한될 수 있다.

이하 더욱 기술되는 바와 같이, 어떤 카운터들의 카운트를 제한하는 것은 의미있는 인터넷 활동들의 더 정확한 묘사를 개발하기 위해 사용될 수 있다. 이들 제한된 카운터들은 전체 웹 트래픽의 관리가능하고 정확한 표현을 사용자들에게 제공하기 위해 단독으로 혹은 히트 카운터들과 조합하여 고려될 수 있다. 예를 들면, 제한된 카운터를 사용하는 것은 특정 서버, 한 세트의 리졸버, IP 어드레스, 등으로부터 비롯될 할 수 있는 인위적인 혹은 신뢰할 수 없는 트래픽 표시자들이 미치는 원하지 않는 영향을 감소시킬 수 있다.

S3500에서, 요청에 연관된 한 세트의 리졸버가 결정될 수 있다. 도면들에 용이하게 도시하기 위해서, 예시적인 한 세트의 리졸버를 서브네트라 칭할 수도 있다. 그러나, 여기에선 논하는 바와 같이, 다수 세트들의 리졸버에 관계된 특징들은 서브네트들 자체로 제한되지 않으며, 예를 들면, 어드레스, 지리적, 조직적, 및 유형, 및 이들의 조합들과 같은 다양한 연관들을 나타낼 수 있는 그외 다른 다수 세트의 리졸버를 포함할 수 있다.

실시예에서, S3300에서 서버 카운터를 증가시킬지 여부를 판정하기에 앞서, 이를테면 평가될 적합한 카운터를 확인하기 위한 판정이 행해질 수 있다. S3500에서, 한 세트의 리졸버에 관계된 데이터가 판정되고 및/또는 액세스될 수 있다. 예를 들면, 이하 더욱 논의되는 바와 같이, 한 세트의 리졸버에 대한 위치, 트래픽 레벨, 트래픽 유형 등에 관계된 데이터가 판정되고, 계산되고 및/또는 액세스될 수 있다.

실시예에서, 특정하게 확인된 요청하는 서버에 관한 정보는 예를 들면, 확인된 서버가 상당한 비-사용자 트래픽을 발생하는 웹 크롤러들, 등에 의해 이용되는 것으로 알려지게 된다면, 적합한 가중치를 적용하기 위해 사용될 수 있다. 이러한 서버들의 목록이 적합한 가중치들과 함께 혹은 없이 데이터베이스에 저장될 수 있다. 이에 따라, 사실상 데이터-위주인 것으로 보이거나, 이것인 것으로 입증되는 요청 서버들은 도메인 스코어링에서 페널티가 가해질 수 있다. 방법은 S3700에서 계속된다.

S3700에서, 한 세트의 리졸버에 대한 가중치(weighting factor; WF)가 결정된다. 이 결정은 S3600에서 결정된 바와 같은 각종 데이터에 기초할 수 있고, S3900에서 도메인에 대한 스코어를 계산하는데 적용될 수 있다.

S3800에서, 요청이 사용자 발생 트래픽을 나타내는지 판정하기 위해 요청이 평가될 수 있다. 이 판정은 이를테면, 예를 들어 정보가 포함된 요청, 한 세트의 발원 리졸버에 관한 정보, 서브네트 아키텍처 등과 같은 여러 요소들에 기초할 수 있다. 이러한 판정을 행하는 방법을 이하 더 기술한다. S3800이 요청이 사용자 발생 트래픽에 관계된 것일 수 있음을 나타낸다면, S3900에서 사용자 가중치가 결정될 수 있다. 실시예에서, 사용자 발생 트래픽에는 원인을 모르는 트래픽, 혹은 기계에서 발생된 것일 수 있는 트래픽과 같은 다른 트래픽보다 높은 WF가 주어질 수 있다. 실시예에서, 사용자 발생 트래픽만이 WF = 1을 적용함으로써 고려될 수 있고 그외 모든 트래픽은 WF = O을 적용함으로써 무시될 수 있다.

도 4에 관련하여, 예시적인 방법은 예를 들면 도 3에서 S3500과 유사한 방법으로, 수신된 요청에 연관된 S1500에서 한 세트의 리졸버를 결정하는 단계를 포함할 수 있다. 이 유형의 정보는 전형적으로, 권한 있는 서버로부터 요청되는 도메인 어드레스 정보에 대한 리턴 어드레스 정보를 제공하기 위해서 이 수신된 요청에 대해 권한 있는 서버가 사용할 수 있다. 방법은 S4510에서 계속될 수 있다.

S4510에서, 한 세트의 리졸버의 위치를 판정하기 위해 요청이 평가될 수 있다. 발명자들은 리졸브하는 서버의 국가와 같은 발원 위치는 이의 쿼리 배후에 사용자들의 수를 나타냄에 있어 의미를 갖는다는 것을 발견하였다. 이것은 인터넷이 맹렬히 개발되는 일부 국가들에서, 이외 다른 개발도상국들에서보다 인터넷 사용자당 더 많은 리졸버가 있다는 사실을 포함한, 다양한 요소들에 기인한다. 이들 수는 반드시 정적인 것은 아니며 훨씬 더 가치있는 정보를 제공하려는 계속되는 과정에서 정제될 수 있다.

표 1에 나타낸 바와 같이, 서로 다른 지리적 지역들 내 한 세트의 리졸버당 사용자들의 수에 관한 데이터는 서브네트들과 같은 여러 다수 세트들의 리졸버로부터 개별적 요청들에 의해 나타난 트래픽 스코어를 유리하게 추정하는데 사용될 수 있다.

국가	사용자	총 서브네트	소 서브네트	소 서브네트 비율	서브네트당 사용자
국가 A	34,820,000	22,482	4,320	19%	1,917
국가 B	34,708,144	35,203	9,129	26%	1,331
국가 C	32,700,000	30,931	5,444	18%	1,283
국가 D	28,000,000	30,070	8,312	28%	1,287
국가 E	26,500,000	17,958	1,197	7%	1,581

실시예에서 한 세트의 리졸버 당 사용자들의 수는 예를 들면 발원 국가에 따라, S4700에서 한 세트의 리졸버에 대해 결정된 가중치(WF)에 대한 베이시스(basis)로서 사용될 수 있다. 이들 값들을 모르거나 달라질 수 있는 상황들에서, 메트릭(metric)의 영향은 비-선형 함수를 사용함으로써 감소될 수 있다. 예를 들면, 3차식의 근은 범위와 입도(granularity) 간에 균형을 맞추는데 있어 양호한 결과들을 달성한다는 것이 발명자들에 의해 판정되었다. 이 스케일은 약 10의 최대/최소 비가 얻어지게 하는 것으로 발견되었다. 주어진 국가에 관한 정보, 한 세트의 리졸버 및 국가 내에 사용자들, 및/또는 관계된 전체 국가들은 유리하게 조합될 수 있다. 예를 들면, 실시예에서, 위에서 지리적 정보의 조합들은 이를테면 다음 식에 의해 도메인 트래픽을 계산할 때 사용될 수 있다:

d - 도메인

C - 관련 국가

W/E/Oc - 도메인 d를 참조하는 국가 c로부터의 W/E/O 서브네트

Weightc - 국가 c의 가중치

UniqueW/E/Oc - 국가 c로부터 고유한 W/E/O 서브네트

n/me/mo - 휴리스틱(heuristic) 기반의 변수

도메인 스코어를 계산함에 있어 이러한 식들을 사용함으로써, 발명자들은 특히 미국인 외의 사용자들에 의해 더 상당히 자주 방문되는 도메인에 대해 트래픽량의 더 정확한 추정이 달성될 수 있음을 발견하였다. 즉, 지리적 지역에 따라 한 세트의 리졸버를 개별적으로 가중함으로써, 도메인의 전역적인 인기의 더 정확한 표현이 달성될 수 있다. 또한, 주어진 고객에 대한 도메인의 광고 및 가치 측면에서, 다소간에 어떤 지리적으로 기반을 둔 트래픽을 가중하기 위해 인기도 계산을 정제하는 것이 바람직할 수 있다. 예를 들면, 어떤 제품 또는 서비스에 대해 광고주들은 지리적 지역, 또는 대중문화, 언어, 등 내에서 도메인의 상대적 인기도에 관심이 있을 수 있다.

이들 경우들에 있어서, 본 발명의 실시예는 이를테면 고객에게 덜 중요한 국가들/지역들 이상으로 어떤 관심 국가들/지역들에 대한 가중치들을 조절함으로써, 고객에게 중요한 트래픽을 반영하는 스코어를 계산하는 메커니즘들을 제공한다. 이러한 방법은 고객으로부터 예를 들면, 지리적 지역과 같은 기준을 수신하는 단계, 사용자가 정의한 기준에 기초하여 도메인에 대한 스코어 및/또는 순위들을 계산하는 단계, 및 수정된 스코어링의 결과들을 고객에게 보고하는 단계를 포함할 수 있다. 상기 요소들은 겨냥하는 대상, 예를 들면 전역적인 혹은 국부적인 대상에 따라 도메인을 스코어링하는데 있어 개선된 융통성을 제공한다. 따라서, 본 발명의 특징들은 도메인 트래픽에 대한 스코어링을 개선하고 정제하기 위해 고객에 특정한 정보와 함께 권한 있는 명칭 서버들에 의해 수신된 한 세트의 리졸버 정보를 활용할 수 있다.

도 4에 도시된 바와 같이, 서브네트 WF를 결정하는 부분으로서, 실시예는 S4520에서 한 세트의 리졸버의 트래픽량(traffic volume; TV)을 판정하는 단계를 포함할 수 있다. 여러 다수 세트들의 리졸버에 대한 트래픽량들은 인터넷에 걸쳐 크게 변할 수 있고, 주어진 시간 내에 한 세트의 리졸버에 의해 발행된 쿼리 수와 같은 트래픽량은 한 세트의 리졸버에 대한 WF를 추정하기 위해 사용될 수 있음이 발견되었다.

예를 들면, 리졸버 IP 어드레스들 중 약 40%가 하루에 또는 하루 이내에 10 DNS를 발생함이 발견되었다. 이 낮은-레벨의 TV는 하루당 상당량의 쿼리를 발생하는 리졸버에 비해, 대응하는 적은 수의 사용자들을 추론하기 위해 사용될 수 있다. 즉, 하루당 적은 수의 전체 쿼리를 갖는 한 세트의 리졸버는 권한 있는 서버에서 수신되는 요청의 상대적 중요도를 가중할 목적으로 취해질 수 있는, 리졸버 레벨에서 낮은 레벨의 전체 트래픽을 갖는 적은 수의 사용자들을 나타낼 수 있다.

또한, 하루당 매우 적은 수의 도메인(즉, 적은 수의 세트의 리졸버)을 참조하며 수 및 퍼센티지가 가변되는 DNS 리졸버가 있다. 발명자들은 어떤 실시예에서, 하루에 많은 수의 도메인에 대한 쿼리를 발행하는 한 세트의 리졸버, 예를 들면 하루에 수백만 도메인을 참조하는 세트의 리졸버과는 달리 매우 적은 수의 도메인에 대한 쿼리를 발행하는 한 세트의 리졸버에 대한 카운터들을 가중하는 것이 유용한 것임이 발견되었다. 이러한 유형의 다수 세트들의 리졸버의 특징은 예를 들면, S4530에서, 트래픽 유형(traffic type; TT) 판정으로서 결정될 수 있다. 트래픽 유형은 여기에서 논하는 바와 같이, 사용자 발생 트래픽에 관심있는 광고, 등의 목적을 위해 도메인의 스코어 및 순위를 계산하는데 있어 유리하게 사용될 수 있는 것으로서, 기계 발생 트래픽에 대해 사용자 발생 트래픽의 존재를 추론하는데 유용할 수 있는 한 세트의 리졸버에 의해 발생되는 트래픽의 다른 측면들을 포함할 수 있다.

본 발명의 특징은 도메인 트래픽에 대한 스코어링을 개선하고 정제하기 위해, 요청하는 한 세트의 리졸버에 관한 메트릭과 함께 권한 있는 명칭 서버들에 의해 수신된 정보를 활용할 수 있다.

도 5에 도시된 바와 같이, 본 발명의 실시예는 한 세트의 리졸버의 아키텍처의 특징들에 기초하여 한 세트의 리졸버의 가중치를 조절할 수도 있다. 이것은 예를 들면, DNS 클라이언트들이 주 및 2차 DNS 서버들로 구성되는 경우와 같은 상황들에서 유리할 수 있다. 이러한 상황들에서, 주 및 2차 서버들과 같은 다수의 서버들을 위한 서로 다른 IP 어드레스들은 공통 사용자 기반을 나타낼 수 있다.

그러나 각각의 IP 어드레스 및 서버는 특정 서버에 의해 취급되는 트래픽의 상대적 퍼센티지에 기초하여 다른 서버들에 관하여 사용자 활동의 서로 같지 않은 레벨들을 나타낼 수 있다. DNS 클라이언트의 다수의 서버들에 대한 각각의 퍼센티지들은 권한 있는 명칭 서버 레벨에서 트래픽 정보를 모니터링함으로써 발견될 수 있다는 것과, 이 결정에 기초하여 적합한 가중치가 적용될 수 있다는 것이 발견되었다.

예를 들면, 도 5에 도시된 바와 같이, 한 세트의 리졸버는 예를 들면 도 3에서 S3500과 유사한 방법으로, S5500에서 결정될 수 있다. S5600에서, 한 세트의 리졸버에 대한 용장성 서버들(redundant servers)을 위한 다른 고유 IP 어드레스들이 있는지 여부를 판정하는 것과 같이, 한 세트의 리졸버의 아키텍처의 특징들이 판정될 수 있다. S5620에서, 한 세트의 리졸버의 아키텍처는 예를 들면, 한 세트의 리졸버에 대한 IP 어드레스들 간에 용장성이 있는지와 같은 미리 결정된 기준을 충족시키는지 여부를 판정하기 위해 평가될 수 있다. S5620에서 긍정의 결과의 경우에, 방법은 아키텍처에 따른 가중치가 할당될 수 있는 S5640로 계속될 수 있다. 실시예에서, 아키텍처에 따른 WF는 한 세트의 리졸버의 특정 IP 어드레스에 의해 취급되는 트래픽의 퍼센티지에 기초할 수 있다.

예를 들면, n 리졸버를 가진 한 세트의 리졸버의 정황에서, 각각의 서버마다 트래픽 퍼센티지가 판정된 상태에서, 예를 들면, 다음 식이 적용될 수 있는데, 이 식에서 한 세트의 리졸버에 대한 스코어는 개개의 리졸버의 스코어에 대한 각각의 퍼센티지들에 기초하여 가중치들을 적용하는 한 세트의 리졸버 내에서, 개개의 IP 어드레스들과 같은, 개개의 리졸버에 대한 신중한 계산에 기초할 수 있다.

SR1w1 + SR2w1 + SRnwn

여기서:

SR1은 첫 번째 리졸버로부터의 스코어이며,

SR2은 두 번째 리졸버로부터의 스코어이며,

w는 각각의 리졸버에 대한 고유한 가중치이다.

일단 아키텍처에 따른 WF가 결정되거나, S5620에서 부정의 결과의 경우에, 방법은 S5700에서 한 세트의 리졸버에 대한 전체 WF를 결정하는 것으로 계속될 수 있다. 이에 따라, 주어진 한 세트의 리졸버에 대해 개별적 IP 어드레스들이 있는 상황들에서, 서로 다른 IP 어드레스들은 서로 다른 카운터들에 의해 카운트될 수 있고, 개별적 가중치들이 서로 다른 카운터들에 적용될 수 있다.

도 5를 더 참조하면, 한 세트의 리졸버의 아키텍처 WF를 적용하는 추가의 예는 주어진 한 세트의 리졸버에 대해 추가의 네트워크 실체들을 개별적으로 카운트하는 것을 포함할 수 있다. 한 세트의 리졸버의 아키텍처의 정황에서, 다음 실체들이 개별적으로 평가될 수 있다:

자치적 시스템 번호(Autonomous system number; ASN) - 대학 또는 비즈니스와 같은 단일 관리적 실체에 의해 관리되는 단일 네트워크 혹은 일 그룹의 네트워크들에 할당되는 전역적으로 고유한 번호.

두 번째 레벨 도메인(Second level domain; SLD) - 도메인(예를 들면 verisign.com에서 "verisign")의 두 번째 부분. 이것은 일반적으로 ISP에 연관된다.

기관(ORG) - IP를 이용하는 기관.

이들 실체들 및 이들의 대응하는 한 세트의 리졸버 간에 관계를 조사함으로써, 발명자들은, 상황들에서, ASN이 가장 집합적이고 그 다음으로 집합성 레벨이 서로 유사한 SLD 및 ORG가 집합적임을 발견하였다. 즉, ASN 실체는 더 많은 수의 한 세트의 리졸버가 나타나게 하고, 다음으로 SLD 및 ORG 실체들이 이와 같이 되게 할 수 있다. 실시예에서, 서로 다른 카운터들은 한 세트의 리졸버로부터 도출되는 서로 구별되는 ASN(들), SLD(들), 및/또는 ORG(들)에 따라 증가될 수 있다.

도 5에 도시된 바와 같이, 이것은 S5600 ~ S5620에서 관계된 ASN, SLD, 및/또는 ORG를 결정하는 단계, 및 각각의 한 세트의 리졸버의 ASN, SLD, 및/또는 ORG 카운터에 대해 한 주어진 카운터에 S5640에서 적합한 아키텍처에 따른 WF를 적용하는 단계를 포함할 수 있다. 한 세트의 리졸버 내에 개개의 실체들에 대해 서로 다른 가중치들을 사용함으로써, DNS 트래픽 정보에 기초한 도메인 스코어를 계산함에 있어 개선된 예측 모델들이 만들어질 수 있음이 발견되었다. 예를 들면, ASN으로부터 트래픽은 도메인 스코어를 계산함에 있어 SLD 및/또는 ORG 카운터들에 관하여 더 중하게 가중될 수 있다. 예를 들면, 평균, 또는 그외 정규화 계산이 다음 식으로부터 취해질 수 있다:

SASNw1 + SSLDw2 + SORGw3 + SSUBw4,

여기서:

SASN은 ASN에 기초한 스코어이다.

SLD는 SLD에 기초한 스코어이다.

SORG ORG에 기초한 스코어이다.

SSUB는 서브네트에 기초한 스코어이다.

w는 각각의 스코어에 대한 고유한 가중치이다.

도 6을 참조하면, 예시된 방법은 예를 들면 도 3에서 S3300과 유사한 방법으로, S6000에서 카운터가 수신된 요청에 관하여 증가되어야 할지를 판정하는 단계를 포함할 수 있다. 위에서 상세히 한 바와 같이, 일부 실시예에서, 히트 카운터는 도메인에 대한 수신된 DNS 요청들에 대해 증가될 수도 있다. 어떤 경우들에 있어서, 제한된 카운터는 증가되지 않을 것으로 결정될 수도 있다. 관련 카운터가 증가될 경우에, 방법은 S6100로 진행할 수 있다.

S6100에서, 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하는지 여부를 판정하기 위해 요청이 평가될 수 있다. 스트링은 "www.example.com"의 경우와 같이, 혹은 "www1.example.com"과 같이 다른 문자들로 네스트된 경우와 같이, 요청된 어드레스의 독립된 부분일 수도 있다. 첫 번째 라벨이 스트링 "www"를 포함하는 것으로 판정된다면, 방법은 S6200으로 진행하여, 도메인 명칭에 대한 www 카운터와 같은 카운터 "A"가 증가될 수 있다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지 않는다면, 방법은 S6300로 진행할 수 있다.

S6300에서, 도메인 명칭에 대한 기타 카운터와 같은 카운터 "B"가 증가될 수 있다. 기타 요청들, 즉, 전술한 카테고리들 중 어느 것도 충족시키지 않는 요청들을 카운트하는 것이 요구되지 않을지라도, 기타 카운터는 검출된 트래픽의 중요성을 평가하는데 있어 장점들을 제공할 수 있다. 예를 들면, 기타 카운터는 사람 상호작용에 의해 명백하게 구동되는 트래픽의 퍼센티지를 판정하기 위해 www 카운터와 비교하여 사용될 수 있다.

S6210 및/또는 S6310에서, 가중치가 결정될 수 있고, 및/또는 각각 카운터들 A 및/또는 B에 할당될 수 있다. 가중치들은 도메인에 대한 카운터들 모두에 혹은 그 미만에 적용될 수 있다. 가중치를 할당하는 것은 카운터의 특성에 관계된 몇가지 요소들 및 도메인에 관하여 수집된 다른 정보에 기초할 수 있다. 가중치들은 또한 동적으로 적용될 수도 있다. 예를 들면, 시간에 따라, 도메인에 대한 서로 다른 카운터들의 카운트들은 변할 수 있고 혹은 도메인에 관하여 정보가 전개될 수도 있다. 이것은 도메인에 대한 카운터들에 적용되는 가중치들 중 하나 이상의 변경을 촉발시킬 수 있다. 방법은 S6900에서 계속될 수 있다.

S6900에서 트래픽 스코어와 같은 스코어가 도메인에 대해 계산될 수 있다. 트래픽 스코어는 다수의 카운터들에 기초할 수 있다. 모든 관계된 카운터들로부터의 카운트들을 사용할 필요는 없음에 유의한다. 스코어는 임의의 관계된 가중치들이 고려된 상태에서, 하나, 둘 이상의 카운트들에 기초하여 계산될 수 있다. 따라서, 도메인 트래픽 스코어는 다수의 카운터들에 기초하여 계산될 수 있고, 카운터들 중 적어도 하나에 가중치를 적용하는 것을 포함할 수 있다.

도 7에 관련하여 예시적 방법은 예를 들면 도 3에 S3300과 유사한 방법으로, S7000에서 수신된 요청에 관하여 카운터를 증가시켜야 할지를 판정하는 단계를 포함할 수 있다. 위에서 상세히 한 바와 같이, 일부 실시예에서, 도메인에 대한 수신된 DNS 요청들에 대해 히트 카운터가 증가될 수 있다. 어떤 경우들에 있어서, 제한된 카운터는 증가되지 않을 것으로 판정될 수도 있다. 관련 카운터가 증가될 것 경우엔, 방법은 S7100으로 갈 수 있다.

S7100에서 요청은 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하는지 여부를 판정하기 위해 평가될 수 있다. 스트링은 "www.example.com"의 경우와 같이, 혹은 "www1.example.com"와 같이 다른 문자들로 네스트된 경우와 같이, 요청된 어드레스의 독립된 부분일 수도 있다. 첫 번째 라벨이 스트링 "www"를 포함하는 것으로 판정된다면, 방법은 S7200으로 진행하여, 도메인 명칭에 대한 www 카운터와 같은 카운터 "A"가 증가될 수 있다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지 않는다면, 방법은 S7300로 진행할 수 있다.

S7300에서 라벨이 미리 결정된 조건 "R(r)"을 만족하는지 여부를 판정하기 위해 요청이 평가될 수 있다. R(r)은 소정 수의 라벨, 명시된 스트링, 혹은 DNS 요청의 그외 다른 특징들을 포함하는 많은 형태들을 취할 수 있다. 다수의 라벨을 지정하는 경우에, 기술된 실시예는 R(2) = 두 라벨인 경우를 포함한다. 수신된 도메인 명칭이 라벨의 미리 결정된 수 R(2)만을 갖는다면, 예를 들면 "example.com"에서 2개의 라벨만을 갖는다면, 방법은 S7400으로 진행하여, 도메인 명칭에 대해 2-라벨 "정확한" 카운터 B(2)와 같은 카운터 B(r)이 증가된다. 요청이 라벨의 설계된 개수 R만을 갖지 않는다면, 예를 들면 라벨의 미리 결정된 수 R이 2일 때 2 이상의 라벨을 갖는다면, 방법은 S7310으로 진행할 수 있다. 실시예는 다수의 B 카운터들, 예를 들면 다수의 정확한 카운터들을 포함할 수 있다. 이들은, 예를 들면, R(r)에 대한 여러 개수들에 대해 개별적 카운터들, 혹은 도메인 스트링들의 정확한 부분들에 대해 "정확한" 카운터들의 다른 버전들을 포함할 수 있다. 예로서, 추가의 카운터 B(3)은 R = 3인 "mail.example.com"에 대한 요청에 응하여 증가될 수 있다. 또 다른 예로서, 한 특정한 스트링, 예를 들면 "mail"을 가진 요청들은 요청이 스트링, 예를 들면 "mail5.example.com"을 내포할 때, 카운터 B("mail")에 의해 카운트될 수 있다. 이것은 S7310에서 추가의 정확한 카운터들 B(r)이 구현되고 있는지 여부를 판정함으로써 구현될 수 있다. 다른 정확한 카운터들이 있다면, 방법은 카운터 B(r)에 대한 새로운 값으로 R(r)이 리셋되는 S7320으로 진행할 수 있다. R(r)이 리셋된 후에, 방법은 다시 S7300으로 계속되어 요청들이 새로운 기준 R(r)을 만족하는지를 판정할 수 있다. S7300, S7310 및 S7320은 R(r)이 만족될 때까지, 혹은 남아있는 정확한 카운터들이 없을 때까지 반복될 수 있다. 남아있는 정확한 카운터들이 없다면, 방법은 S7500로 진행할 수 있다.

S7500에서, 도메인 명칭에 대한 기타 카운터와 같은 카운터 "C"가 증가될 수 있다. 기타 요청들, 즉, 전술한 카테고리들 중 어느 것도 충족시키지 않는 요청들을 카운트할 필요가 없을지라도, 기타 카운터는 검출된 트래픽의 중요성을 평가하는데 장점들을 제공할 수 있다. 예를 들면, 기타 카운터는 사람 상호작용에 의해 명백하게 구동되는 트래픽의 퍼센티지를 판정하기 위해 www 카운터 및 정확한 카운터(들)와 비교하여 사용될 수 있다.

S7210, S7410, 및/또는 S7510에서, 가중치는 결정되고 및/또는 각각 카운터들 A, B(r) 및/또는 C에 할당될 수 있다. 가중치들은 도메인에 대한 카운터들 모두에 혹은 그 미만에 적용될 수 있다. 예를 들면, 가중치는 도메인에 대한 하나, 둘, 또는 모든 카운터들에 적용될 수 있다. 가중치를 할당하는 것은 카운터의 특성에 관계된 몇가지 요소들 및 도메인에 관하여 수집된 다른 정보에 기초할 수 있다. 가중치들은 또한 동적으로 적용될 수도 있다. 예를 들면, 시간에 따라, 도메인에 대한 서로 다른 카운터들의 카운트들은 변할 수 있고 혹은 도메인에 관하여 정보가 전개될 수도 있다. 이것은 도메인에 대한 카운터들에 적용되는 가중치들 중 하나 이상의 변경을 촉발시킬 수 있다. 방법은 S7900에서 계속될 수 있다.

S7900에서 트래픽 스코어와 같은 스코어가 도메인에 대해 계산될 수 있다. 트래픽 스코어는 다수의 카운터들에 기초할 수 있다. 모든 관계된 카운터들로부터의 카운트들을 사용할 필요는 없음에 유의한다. 스코어는 임의의 관계된 가중치들이 고려된 상태에서, 하나, 둘 또는 그 이상의 카운트들에 기초하여 계산될 수 있다. 따라서, 도메인 트래픽 스코어는 다수의 카운터들에 기초하여 계산될 수 있고, 카운터들 중 적어도 하나에 가중치를 적용하는 것을 포함할 수 있다.

앞에서 언급한 바와 같이, 재귀적 명칭 서버가 DNS 쿼리에 대한 응답을 얻었을 때, 이를 차후에 사용하기 위해 캐시해 둘 수 있다. 각각의 응답이 캐시에 저장되는 시간은 TTL에 기초한다. 발명자들은 도메인을 타겟으로 한 총 쿼리 수에 의해 도메인의 트래픽을 측정하는 것은 캐시 기능 및 DNS 기록에 대한 TTL에 근거하여 부정확성들을 가질 수 있음을 관찰하였다. 캐시 기능을 보상하는 것은 각각의 도메인/리졸버가 이의 TTL을 다르게 관리할 수도 있다는 사실에 근거하여 대규모 구현들에 있어선 특히 어려울 수 있다. 예를 들면, 리졸버는 이의 캐시를 매 6 시간마다 리프레시할 수 있고, 또 다른 리졸버는 이의 캐시를 매 12 시간마다 리프레시할 수도 있다. 두 리졸버가 하나의 주어진 도메인에 대해 정확한 횟수만큼 요청을 받을지라도, 개략적으로 말하여, 첫 번째 리졸버는 두 번째 리졸버에 비해서, 두 리졸버가 동일한 량의 사용자-발생 트래픽을 도메인에 나타내고 있더라도, 이 도메인에 대한 DNS 체인에서 쿼리 트래픽량에 두 배를 발생할 것으로 예상될 것이다. 발명자들은 이 문제를 해결하기 위해 몇가지 특징들을 개발하였다.

첫 번째 예로서, 가중 스코어는 DNS 파일에 대한 TTL에 기초하여 결정될 수 있다. 이것은 실제로 서버에 보내지는 요청들만을 보는, 권한 있는 명칭 서버들에 링크된 히트 카운터들의 한계를 어느 정도 보상할 수 있다. 서버에 보내지는 요청들의 수에 기초하여, TTL에 기초한 가중치는 도메인에 보내지고 있는 총 그래픽의 추청치를 계산하기 위해 사용될 수 있다. 일반적으로, 상대적으로 긴 TTL을 가진 사이트들에 있어 트래픽은 짧은 TTL들을 가진 것들보다 큰 가중치를 받을 수 있다. 가중치들은 스코어/순위된 도메인 간의 TTL들의 비에 기초하여 설정될 수 있다.

여기에서 논의되는 바와 같이, 개시된 방법은 각각의 개개의 리졸버의 TTL 및 캐시 정책에 잡음 및 의존성을 덜 야기하는 것으로 발견된, 서로 구별되는 쿼리하는 IP 어드레스들, 한 세트의 리졸버, 등의 수를 관찰하는 것에 관한 것이다. 이 접근 방법은 방대한 량의 전체 트래픽을 볼 수 있는 TDL 및 그외 권한 있는 명칭 서버들의 레벨에서 트래픽을 관찰하는 분야에서 특히 유용할 수 있는 것으로 발견되었다. 고유하게 쿼리하는 IP 어드레스들, 한 세트의 리졸버, 등의 메트릭은 총 히트 카운터들에 의해 수신되는 큰 오프셋들을 방지할 수도 있다. 예를 들면, 히트 카운터에 의해 반영되는 총 트래픽량에만 의존하기 보다는, 각각의 서로 구별되는 쿼리하는 IP 어드레스들, 한 세트의 리졸버, 등은 미리 결정된 기간, 예를 들면 24-시간마다 한번만 카운트될 수도 있다.

이에 관하여, 2가지 유형들의 메트릭들을 고찰하는 것이 유용하다:

히트들(H): 주어진 도메인에 대해 발생된 총 쿼리 수.

서브네트들(S): 주어진 도메인에 대해 쿼리를 발생하는 서로 구별되는 리졸버 IP 어드레스들, 한 세트의 리졸버, 등의 수.

위에서 논한 바와 같이, 주어진 쿼리는 3가지 유형들의 도메인 타겟들인, www, 정확한, 기타 중 한 유형을 요청할 수 있다. 발명자들은 각각의 요청들의 카운트들에 기초하여 트래픽의 특성을 의미있게 해석하는데 도움을 주는 몇가지 요인들을 관찰하였다. 이것은 웹 서비스들, 등과 같은 비-사용자 트래픽과는 반대로, 한 특정한 유형의 각각의 쿼리가 사용자 트래픽을 반영하는 정도를 이해하는데 도움을 줄 수 있다.

www 쿼리에 관하여 이러한 타겟들을 참조하는 대다수의 트래픽은 사용자-본위인 것으로 가정할 수 있다. 그러나, www 쿼리가 전형적으로 도메인에서 사용자-본위 트래픽을 반영하나, 이들은 항시 도메인에 대한 모든 사용자-본위 트래픽을 포함하지 않는다. 일부 도메인에 있어서, 사용자-본위 트래픽의 일부는 "정확한" 및 "기타" 메트릭들 내에 있음이 발견되었다. 예를 들면, 발명자들은 일부 인기있는 웹 사이트들에 있어서, 요청들 중 10% 미만은 www 카테고리에 속함을 발견한다. 그러므로, www 메트릭에만 기초하여 스코어를 계산하는 것은 웹 사이트가 보고 있는 실제 트래픽에 기초하였을 것보다 어떤 웹 사이트들이 훨씬 낮게 순위되는 것을 초래할 수 있다.

이것은 "기타" 쿼리가 사용자-본위 트래픽의 대부분을 포함할 수 있는 큰 도메인의 인기를 평가하는데 있어 특히 관계가 있는 있는 것으로 발견되었다. 예를 들면, 도메인 "example.com"은 대부분의 트래픽이 인기있는 서브-도메인, 예를 들면, mail.example.com; games.example.com; news.example.com; 등에 보내지는 것을 볼 수 있다.

발명자들은 도메인의 크기(즉 이의 트래픽량)와 이의 전체 트래픽 중 "기타" 트래픽의 퍼센티지 간에 큰 상관이 있음을 발견하였다. 도 10은 도메인 트래픽 크기(로그 공간에서)와 "기타" 타겟들(서브-도메인)로 가는 트래픽의 퍼센티지 간의 관계를 도시한 것이다. 각 바의 값은 이 바 내에 위치된 모든 도메인의 퍼센티지의 평균인 것에 유의한다.

이것은 두 요소들 간에 명백한 관계를 보여주는 것으로, 더 큰 도메인은 "기타" 트래픽에서 이들의 총 트래픽의 더 큰 퍼센티지를 갖는 경향이 있음을 의미한다. 따라서, "기타" 트래픽의 중요도는 도메인에 대한 트래픽의 전체 레벨에 따라 달라질 수 있다. 이러한 관찰은 여기에 기술된 다양한 방법을 수립할 때 고려되었다. 예를 들면, 기타 트래픽에는 일반적으로 정확한 트래픽보다는 낮은 가중치가 주어질지라도, 실시예에서, 기타 트래픽에 대한 가중치는 상대적 트래픽량에 따라 증가될 수도 있다.

사용자들에 의한 웹 사이트들에 대다수 의뢰에서 "www" 프리픽스는 생략된다(예를 들면 "example.com"). 그러나, 이러한 요청들에 의해 반영되는 사용자-본위 대 비-사용자 본위의 트래픽의 비, 따라서 "정확한" 요청들의 중요도는 확실하지 않았다.

놀랍게도, 발명자들은 "www" 및 "정확한" 트래픽 메트릭들 둘 다를 고려하는 것은 특히 유리한 결과들이 얻어지게 한다는 것을 관찰하였다. "정확한" 메트릭 단독으로는 명백한 경향 또는 일관성을 이행하지 못하나, "www" 메트릭과 결합되었을 때에는 명백한 패턴이 관찰된다. 따라서, 두 메트릭들은 도 11에 도시된 바와 같이, 예기치 않은 방법으로 서로를 보완하는 것으로 판정되었다.

발명자들은 주어진 기간 내에 주어진 도메인의 인입되는 트래픽을 이 기간 내에 전체 트래픽과 비교함으로써 이 주어진 도메인의 수행을 측정하기 위한 능률적이고 정확한 수법을 개발하기 위해 전술한 관찰에 의존하였다. 실시예에서, www 히트들은 모든 다른 요청들과는 별도로 카운트될 수 있다. 대안적으로, 모든 3개의 DNS 타겟 유형들, 예를 들면 www(W), 정확한(E) 및 기타(O)가 포함될 수 있으며, 각각은 다른 가중추가 할당될 수 있다. 추가의 특징으로서, "리졸버의 세트" 메트릭들은 단독으로, 혹은 "히트" 메트릭들과 조합하여 사용될 수 있다. 예를 들면, 다음은 개시된 방법의 실시예를 나타낸다:

주어진 기간동안 각각의 도메인의 일간 W/E/O 평균 비들을 계산한다. 즉, 각각의 도메인에 대해서, 이의 구별되는 한 세트의 리졸버의 메트릭과 이 날에 서로 구별되는 한 세트의 리졸버의 전체 수 간에 일간 비의 평균을 계산한다. 이것은 타겟 유형들 각각에 대해 개별적으로 행해질 수 있다; W/E/0:

여기서, D는 도메인; P는 기간(|P|는 며칠간의 기간의 크기이다); 따라서 SW/E/O(모두, Dayi)는 W/E/0를 쿼리하는 서로 구별되는 한 세트의 리졸버의 전체 수이다.

주어진 기간 내에 도메인에 대한 전체 스코어를 계산한다.

여기서, WW/E/O는 타겟 유형들 W/E/0 각각의 가중치이다. 바람직한 실시예에서, 다음 근사적인 가중치들이 위에 식에서 사용될 수 있다.

WW = 1

WE = 0.5

WO = 0.2

다른 실시예에서, 가중치들은 보다 일반적으로 기술될 수 있다. 예를 들면, WW ≥ WE ≥ WO이다. 앞에서 제시된 바와 같이, WO는 트래픽량에 따라 조절될 수 있다. 예를 들면, WO는 WO' = (WOK)로서 정정될 수 있는데, K는 K ≥ 1이 비교적 큰 트래픽량이고 K ≤은 비교적 작은 량의 트래픽을 나타내게 하는 도메인 트래픽량의 상대적 요소이다.

발명자들은 유사한 스코어를 그룹화하는 것이 여러 사용자들에게 정보의 유용성을 개선할 수 있음을 알았다. 예를 들면, 그룹들의 유용한 표현은 스코어의 로그를 100개의 동일 폭의 빈들(bin)로 분할함으로써 생성될 수 있으며 여기에서 1은 가장 낮은 것이고 100은 가장 큰 것이다. 도 12는 각 그룹 내 도메인의 수를 보인 것이다.

실시예에서, 광고 가격은 도메인에 대한 그룹에 기초하여 결정될 수 있다. 예를 들면, 90 내지 100 사이의 트래픽 그룹 내 도메인은 50 내지 60 사이의 트래픽 그룹 내 도메인과는 반대로 그에 적용되는 광고료는 다를 수 있다. 이들 그룹들은 원 트래픽 스코어 데이터로 한정되는 것은 아니며 TLD 서버의 레벨로부터 얻어지는 넓은 관점뿐만 아니라, 여기에 기술된 방법에 기초하여 더 의미있고 가치있는 메트릭을 나타내는 것에 유의한다. 예를 들면, 발명자들은 여기에서 논한 방법은 낮은 레벨로 트래픽을 전개하고 있는 웹 사이트들 및 도메인을 종래의 방법보다 앞서 식별할 수 있음을 관찰하였다. 이러한 결과들은, 부분적으로, 인터넷 전역에서부터의 트래픽을 종합하고 이의 중요도를 평가하는 TLD의 능력에 기초하여 얻어질 수 있다.

도 8을 참조하면, 실시예는 S3990, S6900, 및/또는 S7900에서와 같이, 계산된 스코어를 취하는 단계, 및 이 스코어를 사용하여 도메인을 순위하는 단계를 포함할 수 있다. 예를 들면, 도메인에 대해 계산된 트래픽 스코어는 이 도메인을 웹 상에 다른 도메인 간에 순위하기 위해서 S8992에서 다른 계산된 스코어에 비교될 수 있다. 이러한 순위는 사용자들이 특정 도메인에 광고하는 것에 대한 적합한 가격 또는 값을 평가하기 위해 더 직관적인 방법으로 사용될 수 있다. 계산된 순위들은 유료 서비스의 부분으로서 분배될 수도 있고, 혹은 시스템 관리, 등을 포함한 다른 목적들을 위해 사용될 수도 있다.

또한 도메인 순위는 S8994에서 값을 계산하기 위해, 광고와 같은 상업용 서비스들의 맥락에서 사용될 수 있다. 예를 들면, 특정 도메인에 광고하는 값은 자동화된 온라인 광고료들을 제공하는 순위-기반 식에 링크될 수도 있다. 이러한 시스템들은 현재의 방법을 사용하여 가능하지 않은 방법로, 중요한 트래픽을 보는 것을 시작하고 있는 웹 사이트 개발자들을 평가하고 보상하기 위해 사용될 수 있다. 예를 들면, TLD 서버, 혹은 개시된 정보에 액세스할 수 있는 다른 벤더는 잠재적 광고주들로부터의 제의들을 특별한 순위를 충족하는 도메인에 자동으로 제공할 수 있다. 위에 나타낸 바와 같이, 발명자들은 권한 있는 서버, 특히 TLD 서버의 위치로부터 보았을 때, 잠재적 광고주들이 관심을 가질 수 있는, 이전에 인식되지 않은 저-레벨 트래픽 사이트들을 식별하는 것이 가능함을 발견하였다.

본 발명의 실시예는 컴퓨터로 하여금 기술된 방법을 실행하게 하기 위한 명령이 부호화된 컴퓨터-판독가능 저장 매체뿐만 아니라, 기술된 방법을 구현하는 시스템들을 포함할 수 있다. 예를 들면, 도 9에 도시된 바와 같이, 프로세서, 메모리 및 전자 통신 디바이스를 포함하는 전자 시스템(900)은 ISP 서버(950)를 통해 DNS 정보를 요청하게 구성될 수 있다. 시스템(900)은 사용자 컴퓨터 시스템, 920, 970과 같은 무선 통신 디바이스들, 930, 990과 같은 서브네트워크들, 서버, 혹은 필요 기능 능력들을 갖춘 그외 어떤 다른 네트워크 가능 디바이스를 나타낼 수 있다. 서버들(952, 954)은 레지스트리에 연관된 DNS 서버의 부분으로서, 혹은 이와는 별도로 동작할 수 있다.

시스템(900)은 첫 번째 저장장치(도시되지 않았지만, 전형적으로 랜덤 액세스 메모리, 또는 "RAM"), 두 번째 저장장치(도시되지 않았지만, 전형적으로 판독전용 메모리, 또는"ROM")를 포함하는 저장 디바이스들에 결합되는 임의의 수의 프로세서들(도시되지 않음)을 포함한다. 이들 저장 디바이스들 둘 다는 위에 기술된 및/또는 언급된 임의의 적합한 유형의 컴퓨터-판독가능 매체를 포함할 수 있다. 대량 저장 디바이스(도시되지 않음)는 프로그램들, 데이터, 등을 저장하기 위해 사용될 수 있고, 전형적으로 주 저장장치보다는 느린 하드디스크와 같은 2차 저장 매체이다. 대량 저장 디바이스 내에 보유된 정보는 적합한 경우들에 주 저장장치의 부분으로서 표준적인 방법으로 가상 메모리로서 포함될 수 있음을 알 것이다. CD-ROM과 같은 특정한 대량 저장 디바이스는 프로세서에 일방향으로 데이터를 전달할 수도 있다.

시스템(900)은 다른 컴퓨터들 910을 포함해서, 이를테면 비디오 모니터, 트랙 볼, 마우스(904), 키보드, 마이크로폰, 터치-감응 디스플레이, 트랜스듀서 카드 리더기, 자기 또는 종이 테이프 리더기, 타블렛, 스타일러스, 음성 또는 친필 인식기, 또는 그외 공지된 입력 디바이스와 같은 하나 이상의 입력/출력 디바이스를 포함하는 인터페이스를 포함할 수 있다.

시스템(900)은 전체적으로 901로 나타낸 바와 같이 네트워크 연결을 사용하여 컴퓨터 또는 다른 전자 통신 네트워크(990, 980)에 결합될 수 있다. 네트워크는 컴퓨터(910), 서버(950, 952, 954), 무선 통신 디바이스(920, 970) 및 서브-네트워크(990, 930) 간에 정보를 서로 교환하기 위해 다양한 유선, 광학, 전자 및 그외 공지된 네트워크를 연결할 수 있다. 이러한 네트워크 연결로, 시스템(900) 및 이 내에 프로세서는 네트워크로부터 정보를 수신할 수 있거나, 위에 기술된 방법의 단계들을 수행하는 과정에서 네트워크에 정보를 출력할 수 있을 것이다. 위에 기술된 디바이스들 및 자료들은 컴퓨터 하드웨어 및 소프트웨어 당업자들에겐 익숙할 것이며 당업자들에 이해하게 개별적으로 속속들이 도시될 필요는 없을 것이다. 위에 기술된 하드웨어 요소들은 위에 기술된 동작들을 수행하기 위한 하나 이상의 모듈들로서 작용하게 구성될 수 있다(일반적으로 일시적으로).

또한, 본 발명의 실시예는 각종의 컴퓨터로 구현되는 동작들을 수행하기 위한 프로그램 명령을 포함하는 컴퓨터-판독가능 저장매체를 더 포함한다. 또한, 매체는 단독으로, 혹은 프로그램 명령, 데이터 파일들, 데이터 구조들, 테이블들, 등과 조합하여 포함할 수 있다. 매체 및 프로그램 명령은 본 발명의 목적을 위해 특별히 설계되고 구성된 것들일 수 있고, 혹은 이들은 컴퓨터 소프트웨어 기술에 당업자들이 사용할 수 있는 종류의 것일 수 있다. 컴퓨터-판독가능 저장매체의 예들은 하드디스크, 플로피 디스크, 및 자기 테이프와 같은 자기 매체; CD-ROM 디스크와 같은 광학매체; 플로옵티컬 디스크와 같은 자기-광학 매체; 및 프로그램 명령을 저장하고 수행하게 특별하게 구성된, 판독-전용 메모리 디바이스(ROM) 및 랜덤 액세스 메모리(RAM)와 같은 하드웨어 디바이스를 포함한다. 프로그램 명령의 예들은 이를테면 컴파일러에 의해 생성되는 기계 코드, 및 해석기를 사용하여 컴퓨터에 의해 실행될 수 있는 고 레벨의 코드가 포함된 파일들을 포함한다.

발명은 예시적 실시예를 참조하여 기술되었다. 이 명세서를 읽고 이해하였을 때 당업자들에게 기술된 실시예의 수정 및 변경이 명백할 수 있다. 본 발명은 모든 이러한 수정들 및 변경들이 첨부된 청구항들의 범위 혹은 이들의 등가물 내에 포함되는 한 이들을 포함한다.

Claims

도메인 명칭을 리졸브하려는 요청을 권한 있는 명칭 서버에서 수신하는 단계;
상기 도메인 명칭에 대한 서버 카운터를 증가시키는 단계; 및
상기 서버 카운터에 기초하여 도메인 트래픽 스코어를 계산하는 단계로 이루어진 도메인 스코어를 결정하는 자동화 방법에 있어서,
상기 도메인 트래픽 스코어를 계산하는 단계는 리졸버 세트의 요청에 관한 정보에 근거하여 서버 카운터에 가중치를 적용하는 단계를 더욱 포함함을 특징으로 하는 도메인 스코어를 결정하는 자동화 방법
제 1 항에 있어서, 상기 서버 카운터는 미리 결정된 기간 내에 리졸버 세트의 특정한 요청에 대해 하나의 카운트로 제한함을 특징으로 하는 자동화 방법
제 2 항에 있어서, 상기 도메인 명칭을 리졸브하려는 요청을 상기 권한 있는 명칭 서버가 수신할 때마다 히트 카운터를 증가시키는 단계를 더욱 포함하고,
상기 도메인 트래픽 스코어를 계산하는 단계는 히트 카운터에 더욱 근거로 함을 특징으로 하는 자동화 방법
제 1 항에 있어서, 상기 가중치는 리졸버 세트의 요청의 지리적 위치에 근거로 함을 특징으로 하는 자동화 방법
제 1 항에 있어서, 상기 가중치는 리졸버 세트의 요청의 네트워크 트래픽 유형과 네트워크 트래픽 레벨의 적어도 하나에 근거함을 특징으로 하는 자동화 방법
제 1 항에 있어서, 상기 가중치는 리졸버 세트의 요청의 아키텍처에 근거함을 특징으로 하는 자동화 방법
제 1 항에 있어서, 상기 방법은 도메인 명칭의 리졸브 요청이 사용자에 의해 제기된 것인지 여부를 판단하는 단계; 및 상기 판단에 근거하여 가중치를 결정하는 단계를 더욱 포함함을 특징으로 하는 자동화 방법
제 1 항에 있어서, 상기 권한 있는 명칭 서버에 의해 서비스되는 다수의 도메인에 대한 도메인 트래픽 스코어를 자동적으로 계산하는 단계;
상기 도메인 트래픽 스코어에 근거하여 다수의 도메인 순위를 자동적으로 결정하는 단계; 및
상기 적어도 하나의 도메인 순위에 근거하여 도메인 중 적어도 하나에 대한 광고 요율을 결정하는 단계를 더욱 포함함을 특징으로 하는 자동화 방법
제 1 항에 있어서, "www" 스트링을 포함하는 요청과 "www" 스트링을 포함하지 않는 요청은 별도로 카운트됨을 특징으로 하는 자동화 방법
제 9 항에 있어서, 상기 "www" 스트링을 포함하는 요청의 카운트는 계산에서 상기 "www" 스트링을 포함하지 않는 요청의 카운트와는 상이하게 가중치를 부여함을 특징으로 하는 자동화 방법
ⅰ) 프로세서; 및
ⅱ) 도메인 명칭을 리졸브하려는 요청을 권한 있는 명칭 서버에서 수신하는 단계;
상기 도메인 명칭에 대한 서버 카운터를 증가시키는 단계; 및
서버 카운터에 근거하여 도메인 트래픽 스코어를 계산하는 단계로 이루어진 도메인 스코어를 결정하고, 리졸버 세트의 요청에 관한 정보에 근거하여 서버 카운터에 가중치를 적용하는 단계를 포함하는 도메인 스코어 결정 방법
을 수행하기 위한 프로세서에 적용 가능한 컴퓨터 실행 가능 코드로 프로그램화된 메모리;
를 포함하는 도메인 스코어를 결정하기 위한 시스템
제 11 항에 있어서, 상기 서버 카운터는 미리 결정된 기간 내에 리졸버 세트의 특정한 요청에 대해 하나의 카운트로 제한함을 특징으로 하는 시스템
제 12 항에 있어서, 상기 도메인 명칭을 리졸브하려는 요청을 상기 권한 있는 명칭 서버가 수신할 때마다 히트 카운터를 증가시키는 단계를 더욱 포함하고,
상기 도메인 트래픽 스코어를 계산하는 단계는 히트 카운터에 더욱 근거로 함을 특징으로 하는 시스템
제 11 항에 있어서, 상기 가중치는 리졸버 세트의 요청의 지리적 위치에 근거로 함을 특징으로 하는 시스템
제 11 항에 있어서, 상기 가중치는 리졸버 세트의 요청의 네트워크 트래픽 유형과 네트워크 트래픽 레벨의 적어도 하나에 근거함을 특징으로 하는 시스템
제 11 항에 있어서, 상기 가중치는 리졸버 세트의 요청의 아키텍처에 근거함을 특징으로 하는 시스템
제 11 항에 있어서, 상기 시스템은 도메인 명칭의 리졸브 요청이 사용자에 의해 제기된 것인지 여부를 판단하는 단계; 및 상기 판단에 근거하여 가중치를 결정하는 단계를 더욱 포함함을 특징으로 하는 시스템
제 11 항에 있어서, 상기 권한 있는 명칭 서버에 의해 서비스되는 다수의 도메인에 대한 도메인 트래픽 스코어를 자동적으로 계산하는 단계;
상기 도메인 트래픽 스코어에 근거하여 다수의 도메인 순위를 자동적으로 결정하는 단계; 및
상기 적어도 하나의 도메인 순위에 근거하여 도메인 중 적어도 하나에 대한 광고 요율을 결정하는 단계를 더욱 포함함을 특징으로 하는 시스템
제 11 항에 있어서, "www" 스트링을 포함하는 요청과 "www" 스트링을 포함하지 않는 요청은 별도로 카운트됨을 특징으로 하는 시스템
제 19 항에 있어서, 상기 "www" 스트링을 포함하는 요청의 카운트는 계산에서 상기 "www" 스트링을 포함하지 않는 요청의 카운트와는 상이하게 가중치를 부여함을 특징으로 하는 시스템