In-line identification and blocking of dangling DNS records

Abstract

The present application discloses a method, system, and computer system for identifying dangling records, the method including the steps of obtaining a set of domains, determining whether a record associated with a domain included in the set of domains is dangling, and in response to determining that a record associated with the domain is dangling, providing a notification to a registrant that the record is dangling.

Description

[Background technology]

[0001] Malicious individuals attempt to compromise computer systems in a variety of ways. As one example, such individuals may attempt to register a domain or subdomain that was previously registered (e.g., to a genuine individual or service) and that has become available when the registrant, for some reason, mistakenly allows such registration to expire. Upon successful registration of a domain or subdomain, malicious individuals may seek to host malicious services on such domain or subdomain, such as by infecting a client terminal with malware in an attempt to access services previously provided by the genuine individual or service. Thus, a need remains for improved techniques for identifying resources subject to resource hijacking by malicious individuals. [Brief explanation of the drawings]

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. [Figure 1] FIG. 1 is a block diagram of a system for providing dangling record detection according to various embodiments of the present application. [Figure 2] FIG. 2 is a block diagram of a system that provides dangling record detection according to various embodiments of the present application. [Figure 3] FIG. 3 is a flow chart of a method for determining whether a record is dangling, according to various embodiments of the present application. [Figure 4] FIG. 4 is a flowchart of a method for determining whether a record is dangling, according to various embodiments of the present application. [Figure 5]FIG. 5 is a flowchart of a method for providing an indication that a record is dangling, according to various embodiments of the present application. [Figure 6] FIG. 6 is a flowchart of a method for determining whether a record is dangling, according to various embodiments of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0003] The present invention can be implemented in numerous 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 instructions stored on a memory and / or a processor configured to execute instructions stored and / or provided by a memory coupled to the processor. These implementations, or any other form the present invention may take, may be referred to herein as techniques. In general, the order of steps in disclosed processes may be varied within the scope of the present invention. Unless otherwise specified, components, such as a processor or memory, described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform the task at a given time, or as 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.

[0004] A detailed description of one or more embodiments of the present invention is provided below along with accompanying figures that illustrate the principles of the invention. While the present invention will be described in connection with such embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the purposes of clarity, technical material known in the art related to the present invention has not been described in detail so as not to unnecessarily obscure the present invention.

[0005] A system for determining whether a record corresponds to a dangling record is disclosed, the system including one or more processors and a memory, wherein 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 of domains 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.

[0006] As used herein, the term "dangling" 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.

[0007] 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 for third-party services, mail exchange (MX) records, name server (NS) records, canonical name (CNAME) records, delegation name (DNAME) records, etc.

[0008] A malicious individual can monitor or attempt to register a dangling record in order to spoof third parties attempting to obtain services or information from the record. For example, a malicious party could attempt to register a domain that they know to be expired and that they know has provided genuine services to third parties before the record's registration expires. Thus, ingress and egress communications regarding a record, such as a domain, would be exposed to malicious parties. If a malicious party successfully registers a lapsed record, the malicious party could send email or other communications to third parties who are unaware of the record's registration change. Similarly, if a malicious party successfully registers a lapsed record, the malicious party could set up redirects so that third parties attempting to access a record, such as a domain, are redirected to the malicious party or attacker who currently owns the record or otherwise has registration for the record. In the case of a domain, if a malicious party successfully registers a domain, the malicious party could hijack the authoritative DNS. In view of the above, a need exists for active detection of dangling records to alert registrants of dangling records whose registrations may have erroneously expired.

[0009] According to various embodiments, the system determines whether a record corresponds to a dangling record based at least in part on a determination that the record is available for registration or assignment. In some embodiments, the system determines whether a record is dangling simultaneously with DNS traffic. For example, in response to receiving a DNS query, the system determines a record (e.g., a domain, subdomain, IP address, etc.) that corresponds to the DNS query, and the system determines whether the record is dangling simultaneously with servicing the DNS query. In some embodiments, the system intercepts the DNS query or intercepts the response to the DNS query, and the system determines whether the record is dangling (e.g., before the response is communicated 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 customers, and at predetermined time intervals, the system iterates through the set of records to determine whether the records are dangling. The predetermined time intervals can be set to be daily, weekly, monthly, etc. Various other time intervals or schedules can be set based on the configuration or requirements of a user, such as an administrator. For top-level domains, a grace period is often extended for registrants to recover their domains before the expired domains are made publicly available. The grace period is typically two months. Thus, in some embodiments, the system performs a check across a set of domains every three months (i.e., another period longer than two months to allow expired registrations to be made public). A suspected party registers a record (e.g., a domain) during the time that the record's registration expires, and the system performs a check to determine whether the record is dangling.Thus, in various embodiments, the system optimizes or reduces the amount of time between a record's expiration or revocation and a check of the record. In some embodiments, the system stores expected expiration dates corresponding to one or more records, and the system queries third-party services that offer registrations a predetermined period of time after the expected registration date for a particular record. In some embodiments, the set of domains can 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 set of domains corresponds to multiple domains across a set of users or customers.

[0010] 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 for a registrant associated with the record and communicates an indication that the record is dangling to an address or contact included in the contact information. The indication that the record is dangling may include a notice that the record is dangling and an indication that the record may be susceptible to a malicious attacker (e.g., the record may be 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 for a service that checks whether an account's record is dangling, etc.). In some embodiments, the system determines contact information related to the registrant associated with the record based at least in part on querying a service to which the record is related. For example, if the record is a domain, the system queries a WHOIS record for the domain and retrieves registration information from the WHOIS record. In some embodiments, in response to determining that a record is a dangling record, the system communicates with a registrar associated with the record (e.g., a service that provides services related to the record to registrants) to provide such registrar with an indication that the record is susceptible to a malicious attacker.

[0011] In some embodiments, in response to determining that a record is dangling, the system blocks traffic to the record. For example, if the dangling record is a domain, the system actively blocks DNS traffic to the domain or provides instructions or commands to another network device to block DNS traffic to the domain. As another example, if a determination that a record is dangling occurs simultaneously with DNS traffic directed to the record, the system blocks DNS traffic to the record or returns a sinkhole address / redirect to the client from which such DNS traffic originated. As another example, in response to determining that a record is dangling, the system updates a firewall policy, for example, to block traffic directed to the record (or redirect it to a different address associated with the previous registrant associated with the record). In some embodiments, the system maintains a whitelist of records (e.g., domains) for which traffic will not be blocked or redirected. For example, the system allows traffic for a record even if it is determined to be a dangling record (e.g., the system does not block or redirect traffic for records on the whitelist). The whitelist may be configurable, for example, by an administrator, a customer, or the like.

[0012] According to various embodiments, a 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 may be a cloud service offered to various users or customers. As another example, the one or more servers receive queries from a passive DNS service, a DNS security server, a DNS resolver, etc.

[0013] The system improves record security (e.g., record registration) and reduces the likelihood of records being hijacked by malicious third parties. Related art systems can, for example, identify dangling records within their own systems for registrations they manage. Such related art systems typically require access to accounts for registrations. For example, a domain registrar can identify expired customer domain or subdomain registrations for its customers. Various embodiments are not limited to detecting dangling records within records (e.g., domains) managed by the system. For example, various embodiments provide scalable detection of records across third-party service providers and platforms. Systems according to various embodiments do not require access to registrant accounts, such as via certificates associated with the registrants, to detect dangling records for such registrants. In some embodiments, the system uses publicly available information to determine whether a record is a dangling record. For example, the system queries a publicly available third-party service, such as via an application programming interface (API) developed for the third-party service.

[0014] Third-party service providers often throttle or cap the number of queries that a terminal (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 premium services, often models requiring a paid subscription, in which the number of queries is uncapped or the cap is extended relative to the free service. According to various embodiments, the system registers multiple accounts with one or more third-party services, respectively, and uses the multiple accounts to query the one or more third-party services for dangling records related to a given set of records (e.g., a set of records corresponding to customers of the system).

[0015] Figure 1 is a block diagram of a system for providing dangling record detection according to various embodiments of the present application. According to various embodiments, at least a portion of system 100 implements system 200 of Figure 2. System 100 performs process 300 of Figure 3, process 400 of Figure 4, process 500 of Figure 5, and / or process 600 of Figure 6.

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

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

[0018] According to various embodiments, the dangling record service 110 determines whether a record corresponds to a dangling record. As one example, the dangling record service 110 obtains a set of domains, determines whether a record associated with a domain included in the set of domains is dangling, and, in response to determining that a record associated with a domain is dangling, provides a notification to the registrant that the record is dangling. As another example, in addition to or instead of providing a notification that the record is dangling, the dangling record service 110 blocks or redirects traffic (e.g., DNS traffic) directed to the record.

[0019] As shown in FIG. 1, the dangling record service 110 may include one or more of a business application layer 115 and / or a database layer 115.

[0020] 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) a set of domains or records for which the dangling record service 110 will 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 according to which the dangling record service 110 will determine whether a record is dangling.

[0021] The database layer 120 or storage layer is configured to store a mapping of users (or customers) to records that the dangling record service 110 monitors or detects in relation to determining whether a record among those records is dangling. In some embodiments, the database layer 120 stores one or more policies according to which the dangling record service 110 determines whether one or more records correspond to dangling records. The database layer 120 can further store a mapping of one or more policies to one or more users or customers with which each policy is associated. The policies can include policies that indicate a schedule or time period according to which the dangling record service 110 determines whether a record corresponds to a dangling record.

[0022] According to various embodiments, the dangling record service 110 determines whether one or more records associated with one or more record services (e.g., the first record service 130, the second record service 140, and / or the 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 records are dangling. In some embodiments, the query includes a query to register the record (e.g., if registration of the record is permitted or possible, the dangling record service 110 can consider such a record dangling because it is available to a suspicious third party). In some embodiments, the dangling record service 110 communicates the query to the record service via an API corresponding to the record service. For example, the business application layer 115 is used to call the record service via the API. The queries to the one or more record services regarding one or more records can be sent individually or in batches. For example, the dangling record service 110 may communicate multiple queries to a particular record service for all or a subset of the records for which the dangling record service 110 monitors / detects dangling records.

[0023] 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 dangling record services 110, such as business application layer 115 and / or database layer 120. In various embodiments, network 125 includes one or more of a wired network and / or a wireless network, such as a cellular network, a wireless local area network (WLAN), 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.

[0024] 2 is a block diagram of a system for providing dangling record detection according to various embodiments of the present application. According to various embodiments, system 200 may be implemented in conjunction with system 100 of FIG. 1, for example, to dangling record service 110. In various embodiments, system 200 may be implemented in conjunction with process 300 of FIG. 3, process 400 of FIG. 4, process 500 of FIG. 5, and / or process 600 of FIG. 6.

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

[0026] In the illustrated embodiment, system 200 implements one or more modules associated with determining whether a record is a dangling record. System 200 includes a communications interface 205, one or more processors 210, a storage device 215, and / or a memory 220. One or more processors 210 include one or more of a communications module 225, a record selection module 230, a query module 235, a registration module 240, a dangling record determination module 245, and / or an active measurement module 250.

[0027] In some embodiments, system 200 includes a communications module 225. System 200 uses communications module 225 to communicate with various client terminals or user systems, such as an administrator system. In some embodiments, system 200 uses communications module 225 to communicate with one or more record services, for example, in connection with sending queries to determine whether records are available for a particular service (e.g., determining whether a record is available for registration, determining whether a record's registration has expired, attempting to register a record, etc.) and / or receiving responses to queries. For example, communications module 225 provides information to be communicated to communications interface 205. As another example, communications interface 205 provides information received by system 200 to communications module 225. Communications module 225 is configured to receive one or more DNS queries from various client terminals or systems, such as a firewall, a DNS resolver, etc. For example, a dangling record service is used to intercept DNS traffic and identify dangling records before or in connection with providing a response to the DNS traffic. The communications module 225 is configured to receive one or more settings or configurations from a user, such as an administrator or a customer, to the dangling record service 110. Examples of the one or more settings or configurations include configuration of a set of records regarding which dangling records are monitored / detected, policies regarding which dangling records are monitored / detected (e.g., a schedule for determining whether a set of records includes a dangling record, a period or frequency according to which checks for dangling records are performed, a mapping of contact information to records, a whitelist of records, such as domains for which traffic is allowed despite a determination that the corresponding record is dangling, etc.).

[0028] According to various embodiments, system 200 includes record selection module 230. System 200 uses record selection module 230 in connection with determining whether a record that system 200 determines is a dangling record (e.g., a record for which a query is sent to a corresponding record service, such as a domain registrar). In some embodiments, record selection module 230 determines a record based at least in part on DNS traffic. For example, in response to receiving a DNS query, system 200 is queried to determine whether a record (e.g., a top-level domain, a subdomain, an IP address, etc.) corresponding to the DNS query is a dangling record. In some embodiments, record selection module 230 is based at least in part on a set of records for which system 200 monitors / detects records that may be dangling records, or a set of records corresponding to a particular user or customer. For example, system 200 may store policies for monitoring a set of records according to a predetermined schedule or frequency, and in response to determining that such monitoring should be performed at the current time based at least in part on the predetermined schedule or frequency, record selection module 230 may determine a set of records that corresponds to such policies.

[0029] 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., first record service 130, second record service 140, and / or third record service 150). Query module 235 is used to query one or more record services in connection with determining whether one or more records are dangling. For example, query module 235 queries a record service to register a particular record (e.g., in connection with system 200 determining whether a particular record is available for registration). As one example, if the record is an IP address, query module 235 queries a public cloud to determine whether 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 TLD zonefiles. As another example, if the record is a subregion, query module 235 queries a third-party service that provides the subregion (e.g., Shopify, Google, Microsoft, Facebook, etc.).

[0030] In some embodiments, system 200 includes a registration module 240. System 200 uses registration module 240 to attempt to register and / or manage the registration of records with a record service. For example, registration module 240 is configured to attempt to register an account or subdomain with a third-party service (e.g., Shopify, Google, Microsoft, Facebook, Etsy, Printerest, etc.). In some embodiments, a user configures policies for registering particular records associated with the user in response to system 200 determining that the record is dangling. For example, in accordance with such policies, in response to determining that the record's registration has expired, system 200 uses registration module 240 to re-register the user's record (e.g., a previous registrant who erroneously allowed the record's registration to expire).

[0031] In some embodiments, the 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 a response received by the query module 235 in connection with querying one or more record services. The dangling record determination module 245 determines a record is a dangling record if the query module 235 receives an indication that the record has expired. As another example, the dangling record determination module 245 determines whether a record is dangling based at least in part on the registration module 240 determining that the record is registerable, for example, with a third-party service (e.g., the registration module 240 can create an account or register a subregion with a third-party service such as Shopify, Microsoft, etc.).

[0032] In some embodiments, system 200 includes active measurement module 250. System 200 uses active measurement 250 to perform one or more actions in response to system 200 determining that a record is a dangling record. The one or more actions performed in response to determining that a record is a dangling record may be preset in one or more policies or preferences, such as customer policies or preferences, on behalf of the customer whose record system 200 monitors. Examples of the one or more actions include providing a notice or indication that the record is a dangling record, registering the record, blocking traffic to a domain or address corresponding to the dangling record, redirecting traffic to a domain or address corresponding to the dangling record, etc. As one example, in response to system 200 determining that a record is a dangling record, active measurement module 250 communicates (e.g., via communication module 225) an indication that the record is dangling. The indication is communicated to contact information for the record (e.g., a contact for the user or customer whose record system 200 monitors, a registrant identified by the registrar associated with the record, etc.). As another example, in response to the system 200 determining that a record is a dangling record, the active measurement module 250 registers the record, for example, on behalf of a user or customer (e.g., a previous registrant of such record).

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

[0034] In some embodiments, file system data 260 includes a database, such as one or more data sets (e.g., one or more data sets for one or more tenants, etc.), including data about customers, data used in connection with system 200 to determine whether a record is a dangling record, historical information about DNS queries, whitelists of records, such as domains (e.g., a set of domains for which traffic is allowed or otherwise not blocked in response to a determination that the domain is a dangling record), etc.

[0035] Domain data 262 includes data about one or more domains. As one example, the data about one or more domains includes relationships and associations between domains (e.g., top-level domains, subdomains, etc.) and address information, such as IP addresses. As one example, the data about one or more domains includes mappings of domains to registrants, such as users or customers of services provided by system 200 for monitoring / detecting dangling records. As another example, domain data 262 includes information about 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).

[0036] Record data 264 includes information about one or more records that allows system 200 to determine 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 subdomains such as Shopify, etc.). As one example, record data 264 includes a mapping of an API or communication protocol or syntax according to which system 200 communicates with the record service. As another example, record data 264 includes one or more indicators, each indicating whether one or more records correspond to a dangling record.

[0037] Policy data 266 includes one or more policies according to which system 200 determines whether one or more records correspond to dangling records. For example, policy data 266 includes a mapping of records to a schedule or time period according to which system 200 performs a check on whether a record is a dangling record. As another example, policy data 266 includes a mapping of records to active measures that are executed in response to a particular record being determined to be a dangling record. As another example, policy data 266 includes a mapping of users or customers to active measures that are executed in response to a user's or customer's record being determined to be a dangling record. Various other policies may be stored in policy data 266.

[0038] According to various embodiments, memory 220 includes execution application data 275. Execution application data 275 includes data obtained or used in connection with executing an application, such as an application executing a process for determining whether a record is a dangling record or for configuring system 200 with settings or policies to use in connection with determining whether a record is a dangling record. In embodiments, the applications include one or more applications that perform one or more of: receiving and / or executing queries or tasks; generating reports and / or configuring information responsive to executed queries or tasks; and / or providing information responsive to queries or tasks to a user. The other applications include any other suitable applications (e.g., an application for querying a record service, an application for establishing communication with a record service, an application for executing active measures, an application for registering records with a third-party service, a reporting application, a user interface application, a data analysis application, an application for blocking or redirecting traffic, a user authentication application, etc.).

[0039] 3 is a flowchart of a method for determining whether a record is dangling, according to various embodiments of the present application. According to various embodiments, process 300 may be implemented in conjunction with system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0040] In some embodiments, process 300 is invoked according to a pre-defined schedule, such as a schedule set by a customer of a dangling record service (e.g., a monitoring or detection service). Process 300 can also be invoked in response to user input, such as a request from an administrator.

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

[0042] In some embodiments, the set of domains corresponds to one or more domains (e.g., DNS resolvers, firewalls, etc.) associated with requests from DNS traffic interception. As one example, the set of domains is provided to a system for determining whether any of the one or more domains correspond to dangling records in response to intercepting one or more DNS queries or intercepting responses to one or more DNS queries.

[0043] At 310, a domain is selected. The domain is selected from among a 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 customer subscribes to a level of service offered by the system.

[0044] At 315, records associated with the selected domain are selected. In some embodiments, the system determines records 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 a user's account for the domain). Example records include domains, subdomains, IP addresses, accounts for 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 connection with iterating through all or a set of records associated with the domain.

[0045] A determination is made whether the record is a dangling record at 320. In some embodiments, the system determines whether the record is dangling based at least in part on a determination that the record's registration has expired or has expired, or that the record is otherwise available to be registered (e.g., the system is able to register the record).

[0046] According to various embodiments, the system queries one or more record services in connection with determining whether a record is dangling. The system determines the record services associated with a selected record and generates queries to those record services to determine information about the record (e.g., registration details about the record, the availability of such record for registration, an indication of whether the record's registration has expired or expired, etc.). As one example, in the case of a domain, the system determines whether the domain is expired and available for registration. The system determines whether top-level domain zonefiles contain the domain. For example, if the top-level domain zonefiles contain the domain, the system considers the record (e.g., the domain) to be not dangling. If the top-level domain zonefiles do not contain 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 one example, in response to determining that the domain can be registered, the domain is considered a dangling record.

[0047] In response to determining that the record is a dangling record at 320, process 300 proceeds to 325, where an indication that the record is dangling is provided. According to various embodiments, in response to determining that the record is a dangling record, the system provides a notification to the previous registrant. As one example, the system determines contact information for 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, querying the WHOIS record for corresponding registration information, etc.). As another example, if the system is monitoring records on behalf of a customer, in response to determining that the record is dangling, the system provides an indication to the customer and / or their contact information, for example, via a user interface (e.g., a dashboard provided by the system). In some embodiments, in addition to or as an alternative to providing an indication, the system performs active measures. Examples of active measures include blocking traffic to addresses associated with the dangling record, redirecting traffic to a sinkhole IP, etc.

[0048] Conversely, in response to determining at 320 that the record is not a dangling record, process 300 proceeds to 330, where an indication is provided that the record is not dangling. In some embodiments, 330 is omitted from process 300. For example, in some embodiments, in response to determining that the record is not dangling, process 300 does not provide such an indication and does not modify traffic to the address corresponding to the record.

[0049] At 335, a determination is made as to whether to perform a check or determination on other records associated with the selected domain. In response to determining that a determination is to be made on another record of the selected domain, process 300 returns to 315, and process 300 continues to execute 315 through 335 until there are no more records to check to determine whether such records are dangling records. As one example, the determination of whether more records should be monitored can be based at least in part on the set of records associated with customers of such domain. As another example, the determination of whether more records should be monitored can be based on user input, such as a command from an administrator to pause or terminate process 300.

[0050] In response to determining that no determination is to be made regarding another record for the selected domain, process 300 proceeds to 340, where a determination is made as to whether to check or make a determination regarding another domain. In response to determining that a determination is to be made regarding another domain, process 300 returns to 310, and process 300 continues executing 310 through 340 until there are no more domains to monitor to determine whether the associated record is a dangling record. As one example, the determination of whether to check additional domains is based on a determination that the set of DNS traffic from which process 300 was invoked does not include traffic for any additional domains. As another example, the determination of whether to check additional domains is based on a determination that the set of domains the system will monitor according to the default schedule from which process 300 was invoked does not include additional domains. As another example, the determination of whether to monitor additional domains can be based on user input, such as an instruction from an administrator to pause or terminate process 300.

[0051] At 345, a determination is made as to whether process 300 is complete. In some embodiments, process 300 is determined to be complete in response to a determination that there are no more domains in the set of domains (e.g., at least for this iteration of process 300), an administrator indicates that process 300 should be paused or stopped, etc. In response to a determination that process 300 is complete, process 300 completes. In response to a determination that process 300 is not complete, 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 receiving suspicious DNS traffic, etc.).

[0052] 4 is a flowchart of a method for determining whether a record is dangling, according to various embodiments of the present application. According to various embodiments, process 300 is implemented in conjunction with system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0053] According to various embodiments, the process 400 is invoked in connection with determining whether a record is a dangling record.

[0054] At 405, the service associated with the record is determined.

[0055] At 410, a determination is made as to whether the availability of the record can be determined based on the query.

[0056] In response to a determination at 410 that record availability can be determined based on the query, process 400 proceeds to 415, where a query is sent to query the availability of records for the service.

[0057] At 420, an indication of whether a record is available for the service is received.

[0058] At 425, a determination is made as to whether the record is dangling based at least in part on the indication of whether the record is available for the service.

[0059] In response to a determination at 410 that record availability is not determinable based on a query, process 400 proceeds to 435, where a determination is made as to whether record availability is determinable based on a registration (or attempted registration). In response to a determination at 435 that record availability is not determinable based on a registration or attempted registration, process 400 proceeds to 430.

[0060] In response to a determination at 435 that the availability of the record is determinable based on the registration or registration attempt (or in response to a decision to attempt to register the record), process 400 proceeds to 440, where a registration request is sent to a service that manages the registration of the record (e.g., a record service). For example, in the case of a third-party service that offers registration for subdomains (e.g., Shopify, Substack.com, Facebook, etc.), the system sends a request to register the record. As another example, if the domain and service is a top-level domain registrar (e.g., GoDaddy.com), the system sends a request to register the domain.

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

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

[0063] At 430, a determination is made as to whether process 400 is complete. In some embodiments, process 400 is determined to be complete in response to a determination that there are no more records in the set of records against which the system performs checks to see if such records are dangling records, an administrator indicates that process 400 should be paused or stopped, etc. In response to a determination that process 400 is complete, process 400 terminates. In response to a determination that process 400 is not complete, 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 receiving suspicious DNS traffic, etc.).

[0064] 5 is a flowchart of a method for providing an indication that a record is dangling, according to various embodiments of the present application. According to various embodiments, process 300 is implemented in conjunction with system 100 of FIG. 1 and / or system 200 of FIG. 2.

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

[0066] An indication that the record is a dangling record is provided to the client at 520. In response to obtaining an indication that the record is a dangling record (e.g., in response to determining that the record is a dangling record), the system communicates the indication that the record is a dangling record to a client, such as a customer (e.g., via a user interface, a dashboard, a text message, an email, etc.), or to a contact associated with the registration of the record (e.g., a contact included within contact information included in a prior registration of the record, such as WHOIS registrant information).

[0067] At 530, a determination is made as to whether a request to resolve a dangling record has been received. In some embodiments, the system receives a request to resolve a dangling record, such as to register a record on behalf of a user. In some embodiments, the system request to resolve a dangling record is generated automatically based at least in part on a predefined policy, such as a policy for a particular customer of a dangling record service provided by the system.

[0068] In response to determining at 530 that a request to resolve a dangling record has been received, process 500 proceeds to 540, where a request to register the record is sent to the service.

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

[0070] At 560, a determination is made as to whether process 500 is complete. In some embodiments, process 500 is determined to be complete in response to a determination that there are no further records that are considered dangling records, an administrator indicates that process 500 should be paused or stopped, etc. In response to a determination that process 500 is complete, process 500 terminates. In response to a determination that process 500 is not complete, 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 receiving suspicious DNS traffic, etc.).

[0071] 6 is a flowchart of a method for determining whether a record is dangling, according to various embodiments of the present application. According to various embodiments, process 300 is implemented in conjunction with system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0072] According to various embodiments, process 600 is invoked in response to receiving DNS traffic, for example, process 600 is invoked in response to an intercept being invoked for a DNS query or a response to a DNS query.

[0073] At 605, DNS traffic is received. In some embodiments, the DNS traffic is received in connection with an intercept that intercepts DNS queries and / or responses to DNS queries.

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

[0075] At 615, records associated with the domain are selected. In some embodiments, the system analyzes DNS traffic and / or domains from the traffic, and the system determines records corresponding to the domain. In some embodiments, the system determines records 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 a user's account for the domain). Examples of records include domains, subdomains, IP addresses, accounts for third-party services, mail exchange (MX) records, name server (NS) records, canonical name (CNAME) records, delegation name (DNAME) records, etc. In some embodiments, the system selects records in connection with iterating through all or a set of records associated with the domain.

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

[0077] In response to determining at 620 that the record associated with the domain 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 325 of process 300 of Figure 3. In some embodiments, process 600 does not include 625 (e.g., no notification or indication is provided that the record is a dangling record).

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

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

[0080] At 640, a determination is made as to whether to perform a check or determination on other records associated with the selected domain. In response to determining that a determination is to be made on another record of the selected domain, process 600 returns to 615, and process 600 continues to execute 615 through 640 until there are no more records to check to determine whether such records are dangling records. As one example, the determination of whether more records should be monitored can be based at least in part on the set of records associated with customers of such domain. As another example, the determination of whether more records should be monitored can be based on user input, such as a command from an administrator to pause or terminate process 600.

[0081] In response to determining that no determination should be made regarding another record for the selected domain, process 600 proceeds to 645, where a determination is made as to whether to check or make a determination regarding another domain. In response to determining that a determination should be made regarding another domain, process 600 returns to 610, and process 600 continues executing 610 through 645 until there are no more domains to monitor to determine whether the associated record is a dangling record. As one example, the determination of whether more domains should be checked is based on a determination that the set of DNS traffic from which process 600 was invoked does not include traffic for any more domains. As another example, the determination of whether more domains should be checked is based on a determination that the set of domains the system will monitor according to the default schedule from which process 600 was invoked does not include any more domains. As another example, the determination of whether more domains should be monitored can be based on user input, such as a command from an administrator to pause or terminate process 600.

[0082] At 650, a determination is made as to whether process 600 is complete. In some embodiments, process 600 is determined to be complete in response to a determination that there are no more domains in the set of domains (e.g., at least for this iteration of process 600), an administrator indicates that process 600 should be paused or stopped, etc. In response to a determination that process 600 is complete, process 600 terminates. In response to a determination that process 600 is not complete, 600 returns to 605. In some embodiments, process 600 is invoked at the next intercept of DNS traffic or in response to an event (e.g., in response to receipt of suspicious DNS traffic, etc.).

[0083] Various examples of the embodiments described herein are described with reference to flowcharts. Although the examples may include some steps performed in a particular order, according to various embodiments, various steps may be performed in different orders and / or various steps may be combined into a single step or in parallel.

[0084] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system comprising one or more processors and a memory, The one or more processors: obtaining DNS traffic based at least in part on intercepting the network traffic, the DNS traffic including DNS queries directed to the domain; obtaining a set of one or more domains based at least in part on said DNS traffic; determining whether a record associated with a domain included in the set of domains is dangling; Determining whether a record associated with the domain is dangling includes: querying a registration service of record for registration information corresponding to a record associated with said domain; and determining whether a record associated with the domain is dangling based at least in part on the registration information; and in response to determining that a record associated with the domain is dangling, providing a notice to the registrant that the record is dangling; It is structured as follows: The memory includes: a processor coupled to the processor and providing instructions to the processor; It is configured as follows: system.

2. a record associated with the domain is determined to be dangling in response to a determination that the record is available for registration upon receipt of a DNS query directed to the domain; The system of claim 1 .

3. The one or more processors further Blocking DNS queries to the domain associated with the record determined to be dangling. The system of claim 1 , configured to:

4. The records correspond to one or more of a top-level domain, a subdomain, and an IP address; The system of claim 1 .

5. Determining whether the record is dangling includes: checking whether a top-level domain associated with said domain is available for registration; The system of claim 1 , comprising:

6. Checking whether the top level domain is available for registration includes: querying a domain registrar to register said top-level domain; The system of claim 4 , comprising:

7. Determining whether the record is dangling includes: checking whether a subdomain associated with said domain is available for registration; The system of claim 1 , comprising:

8. Checking whether the subdomain is available for registration includes: querying services offered by a registrant of a top-level domain associated with said domain; the service is queried to attempt to register the subdomain; The system of claim 7.

9. Determining whether the record is dangling includes: attempting to allocate an IP address associated with said domain from a public cloud; The system of claim 1 , comprising:

10. The one or more processors are further configured to receive a DNS query; and determining whether the record is dangling is performed in response to receiving the DNS query. The system of claim 1 .

11. the domain for which a determination is made as to whether an associated record is dangling is selected based at least in part on the DNS query; The system of claim 10.

12. the domain is selected based at least in part on determining that the DNS query is directed to the domain; The system of claim 11.

13. determining whether the record is dangling is performed concurrently with resolving the DNS query; The system of claim 10.

14. determining whether the record is dangling is performed at predetermined time intervals; The system of claim 1 .

15. the one or more processors iteratively (i) select a particular domain from the set of domains, and (ii) determine whether a particular record associated with the particular domain is dangling; The system of claim 1 , configured to:

16. Providing said notice to said registrant comprises: determining a particular registrant associated with said record; and sending a communication to said particular subscriber; The system of claim 1 , comprising:

17. the communication is an email; 17. The system of claim 16.

18. The one or more processors further receiving traffic to the domain associated with the dangling record; and routing the traffic according to a customer security policy for a customer associated with the domain; The system of claim 1 , configured to:

19. 1. A method comprising: obtaining, by one or more processors, DNS traffic based at least in part on intercepting network traffic, the DNS traffic including DNS queries directed to a domain; obtaining, by the one or more processors, a set of one or more domains based at least in part on the DNS traffic; determining, by the one or more processors, whether a record associated with a domain included in the set of domains is dangling; The step of determining whether a record associated with the domain is dangling includes: querying a registration service of record for registration information corresponding to a record associated with said domain; and determining whether a record associated with the domain is dangling based at least in part on the registration information; and in response to determining that a record associated with the domain is dangling, providing, by the one or more processors, a notification to a registrant that the record is dangling; A method comprising:

20. A computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions: The instructions, when executed, cause one or more processors to: obtaining DNS traffic based at least in part on intercepting network traffic, the DNS traffic including DNS queries directed to a domain; obtaining a set of one or more domains based at least in part on the DNS traffic; determining whether a record associated with a domain included in the set of domains is dangling; The step of determining whether a record associated with the domain is dangling includes: querying a registration service of record for registration information corresponding to a record associated with said domain; and determining whether a record associated with the domain is dangling based at least in part on the registration information; and in response to determining that a record associated with the domain is dangling, providing a notice to a registrant that the record is dangling; To implement Computer program.

Images