KR20240070621A - 댕글링 dns 레코드들의 인라인 식별 및 차단 - Google Patents

Abstract

본 출원은 댕글링 레코드들을 식별하기 위한 방법, 시스템, 및 컴퓨터 시스템을 개시한다. 방법은 도메인들의 세트를 획득하는 단계, 도메인들의 세트에 포함된 도메인과 연관된 레코드가 댕글링인지 여부를 결정하는 단계, 및 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 등록자에게 레코드가 댕글링이라는 통지를 제공하는 단계를 포함한다.

Description

댕글링 DNS 레코드들의 인라인 식별 및 차단

악의적인 개인들은 다양한 방법들로 컴퓨터 시스템들을 손상시키려 시도한다. 일례로, 그러한 개인들은 (예컨대 실제 개인 또는 서비스에) 이전에 등록되었으나 등록자가 실수로 그러한 등록이 만료되도록 허용한 경우와 같이 어떤 이유로 이용 가능하게 된 도메인들 또는 하위 도메인들을 등록하려고 할 수 있다. 도메인 또는 하위 도메인의 성공적인 등록시, 실제 개인 또는 서비스에 의해 이전에 제공된 서비스들에 액세스하려고 시도하는 클라이언트 단말들을 악성 코드로 감염시키는 것과 같이, 악의적인 개인들은 그와 같은 도메인들 또는 하위 도메인들에서 악성 서비스들을 호스트할 수 있다. 따라서, 악의적인 개인들에 의한 리소스들의 탈취에 노출된 리소스들을 식별하기 위한 개선된 기술들에 대한 지속적인 요구가 존재한다.

본 발명의 다양한 실시예들은 다음의 상세한 설명과 첨부 도면들에 개시되어 있다.
도 1은 본 출원의 다양한 실시예들에 따른 댕글링 레코드 검출을 제공하는 시스템의 블록도이다.
도 2는 본 출원의 다양한 실시예들에 따른 댕글링 레코드 검출을 제공하는 시스템의 블록도이다.
도 3은 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다.
도 4는 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다.
도 5는 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다.
도 6은 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다.

본 발명은 프로세스; 장치; 시스템; 물질의 구성; 컴퓨터 판독 가능 저장 매체에 구현된 컴퓨터 프로그램 제품; 및/또는 프로세서에 연결된 메모리에 저장 및/또는 메모리에 의해 제공되는 명령들을 실행하도록 구성된 프로세서와 같은 프로세서를 포함하여 수 많은 방식들로 구현될 수 있다. 본 명세서에서, 이러한 구현들 또는 본 발명이 취할 수 있는 임의의 다른 형태는 기술들로 지칭될 수 있다. 일반적으로, 개시된 프로세스들의 단계들의 순서는 본 발명의 범위 내에서 변경될 수 있다. 달리 명시되지 않는 한, 작업을 수행하도록 구성된 것으로 설명된 프로세서 또는 메모리와 같은 구성요소는 주어진 시간에 작업을 일시적으로 수행하도록 구성된 일반 구성요소 또는 작업을 수행하도록 제작된 특정 구성요소로 구현될 수도 있다. 본원에 사용된 것과 같이, 용어 '프로세서'는 컴퓨터 프로그램 명령들과 같은 데이터를 처리하도록 구성된 하나 이상의 디바이스들, 회로들, 및/또는 처리 코어들을 의미한다.

본 발명의 하나 이상의 실시예들에 대한 상세한 설명은 본 발명의 원리들을 예시하는 첨부 도면들과 함께 아래에 제공된다. 본 발명은 이러한 실시예들과 관련하여 설명되지만, 본 발명은 임의의 실시예로 제한되지 않는다. 본 발명의 범위는 청구범위에 의해서만 제한되며, 본 발명은 수많은 대안들, 수정들 및 등가물들을 포함한다. 본 발명의 철저한 이해를 제공하기 위해 수 많은 특정 세부사항들이 다음 설명에 기재되어 있다. 이러한 세부사항들은 예시의 목적으로 제공되며, 본 발명은 이러한 특정 세부사항들 중 일부 또는 전부 없이 청구범위에 따라 실시될 수 있다. 본 발명이 불필요하게 모호해지지 않도록 명확성을 기하기 위해, 본 발명과 연관된 기술 분야들에 알려져 있는 기술 자료는 상세히 설명하지 않았다.

레코드가 댕글링 레코드에 대응하는지 여부를 결정하기 위한 시스템이 개시된다. 시스템은 하나 이상의 프로세서들과 메모리를 포함한다. 하나 이상의 프로세스들은 도메인들의 세트를 획득하고, 도메인들의 세트에 포함된 도메인과 연관된 레코드가 댕글링인지 여부를 결정하고, 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 등록자에게 레코드가 댕글링이라는 통지를 제공하도록 구성된다.

본 명세서에서 사용되는 "댕글링(dangling)"이라는 용어는 레코드가 이전에 등록되었고 현재 레코드의 등록이 완료되지 않았거나 유효하지 않으며 그 레코드의 등록이 잠재적으로 제 3 자 등록에 취약한 상태를 의미한다.

본 명세서에서 사용된 용어 "레코드"는 당사자에게 등록 가능하거나 할당 가능한 인터넷 리소스를 의미한다. 레코드의 예들로는 도메인, 하위 도메인, IP 주소, 제 3 자 서비스 계정, MX(mail exchange) 레코드, NS(nameserver) 레코드, CNAME(canonical name) 레코드, DNAME(delegation name) 레코드 등을 포함한다.

악의적인 개인들은 레코드에서 서비스나 정보를 얻으려고 시도하는 제 3 자들을 속이기 위해 댕글링 레코드들을 모니터링하거나 레코드를 등록하려고 할 수 있다. 예를 들어, 악의적인 당사자는 만료된 것으로 알고 있고 레코드에 대한 등록의 만료 전에 제 3 자들에게 진정한 서비스를 제공한 것으로 알고 있는 도메인을 등록하려고 시도할 수 있다. 따라서, 도메인과 같은 레코드에 대한 인그레스 및 아웃그레스 통신들은 악의적인 당사자들에게 노출될 수 있다. 악의적인 당사자가 실효된 레코드를 성공적으로 등록하는 경우, 악의적인 당사자는 레코드 등록의 변경을 알지 못하는 제 3 자들에게 이메일들이나 다른 통신문들을 보낼 수 있다. 유사하게, 악의적인 당사자가 실효된 레코드의 등록에 성공하는 경우, 악의적인 당사자는 도메인과 같은 레코드에 액세스하려는 제 3 자가 레코드를 현재 소유하거나 레코드에 대한 등록을 갖고 있는 악의적인 당사자나 공격자에게 리디렉션되도록 리디렉션들을 설정할 수 있다. 도메인의 경우, 악의적인 당사자가 도메인을 성공적으로 등록하면, 악의적인 당사자는 권한 있는 DNS를 탈취할 수 있다. 상기 관점에서, 등록(들)이 잘못되어 실효되었을 수 있는 댕글링 레코드들을 등록자들에게 경고하기 위해 댕글링 레코드들을 적극적으로 검출할 필요가 있다.

다양한 실시예들에 따르면, 시스템은 레코드가 등록 또는 할당에 이용 가능하다는 결정에 적어도 부분적으로 기초하여 레코드가 댕글링 레코드에 대응하는지 여부를 결정한다. 일부 실시예들에서, 시스템은 레코드가 DNS 트래픽과 동시에 댕글링인지 여부를 결정한다. 예를 들어, DNS 질의의 수신에 응답하여 시스템은 DNS 질의에 대응하는 레코드(예컨대, 도메인, 하위 도메인, IP 주소 등)를 결정하고, 시스템은 레코드가 DNS 질의 서비스와 동시에 댕글링인지 여부를 결정한다. 일부 실시예들에서, 시스템은 DNS 질의를 가로채거나 DNS 질의에 대한 응답을 가로채고, 시스템은 레코드가 댕글링인지 여부를 결정한다(예컨대, 응답이 DNS 질의가 시작된 클라이언트 형식으로 통신되기 전에). 일부 실시예들에서, 시스템은 미리 결정된 스케쥴에 따라 레코드가 댕글링인지 여부를 결정한다. 예를 들어, 시스템은 한 명 이상의 고객들과 연관된 레코드들과 같은 레코드들의 세트를 수신(또는 관리)하고, 미리 정의된 시간 간격들로 시스템은 레코드가 댕글링인지 결정하기 위해 레코드들의 세트를 반복한다. 미리 정의된 시간 간격은 매일, 매주, 매월 등으로 설정될 수 있다. 관리자와 같은 사용자의 구성이나 요청에 기초하여 다양한 다른 시간 간격들이나 스케쥴들이 설정될 수 있다. 최상위 도메인들의 경우, 일반적으로 실효된 도메인들이 대중에 이용 가능하게 되기 전에 도메인들을 복구할 수 있도록 등록자들에게 유예 기간이 연장된다. 유예 기간은 보통 2개월이다. 따라서, 일부 실시예들에서, 시스템은 3개월마다(또는 실효된 등록들이 공개적으로 노출되도록 하기 위해 2개월보다 긴 다른 기간) 도메인들의 세트에 대해 확인을 수행한다. 의심스러운 당사자는 레코드(예컨대 도메인) 등록이 만료된 시간과 시스템 레코드가 댕글링인지 결정하기 위해 확인을 수행하는 시간 사이에 레코드를 등록한다. 따라서, 다양한 실시예들에서, 시스템은 레코드의 만료 또는 소멸과 레코드의 확인 사이의 시간의 양을 최적화하거나 줄인다. 일부 실시예들에서, 시스템은 하나 이상의 레코드들에 대응하는 예상 만료일들을 저장하고, 시스템은 특정 레코드에 대한 예상 등록일 이후 미리 결정된 기간에 등록을 제공하는 제 3 자 서비스에 질의한다. 일부 실시예들에서, 도메인들의 세트는 사용자 또는 고객(예컨대, 시스템에 의해 제공되는 서비스의 고객)과 연관된 하나 이상의 도메인들에 대응할 수 있다. 일부 실시예들에서, 도메인들의 세트는 사용자들 또는 고객들의 세트에 대한 복수의 도메인들에 대응한다.

다양한 실시예들에 따르면, 레코드가 댕글링 레코드에 대응한다는 결정에 응답하여, 시스템은 레코드가 댕글링이라는 표시(본 명세서에서는 댕글링 레코드라고도 함)를 제공한다. 일부 실시예들에서, 시스템은 레코드와 연관된 등록자와 관련된 연락처 정보를 결정하고 레코드가 댕글링이라는 표시를 연락처 정보에 포함된 주소 또는 연락처에 통신한다. 레코드가 댕글링이라는 표시는 레코드가 댕글링이라는 통지와 대응 레코드가 악의적인 공격들을 받을 수 있다는 표시(예컨대, 대응 레코드가 제 3 자에 의해 등록될 수 있음)를 포함할 수 있다. 연락처 정보에 포함된 주소는 이메일, 전화번호, 계정 식별자(예컨대, 계정에 대한 레코드들이 댕글링인지를 확인하는 서비스를 위한 시스템과 연관된 계정의 경우 등)를 포함할 수 있다. 일부 실시예들에서, 시스템은 레코드가 속하는 서비스에 대한 질의에 적어도 부분적으로 기초하여 레코드와 연관된 등록자와 관련된 연락처 정보를 결정한다. 예를 들어, 레코드가 도메인인 경우, 시스템은 도메인에 대한 WHOIS 레코드를 질의하고 WHOIS 레코드에서 등록 정보를 획득한다. 일부 실시예들에서, 레코드가 댕글링 레코드라는 결정에 응답하여, 시스템은 레코드와 연관된 등록대행기관(예컨대, 등록자에게 레코드에 관한 서비스를 제공하는 서비스)과 통신하고 그러한 등록대행기관에게 대응 레코드가 악의적인 공격자의 대상이 될 수 있다는 표시를 제공한다.

일부 실시예들에서, 레코드가 댕글링이라는 결정에 응답하여, 시스템은 레코드에 대한 트래픽이 차단되게 한다. 예를 들어, 댕글링 레코드가 도메인인 경우, 시스템은 대응 도메인에 대한 DNS 트래픽을 적극적으로 차단하거나 다른 네트워크 장치에 대응 도메인에 대한 DNS 트래픽을 차단하라는 표시나 명령을 제공한다. 또 다른 예로, 레코드로 향하는 DNS 트래픽과 동시에 레코드가 댕글링이라는 결정이 수행되는 경우, 시스템은 대응 레코드로의 DNS 트래픽을 차단하거나 DNS 트래픽이 발생한 클라이언트에게 싱크홀(sinkhole) 주소를 반환/리디렉션한다. 또 다른 예로서, 레코드가 댕글링이라는 결정에 응답하여, 시스템은 예를 들어 레코드로 향하는 트래픽이 차단(또는 레코드와 연관된 이전 등록자와 연관된 다른 주소로 리디렉션)되도록 하기 위해 방화벽 정책을 업데이트한다. 일부 실시예들에서, 시스템은 트래픽이 차단되거나 리디렉션되지 않는 레코드들(예컨대 도메인들)의 화이트리스트를 저장한다. 예를 들어, 어떤 레코드가 댕글링 레코드로 결정되더라도, 시스템은 레코드에 대한 트래픽을 허용한다(예컨대 화이트리스트에 있는 레코드에 대한 트래픽을 차단하거나 리디렉션하지 않는다). 화이트리스트는 예를 들어 관리자, 고객 등이 구성할 수 있다.

다양한 실시예들에 따르면, 댕글링 레코드를 검출하거나 레코드가 댕글링 레코드인지 여부를 결정하는 시스템은 하나 이상의 서버들에 의해 제공된다. 예를 들어, 시스템은 다양한 사용자들이나 고객들에게 제공되는 클라우드 서비스일 수 있다. 또 다른 예로, 하나 이상의 서버들은 수동 DNS 서비스들, DNS 보안 서버, DNS 리졸버(resolver) 등으로부터 질의들을 받는다.

시스템은 레코드들의 보안(예컨대, 레코드들의 등록들)을 향상시키고 악의적인 제 3 자들에 의해 레코드들이 탈취될 가능성을 줄인다. 관련 기술 시스템들은 이러한 관련 기술 시스템들이 관리하는 등록들과 같은 자체 시스템 내에서 댕글링 레코드들을 식별할 수 있다. 이러한 관련 기술 시스템들은 일반적으로 등록을 위한 계정에 대한 액세스를 필요로 한다. 예를 들어, 도메인 등록대행기관(domain registrar)은 고객들을 위해 실효된 고객의 도메인 등록들 또는 하위 도메인 등록들을 식별할 수 있다. 다양한 실시예들은 시스템에 의해 관리되는 레코드들(예컨대, 도메인들) 내의 댕글링 레코드들을 검출하는 것에 국한되지 않는다. 예를 들어, 다양한 실시예들은 제 3 자 서비스 제공자들 및 플랫폼들 전반에 걸쳐 확장 가능한 레코드들의 검출을 제공한다. 다양한 실시예들에 따른 시스템은 등록자에 대한 댕글링 레코드들을 검출하기 위해 등록자와 연관된 자격증명들 등을 통해 등록자의 계정에 대한 액세스를 요구하지 않는다. 일부 실시예들에서, 시스템은 대중에 노출되는 정보를 사용하여 레코드가 댕글링 레코드인지 여부를 결정한다. 예를 들어, 시스템은 이러한 제 3 자 서비스들을 위해 개발된 애플리케이션 프로그래밍 인터페이스들(APIs) 등을 통해 대중이 사용할 수 있는 제 3 자 서비스들에 질의한다.

제 3 자 서비스 제공자들은 종종 터미널(예컨대, 시스템)이 API 등을 통해 제 3 자 서비스 제공자에게 보낼 수 있는 질의들의 수를 스로틀링하거나 제한한다. 어떤 경우들에는 제 3 자 서비스 제공자들이 프리미엄 서비스, 일반적으로 질의들의 수에 제한이 없거나 무료 서비스에 비해 제한이 확장되는 유료 구독이 필요한 모델을 제공한다. 다양한 실시예들에 따르면, 시스템은 하나 이상의 제 3 자 서비스들 각각에 복수의 계정들을 등록하고, 복수의 계정들을 사용하여 미리 결정된 레코드들의 세트(예컨대, 시스템의 고객(들)에 대응하는 레코드들의 세트)에 대한 레코드들을 댕글링하기 위한 하나 이상의 제 3 자 서비스들에 대한 질의를 수행한다.

도 1은 본 출원의 다양한 실시예들에 따른 댕글링 레코드 검출을 제공하는 시스템의 블록도이다. 다양한 실시예들에 따르면, 시스템(100)의 적어도 일부는 도 2의 시스템(200)을 구현한다. 시스템(100)은 도 3의 프로세스(300), 도 4의 프로세스(400), 도 5의 프로세스(500), 및/또는 도 6의 프로세스(600)를 구현한다.

도시된 예에서, 시스템(100)은 댕글링 레코드 서비스(110)를 포함한다. 시스템(100)은 제 1 레코드 서비스(130), 제 2 레코드 서비스(140), 제 3 레코드 서비스(150), 관리자 시스템(160), 및/또는 클라이언트 시스템(170) 중 하나 이상을 더 포함할 수 있다. 시스템(100)은 네트워크(180)를 더 포함할 수 있다. 다양한 실시예들에 따르면, 댕글링 레코드 서비스(110)는 비즈니스 애플리케이션 계층(115) 및 데이터베이스 계층(120) 중 하나 이상을 포함한다.

제 1 레코드 서비스(130), 제 2 레코드 서비스(140), 및/또는 제 3 레코드 서비스(150)는 한 명 이상의 사용자들 또는 고객들에게 서비스들을 제공한다. 다양한 실시예들에 따르면, 서비스들은 하나 이상의 레코드들의 등록을 포함한다. 예를 들어, 제 1 레코드 서비스(130)는 도메인 등록대행기관이다. 다른 예로서, 제 2 서비스(140)는 하위 도메인들(예컨대, Shopify, Facebook, Google, Microsoft 등)의 등록을 제공하는 서비스 제공자이다. 레코드들의 예들로는 최상위 도메인이나 하위 도메인과 같은 도메인, IP 주소, 계정 등을 포함한다.

다양한 실시예들에 따르면, 댕글링 레코드 서비스(110)는 레코드가 댕글링 레코드에 대응하는지 여부를 결정할 수 있다. 일례로서, 댕글링 레코드 서비스(110)는 도메인들의 세트를 획득하고, 도메인들의 세트에 포함된 도메인과 연관된 레코드가 댕글링인지 여부를 결정하고, 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 등록자에게 레코드가 댕글링이라는 통지를 제공한다. 다른 예로서, 레코드가 댕글링이라는 통지를 제공하는 것에 더하여 또는 그에 대한 대안으로서, 댕글링 레코드 서비스(100)는 레코드로 향하는 트래픽(예컨대, DNS 트래픽)을 차단하거나 리디렉션한다.

도 1에 도시된 바와 같이, 댕글링 레코드 서비스(110)는 비즈니스 애플리케이션 계층(115) 및/또는 데이터베이스 계층(115) 중 하나 이상을 포함할 수 있다.

비즈니스 애플리케이션 계층(115)은 댕글링 레코드 서비스(110)를 제어 및/또는 구성하는 것과 관련하여 사용된다. 하나 이상의 정책들이 비즈니스 애플리케이션 계층(115)을 통해 설정되어 댕글링 레코드들을 모니터링하거나 검출할 수 있다. 예를 들어, 관리자는 관리자 시스템(160)을 사용하여 비즈니스 애플리케이션 계층(115)과 통신하여 댕글링 레코드 서비스(110)가 댕글링 레코드를 모니터링 또는 검출할 도메인들의 세트 또는 레코드들의 세트를 구성(예컨대, 정의)한다. 다른 예로서, 관리자는 비즈니스 애플리케이션 계층(115)과 통신하여 댕글링 레코드 서비스(110)에 레코드가 댕글링인지 여부를 결정하거나, 또는 댕글링 레코드 서비스(110)가 레코드가 댕글링인지 여부를 결정하는 스케쥴들 또는 시간 기간들을 설정하도록 요청하거나 지시한다.

데이터베이스 계층(120) 또는 저장 계층은 댕글링 서비스 레코드(110)가 그러한 레코드들 중 하나의 레코드가 댕글링되는지 여부를 결정하는 것과 관련하여 모니터링 또는 검출할 레코드들과 같은 레코드들에 대한 사용자들(또는 고객들)의 매핑들을 저장하도록 구성된다. 일부 실시예들에서, 데이터베이스 계층(120)은 하나 이상의 레코드들이 댕글링 레코드에 대응하는지 여부를 댕글링 레코드 서비스(110)가 결정하는 하나 이상의 정책들을 저장한다. 데이터베이스 계층(120)은 각각의 정책들이 속하는 하나 이상의 사용자들 또는 고객들에 대한 하나 이상의 정책들의 매핑을 추가로 저장할 수 있다. 정책들은 댕글링 레코드 서비스(110)가 레코드(들)가 댕글링 레코드에 대응하는지 여부에 대한 결정을 수행하는 스케쥴 또는 시간 기간을 나타내는 정책을 포함할 수 있다.

다양한 실시예들에 따르면, 댕글링 레코드 서비스(110)는 하나 이상의 레코드 서비스들(예컨대, 제 1 레코드 서비스(130), 제 2 레코드 서비스(140), 및/또는 제 3 레코드 서비스(150))와 연관된 하나 이상의 레코드들이 댕글링인지 여부를 결정한다. 예를 들어, 댕글링 레코드 서비스(110)는 대응 레코드(들)이 댕글링인지 여부를 결정하는 것과 관련하여 대응하는 하나 이상의 레코드 서비스들에 질의한다. 일부 실시예들에서, 질의들은 레코드를 등록하기 위한 질의를 포함한다(예컨대, 레코드의 등록이 허용되거나 가능한 경우, 댕글링 레코드 서비스(110)는 의심스러운 제 3 자가 등록할 수 있기 때문에 그러한 레코드를 댕글링인 것으로 간주할 수 있다). 일부 실시예들에서, 댕글링 레코드 서비스(110)는 레코드 서비스에 대응하는 API를 통해 질의를 레코드 서비스에 통신한다. 예를 들어, 비즈니스 애플리케이션 계층(115)은 API를 통해 레코드 서비스를 호출하는 데 사용된다. 하나 이상의 레코드들과 관련된 하나 이상의 레코드 서비스들에 대한 질의들은 개별적으로 또는 일괄적으로 송신될 수 있다. 예를 들어, 댕글링 레코드 서비스(110)는 댕글링 레코드 서비스(110)가 댕글링 레코드들을 모니터링/검출할 레코드들의 전부 또는 서브세트에 대해 특정 레코드 서비스에 대한 복수의 질의들을 통신한다.

시스템(100)은 관리자 시스템(160) 및/또는 클라이언트 시스템(170)이 비즈니스 애플리케이션 계층(115) 및/또는 데이터베이스 계층(120)과 같은 하나 이상의 댕글링 레코드 서비스(110)와 통신하는 네트워크(18)와 같은 하나 이상의 네트워크들을 더 포함한다. 다양한 실시예들에서, 네트워크(125)는 유선 네트워크 및/또는 셀룰러 네트워크, 무선 근거리 통신망(WLAN), 또는 임의의 다른 적절한 네트워크와 같은 무선 네트워크 중 하나 이상을 포함한다. 일부 실시예들에서, 비즈니스 애플리케이션 계층(115) 및/또는 데이터베이스 계층(120)은 각각 하나 이상의 서버들에 의해 구현된다. 시스템(100)은 다양한 다른 시스템들 또는 단말들을 포함할 수 있다.

도 2는 본 출원의 다양한 실시예들에 따른 댕글링 레코드 검출을 제공하는 시스템의 블록도이다. 다양한 실시예들에 따르면, 시스템(200)은 예를 들어 댕글링 레코드 서비스(110)를 위해 도 1의 시스템(100)과 관련하여 구현된다. 다양한 실시예들에서, 시스템(200)은 도 3의 프로세스(300), 도 4의 프로세스(400), 도 5의 프로세스(500), 및/또는 도 6의 프로세스(600)와 연계하여 구현된다.

시스템(200)은 서버들과 같은 하나 이상의 장치들에 의해 구현될 수 있다. 시스템(200)은 네트워크의 다양한 위치들에서 구현될 수 있다. 예를 들어, 댕글링 레코드 서비스는 DNS 리졸버에 배포된다. 또 다른 예로, 댕글링 레코드 서비스는 방화벽에 배포된다. 또 다른 예로서, 댕글링 레코드 서비스는 DNS 리졸버에게 제공되는 서비스이다(예컨대, 댕글링 레코드 서비스는 DNS 트래픽에 대한 도메인과 같은 레코드가 댕글링 레코드에 대응하는지 여부를 결정하기 위해 DNS 리졸버 또는 방화벽으로부터 질의들을 서비스하는 하나 이상의 원격 서버들에 배포된다). 또 다른 예로서, 댕글링 레코드 서비스는 네트워크 상의 한 위치에 배포되어 DNS 질의들 및/또는 DNS 질의들에 응답하여 통신되는 응답들과 같은 DNS 트래픽을 가로챈다.

도시된 예에서, 시스템(200)은 레코드가 댕글링 레코드인지 여부를 결정하는 것과 연계하여 하나 이상의 모듈들을 구현한다. 시스템(200)은 통신 인터페이스(205), 하나 이상의 프로세서들(210), 스토리지(215), 및/또는 메모리(220)를 포함한다. 하나 이상의 프로세서들(210)은 통신 모듈(225), 레코드 선택기 모듈(230), 질의 모듈(235), 등록 모듈(240), 댕글링 레코드 결정 모듈(245), 및/또는 능동적 조치 모듈(250) 중 하나 이상을 포함한다.

일부 실시예들에서, 시스템(200)은 통신 모듈(225)을 포함한다. 시스템(200)은 통신 모듈(225)을 사용하여 다양한 클라이언트 단말들 또는 관리자 시스템과 같은 사용자 시스템들과 통신한다. 일부 실시예들에서, 시스템(200)은 예를 들어 레코드가 특정 서비스에 대해 이용 가능한지 여부를 결정하기 위한(예컨대, 레코드가 등록 가능한지 여부를 결정하고, 레코드 등록이 만료/실효되었는지 결정하고, 레코드를 등록하기 위해 시도하는 등) 질의를 전송하고, 및/또는 질의에 대한 응답을 수신하는 것과 관련하여 하나 이상의 레코드 서비스들과 통신하기 위해 통신 모듈(225)을 사용한다. 예를 들어, 통신 모듈(225)은 통신될 정보를 통신 인터페이스(205)에 제공한다. 다른 예로서, 통신 인터페이스(205)는 시스템(200)에 의해 수신된 정보를 통신 모듈(225)에 제공한다. 통신 모듈(225)은 방화벽들, DNS 리졸버들 등과 같은 다양한 클라이언트 단말들이나 시스템들로부터 하나 이상의 DNS 질의들을 수신하도록 구성된다. 예를 들어, 댕글링 레코드 서비스는 DNS 트래픽을 가로채고 DNS 트래픽에 대한 응답을 제공하기 전에 또는 이와 관련하여 댕글링 레코드를 식별하는 데 사용된다. 통신 모듈(225)은 관리자 또는 고객과 같은 사용자로부터 댕글링 레코드 서비스(110)에 대한 하나 이상의 설정들 또는 구성들을 수신하도록 구성된다. 하나 이상의 설정들 또는 구성들의 예들은 댕글링 레코드들이 모니터링/검출될 레코드들의 세트의 구성들, 댕글링 레코드들이 모니터링/검출될 정책(예컨대, 레코들의 세트가 댕글링 레코드를 포함하는지 여부를 결정하는 스케쥴, 댕글링 레코드들에 대한 확인들이 수행될 시간 기간 또는 빈도, 레코드들에 대한 연락처 정보의 매핑, 대응 레코드가 댕글링이라는 결정에도 불구하고 트래픽이 허용되는 도메인들과 같은 레코드들의 화이트 리스트 등)을 포함한다.

다양한 실시예들에 따르면, 시스템(200)은 레코드 선택 모듈(230)을 포함한다. 시스템(200)은 시스템(200)이 레코드가 댕글링 레코드(예컨대, 질의가 도메인 등록대행기관 등과 같은 대응 레코드 서비스로 송신되는 레코드)인지 여부를 결정하는 레코드 결정과 관련하여 레코드 선택 모듈(230)을 사용한다. 일부 실시예들에서, 레코드 선택 모듈(230)은 DNS 트래픽에 적어도 부분적으로 기초하여 레코드를 결정한다. 예를 들어, DNS 질의 수신에 응답하여, 시스템(200)은 DNS 질의에 대응하는 레코드(예컨대, 최상위 도메인, 하위 도메인, IP 주소 등)가 댕글링 레코드인지 여부를 결정하기 위해 질의된다. 일부 실시예들에서, 레코드 선택 모듈(230)은 시스템(200)이 댕글링 레코드가 되는 레코드를 모니터링/검출하는 레코드들의 세트, 또는 특정 사용자 또는 고객에 대응하는 레코드들의 세트와 같은 레코드들의 세트에 적어도 부분적으로 기초한다. 예를 들어, 시스템(200)이 미리 결정된 스케쥴 또는 빈도에 따라 그리고 그러한 모니터링이 미리 결정된 스케쥴 또는 빈도에 적어도 부분적으로 기초하여 현재 시간에 수행되어야 한다는 결정에 응답하여 레코드들의 세트를 모니터링하기 위한 정책을 저장하면, 레코드 선택 모듈(230)은 그러한 정책에 대응하는 레코드들의 세트를 결정한다.

일부 실시예들에서, 시스템(200)은 질의 모듈(235)을 포함한다. 시스템(200)은 하나 이상의 레코드 서비스들(예컨대, 제 1 레코드 서비스(130), 제 2 레코드 서비스(140), 및/또는 제 3 레코드 서비스(150))에 질의하기 위해 질의 모듈(235)을 사용한다. 질의 모듈(235)은 하나 이상의 레코드들이 댕글링인지 여부를 결정하는 것과 관련하여 하나 이상의 레코드 서비스들에 질의하는 데 사용된다. 예를 들어, 질의 모듈(235)은 특정 레코드를 등록하기 위해 레코드 서비스에 질의한다(예컨대, 시스템(200)이 특정 레코드가 등록 가능한지 여부를 결정하는 것과 관련하여). 예를 들어, 레코드가 IP 주소인 경우, 질의 모듈(235)은 시스템(200)이 IP 주소를 획득할 수 있는지 여부를 결정하기 위해 공용 클라우드에 질의한다. 다른 예로서, 레코드가 도메인인 경우, 질의 모듈(235)은 등록대행기관 또는 TLD 영역 파일들을 제공하는 서비스에 질의한다. 다른 예로서, 레코드가 하위 도메인인 경우, 질의 모듈(235)은 하위 도메인을 제공하는 제 3 자 서비스(예컨대 Shopify, Google, Microsoft, Facebook 등)에 질의한다.

일부 실시예들에서, 시스템(200)은 등록 모듈(240)을 포함한다. 시스템(200)은 등록 모듈(240)을 사용하여 레코드 서비스에 레코드를 등록하고 및/또는 레코드 서비스에 레코드들의 등록을 관리하려고 시도한다. 예를 들어, 등록 모듈(240)은 제 3 자 서비스(예컨대 Shopify, Google, Microsoft, Facebook, Etsy, Pinterest 등)에 계정 또는 하위 도메인의 등록을 시도하도록 구성된다. 일부 실시예들에서, 사용자는 레코드가 댕글링이라는 결정에 응답하여 사용자와 연관된 특정 레코드를 등록하도록 시스템(200)에 대한 정책을 구성한다. 예를 들어, 그러한 정책에 따라, 레코드의 등록이 만료/실효되었다는 결정에 응답하여, 시스템(200)은 등록 모듈(240)을 사용하여 사용자(예컨대, 레코드의 등록이 만료/소멸되도록 잘못 허용된 이전 등록자)에 대한 레코드를 재등록한다).

일부 실시들에서, 시스템(200)은 댕글링 레코드 결정 모듈(245)을 포함한다. 시스템은 댕글링 레코드 결정 모듈(245)을 사용하여 레코드가 댕글링 레코드인지 여부를 결정한다. 예를 들어, 댕글링 레코드 결정 모듈(245)은 응답 질의 모듈(235)이 하나 이상의 레코드 서비스들에 질의하는 것과 관련하여 수신하는 것에 적어도 부분적으로 기초하여 레코드가 댕글링인지 여부를 결정한다. 질의 모듈(235)이 레코드가 만료/실효되었다는 표시를 수신하는 경우, 댕글링 레코드 결정 모듈(245)은 레코드가 댕글링 레코드라고 결정한다. 다른 예로서, 댕글링 레코드 결정 모듈(245)은 레코드가 예를 들어 제 3 자 서비스에 의해 레코드가 등록 가능하다고(예컨대, 등록 모듈(240)이 계정을 생성할 수 있거나 Shopify, Microsoft 등과 같은 제 3 자 서비스에 의해 하위 도메인을 등록할 수 있다고) 등록 모듈(240)이 결정하는 것에 적어도 부분적으로 기초하여 결정한다.

일부 실시예들에서, 시스템(200)은 능동적 조치 모듈(250)을 포함한다. 시스템(200)은 레코드가 댕글링 레코드라고 시스템(200)이 결정하는 것에 응답하여 하나 이상의 동작들을 수행하기 위해 능동적 조치(250)를 사용한다. 레코드가 댕글링 레코드라는 결정에 응답하여 수행되는 하나 이상의 동작들은 시스템(200)이 레코드를 모니터링하는 고객의 정책 또는 선호도와 같은 하나 이상의 정책들 또는 선호도들에 미리 설정될 수 있다. 하나 이상의 동작들의 예들은 대응 레코드가 댕글링 레코드라는 통지 또는 표시 제공, 레코드 등록, 댕글링 레코드에 대응하는 도메인 또는 주소로의 트래픽 차단, 댕글링 레코드에 대응하는 도메인 또는 주소로의 트래픽 리디렉팅을 포함한다. 일례로서, 레코드가 댕글링 레코드라고 시스템(200)이 결정하는 것에 응답하여, 능동적 조치 모듈(250)은 레코드가 댕글링이라는 표시를(예컨대, 통신 모듈(225)을 통해) 통신한다. 표시는 레코드와 관련된 연락처 정보(예컨대, 시스템(200)이 레코드를 모니터링하는 사용자 또는 고객의 연락처, 레코드와 연관된 등록대행기관에 의해 식별된 등록자 등)로 통신된다. 다른 예로서, 레코드가 댕글링 레코드라고 시스템(200)이 결정하는 것에 응답하여, 능동적 조치 모듈(250)은 예를 들어 사용자 또는 고객(예컨대, 그러한 레코드에 대한 이전 등록자)을 대신하여 레코드를 등록한다.

다양한 실시예들에 따르면, 스토리지(215)는 파일시스템 데이터(260), 도메인 데이터(262), 레코드 데이터(264), 및/또는 정책 데이터(266) 중 하나 이상을 포함한다. 스토리지(215)는 공유 스토리지(예컨대, 네트워크 스토리지 시스템) 및/또는 데이터베이스 데이터, 및/또는 사용자 활동 데이터를 포함한다.

일부 실시예들에서, 파일시스템 데이터(260)는 하나 이상의 데이터 세트들(예컨대, 하나 이상의 테넌트들(tenants)에 대한 하나 이상의 데이터 세트들 등)과 같은 데이터베이스를 포함한다. 파일시스템 데이터(260)는 고객과 관련된 데이터, 레코드가 댕글링 레코드인지 여부를 결정하는 시스템(200)과 관련하여 사용되는 데이터, DNS 질의들에 관한 이력 정보, 도메인들과 같은 레코드들의 화이트 목록(예컨대 트래픽이 도메인들의 세트 또는 도메인이 댕글링 레코드라는 결정에 응답하여 허용되거나 차단되는 도메인들의 세트) 등을 포함한다.

도메인 데이터(262)는 하나 이상의 도메인들과 관련된 데이터를 포함한다. 일례로서, 하나 이상의 도메인들과 관련된 데이터는 도메인들(예컨대, 최상위 도메인들, 하위 도메인들 등) 간의 관계들 및 연관들 및 IP 주소들과 같은 주소 정보를 포함한다. 일례로서, 하나 이상의 도메인들과 관련된 데이터는 댕글링 레코드들을 모니터링/검출하기 위해 시스템(200)에 의해 제공되는 서비스의 사용자들 또는 고객들과 같은 등록자들에 대한 도메인들의 매핑을 포함한다. 다른 예로서, 도메인 데이터(262)는 DNS 질의 또는 DNS 질의에 대한 응답에 포함된 도메인과 관련된 정보(예컨대, DNS 질의 또는 DNS 질의에 대한 응답으로부터 시스템(200)이 가로챈 도메인)을 포함한다.

레코드 데이터(264)는 시스템(200)이 특정 레코드가 댕글링 레코드인지 여부를 결정하는 하나 이상의 레코드들와 관련된 정보를 포함한다. 일부 실시예들에서, 레코드 데이터(264)는 그러한 레코드에 대한 등록을 관리하거나 제공하는 레코드 서비스들(예컨대, 도메인 등록대행기관, 공용 클라우드, 사용자들이 Shopify와 같은 하위 도메인들을 등록할 수 있도록 허용하는 제 3 자 서비스 등)에 대한 레코드들의 매핑을 포함한다. 예를 들어, 레코드 데이터(264)는 시스템(200)이 레코드 서비스(들)와 통신할 API들 또는 통신 프로토콜들 또는 신택스(syntax)의 매핑을 포함한다. 다른 예로서, 레코드 데이터(264)는 하나 이상의 레코드들이 댕글링 레코드들에 대응하는지 여부를 각각 표시하는 하나 이상의 표시자들을 포함한다.

정책 데이터(266)는 시스템(200)이 하나 이상의 레코드들이 댕글링 레코드에 대응하는지 여부를 결정할 하나 이상의 정책들을 포함한다. 예를 들어, 정책 데이터(266)는 레코드가 댕글링 레코드인지 여부를 시스템(200)이 확인하는 스케쥴들 또는 시간 기간들에 대한 레코드들의 매핑을 포함한다. 다른 예로서, 정책 데이터(266)는 특정 레코드가 댕글링 레코드인 것으로 결정되었다는 결정에 응답하여 수행될 능동적 조치들에 대한 레코드들의 매핑을 포함한다. 다른 예로서, 정책 데이터(266)는 사용자 또는 고객의 레코드가 댕글링 레코드인 것으로 결정되었다는 결정에 응답하여 수행될 능동적 조치들에 대한 사용자들 또는 고객들의 매핑을 포함한다. 다양한 다른 정책들이 정책 데이터(266)에 저장될 수 있다.

다양한 실시예들에 따르면, 메모리(220)는 실행 애플리케이션 데이터(275)를 포함한다. 실행 애플리케이션 데이터(275)는 레코드가 댕글링 레코드인지 여부를 결정하는 것과 관련하여 사용할 설정들 또는 정책들에 대해 시스템(200)을 구성하기 위한 또는 레코드가 댕글링 레코드인지 여부를 결정하기 위한 프로세스를 실행하는 애플리케이션과 같은 애플리케이션 실행과 관련하여 획득되거나 사용되는 데이터를 포함한다. 실시예들에서, 애플리케이션은 질의 또는 작업의 수신 및/또는 실행, 보고서 생성 및/또는 실행된 질의 또는 작업에 응답하는 정보 구성, 및/또는 질의나 작업에 응답하는 정보를 사용자에게 제공하는 것 중 하나 이상을 수행하는 하나 이상의 애플리케이션들을 포함한다. 다른 애플리케이션들은 임의의 다른 적절한 애플리케이션들(예컨대, 레코드 서비스들 질의용 애플리케이션, 레코드 서비스와의 통신 확립용 애플리케이션, 능동적 조치 수행용 애플리케이션, 제 3 자 서비스에 레코드를 등록하기 위한 애플리케이션, 보고서 준비 애플리케이션, 사용자 인터페이스 애플리케이션, 데이터 분석 애플리케이션, 트래픽을 차단하거나 리디렉션하는 애플리케이션, 사용자 인증 애플리케이션 등)을 포함한다.

도 3은 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다. 다양한 실시예들에 따르면, 프로세스(300)는 도 1의 시스템(100) 및/또는 도 2의 시스템(200)과 연계하여 구현된다.

일부 실시예들에서, 프로세스(300)는 댕글링 레코드 서비스(예컨대, 모니터링 또는 검출 서비스)의 고객이 설정한 스케쥴과 같은 미리 결정된 스케쥴에 따라 호출된다. 프로세스(300)는 관리자로부터의 요청과 같은 사용자 입력에 응답하여 호출될 수 있다.

305에서, 도메인들의 세트가 수신된다. 일부 실시예들에서, 시스템은 시스템이 댕글링 레코드들을 모니터링하거나 검출하도록 구성된 레코드들의 데이터베이스로부터 도메인들의 세트를 수신한다. 예를 들어, 도메인들의 세트는 댕글링 레코드 서비스의 특정 고객과 연관된 도메인들을 포함할 수 있다. 또 다른 예로, 도메인들의 세트는 댕글링 레코드 서비스가 댕글링 레코드를 모니터링하거나 검출하는 모든 고객들의 모든 도메인들에 대응한다.

일부 실시예들에서, 도메인들의 세트는 DNS 트래픽 가로채기(예컨대, DNS 리졸버, 방화벽 등)로부터의 요청과 연관된 하나 이상의 도메인들에 대응한다. 일례로서, 하나 이상의 DNS 질의들을 가로채거나 하나 이상의 DNS 질의들에 대한 응답들을 가로채는 것에 응답하여, 하나 이상의 도메인들 중 어느 하나가 댕글링 레코드에 대응하는지 여부를 결정하기 위해 도메인들의 세트가 시스템에 제공된다.

310에서, 도메인이 선택된다. 도메인은 도메인들의 세트 중에서 선택된다. 일부 실시예들에서, 도메인은 대응 도메인이 시스템의 고객에 대응하거나 그러한 고객이 시스템에 의해 제공되는 서비스 레벨에 가입했다는 결정에 기초하여 선택된다.

315에서, 선택된 도메인과 연관된 레코드가 선택된다. 일부 실시예들에서, 시스템은 도메인에 매핑된 하나 이상의 레코드들(예컨대, 도메인에 대한 사용자의 계정에 매핑된 하나 이상의 레코드들)에 적어도 부분적으로 기초하여 도메인과 연관된 레코드를 결정한다. 레코드의 예들은 도메인, 하위 도메인, IP 주소, 제 3 자 서비스 계정, MX(mail exchange) 레코드, NS(nameserver) 레코드, CNAME(canonical name) 레코드, DNAME(delegation name) 레코드 등을 포함한다. 일부 실시예들에서, 시스템은 도메인과 연관된 레코드들 전체 또는 세트에 대한 반복과 관련하여 레코드를 선택한다.

320에서, 레코드가 댕글링 레코드인지 여부가 결정된다. 일부 실시예들에서, 시스템은 레코드의 등록이 실효 또는 만료되었거나 레코드가 다른 방식으로 등록 가능하다는(예컨대, 시스템이 레코드를 등록할 수 있다는) 결정에 적어도 부분적으로 기초하여 레코드가 댕글링인지 여부를 결정한다.

다양한 실시예들에 따르면, 시스템은 레코드가 댕글링인지 여부를 결정하는 것과 관련하여 하나 이상의 레코드 서비스들에 질의한다. 시스템은 선택된 레코드와 연관된 레코드 서비스를 결정하고, 레코드와 관련된 정보(예컨대 레코드와 관련된 등록 세부 사항들, 등록을 위한 그러한 레코드의 이용 가능성, 레코드에 대한 등록이 실효 또는 만료되었지 여부의 표기 등)를 결정하기 위해 그러한 레코드 서비스에 대한 질의를 생성한다. 일례로서, 도메인의 경우, 시스템은 도메인이 만료되어 등록 가능한지 여부를 결정한다. 시스템은 최상위 도메인 영역 파일들이 도메인을 포함하는지 여부를 결정한다. 예를 들어, 최상위 도메인 영역 파일들이 도메인을 포함하는 경우, 시스템은 대응 레코드(예컨대, 도메인)가 댕글링이 아닌 것으로 간주한다. 최상위 도메인 영역 파일들이 도메인을 포함하지 않는 경우, 시스템은 등록 기관(예컨대 GoDaddy.com과 같은 도메인 등록대행기관)에 질의하여 도메인이 등록(예컨대 구매)될 수 있는지 여부를 결정한다. 일례로서, 도메인이 등록될 수 있다는 결정에 응답하여, 도메인은 댕글링 레코드로 간주된다.

320에서 레코드가 댕글링 레코드라는 결정에 응답하여, 프로세스(300)는 레코드가 댕글링이라는 표시가 제공되는 325로 진행된다. 다양한 실시예들에 따르면, 시스템은 레코드가 댕글링 레코드라는 결정에 응답하여 이전 등록자에게 통지를 제공한다. 일례로서, 시스템은 레코드 서비스 질의(예컨대, 대응 등록 정보에 대한 WHOIS 레코드 질의와 같이 레코드가 최상위 도메인인 경우 WHOIS 레코드 질의)에 적어도 부분적으로 기초하여 레코드와 관련된 연락처 정보를 결정한다. 또 다른 예로서, 시스템이 고객을 대신하여 레코드를 모니터링하는 경우, 레코드가 댕글링이라는 결정에 응답하여, 시스템은 예를 들어 사용자 인터페이스(예컨대, 시스템에 의해 제공되는 대시보드 등) 및/또는 그러한 고객의 연락처 정보를 통해 고객에게 표시를 제공한다. 일부 실시예들에서, 표시 제공에 추가로 또는 대안으로, 시스템은 능동적 조치를 수행한다. 능동적 조치의 예들은 댕글링 레코드와 연관된 주소로의 트래픽을 차단하거나 싱크홀 IP로 트래픽을 리디렉션하는 것 등을 포함한다.

반대로, 320에서 레코드가 댕글링 레코드가 아니라는 결정에 응답하여, 프로세스(300)는 레코드가 댕글링이 아니라는 표시가 제공되는 330로 진행된다. 일부 실시예들에서, 330은 프로세스 300으로부터 제외된다. 예를 들어, 일부 구현들에서, 레코드가 댕글링이 아니라는 결정에 응답하여, 프로세스(300)는 그러한 표시를 제공하지 않으며 레코드에 대응하는 주소에 대한 트래픽을 변경하지 않는다.

335에서는 선택된 도메인과 연관된 다른 레코드들에 대한 확인 또는 결정을 수행할지 여부에 대한 결정이 이루어진다. 선택된 다른 레코드에 대해 결정이 이루어져야 한다는 결정에 응답하여, 프로세스(300)는 315로 돌아가고, 프로세스(300)는 그러한 레코드들이 댕글링 레코드들인지 여부를 결정하기 위해 추가 레코드들이 확인되지 않을 때까지 315-335를 계속 수행한다. 일례로서, 추가 레코드들을 모니터링할지 여부에 대한 결정은 그러한 도메인의 고객과 연관된 레코드들의 세트에 적어도 부분적으로 기초할 수 있다. 다른 예로서, 추가 레코드들이 모니터링되어야 하는지 여부에 대한 결정은 프로세스(300)를 일시 중지하거나 종료하라는 관리자의 명령과 같은 사용자 입력에 기초할 수 있다.

선택된 도메인에 대한 다른 레코드와 관련하여 결정이 이루어지지 않아야 한다는 결정에 응답하여, 프로세스(300)는 다른 도메인에 대한 확인 또는 결정을 수행할지 여부에 대한 결정이 이루어지는 340으로 진행한다. 선택된 다른 레코드에 대해 결정이 이루어져야 한다는 결정에 응답하여, 프로세스(300)는 310로 돌아가고, 프로세스(300)는 그러한 레코드들이 댕글링 레코드들인지 여부를 결정하기 위해 추가 레코드들이 확인되지 않을 때까지 310-340를 계속 수행한다. 일례로서, 프로세스(300)가 호출된 DNS 트래픽 세트가 임의의 추가 도메인들에 대한 트래픽을 포함하지 않는다는 결정에 기초하여 추가 도메인들을 확인할지 여부를 결정한다. 다른 예로서, 프로세스(300)가 호출된 미리 결정된 스케쥴에 따라 시스템이 모니터링할 도메인들의 세트가 어떠한 추가 도메인들도 포함하지 않는다는 결정에 기초하여 추가 도메인들을 확인할지 여부를 결정한다. 다른 예로서, 추가 레코드들이 모니터링되어야 하는지 여부에 대한 결정은 프로세스(300)를 일시 중지하거나 종료하라는 관리자의 명령과 같은 사용자 입력에 기초할 수 있다.

345에서, 프로세스(300)가 완료되었는지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 프로세스(300)는 도메인들의 세트 중에 추가 도메인들이 존재하지 않는다는 결정(예컨대, 프로세스(300)의 적어도 이 반복에 대해)에 응답하여 완료된 것으로 결정되고, 관리자는 프로세스(300)가 일시 중지 또는 중지되어야 한다는 등을 표시한다. 프로세스(300)가 완료되었다는 결정에 응답하여, 프로세스(300)는 종료된다. 프로세스(300)가 완료되지 않았다는 결정에 응답하여, 프로세스(300)는 305로 되돌아간다. 일부 실시예들에서, 프로세스(300)는 다음 예정된 시간에 또는 미리 결정된 시간 이후에 또는 이벤트에 응답하여(예컨대, 의심스러운 DNS 트래픽의 수신에 응답하는 등) 호출된다.

도 4는 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다. 다양한 실시예들에 따르면, 프로세스(300)는 도 1의 시스템(100) 및/또는 도 2의 시스템(200)과 연계하여 구현된다.

다양한 실시예들에 따르면, 레코드가 댕글링 레코드인지 여부를 결정하는 것과 관련하여 프로세스(400)가 호출된다.

405에서, 레코드와 연관된 서비스가 결정된다.

410에서, 질의에 기초하여 레코드의 이용 가능성이 결정 가능한지 여부가 결정된다.

410에서의 질의에 기초하여 레코드의 이용 가능성이 결정 가능하다는 결정에 응답하여, 프로세스(400)는 서비스에 대하여 레코드의 이용 가능성을 질의하기 위해 질의가 송신되는 415로 진행한다.

420에서, 서비스에 대해 레코드가 이용 가능한지 여부에 대한 표시가 수신된다.

425에서, 레코드가 서비스에 대해 이용 가능한지 여부에 대한 표시에 적어도 부분적으로 기초하여 레코드가 댕글링인지 여부에 대한 결정이 이루어진다.

410에서의 질의에 기초하여 레코드의 이용 가능성을 결정할 수 없다는 결정에 응답하여, 프로세스(400)는 레코드의 이용 가능성이 등록(또는 등록 시도)에 기초하여 결정 가능한지 여부에 대한 결정이 이루어지는 435로 진행한다. 435에서 레코드의 이용 가능성이 등록 또는 등록 시도에 기초하여 결정될 수 없다는 결정에 응답하여 프로세스(400)는 430으로 진행된다.

435에서 레코드의 이용 가능성이 등록 또는 등록 시도에 기초하여 결정 가능하다는 결정에 응답하여(또는 레코드의 등록을 시도하겠다는 결정에 응답하여), 프로세스(400)는 등록 요청이 레코드 등록을 관리하는 서비스(예컨대, 레코드 서비스)로 송신되는 440으로 진행한다. 예를 들어, 하위 도메인들에 대한 등록을 제공하는 제 3 자 서비스(예컨대, Shopify, Substack.com, Facebook 등)의 경우, 시스템은 레코드 등록 요청을 보낸다. 또 다른 예로, 도메인과 서비스가 최상위 도메인 등록대행기관(예컨대 GoDaddy.com)인 경우, 시스템은 도메인 등록 요청을 보낸다.

445에서는 등록 요청에 대한 응답이다. 일부 실시예들에서, 응답은 서비스에 대해 레코드 등록이 가능한지 여부를 나타낸다. 일부 실시예들에서, 등록 요청에 대한 응답은 등록 확인이다(예컨대, 시스템은 이전 등록자였던 고객을 대신하여 레코드를 등록할 수 있다 등).

450에서, 등록 요청에 대한 응답에 적어도 부분적으로 기초하여 레코드가 댕글링 레코드인지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 시스템은 레코드 등록이 이용 가능하다는 표시의 수신에 응답하여 또는 시스템이 레코드를 성공적으로 등록한다면(예컨대, 고객을 대신하여) 레코드가 댕글링인 것으로 결정한다.

430에서, 프로세스(400)가 완료되었는지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 프로세스(400)는 시스템이 그러한 레코드들이 댕글링 레코드들인지 여부에 대한 확인을 수행할 레코드들의 세트 중에 추가 레코드들이 없다는 결정에 응답하여 완료된 것으로 결정되고, 관리자는 프로세스(400)가 일시 중지되거나 중지되어야 한다고 표시한다. 프로세스(400)가 완료되었다는 결정에 응답하여, 프로세스(400)는 종료된다. 프로세스(400)가 완료되지 않았다는 결정에 응답하여, 프로세스(400)는 405로 되돌아간다. 일부 실시예들에서, 프로세스(400)는 다음 예정된 시간에 또는 미리 결정된 시간 이후에 또는 이벤트에 응답하여(예컨대, 의심스러운 DNS 트래픽의 수신에 응답하는 등) 호출된다.

도 5는 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다. 다양한 실시예들에 따르면, 프로세스(300)는 도 1의 시스템(100) 및/또는 도 2의 시스템(200)과 연계하여 구현된다.

510에서, 레코드가 댕글링 레코드라는 표시가 획득된다. 일부 실시예들에서, 시스템은 레코드의 등록이 만료 또는 실효되었다는 결정에 응답하여, 또는 레코드가 등록 가능하다는 결정에 응답하여 레코드가 댕글링 레코드라는 표시를 획득한다.

520에서, 레코드가 댕글링 레코드라는 표시가 클라이언트에게 제공된다. 레코드가 댕글링 레코드라는 표시를 획득한 것에 응답하여(예컨대, 대응 레코드가 댕글링 레코드라고 결정한 것에 응답하여), 시스템은 고객(예컨대 고객) 또는 레코드 등록과 연관된 연락처(예컨대, WHOIS 등록자 정보와 같이 이전 레코드 등록에 포함된 연락처 정보에 포함된 연락처)에 (예컨대, 사용자 인터페이스, 대시보드, 문자 메시지, 이메일 등을 통해) 레코드가 댕글링 레코드라는 표시를 통신한다.

530에서, 댕글링 레코드를 해결하라는 요청이 수신되었는지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 시스템은 사용자 등을 대신하여 레코드를 등록하라는 것과 같은 댕글링 레코드를 해결하라는 요청을 수신한다. 일부 실시예들에서, 댕글링 레코드를 해결하라는 시스템 요청은 시스템에 의해 제공되는 댕글링 레코드 서비스의 특정 고객을 위한 정책과 같은 미리 결정된 정책에 적어도 부분적으로 기초하여 자동적으로 생성된다.

530에서 댕글링 레코드를 해결하라는 요청이 수신되었다는 결정에 응답하여, 프로세스(500)는 레코드를 등록하라는 요청이 서비스에 송신되는 540으로 진행한다.

550에서, 레코드가 등록되었는지 여부에 대한 표시가 서비스로부터 수신된다. 서비스(예컨대, 도메인 등록대행기관과 같은 레코드들에 대한 등록을 제공/관리하는 제 3 자 서비스)에 요청을 송신하는 것에 응답하여, 시스템은 레코드가 성공적으로 등록되었는지 여부를 나타내는 응답을 받는다.

560에서, 프로세스(500)가 완료되었는지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 프로세스(400)는 더 이상 레코드들이 댕글링 레코드들로 간주되지 않는다는 결정에 응답하여 완료된 것으로 결정되고, 관리자는 프로세스(500)가 일시 중지 또는 중지해야 한다는 것 등을 표시한다. 프로세스 500이 완료되었다는 결정에 응답하여, 프로세스 400은 종료된다. 프로세스(500)가 완료되지 않았다는 결정에 응답하여, 프로세스(500)는 510로 되돌아간다. 일부 실시예들에서, 프로세스(500)는 다음 예정된 시간에 또는 미리 결정된 시간 이후에 또는 이벤트에 응답하여(예컨대, 의심스러운 DNS 트래픽의 수신에 응답하는 등) 호출된다.

도 6은 본 출원의 다양한 실시예들에 따른 레코드가 댕글링인지 여부를 결정하기 위한 방법의 흐름도이다. 다양한 실시예들에 따르면, 프로세스(300)는 도 1의 시스템(100) 및/또는 도 2의 시스템(200)과 연계하여 구현된다.

다양한 실시예들에 따르면, 프로세스(600)는 DNS 트래픽 수신에 응답하여 호출된다. 예를 들어, 프로세스(600)는 DNS 질의에 대한 응답 또는 DNS 질의에 대해 호출된 가로채기에 응답하여 호출된다.

605에서 DNS 트래픽이 수신된다. 일부 실시예들에서, DNS 질의들 및/또는 DNS 질의들에 대한 응답들을 가로채는 가로채기와 관련하여 DNS 트래픽이 수신된다.

610에서, 도메인이 결정된다. 시스템은 적어도 부분적으로 DNS 트래픽에 기초하여 도메인을 결정한다. 일부 실시예들에서, 시스템은 DNS 질의에 포함되거나 DNS 질의에 대한 응답으로 도메인을 결정한다.

615에서, 도메인과 연관된 레코드가 선택된다. 일부 실시예들에서, 시스템은 트래픽에서 DNS 트래픽 및/또는 도메인을 분석하고, 시스템은 도메인에 대응하는 레코드를 결정한다. 일부 실시예들에서, 시스템은 도메인에 매핑된 하나 이상의 레코드들(예컨대, 도메인에 대한 사용자의 계정에 매핑된 하나 이상의 레코드들)에 적어도 부분적으로 기초하여 도메인과 연관된 레코드를 결정한다. 레코드의 예들은 도메인, 하위 도메인, IP 주소, 제 3 자 서비스 계정, MX(mail exchange) 레코드, NS(nameserver) 레코드, CNAME(canonical name) 레코드, DNAME(delegation name) 레코드 등을 포함한다. 일부 실시예들에서, 시스템은 도메인과 연관된 레코드들 전체 또는 세트에 대한 반복과 관련하여 레코드를 선택한다.

620에서, 도메인과 연관된 레코드가 댕글링인지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 625는 도 3의 프로세스(300)의 320, 또는 도 4의 프로세스(400)의 425 또는 450에 대응하거나 유사하다.

620에서 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 프로세스(600)는 레코드가 댕글링이라는 표시가 제공되는 625로 진행된다. 일부 실시예들에서, 625는 도 3의 프로세스(300)의 325에 대응하거나 유사하다. 일부 실시예들에서, 프로세스(600)는 625를 포함하지 않는다(예컨대, 레코드가 댕글링 레코드라는 통지 또는 표시가 제공되지 않음).

630에서, DNS 트래픽에 대한 응답이 제공된다. 일부 실시예들에서, 레코드가 댕글링 레코드라는 결정에 응답하여, 시스템은 능동적 조치를 수행한다. DNS 트래픽의 경우, 능동적 조치는 레코드(예컨대 IP 주소, 도메인 등)에 대한 DNS 트래픽을 차단하거나 DNS 트래픽을 싱크홀 IP로 리디렉션하는 것을 포함할 수 있다.

620에서 도메인과 연관된 레코드가 댕글링이 아니라는 결정에 응답하여, 프로세스(600)는 DNS 트래픽에 응답이 제공되는 635로 진행한다. 일부 실시예들에서, 레코드가 댕글링 레코드가 아니라는 결정에 응답하여 아무런 액션도 수행되지 않거나 통지가 제공되지 않는다.

640에서는 선택된 도메인과 연관된 다른 레코드들에 대한 확인 또는 결정을 수행할지 여부에 대한 결정이 이루어진다. 선택된 다른 레코드에 대해 결정이 이루어져야 한다는 결정에 응답하여, 프로세스(600)는 615로 돌아가고, 프로세스(600)는 그러한 레코드들이 댕글링 레코드들인지 여부를 결정하기 위해 추가 레코드들이 확인되지 않을 때까지 615-640를 계속 수행한다. 일례로서, 추가 레코드들을 모니터링할지 여부에 대한 결정은 그러한 도메인의 고객과 연관된 레코드들의 세트에 적어도 부분적으로 기초할 수 있다. 다른 예로서, 추가 레코드들이 모니터링되어야 하는지 여부에 대한 결정은 프로세스(600)를 일시 중지하거나 종료하라는 관리자의 명령과 같은 사용자 입력에 기초할 수 있다.

선택된 도메인에 대한 다른 레코드에 대해 결정이 이루어지지 않는다는 결정에 응답하여, 프로세스(600)는 다른 도메인에 대한 확인 또는 결정을 수행할지 여부에 대한 결정이 이루어지는 645으로 진행한다. 다른 도메인에 대해 결정이 이루어져야 한다는 결정에 응답하여, 프로세스(600)는 610로 돌아가고, 프로세스(600)는 그러한 레코드들이 댕글링 레코드들인지 여부를 결정하기 위해 추가 레코드들이 확인되지 않을 때까지 610-645를 계속 수행한다. 일례로서, 프로세스(600)가 호출된 DNS 트래픽의 세트가 어떤 추가 도메인들에 대한 트래픽도 포함하지 않는다는 결정에 기초하여 추가 도메인들을 확인할지 여부를 결정한다. 다른 예로서, 프로세스(600)가 호출된 미리 결정된 스케쥴에 따라 시스템이 모니터링할 도메인들의 세트가 어떠한 추가 도메인들도 포함하지 않는다는 결정에 기초하여 추가 도메인들을 확인할지 여부를 결정한다. 다른 예로서, 추가 레코드들이 모니터링되어야 하는지 여부에 대한 결정은 프로세스(600)를 일시 중지하거나 종료하라는 관리자로부터의 명령과 같은 사용자 입력에 기초할 수 있다.

650에서, 프로세스(600)가 완료되었는지 여부에 대한 결정이 이루어진다. 일부 실시예들에서, 프로세스(600)는 도메인들의 세트 중에 추가 도메인들이 존재하지 않는다는 결정(예컨대, 프로세스(600)의 적어도 이 반복에 대해)에 응답하여 완료된 것으로 결정되고, 관리자는 프로세스(600)가 일시 중지되거나 중지되어야 한다는 것 등을 표시한다. 프로세스(600)가 완료되었다는 결정에 응답하여, 프로세스(600)는 종료된다. 프로세스(600)가 완료되지 않았다는 결정에 응답하여, 600 300은 605로 되돌아간다. 일부 실시예들에서, 프로세스(600)는 DNS 트래픽과 관련하여 다음 인터셉트에서 호출되거나 또는 이벤트에 응답하여(예컨대, 의심스러운 DNS 트래픽의 수신에 응답하는 등) 호출된다.

본 명세서에 설명된 실시예들의 다양한 예들은 흐름도들과 관련하여 설명된다. 예시들은 특정 순서로 수행되는 특정 단계들을 포함할 수 있지만, 다양한 실시예들에 따르면, 다양한 단계들이 다양한 순서들로 수행될 수 있으며 및/또는 다양한 단계들은 단일 단계로 결합되거나 병렬로 결합될 수 있다.

전술한 실시예들은 이해의 명확성을 위해 어느 정도 상세하게 설명되었지만, 본 발명은 제공된 세부사항들에 제한되지 않는다. 본 발명을 구현하는 많은 대안의 방법들이 있다. 개시된 실시예들은 예시적이며 제한적이지 않다.

Claims (20)

1. 시스템에 있어서,
   도메인들의 세트를 획득하고;
   상기 도메인들의 세트에 포함된 도메인과 연관된 레코드가 댕글링(dangling)인지 여부를 결정하고;
   상기 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 등록자(registrant)에게 상기 레코드가 댕글링이라는 통지를 제공하도록 구성된 하나 이상의 프로세서들; 및
   상기 프로세서에 연결되고 상기 프로세서에 명령들을 제공하도록 구성된 메모리를 포함하는, 시스템.
2. 제 1 항에 있어서, 상기 도메인으로 보내진 DNS 질의의 수신과 동시에 상기 레코드가 등록에 이용 가능하다는 결정에 응답하여, 상기 도메인과 연관된 레코드가 댕글링인 것으로 결정되는, 시스템.
3. 제 1 항에 있어서, 상기 하나 이상의 프로세서들은 또한 댕글링인 것으로 결정된 상기 레코드와 연관된 상기 도메인에 대한 DNS 질의를 차단하도록 구성되는, 시스템.
4. 제 1 항에 있어서, 상기 레코드는 최상위 도메인, 하위 도메인, 및 IP 주소 중 하나 이상에 대응하는, 시스템.
5. 제 1 항에 있어서, 상기 레코드가 댕글링인지 여부를 결정하는 것은:
   상기 도메인과 연관된 최상위 도메인이 등록에 이용 가능한지 여부를 확인하는 것을 포함하는, 시스템.
6. 제 4 항에 있어서, 상기 최상위 도메인이 등록에 이용 가능한지 여부를 확인하는 것은:
   상기 최상위 도메인을 등록하기 위해 도메인 등록대행기관(domain registrar)에 질의하는 것을 포함하는, 시스템.
7. 제 1 항에 있어서, 상기 레코드가 댕글링인지 여부를 결정하는 것은:
   상기 도메인과 연관된 하위 도메인이 등록에 이용 가능한지 여부를 확인하는 것을 포함하는, 시스템.
8. 제 7 항에 있어서, 상기 하위 도메인이 등록에 이용 가능한지 여부를 확인하는 것은:
   상기 도메인과 연관된 최상위 도메인의 등록자에 의해 제공되는 서비스에 질의하는 것을 포함하고, 상기 서비스는 하위 도메인 등록을 시도하기 위해 질의되는, 시스템.
9. 제 1 항에 있어서, 상기 레코드가 댕글링인지 여부를 결정하는 것은:
   퍼블릭 클라우드(public cloud)에서 상기 도메인과 연관된 IP 주소를 할당하려고 시도하는 것을 포함하는, 시스템.
10. 제 1 항에 있어서,
    상기 하나 이상의 프로세서들은 또한 DNS 질의를 수신하도록 구성되고;
    상기 레코드가 댕글링인지 여부를 결정하는 것은 상기 DNS 질의의 수신에 응답하여 수행되는, 시스템.
11. 제 10 항에 있어서, 연관된 레코드가 댕글링인지 여부가 결정되는 도메인은 상기 DNS 질의에 적어도 부분적으로 기초하여 선택되는, 시스템.
12. 제 11 항에 있어서, 상기 도메인은 상기 DNS 질의가 상기 도메인으로 보내진다는 결정에 적어도 부분적으로 기초하여 선택되는, 시스템.
13. 제 10 항에 있어서, 상기 레코드가 댕글링인지 여부에 대한 결정은 상기 DNS 질의의 해결과 동시에 수행되는, 시스템.
14. 제 1 항에 있어서, 상기 레코드가 댕글링인지 여부를 결정하는 것은 미리 결정된 시간 간격으로 수행되는, 시스템.
15. 제 1 항에 있어서, 상기 하나 이상의 프로세서들은 반복적으로 (i) 도메인들의 세트로부터 특정 도메인을 선택하고, (ii) 특정 도메인과 연관된 특정 레코드가 댕글링인지 여부를 결정하도록 구성되는, 시스템.
16. 제 1 항에 있어서, 상기 등록자에게 상기 통지를 제공하는 것은:
    상기 레코드와 연관된 특정 등록자를 결정하는 것; 및
    상기 특정 등록자에게 통신문(communication)을 송신하는 것을 포함하는, 시스템.
17. 제 16 항에 있어서, 상기 통신문은 이메일인, 시스템.
18. 제 1 항에 있어서, 상기 하나 이상의 프로세서들은 또한:
    댕글링 레코드와 연관된 상기 도메인에 대한 트래픽을 수신하고;
    상기 도메인과 연관된 고객에 대한 고객 보안 정책에 따라 상기 트래픽을 라우팅하도록 구성되는, 시스템.
19. 방법에 있어서,
    하나 이상의 프로세서들에 의해 도메인들의 세트를 획득하는 단계;
    상기 하나 이상의 프로세서들에 의해, 상기 도메인들의 세트에 포함된 도메인과 연관된 레코드가 댕글링인지 여부를 결정하는 단계; 및
    상기 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 등록자에게 상기 레코드가 댕글링이라는 통지를 제공하는 단계를 포함하는, 방법.
20. 비일시적 컴퓨터 판독 가능 매체에 구현되고 컴퓨터 명령들을 포함하는 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 명령들은:
    하나 이상의 프로세서들에 의해 도메인들의 세트를 획득하고;
    상기 하나 이상의 프로세서들에 의해, 상기 도메인들의 세트에 포함된 도메인과 연관된 레코드가 댕글링인지 여부를 결정하고;
    상기 도메인과 연관된 레코드가 댕글링이라는 결정에 응답하여, 등록자에게 상기 레코드가 댕글링이라는 통지를 제공하는 것인, 컴퓨터 프로그램 제품.