Inline identification and blocking of dangling DNS records

Abstract

A method, system, and computer system for identifying dangling records are disclosed. The method includes obtaining a domain set, determining whether a record associated with a domain included in the domain set is dangling, and responsive to determining that the record associated with the domain is dangling, providing a notification to a registrar that the record is dangling.

Description

Technical Field

[0001] This invention relates to the technical field of computer network security, and more particularly to methods and systems for identifying suspending records. Background Technology

[0002] Malicious individuals attempt to compromise computer systems in a variety of ways. As an example, such an individual might seek to register a domain or subdomain that was previously registered (e.g., to a legitimate entity or service) and has become available for some reason, such as if the registrant mistakenly allowed such a registration to become invalid. Upon successful registration of the domain or subdomain, the malicious individual might seek to host malicious services on such domain or subdomain, such as client terminals that attempt to access services previously provided by the legitimate entity or service, leading to malware infections. Therefore, there is a continuous need for improved techniques to identify resources exposed to hijacking by malicious individuals. Summary of the Invention

[0003] According to one aspect of the present invention, a system is disclosed, comprising: one or more processors configured to: obtain DNS traffic at least partially based on the interception of network traffic, the DNS traffic including DNS queries directed to a domain; obtain one or more domain sets at least partially based on the DNS traffic; and, in response to receiving a DNS query, determine whether a record associated with a domain included in the domain set is dangling, wherein: determining whether a record associated with the domain is dangling includes: querying a record registration service for registration information corresponding to a record associated with the domain; and determining whether a record associated with the domain is dangling based at least partially on the registration information; and determining that the record is dangling in response to a determination that a record associated with the domain is available for registration occurring simultaneously with receiving a DNS query directed to the domain; and providing a notification to a registrant that the record is dangling in response to determining that the record associated with the domain is dangling; and

[0004] The memory is coupled to the processor and configured to provide instructions to the processor.

[0005] According to another aspect of the invention, a method is disclosed, comprising: obtaining DNS traffic at least partially based on the interception of network traffic, the DNS traffic including DNS queries directed to a domain; obtaining one or more domain sets by one or more processors at least partially based on the DNS traffic; and, in response to receiving a DNS query, determining by the one or more processors whether a record associated with a domain included in the domain set is dangling, wherein: determining whether a record associated with a domain is dangling includes: querying a record registration service for registration information corresponding to a record associated with the domain; and determining whether a record associated with a domain is dangling based at least partially on the registration information; and determining that the record is dangling in response to a determination that a record associated with the domain is available for registration occurring simultaneously with receiving a DNS query directed to the domain; and providing a notification to a registrant that the record is dangling in response to the determination that the record associated with the domain is dangling. Attached Figure Description

[0006] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings.

[0007] Figure 1 This is a block diagram of a system for detecting suspended records according to various embodiments of this application.

[0008] Figure 2 This is a block diagram of a system for detecting suspended records according to various embodiments of this application.

[0009] Figure 3 This is a flowchart of a method for determining whether a record is suspended, according to various embodiments of this application.

[0010] Figure 4 This is a flowchart of a method for determining whether a record is suspended, according to various embodiments of this application.

[0011] Figure 5 This is a flowchart of a method for providing an indication that a record is suspended, according to various embodiments of this application.

[0012] Figure 6 This is a flowchart of a method for determining whether a record is suspended, according to various embodiments of this application. Detailed Implementation

[0013] This invention can be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by memory coupled to the processor. In this specification, these implementations or any other form of the invention may take may be referred to as technology. Generally, the order of steps of the disclosed process may be changed within the scope of the invention. Unless otherwise stated, components such as processors or memory described as being configured to perform a task can be implemented as: general components temporarily configured to perform the task at a given time, or specific components manufactured to perform the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0014] The following provides a detailed description of one or more embodiments of the invention, along with accompanying figures illustrating the principles of the invention. The invention is described in relation to such embodiments, but is not limited to any particular embodiment. The scope of the invention is defined only by the claims, and the invention covers many alternatives, modifications, and equivalents. To provide a thorough understanding of the invention, numerous specific details are set forth in the following description. These details are provided for illustrative purposes, and the invention can be practiced according to the claims without requiring some or all of these specific details. For clarity, technical materials known in the art related to the invention are not described in detail so as not to unnecessarily obscure the invention.

[0015] A system for determining whether a record corresponds to a dangling record is disclosed. The system includes a memory and one or more processors. The one or more processors are configured to obtain a set of domains, determine whether a record associated with a domain included in the set is dangling, and, in response to determining that a record associated with a domain is dangling, provide a notification to a registrant that the record is dangling.

[0016] As used herein, the term “suspended” refers to a state in which a record has been previously registered, and the current registration of the record is incomplete or otherwise invalid, and the registration of the record is potentially susceptible to third-party registration.

[0017] As used herein, the term "record" refers to an Internet resource that can be registered or assigned to a party. Examples of records include domains, subdomains, IP addresses, accounts using third-party services, mail exchange (MX) records, name server (NS) records, canonical name (CNAME) records, delegated name (DNAME) records, and so on.

[0018] Malicious individuals can monitor or seek out dangling records to deceive third parties seeking services or information from them. For example, a malicious party might attempt to register a domain they know has expired and that genuinely provided services to a third party before the record's registration became invalid. Consequently, incoming and outgoing communications regarding records such as domains would be exposed to the malicious party. If the malicious party successfully registers an expired record, they can send emails or other communications to third parties unaware of the changes in the record's registration. Similarly, if a malicious party successfully registers an expired record, they can set up redirects so that third parties attempting to access the record (such as a domain) are redirected to a malicious party or attacker who now owns the record or otherwise has registrations related to it. In the case of a domain, if the malicious party successfully registers the domain, they could potentially hijack authoritative DNS servers. Therefore, proactive detection of dangling records is necessary to warn registrants about potentially expired dangling records they have registered.

[0019] According to various embodiments, the system determines whether a record corresponds to a dangling record based at least in part on the determination that the record is available for registration or allocation. In some embodiments, the system determines whether a record is dangling concurrently with DNS traffic. For example, in response to receiving a DNS query, the system determines the record corresponding to that DNS query (e.g., domain, subdomain, IP address, etc.), and the system determines whether a record is dangling concurrently with the service of the DNS query. In some embodiments, the system intercepts a DNS query or intercepts a response to a DNS query, and the system determines whether a record is dangling (e.g., before the response is delivered to the client from which the DNS query originated). In some embodiments, the system determines whether a record is dangling according to a predetermined schedule. For example, the system receives (or manages) a set of records, such as records associated with one or more clients, and iterates through the set of records at predefined time intervals to determine whether a record is dangling. The predefined time intervals can be set to daily, weekly, monthly, etc. Various other time intervals or schedules can be set based on user (such as administrator) configuration or requests. Regarding top-level domains, a grace period is typically extended to registrants to restore the domain before the failed domain becomes publicly available. The grace period is typically two months. Therefore, in some embodiments, the system performs checks across a domain set every three months (or an additional period of more than two months to allow expired registrations to be publicly exposed). A suspicious party registers a record (e.g., a domain) between the time its registration expires and the time the system performs the check to determine if the record is vacant. Thus, in various embodiments, the system optimizes or reduces the amount of time between a record's expiration or invalidation and the record's check. In some embodiments, the system stores expected expiration dates corresponding to one or more records, and the system queries third-party services that provide registration for a specific record at a predetermined time period after the expected registration date. In some embodiments, the domain set may correspond to one or more domains associated with a user or customer (e.g., a customer of a service provided by the system). In some embodiments, the domain set corresponds to multiple domains across a set of users or customers.

[0020] According to various embodiments, in response to determining that a record corresponds to a dangling record, the system provides an indication that the record is dangling (also referred to herein as a dangling record). In some embodiments, the system determines contact information about the registrant associated with the record and transmits the indication that the record is dangling to an address or contact person included in the contact information. The indication that the record is dangling may include a notification that the record is dangling and an indication that the record may be under attack by a malicious attacker (e.g., the record may have been registered by a third party). The address included in the contact information may include an email address, a phone number, an account identifier (e.g., for an account associated with a system used to check whether an account record is dangling). In some embodiments, the system determines contact information about the registrant associated with the record based at least in part on querying the service associated with the record. For example, in the case that the record is a domain, the system queries the WHOIS record for that domain and obtains registration information from the WHOIS record. In some embodiments, in response to determining that a record is a dangling record, the system communicates with the registrar associated with the record (e.g., a service that provides services to registrants regarding the record) and provides such a registrar with an indication that the record may be under attack by a malicious attacker.

[0021] In some embodiments, in response to determining that a record is dangling, the system blocks traffic destined for that record. For example, if the dangling record is a domain, the system proactively blocks DNS traffic destined for that domain, or provides an indication or instruction to another network device to block DNS traffic destined for that domain. As another example, if the determination that a record is dangling occurs simultaneously with DNS traffic directed to that record, the system blocks DNS traffic destined for that record, or returns a sinkhole address / redirects to the client from which such DNS traffic originates. As another example, in response to determining that a record is dangling, the system updates firewall policies, such as to block (or redirect) traffic destined for that record to a different address associated with a previous registrant associated with that record. In some embodiments, the system stores a whitelist of records (e.g., domains) whose traffic is not blocked or redirected. For example, even if a record is determined to be dangling, the system allows traffic to that record (e.g., the system does not block or redirect traffic to records on the whitelist). The whitelist may be configurable, such as by an administrator, a customer, etc.

[0022] According to various embodiments, the system for detecting dangling records or determining whether a record is a dangling record is provided by one or more servers. For example, the system could be a cloud service provided to various users or clients. As another example, the one or more servers receive queries from passive DNS services, DNS security servers, DNS resolvers, etc.

[0023] This system improves the security of records (e.g., record registration) and reduces the likelihood of records being hijacked by malicious third parties. Related technical systems can identify dangling records within their own systems, such as registrations used for management by such related systems. Such related technical systems typically require access to the registered account. For example, a domain registrar can identify for its clients those domain registrations or subdomain registrations that have expired. Various embodiments are not limited to detecting dangling records within records managed by the system (e.g., domains). For example, various embodiments provide scalable record detection across third-party service providers and platforms. Systems according to various embodiments do not require access to the registrant's account, such as via credentials associated with the registrant, in order to detect dangling records for such registrants. In some embodiments, the system uses information exposed to the public to determine whether a record is a dangling record. For example, the system may query a publicly available third-party service via an application programming interface (API) developed for such a third-party service.

[0024] Third-party service providers often restrict or limit the number of queries that an endpoint (e.g., a system) can send to the third-party service provider, such as via an API. In some cases, third-party service providers offer select services, typically requiring a paid subscription model, where the number of queries is not limited, or the cap is increased relative to the free service. According to various embodiments, the system registers multiple accounts on each of one or more third-party services and uses said multiple accounts to perform queries on said one or more third-party services against dangling records of a predetermined set of records (e.g., a set of records corresponding to one or more of the system's clients).

[0025] Figure 1 This is a block diagram of a system for detecting suspended records according to various embodiments of this application. According to various embodiments, at least a portion of system 100 is implemented... Figure 2 System 200. System 100 implementation. Figure 3 Process 300 Figure 4 Process 400 Figure 5 Process 500 and / or Figure 6 The process is 600.

[0026] In the illustrated example, system 100 includes a dangling record service 110. System 100 may further include one or more of a first record service 130, a second record service 140, a third record service 150, an administrator system 160, and / or a client system 170. System 100 may further include a network 180. According to various embodiments, the dangling record service 110 includes one or more of a business application layer 115 and a database layer 120.

[0027] The first record service 130, the second record service 140, and / or the third record service 150 provide services to one or more users or customers. According to various embodiments, the services include the registration of one or more records. As an example, the first record service 130 is a domain registrar. As another example, the second service 140 is a service provider offering subdomain registration (e.g., Shopify, Facebook, Google, Microsoft, etc.). Examples of records include domains such as top-level domains or subdomains, IP addresses, accounts, etc.

[0028] According to various embodiments, the dangling record service 110 determines whether a record corresponds to a dangling record. As an example, the dangling record service 110 obtains a domain set, determines whether a record associated with a domain included in that domain set is dangling, and, in response to determining that a record associated with that domain is dangling, provides a notification to the registrant that the record is dangling. As another example, in addition to providing a notification that a record is dangling, or as an alternative, the dangling record service 100 blocks or redirects traffic (e.g., DNS traffic) destined for that record.

[0029] like Figure 1 As illustrated, the suspended record service 110 may include one or more of the business application layer 115 and / or the database layer 115.

[0030] The business application layer 115 is used in connection with controlling and / or configuring the dangling record service 110. One or more policies can be set via the business application layer 115 to monitor or detect dangling records. For example, an administrator uses the administrator system 160 to communicate with the business application layer 115 to configure (e.g., define) the domain set or record set for which the dangling record service 110 should monitor or detect dangling records. As another example, an administrator communicates with the business application layer 115 to request or instruct the dangling record service 110 to determine whether a record is dangling, or to set a schedule or time period for the dangling record service 110 to determine whether a record is dangling.

[0031] Database layer 120 or storage layer is configured to store a mapping of users (or clients) to records, such as records for which the dangling record service 110 monitors or detects whether a record among such records has become dangling. In some embodiments, database layer 120 stores one or more policies that the dangling record service 110 uses to determine whether one or more records correspond to dangling records. Database layer 120 may further store mappings of the one or more policies to one or more users or clients to which the respective policies apply. The policies may include policies indicating schedules or time periods that the dangling record service 110 uses to determine whether one or more records correspond to dangling records.

[0032] According to various embodiments, the dangling record service 110 determines whether one or more records associated with one or more record services (e.g., first record service 130, second record service 140, and / or third record service 150) are dangling. For example, the dangling record service 110 queries the corresponding one or more record services in connection with determining whether the corresponding record(s) are dangling. In some embodiments, the query includes a query for registered records (e.g., if registration of a record is permitted or possible, the dangling record service 110 may consider such a record dangling because it can be used for registration by a suspicious third party). In some embodiments, the dangling record service 110 transmits the query to the record service via an API corresponding to the record service. For example, a business application layer 115 is used to invoke the record service via the API. Queries about one or more records to one or more record services can be sent individually or in batches. For example, the dangling record service 110 transmits multiple queries to a specific record service for all records or subsets of records for which it monitors / detects dangling records.

[0033] System 100 further includes one or more networks, such as network 18, through which administrator system 160 and / or client system 170 communicate with one or more of the following overhanging record services 110, such as business application layer 115 and / or database layer 120. In various embodiments, network 125 includes one or more wired networks and / or wireless networks such as cellular networks, wireless local area networks (WLANs), or any other suitable network. In some embodiments, business application layer 115 and / or database layer 120 are each implemented by one or more servers. System 100 may include various other systems or terminals.

[0034] Figure 2 This is a block diagram of a system for detecting suspended records according to various embodiments of this application. According to various embodiments, and... Figure 1System 200 is implemented in relation to system 100, such as for levitation recording service 110. In various embodiments, with Figure 3 Process 300 Figure 4 Process 400 Figure 5 Process 500 and / or Figure 6 The process 600 is related to the implementation of system 200.

[0035] System 200 can be implemented by one or more devices, such as a server. System 200 can be implemented at various locations on a network. For example, a dangling record service is deployed on a DNS resolver. As another example, a dangling record service is deployed on a firewall. As another example, a dangling record service is a service provided to a DNS resolver (e.g., the dangling record service is deployed on one or more remote servers that serve queries from a DNS resolver or firewall to determine whether a record, such as a domain undergoing DNS traffic, corresponds to a dangling record). As another example, a dangling record service is deployed at a location on a network whereby the dangling record service intercepts DNS traffic such as DNS queries and / or responses transmitted in response to DNS queries.

[0036] In the example shown, system 200 implements one or more modules related to determining whether a record is a dangling record. System 200 includes a communication interface 205, one or more processors 210, a storage device 215, and / or a memory 220. The one or more processors 210 include one or more of the following: a communication module 225, a record selector module 230, a query module 235, a registration module 240, a dangling record determination module 245, and / or an active measures module 250.

[0037] In some embodiments, system 200 includes a communication module 225. System 200 uses communication module 225 to communicate with various client terminals or user systems, such as administrator systems. In some embodiments, system 200 uses communication module 225 to communicate with one or more record services, such as determining, in relation to sending a query, whether a record is available with respect to a particular service (e.g., determining whether a record is available for registration, determining whether a record's registration has expired / dead, attempting to register a record, etc.), and / or receiving responses to queries. For example, communication module 225 provides information to be transmitted to communication interface 205. As another example, communication interface 205 provides information received by system 200 to communication module 225. Communication module 225 is configured to receive one or more DNS queries from various client terminals or systems (such as firewalls, DNS resolvers, etc.). For example, a dangling record service is used to intercept DNS traffic and identify dangling records before or in relation to providing a response to DNS traffic. Communication module 225 is configured to receive one or more settings or configurations from an administrator or user, such as a client, to dangling record service 110. Examples of the one or more settings or configurations include configurations for which dangling records should be monitored / detected, policies for which dangling records should be monitored / detected (e.g., scheduling to determine whether a record set includes dangling records, the time period or frequency for which checks should be performed on dangling records, mapping of contact information to records, whitelisting of records (e.g., domains for which traffic should still be allowed even though the corresponding record is determined to be dangling), etc.

[0038] According to various embodiments, system 200 includes a record selection module 230. System 200 uses record selection module 230 in connection with determining whether a record is a dangling record (e.g., a record for which a query is to be sent to a corresponding record service such as a domain registrar). In some embodiments, record selection module 230 determines records based at least in part on DNS traffic. For example, in response to receiving a DNS query, query system 200 determines whether a record corresponding to the DNS query (e.g., top-level domain, subdomain, IP address, etc.) is a dangling record. In some embodiments, record selection module 230 is based at least in part on a record set (such as a record set for which system 200 monitors / detects records that are dangling records), or a record set corresponding to a particular user or client. For example, if system 200 stores a policy for monitoring record sets according to a predetermined schedule or frequency, and in response to a determination to perform such monitoring at the current time based at least in part on the predetermined schedule or frequency, record selection module 230 determines a record set corresponding to such a policy.

[0039] In some embodiments, system 200 includes a query module 235. System 200 uses query module 235 to query one or more record services (e.g., a first record service 130, a second record service 140, and / or a third record service 150). Query module 235 is used to query the one or more record services in relation to determining whether one or more records are dangling. For example, query module 235 queries a record service to register a specific record (e.g., in relation to system 200 determining whether a specific record is available for registration). As an example, if the record is an IP address, query module 235 queries a public cloud to determine if system 200 can obtain the IP address. As another example, if the record is a domain, query module 235 queries a registrar or service that provides a TLD (Terrain Directory) file. As another example, if the record is a subdomain, query module 235 queries a third-party service that provides the subdomain (e.g., Shopify, Google, Microsoft, Facebook, etc.).

[0040] In some embodiments, system 200 includes a registration module 240. System 200 uses registration module 240 to attempt to register records with a record service and / or manage record registrations with the record service. For example, registration module 240 is configured to attempt to register accounts or subdomains with third-party services (e.g., Shopify, Google, Microsoft, Facebook, Etsy, Pinterest, etc.). In some embodiments, a user configures a policy for system 200 to register a record in response to determining that a specific record associated with the user is dangling. For example, according to such a policy, in response to determining that a record's registration has expired / expired, system 200 uses registration module 240 to re-register a record for the user (e.g., a previous registrant who mistakenly allowed the record's registration to expire / expirate).

[0041] In some embodiments, system 200 includes a dangling record determination module 245. The system uses the dangling record determination module 245 to determine whether a record is a dangling record. For example, the dangling record determination module 245 determines whether a record is dangling based at least in part on responses received by query module 235 related to a query for one or more record services. If query module 235 receives an indication that a record has expired / expired, the dangling record determination module 245 determines that the record is a dangling record. As another example, the dangling record determination module 245 determines whether a record is dangling based at least in part on registration module 240 determining that the record is available for registration with a third-party service (e.g., registration module 240 is capable of creating accounts or registering subdomains with third-party services such as Shopify, Microsoft, etc.).

[0042] In some embodiments, system 200 includes an active measures module 250. In response to system 200 determining that a record is a dangling record, system 200 uses active measures 250 to perform one or more operations. The one or more operations performed in response to the determination that a record is a dangling record can be preset in one or more policies or preferences, such as policies or preferences of system 200 on behalf of its clients monitoring the record. Examples of the one or more operations include providing a notification or indication that a record is a dangling record, registering the record, blocking traffic to the domain or address corresponding to the dangling record, redirecting traffic to the domain or address corresponding to the dangling record, etc. As an example, in response to system 200 determining that a record is a dangling record, active measures module 250 transmits an indication that the record is dangling (e.g., via communication module 225). This indication is transmitted to contact information associated with the record (e.g., a contact person for the user or client that system 200 is monitoring the record, a registrant identified by the registrar associated with the record, etc.). As another example, in response to system 200 determining that a record is a dangling record, proactive action module 250 may register the record on behalf of a user or customer (e.g., a previous registrant of such a record).

[0043] According to various embodiments, storage device 215 includes one or more of the following: file system data 260, domain data 262, record data 264, and / or policy data 266. Storage device 215 includes shared storage device (e.g., network storage system) and / or database data, and / or user activity data.

[0044] In some embodiments, file system data 260 includes databases, such as one or more datasets (e.g., one or more datasets for one or more tenants). File system data 260 includes customer-related data, data used in relation to system 200 determining whether a record is a dangling record, historical information related to DNS queries, whitelists of records for domains (e.g., a set of domains for which traffic is permitted or otherwise not blocked in response to the determination that a domain is a dangling record), etc.

[0045] Domain data 262 includes data relating to one or more domains. As an example, domain data includes relationships and associations between domains (e.g., top-level domains, subdomains, etc.) and address information such as IP addresses. As an example, domain data includes a mapping of domains to registrants for monitoring / detecting dangling records, such as users or clients of services provided by system 200. As another example, domain data 262 includes information relating to domains included in DNS queries or responses to DNS queries (e.g., domains intercepted by system 200 from DNS queries or responses to DNS queries).

[0046] Record data 264 includes information relating to one or more records for which system 200 determines whether a particular record is a dangling record. In some embodiments, record data 264 includes a mapping of records to a record service that manages or provides registration for such records (e.g., a domain registrar, a public cloud, a third-party service that allows users to register for subdomains such as Shopify, etc.). As an example, record data 264 includes a mapping of an API or communication protocol or syntax that system 200 uses to communicate with the record service(s). As another example, record data 264 includes one or more indicators that respectively indicate whether the one or more records correspond to dangling records.

[0047] Policy data 266 includes one or more policies that system 200 uses to determine whether one or more records correspond to dangling records. For example, policy data 266 includes a mapping of records to schedules or time periods, which system 200 uses to perform checks to determine if a record is a dangling record. As another example, policy data 266 includes a mapping of records to proactive actions to be taken in response to determining that a particular record is a dangling record. As yet another example, policy data 266 includes a mapping of users or customers to proactive actions to be taken in response to determining that a user's or customer's record is a dangling record. Various other policies may be stored in policy data 266.

[0048] According to various embodiments, memory 220 includes application execution data 275. Application execution data 275 includes data acquired or used in relation to the execution of an application, such as an application performing a process for determining whether a record is a dangling record, or an application performing a process for configuring system 200 with regard to settings or policies used in relation to determining whether a record is a dangling record. In embodiments, applications include one or more applications that perform one or more of the following: receiving and / or performing queries or tasks, generating reports in response to performed queries or tasks and / or configuring information in response to performed queries or tasks, and / or providing information to a user in response to queries or tasks. Other applications include any other suitable applications (e.g., applications for querying a logging service, applications for establishing communication with a logging service, applications for performing proactive measures, applications for registering records with third-party services, report preparation applications, user interface applications, data analysis applications, applications for blocking or redirecting traffic, user authentication applications, etc.).

[0049] Figure 3 This is a flowchart of a method for determining whether a record is suspended, according to various embodiments of this application. According to various embodiments, and... Figure 1 System 100 and / or Figure 2The system 200 is related to the implementation process 300.

[0050] In some embodiments, process 300 is invoked according to a predetermined schedule, such as a schedule set by a client of a suspending record service (e.g., a monitoring or detection service). Process 300 may be invoked in response to user input, such as a request from an administrator.

[0051] At 305, a domain set is received. In some embodiments, the system receives from a database of records a domain set that the system is configured to monitor or detect dangling records. For example, the domain set may include domains associated with a specific customer of the dangling record service. As another example, the domain set corresponds to all domains of the dangling record service for all customers for whom it monitors or detects dangling records.

[0052] In some embodiments, the domain set corresponds to one or more domains associated with a request from DNS traffic interception (e.g., a DNS resolver, firewall, etc.). As an example, in response to intercepting one or more DNS queries or intercepting responses to one or more DNS queries, the domain set is provided to the system to determine whether any of the one or more domains corresponds to a dangling record.

[0053] At 310, a domain is selected. The domain is selected from the set of domains. In some embodiments, the domain is selected based on a determination that the domain corresponds to a customer of the system or that such a customer has subscribed to a service level provided by the system.

[0054] At 315, select the record associated with the selected domain. In some embodiments, the system determines the record associated with the domain based at least in part on one or more records mapped to the domain (e.g., one or more records mapped to user accounts related to the domain). Examples of records include domains, subdomains, IP addresses, accounts utilizing third-party services, mail exchange (MX) records, name server (NS) records, canonical name (CNAME) records, delegated name (DNAME) records, etc. In some embodiments, the system selects the record in relation to iterating over all records or sets of records associated with the domain.

[0055] At 320, a determination is made as to whether a record is a dangling record. In some embodiments, the system determines whether a record is dangling based at least in part on the determination that the record’s registration has expired or expired, or that the record is otherwise registrable (e.g., the system is able to register the record).

[0056] According to various embodiments, the system queries one or more record services in relation to determining whether a record is dangling. The system determines the record service associated with the selected record and generates a query for such record service to determine information related to the record (e.g., registration details related to the record, availability of such a registered record, indication that the record's registration has expired or expired, etc.). As an example, in the case of a domain, the system determines whether the domain has expired and is available for registration. The system determines whether the top-level domain area file includes the domain. For example, if the top-level domain area file includes the domain, the system considers the record (e.g., the domain) not dangling. If the top-level domain area file does not include the domain, the system queries a registrar (e.g., a domain registrar such as GoDaddy.com) to determine whether the domain can be registered (e.g., purchased). As an example, in response to determining that the domain can be registered, the domain is considered a dangling record.

[0057] In response to determining at 320 that a record is a dangling record, process 300 proceeds to 325, where an indication that the record is dangling is provided. According to various embodiments, in response to determining that a record is a dangling record, the system provides a notification to the previous registrant. As an example, the system determines contact information related to the record based at least in part on querying a record service (e.g., querying a WHOIS record if the record is a top-level domain, such as querying a WHOIS record for the corresponding registration information). As another example, where the system monitors records on behalf of a customer, in response to determining that a record is dangling, the system provides the customer with an indication and / or such customer contact information, such as via a user interface (e.g., a dashboard provided by the system). In some embodiments, in addition to providing an indication or instead of providing an indication, the system performs proactive measures. Examples of proactive measures include blocking traffic to the address associated with the dangling record, redirecting traffic to a sinkhole IP, etc.

[0058] Instead, in response to determining at 320 that the record is not a dangling record, process 300 proceeds to 330, where it indicates that the record is not dangling. In some embodiments, 330 is excluded from process 300. For example, in some implementations, in response to determining that the record is not dangling, process 300 does not provide such an indication and does not change the traffic going to the address corresponding to said record.

[0059] At point 335, a determination is made regarding whether to perform a check or determination on other records associated with the selected domain. In response to the determination to make a determination on another selected record, process 300 returns to 315, and process 300 continues execution from 315 to 335 until no other records need to be checked to determine whether such a record is a dangling record. As an example, the determination of whether to monitor another record can be based at least in part on the set of records associated with customers of such a domain. As another example, the determination of whether to monitor another record can be based on user input, such as an instruction from an administrator to pause or exit process 300.

[0060] In response to determining that no further determination is made regarding another record in the selected domain, process 300 proceeds to 340, where a determination is made regarding whether to perform an inspection or determination on another domain. In response to determining that a determination should be made regarding another domain, process 300 returns to 310, and process 300 continues execution from 310 to 340 until no other domain is to be monitored to determine whether the associated record is a dangling record. As an example, the determination to inspect another domain is based on the determination that the set of DNS traffic for which process 300 is invoked does not include traffic from any other domain. As another example, the determination to inspect another domain is based on the determination that the set of domains for which the system is to monitor according to a predetermined schedule (for which process 300 is invoked) does not include any other domain. As another example, the determination to monitor another domain may be based on user input, such as an instruction from an administrator to pause or exit process 300.

[0061] At 345, a determination is made regarding whether process 300 has completed. In some embodiments, process 300 is determined to be complete in response to a determination that no other domain exists in the domain set (e.g., at least for this iteration of process 300), an administrator instruction to pause or stop process 300, etc. In response to the determination that process 300 has completed, process 300 ends. In response to a determination that process 300 has not completed, process 300 returns to 305. In some embodiments, process 300 is invoked at the next scheduled time or after a predetermined time, or in response to an event (e.g., in response to the reception of suspicious DNS traffic, etc.).

[0062] Figure 4 This is a flowchart of a method for determining whether a record is suspended, according to various embodiments of this application. According to various embodiments, and... Figure 1 System 100 and / or Figure 2 The system 200 is related to the implementation process 300.

[0063] According to various embodiments, procedure 400 is invoked in relation to determining whether a record is a dangling record.

[0064] At point 405, identify the service associated with the record.

[0065] At point 410, the determination of whether the availability of a record is based on query determinability is made.

[0066] In response to the determination of record availability at 410 based on the query, process 400 proceeds to 415, where a query is sent to inquire about the availability of the record regarding the service.

[0067] At 420, receive a record indicating whether the service is available.

[0068] At point 425, the determination of whether a record is dangling is made at least in part based on whether the record indicates whether the service is available.

[0069] In response to the query at 410 determining that the availability of a record is undeterminable, process 400 proceeds to 435, where a determination is made regarding whether the availability of the record is determinable based on registration (or registration attempt). In response to the determination at 435 that the availability of a record is undeterminable based on registration or registration attempt, process 400 proceeds to 430.

[0070] In response to a determination at 435 that the availability of a record can be determined based on registration or registration attempts (or in response to a determination of an attempt to register a record), process 400 proceeds to 440, where a registration request is sent to a service that manages record registration (e.g., a record service). For example, in the case of a third-party service that provides registration for subdomains (e.g., Shopify, Substack.com, Facebook, etc.), the system sends a request to register the record. As another example, in the case where the domain and service are top-level domain registrars (e.g., GoDaddy.com), the system sends a request to register the domain.

[0071] At 445, the response to the registration request. In some embodiments, the response indicates whether the registration record is available for the service. In some embodiments, the response to the registration request is an confirmation of the registration (e.g., the system may register the record on behalf of a customer who is a previous registrant, etc.).

[0072] At 450, the determination of whether a record is a dangling record is made at least in part based on the response to a registration request. In some embodiments, the system determines that the record is dangling in response to receiving an indication that registration of the record is available, or if the system (e.g., on behalf of a customer) successfully registers the record.

[0073] At 430, a determination is made regarding whether process 400 has completed. In some embodiments, process 400 is determined to be complete in response to determining that there are no other records in the record set for which the system is to perform a check on whether such records are dangling records, or when an administrator instructs process 400 to be paused or stopped, etc. In response to determining that process 400 has completed, process 400 ends. In response to determining that process 400 has not completed, process 400 returns to 405. In some embodiments, process 400 is invoked at the next scheduled time or after a predetermined time, or in response to an event (e.g., in response to the reception of suspicious DNS traffic, etc.).

[0074] Figure 5 This is a flowchart of a method for providing an indication that a record is suspended, according to various embodiments of this application. According to various embodiments, with... Figure 1 System 100 and / or Figure 2 The system 200 is related to the implementation process 300.

[0075] At 510, an indication is obtained that the record is a dangling record. In some embodiments, the system obtains an indication that the record is a dangling record in response to determining that the registration of the record has expired or expired, or in response to determining that the record is registrable.

[0076] At 520, an indication that a record is a dangling record is provided to the client. In response to receiving the indication that a record is a dangling record (e.g., in response to determining that a record is a dangling record), the system transmits the indication that a record is a dangling record to a client such as a customer (e.g., via a user interface, dashboard, text message, email, etc.) or to a contact associated with the registration of the record (e.g., a contact included in contact information such as WHOIS registrant information included in previous registrations of the record).

[0077] At point 530, a determination is made regarding whether a request to parse a dangling record has been received. In some embodiments, the system receives a request to parse a dangling record, such as on behalf of a user registration record. In some embodiments, the system request to parse a dangling record is automatically generated, at least in part, based on a predetermined policy, such as a policy for a specific customer of the dangling record service provided by the system.

[0078] In response to the determination that a request to resolve a dangling record was received at 530, process 500 proceeds to 540, at which point a request to register the record is sent to the service.

[0079] At position 550, the system receives an indication from the service whether a record has been registered. In response to a request sent to the service (e.g., a third-party service that provides / manages record registration, such as a domain registrar), the system receives a response indicating whether the record has been successfully registered.

[0080] At 560, a determination is made regarding whether process 500 has completed. In some embodiments, in response to the determination that no other record is considered a dangling record, the administrator instructs process 500 to be paused or stopped, etc., and process 400 is determined to be completed. In response to the determination that process 500 has completed, process 400 ends. In response to the determination that process 500 has not completed, process 500 returns to 510. In some embodiments, process 500 is invoked at the next scheduled time or after a predetermined time, or in response to an event (e.g., in response to the reception of suspicious DNS traffic, etc.).

[0081] Figure 6 This is a flowchart of a method for determining whether a record is suspended, according to various embodiments of this application. According to various embodiments, and... Figure 1 System 100 and / or Figure 2 The system 200 is related to the implementation process 300.

[0082] According to various embodiments, procedure 600 is invoked in response to receiving DNS traffic. For example, procedure 600 is invoked in response to interception of a call regarding a DNS query or a response to a DNS query.

[0083] At 605, DNS traffic is received. In some embodiments, DNS traffic is received in connection with intercepting DNS queries and / or the responses to DNS queries.

[0084] At 610, the domain is determined. The system determines the domain based at least in part on DNS traffic. In some embodiments, the system determines the domain that is included in a DNS query or in the response to a DNS query.

[0085] At 615, a record associated with the domain is selected. In some embodiments, the system analyzes DNS traffic and / or the domain from which the traffic originates, and determines the record corresponding to said domain. In some embodiments, the system determines the record associated with the domain based at least in part on one or more records mapped to said domain (e.g., one or more records mapped to user accounts related to said domain). Examples of records include domains, subdomains, IP addresses, accounts utilizing third-party services, mail exchange (MX) records, name server (NS) records, canonical name (CNAME) records, delegated name (DNAME) records, etc. In some embodiments, the system selects records in relation to iterating over all records or record sets associated with the domain.

[0086] At 620, a determination is made regarding whether a record associated with the domain is dangling. In some embodiments, 625 corresponds to or is similar to... Figure 3 The process of 300 to 320, or Figure 4 The process is 400 to 425 or 450.

[0087] In response to determining at 620 that the record associated with the field is dangling, process 600 proceeds to 625, where an indication that the record is dangling is provided. In some embodiments, 625 corresponds to or is similar to Figure 3 Process 300 of 325. In some embodiments, process 600 does not include 625 (e.g., no notification or indication is provided that a record is a dangling record).

[0088] At 630, a response to DNS traffic is provided. In some embodiments, in response to determining that a record is a dangling record, the system performs proactive measures. In the case of DNS traffic, proactive measures may include blocking DNS traffic destined for the record (e.g., IP address, domain, etc.) or redirecting DNS traffic to a sinkhole IP.

[0089] In response to determining at 620 that the record associated with the domain is not dangling, process 600 proceeds to 635, where a response is provided to the DNS traffic. In some embodiments, in response to determining that the record is not dangling, no action is taken or no notification is provided.

[0090] At 640, a determination is made regarding whether to perform an inspection or determination on other records associated with the selected domain. In response to the determination to make a determination on another selected record, process 600 returns to 615, and process 600 continues execution from 615 to 640 until no other record needs to be inspected to determine whether such a record is a dangling record. As an example, the determination of whether to monitor another record can be based at least in part on the set of records associated with customers of such a domain. As another example, the determination of whether to monitor another record can be based on user input, such as an instruction from an administrator to pause or exit process 600.

[0091] In response to determining that no further determination is made regarding another record in the selected domain, process 600 proceeds to 645, where a determination is made regarding whether to perform an inspection or determination for another domain. In response to determining that a determination is to be made regarding another domain, process 600 returns to 610, and process 600 continues execution from 610 to 645 until no other domain is to be monitored to determine whether the associated record is a dangling record. As an example, process 600 determines whether to inspect another domain based on its determination that the DNS traffic set to which it is invoked does not include traffic from any other domain. As another example, process 600 determines whether to inspect another domain based on the determination that the system is to monitor a set of domains according to a predetermined schedule that does not include any other domain, and process 600 is invoked for said predetermined schedule. As another example, the determination whether to monitor another domain may be based on user input, such as an instruction from an administrator to pause or exit process 600.

[0092] At 650, a determination is made regarding whether process 600 has completed. In some embodiments, process 600 is determined to be complete in response to a determination that no other domain exists in the domain set (e.g., at least for this iteration of process 600), an administrator instruction that process 600 should be paused or stopped, etc. In response to the determination that process 600 has completed, process 600 ends. In response to the determination that process 600 has not completed, 600 300 returns to 605. In some embodiments, process 600 is invoked at the next interception of DNS traffic, or in response to an event (e.g., in response to the reception of suspicious DNS traffic, etc.).

[0093] Various examples and flowcharts of the embodiments described herein are described in connection with them. While examples may include certain steps performed in a particular order, according to various embodiments, various steps may be performed in various orders and / or various steps may be combined into a single step or performed in parallel.

[0094] While the foregoing embodiments have been described in detail for clarity of understanding, the invention is not limited to the details provided. Many alternative ways of implementing the invention exist. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system comprising: One or more processors are configured as follows: DNS traffic is obtained at least in part based on the interception of network traffic, and the DNS traffic includes DNS queries pointing to domains; One or more domain sets are obtained, at least in part, based on DNS traffic; In response to receiving a DNS query, determine whether a record associated with a domain included in the domain set is dangling, wherein: Determining whether a record associated with the field is dangling includes: Query the record registration service for registration information corresponding to the record associated with the domain; and Whether a record associated with the domain is dangling is determined, at least in part, based on registration information; and In response to the determination that a record associated with the domain is available for registration occurring simultaneously with the receipt of a DNS query pointing to the domain, it is determined that the record is dangling; and In response to determining that a record associated with the domain is dangling, a notification is provided to the registrant that the record is dangling; and The memory is coupled to the processor and configured to provide instructions to the processor.

2. The system of claim 1, wherein the one or more processors are further configured to block DNS queries to the domain associated with the record determined to be dangling.

3. The system of claim 1, wherein the record corresponds to one or more top-level domains, subdomains, and IP addresses.

4. The system of claim 1, wherein determining whether a record is suspended comprises: Check whether the top-level domain associated with the domain is available for registration.

5. The system of claim 3, wherein checking whether the top-level domain is available for registration includes: Contact your domain registrar to register a top-level domain.

6. The system of claim 1, wherein determining whether a record is floating comprises: Check whether the subdomains associated with the domain are available for registration.

7. The system of claim 6, wherein checking whether a subdomain is available for registration includes: Query services provided by the registrar of the top-level domain associated with the said domain, wherein the service is queried to attempt to register the subdomain.

8. The system of claim 1, wherein determining whether a record is floating comprises: Attempt to assign an IP address associated with the domain from a public cloud.

9. The system according to claim 1, wherein: The one or more processors are further configured to receive DNS queries; and In response to receiving a DNS query, determine whether a record is dangling.

10. The system of claim 9, wherein the domain for which the determination of whether an associated record is dangling is performed is based at least in part on the DNS query.

11. The system of claim 10, wherein the domain is selected at least in part based on the determination of a DNS query pointing to the domain.

12. The system of claim 9, wherein the determination of whether the record is dangling occurs simultaneously with the DNS query resolution.

13. The system of claim 1, wherein determining whether the record is suspended is performed at predetermined time intervals.

14. The system of claim 1, wherein the one or more processors are configured to iteratively (i) select a specific domain from the domain set, and (ii) determine whether a specific record associated with the specific domain is dangling.

15. The system of claim 1, wherein providing notification to the registrant comprises: Identify the specific registrant associated with the record; and Send communications to the specific registrant.

16. The system of claim 15, wherein the communication is email.

17. The system of claim 1, wherein the one or more processors are further configured to: Receive traffic destined for the domain associated with the dangling record; and The traffic is routed according to the customer security policy of the customer associated with the domain.

18. A method comprising: DNS traffic is obtained at least in part based on the interception of network traffic, and the DNS traffic includes DNS queries pointing to domains; One or more domain sets are obtained by one or more processors, at least in part, based on DNS traffic; In response to receiving a DNS query, the one or more processors determine whether a record associated with a domain included in the domain set is dangling, wherein: Determining whether a record associated with the field is dangling includes: Query the record registration service for registration information corresponding to the record associated with the domain; and Whether a record associated with the domain is dangling is determined, at least in part, based on registration information; and In response to the simultaneous occurrence of the determination that a record associated with the domain is available for registration and the receipt of a DNS query pointing to the domain, it is determined that the record is dangling; and In response to determining that a record associated with the domain is dangling, a notification is provided to the registrant that the record is dangling.

19. A computer program product embodied in a non-transitory computer-readable medium and comprising computer instructions for: DNS traffic is obtained at least in part based on the interception of network traffic, and the DNS traffic includes DNS queries pointing to domains; One or more domain sets are obtained by one or more processors, at least in part, based on DNS traffic; In response to receiving a DNS query, the one or more processors determine whether a record associated with a domain included in the domain set is dangling, wherein: Determining whether a record associated with the field is dangling includes: Query the record registration service for registration information corresponding to the record associated with the domain; and Whether a record associated with the domain is dangling is determined, at least in part, based on registration information; and In response to the determination that a record associated with the domain is available for registration occurring simultaneously with the receipt of a DNS query, it is determined that the record is dangling, and the DNS query points to the domain; and In response to determining that a record associated with the domain is dangling, a notification is provided to the registrant that the record is dangling.

Images