WO2021062425A1 - System and method for improving network performance when using secure dns access schemes - Google Patents
System and method for improving network performance when using secure dns access schemes Download PDFInfo
- Publication number
- WO2021062425A1 WO2021062425A1 PCT/US2020/060445 US2020060445W WO2021062425A1 WO 2021062425 A1 WO2021062425 A1 WO 2021062425A1 US 2020060445 W US2020060445 W US 2020060445W WO 2021062425 A1 WO2021062425 A1 WO 2021062425A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- dns
- preload
- cpe
- client
- address
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 230000036316 preload Effects 0.000 claims abstract description 352
- 230000004044 response Effects 0.000 claims abstract description 22
- 238000004891 communication Methods 0.000 claims description 55
- 230000000694 effects Effects 0.000 claims description 22
- 230000036541 health Effects 0.000 claims description 18
- 238000004458 analytical method Methods 0.000 claims description 17
- 230000008859 change Effects 0.000 claims description 11
- 238000013507 mapping Methods 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 2
- 230000008569 process Effects 0.000 description 19
- 238000012545 processing Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 230000003287 optical effect Effects 0.000 description 7
- 230000000737 periodic effect Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 5
- 238000013500 data storage Methods 0.000 description 4
- 239000000284 extract Substances 0.000 description 4
- 239000008186 active pharmaceutical agent Substances 0.000 description 3
- 238000003491 array Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 239000000523 sample Substances 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 101100498818 Arabidopsis thaliana DDR4 gene Proteins 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000004549 pulsed laser deposition Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1433—Vulnerability analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/121—Timestamp
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/58—Caching of addresses or names
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/06—Airborne or Satellite Networks
Definitions
- the packet switched networks are increasingly used by voice and data communication systems. Such networks include private networks accessible only to authorized personnel. Packet switched networks also include public networks, such as the internet, which are accessible to consumers via providers such as an internet service provider (ISP), wireless (cellular) service provider, etc. For example, many consumers interact with news-oriented websites in order to obtain information such as current events, sports, weather, traffic, etc. using a web browser operating on devices capable of accessing the internet. Consumers also interact with recreational websites in order to access social media, music streaming services, video streaming services, etc.
- ISP internet service provider
- cellular service provider wireless
- IP internet protocol
- DNS domain name system
- the DNS server examines the web address contained in the request for address translation, and returns a matching IP address to the web browser.
- the web browser subsequently utilizes the IP address to establish a connection, thus allowing the consumer to access the desired information.
- the IP address may expire and/or change. Accordingly, it is necessary to obtain the current (and valid) IP address from the DNS server in order to access the website.
- DNS requests or DNS queries
- DNS requests can be intercepted by third parties who supply a false IP address to the web browser or user device.
- malicious software can be installed on the user device in order to access personal and/or security information.
- Various techniques, such as encryption have been proposed to address some of these vulnerabilities.
- security protocols have been proposed to encrypt information contained with requests for DNS resolution, and response from the DNS server.
- Certain wireless communication systems implement caching clients within satellite terminals deployed at consumer locations and/or satellite gateways.
- the caching clients function to reduce latency associated with transmission to/from the satellite.
- a caching client can be configured to store copies of IP addresses associated with DNS requests.
- the caching client supplies a stored IP address to the user device.
- the latency associated with transmission of the DNS request to/from the satellite and subsequently to the DNS server can be eliminated.
- the system includes a terminal of a satellite communication system and a DNS preload client associated with a customer premise equipment (CPE).
- the terminal is configured to: receive DNS queries from a customer premise equipment (CPE), supply DNS records to the CPE in response to the DNS queries, perform an analysis of DNS queries received from the CPE having an assigned internet protocol (IP) address as a source IP address parameter, DNS records supplied to the CPE with the assigned IP address as a destination IP address parameter, and network activity of the CPE, and generate a preload list containing domains and a time schedule at which name resolution should be requested for the domains, wherein the preload list is based, at least in part, on the analysis.
- IP internet protocol
- the DNS preload client being configured to: receive the preload list from the terminal, and submit preload DNS queries for name resolution of domains contained in the preload list at times specified in the time schedule, wherein the DNS preload client submits the preload DNS queries via the CPE.
- Preload records supplied in response to the preload DNS queries are stored within a DNS cache of the CPE, and preload records stored in the DNS cache of the CPE are usable to resolve DNS queries from applications installed on the CPE.
- the method includes: receiving DNS queries, from a customer premise equipment (CPE), at a terminal of a satellite communication system; supplying DNS records to the CPE in response to the DNS queries; analyzing DNS queries received from the CPE having an assigned internet protocol (IP) address as a source IP address parameter, DNS records supplied to the CPE with the assigned IP address as a destination IP address parameter, network activity of the CPE; generating a preload list containing domains and a time schedule at which name resolution should be requested for the domains, wherein the preload list is based, at least in part, on the analysis; transmitting the preload list to a DNS preload client within the CPE; submitting, by the DNS preload client, preload DNS queries for name resolution of domains contained in the preload list at times specified in the time schedule, wherein the DNS preload client submits the preload DNS queries via the CPE; and storing preload records supplied in response to the preload DNS queries within a DNS cache of the CPE, wherein the preload
- FIG. 1 is a diagram of a system capable of providing of voice and data services, according to at least one embodiment
- FIG. 2 is a diagram of a system for improving network performance using a DNS preload client, according to various embodiments
- FIG. 3 is a flowchart of a process for improving DNS performance, according to one embodiment
- Fig. 4 is a ladder diagram illustrating registration of DNS preload clients, according to one embodiment
- Fig. 5 is a flowchart of a process for detecting changes in the IP address associated with a DNS preload client, according to one or more embodiments
- Fig. 6 is a ladder diagram illustrating DNS activity tracking, according to various embodiments.
- Fig. 7 is a ladder diagram illustrating DNS cache refresh, according to one or more embodiments.
- FIGs. 8 A and 8B are a flowchart of a process for improving DNS performance using DNS preload client, according to various embodiments;
- Fig. 9 is a diagram of a computer system that can be used to implement various exemplary features and embodiments;
- Fig. 10 is a diagram of a chip set that can be used to implement various exemplary features and embodiments.
- Fig. 1 illustrates a satellite communication system 100 capable of providing voice and data services.
- the satellite communication system 100 includes a satellite 110 that supports communications among a number of gateways 120 (only one shown) and multiple stationary satellite terminals 140a-140n.
- Each satellite terminal (or terminal) 140 can be configured for relaying traffic between its customer premise equipment (CPEs) 142a-142n (i.e., user equipment), a public network 150 such as the internet, and/or its private network 160.
- the customer premise equipment 142 can be a desktop computer, laptop, tablet, cell phone, etc.
- Customer premise equipment 142 can also be in the form of connected appliances that incorporate embedded circuitry for network communication can also be supported by the satellite terminal. Connected appliances can include, without limitation, televisions, home assistants, thermostats, refrigerators, ovens, etc.
- the network of such devices is commonly referred to as the internet of things (IoT).
- IoT internet of things
- the terminals 140 can be in the form of very small aperture terminals (VSATs) that are mounted on a structure, habitat, etc. Depending on the specific application, however, the terminal 140 can incorporate an antenna dish of different sizes (e.g., small, medium, large, etc.). The terminals 140 typically remain in the same location once mounted, unless otherwise removed from the mounting. According various embodiments, the terminals 140 can be mounted on mobile platforms that facilitate transportation thereof from one location to another. Such mobile platforms can include, for example, cars, buses, boats, planes, etc. The terminals 140 can further be in the form of transportable terminals capable of being transported from one location to another. Such transportable terminals are operational only after arriving at a particular destination, and not while being transported.
- VSATs very small aperture terminals
- the satellite communication system 100 can also include a plurality of mobile terminals 145 that are capable of being transported to different locations by a user. In contrast to transportable terminals, the mobile terminals 145 remain operational while users travel from one location to another.
- the terms user terminal, satellite terminal, terminal may be used interchangeably herein to identify any of the foregoing types.
- the gateway 120 can be configured to route traffic from stationary, transportable, and mobile terminals (collectively terminals 140) across the public network 150 and private network 160 as appropriate.
- the gateway 120 can be further configured to route traffic from the public internet 150 and private network 160 across the satellite link to the appropriate terminal 140.
- the terminal 140 then routes the traffic to the appropriate customer premise equipment (CPE) 142.
- CPE customer premise equipment
- the gateway 120 can include various components, implemented in hardware, software, or a combination thereof, to facilitate communication between the terminals 140 and external networks 150, 160 via the satellite 110.
- the gateway 120 can include a radio frequency transceiver 122 (RFT), a processing unit 124 (or computer, CPU, etc.), and a data storage unit 126 (or storage unit).
- RFT radio frequency transceiver
- processing unit 124 or computer, CPU, etc.
- data storage unit 126 or storage unit
- the CPU 124 can encompass various configurations including, without limitations, a personal computer, laptop, server, etc.
- a transceiver corresponds to any type of antenna unit used to transmit and receive signals, a transmitter, a receiver, etc.
- the RFT 122 is useable to transmit and receive signals within a communication system such as the satellite communication system 100 illustrated in Fig. 1.
- the data storage unit 126 can be used, for example, to store and provide access to information pertaining to various operations in the satellite communication system 100.
- the data storage unit 126 (or storage unit) can be configured as a single drive, multiple drives, an array of drives configured to operate as a single drive, etc.
- the gateway 120 can include multiple processing units 124 and multiple data storage units 126 in order to accommodate the needs of a particular system implementation.
- the gateway 120 can also include one or more workstations 125 (e.g., computers, laptops, etc.) in place of, or in addition to, the one or more processing units 124.
- workstations 125 e.g., computers, laptops, etc.
- Various embodiments further provide for redundant paths for components of the gateway 120. The redundant paths can be associated with backup components capable of being seamlessly or quickly switched in the event of a failure or critical fault of the primary component.
- the gateway 120 includes baseband components 128 which operate to process signals being transmitted to, and received from, the satellite 110.
- the baseband components 128 can incorporate one or more modulator/demodulator units, system timing equipment, switching devices, etc.
- the modulator/demodulator units can be used to generate carriers that are transmitted into each spot beam and to process signals received from the terminals 140.
- the system timing equipment can be used to distribute timing information for synchronizing transmissions from the terminals 140.
- a fault management unit 130 can be included in the gateway 120 to monitor activities and output one or more alerts in the event of a malfunction in any of the gateway components.
- the fault management unit 130 can include, for example, one or more sensors and interfaces that connect to different components of the gateway 120.
- the fault management unit 130 can also be configured to output alerts based on instructions received from a remotely located network management system 170 (NMS).
- NMS network management system 170
- the NMS 170 maintains, in part, information (configuration, processing, management, etc.) for the gateway 120, and all terminals 140 and beams supported by the gateway 120.
- the gateway 120 can further include a network interface 132, such as one or more edge routers, for establishing connections with a terrestrial connection point 134 from a service provider. Depending on the specific implementation, however, multiple terrestrial connection points 134 may be utilized.
- Fig. 2 illustrates a system 200 for improving DNS access, in accordance with various embodiments.
- the system 200 includes a terminal 210 configured to establish communication with a gateway 260 via a satellite network 250 (or satellite link), and exchange various types of information.
- the information exchanged between the terminal and the gateway can include, without limitation, voice, data, control signals, etc.
- the terminal 210 includes a DNS preload server 212, a packet inspector 214, a satellite network transport unit 216, and a configuration handler 218.
- the terminal 210 can further include one or more processing units configured to control and/or assist in performing various operations.
- components such as the DNS preload server 212, packet inspector 214, satellite network transport 216, and configuration handler 218 can also incorporate processing units and/or co-processors in order to perform various tasks, as will be described in greater details below.
- the DNS preload server 212 is configured to monitor, process, and/or improve DNS search performance.
- the DNS preload server 212 interacts with DNS preload clients 232 installed on the individual customer premise equipment (CPEs) 230a - 23 On to track DNS request and DNS response activity, and intelligently derives correlation between the domains accessed and the time accessed.
- the DNS preload server 212 also tracks the expiration time of DNS records based, in part, on the time to live (TTL) information contained in the DNS record.
- the DNS preload server 212 subsequently generates, or updates, a preload list for each CPE 230.
- the preload list contains the domain names and a time schedule/plan at which the DNS preload client 232 should submit a request for name resolution. Table 1 (below) illustrates an exemplary preload list.
- the preload list includes a first entry scheduled for 8:10.
- the date can optionally be include, for example, as November 15, 2019.
- the first entry in the preload list also specifies five (5) domain names that should be submitted for resolution. Accordingly, at 8: 10, the DNS preload client 232 would submit DNS queries for the five domain names. The DNS preload client 232 would then wait until the time specified in the second entry to submit the next DNS query. As shown in Table 1, the second entry in the preload list only specifies two domain names for resolution. The DNS preload client 232 would continue processing the preload list by submitting DNS queries until reaching the final entry at 21 :00. As shown in Table 1, each entry in the preload list can contain different domains.
- a new preload list may be provided to the DNS preload client 232 prior to reaching the final entry (at 21:00). Under such circumstances, the current preload list would be discarded, and the DNS preload client 232 would begin processing new preload list.
- the time schedule can be derived, in part, by tracking the DNS requests/responses, traffic activity, and the TTL of the name resolutions. Furthermore, the time schedule can be adjusted to ensure that the DNS preload client 232 submits the DNS queries from the preload list prior to the actual applications 234 requesting resolution of any domain names contained in the preload list.
- the DNS preload server 212 can be configured to monitor domains contained in the preload list for subsequent network traffic (e.g., exchange of TCP/UDP packets). Domains that did not generate additional user traffic activity, following name lookup, are removed from the preload list. Such embodiments can ensure that the preload list contains domains that are actually used by the applications 234.
- the satellite network transport unit 216 is configured to provide transport path between the terminal 210 and the Gateway 260.
- the satellite network transport unit 216 can include a combination of hardware and/software components which interact to facilitate the transport path between the terminals 210 and the gateway 260.
- the satellite network transport unit 216 can be configured to optimize information exchange over the satellite link 250.
- the satellite network transport unit 216 can implement performance enhancing proxies (PEP) to improve transmission efficiency.
- PEP performance enhancing proxies
- various PEP techniques can be used to transmit information over the satellite link 250 instead of conventional TCP/IP packets.
- the configuration handler 218 includes various components (not shown), implemented as hardware and/or software combinations that interact with the terminal 210 and gateway 260 to provide necessary configuration information necessary. .
- the terminal 210 can perform various functions associated with connecting customer premise equipment (CPE) 230a - 23 On (collectively 230) to the gateway 260 for subsequent access to private networks or a public network such as the internet 270.
- CPE customer premise equipment
- the terminal 210 can interconnect a plurality of CPEs 230 via a home or office network 220, and facilitate communication with the gateway 260 via the satellite link 250.
- the home network 220 can be established using one or more separate components such as routers, switches, etc.
- the terminal 210 can incorporate routing, switching, and other networking functions internally.
- the terminal 210 can incorporate multiple ethernet ports for establishing a wired connection to various CPEs 230.
- the terminal 210 can further incorporate wireless transceivers (not shown) for establishing wireless communication links with certain types of CPEs 230 such as mobile phones, tablets, notebooks, etc.
- CPE230a can include, in part, a DNS preload client 232, and one or more installed applications 234.
- a DNS services system 236 can also be included in CPE230a for managing all aspects of domain resolution required by CPE230a.
- requests for domain name resolution i.e., DNS requests
- the DNS services system 236 also includes a DNS protocol unit 238 capable of implementing standard DNS protocols as well as domain name system security extensions (DNSSEC).
- DNS protocol unit 238 can be configured to digitally verify all DNS responses in accordance with DNSSEC protocols.
- DNSSEC applies security techniques such as public/private key encryption to facilitate authentication of both the data and source (i.e., sender) of information being exchanged.
- DNS queries and records can be accepted as authentic if the data and sender can be verified based, in part, on the digital signature.
- the data being exchanged using DNS SEC remains accessible in text format, thereby allowing the packet inspector 214 and DNS preload server 212 to examine parameters of DNS queries received from the CPE 230 and DNS records supplied from the gateway 260. Any tampering or modification of the data, however, would result in a data authentication failure and/or a sender authentication failure.
- the DNS services system 236 also includes a storage unit 240 capable of storing information usable for processing and/or resolving various requests for domain name resolution (i.e., DNS requests).
- the storage unit 240 can store, for example, a list of unexpired DNS records (or simply records) that can be used to resolve DNS queries received from the applications 234.
- the storage unit 240 can be in the form of various combinations of hardware and software designed to optimize data/information storage and retrieval.
- the storage unit 240 can be in the form of a solid-state storage device, standard non-volatile memory, high performance cache storage, etc.
- the DNS preload client 232 can be in the form of a light weight application that is resident on the CPE 230a (i.e., user device) and configured to function on the same operating system platform (e.g., iOS, Android, Windows, LINUX, MacOS etc.)
- the DNS preload client 232 is configured to request name resolution (i.e., DNS requests) for domains contained in the preload list, using platform specific application programming interfaces (APIs) 242, for domains that are likely to be used by other applications 234 running on CPE 230a.
- APIs platform specific application programming interfaces
- name resolution for preload list entries are only requested, or initiated, in order to store the results in the storage unit 240 (e.g., DNS cache) maintained by the specific DNS services system 236.
- the domains that are to be resolved by DNS request submitted from DNS preload client 232, and the time at which they are to be requested, is supplied by the DNS preload server 212 in the satellite terminal 210.
- the DNS protocol unit 238 can be configured to apply DNS SEC protocols to DNS requests submitted by the preload client 238. Matching DNS records received and saved in the storage unit 240 are also digitally signed in accordance with DNSSEC protocols.
- the DNS preload client 232 is configured to implement platform specific schemes for detecting the presence of the DNS preload server 212 and establishing a connection that can be used, in part, to receive the preload list. According to various embodiments, the DNS preload client 232 can optionally supply information to assist the DNS preload server 212 in customizing the preload list. For example, the DNS preload client 232 can be configured to probe the CPE 232a and identify currently installed applications 234. The DNS preload client 232 can further determine the frequency with which each application 234 is used, when applications 234 are installed or deleted etc.
- the terminal 210 facilitates communication between the CPEs 230 and various public and private networks such as the internet 270. More particularly, the terminal 210 transmits and receives traffic to/from the gateway 260 using the satellite network 250. The gateway 260 subsequently forwards user traffic to/from the external network 270. According to various embodiments, all traffic over the satellite network 250 is encrypted using predetermined security protocols in order to minimize and/or eliminate data access by unauthorized parties. The encryption can be applied at different layers (e.g., Iayer2, layer3, etc.), depending on the specific implementation.
- the gateway 260 can include a gateway DNS server 262, a network manager 264, and one or more CPU 266. It should be noted, however, that the gateway 260 can be optionally configured to operate without the gateway DNS server 262. In such implementations, DNS queries from the terminal 210 are received at the gateway 260, and forwarded directly to the authoritative DNS server 280. According to one or more embodiments, the CPU 266 can be configured to provide some or all of the functionality of the components within the gateway 260. According to other embodiments, the CPU 266 can be configured to supplement operation of other components within the gateway 260 by reallocating excess computational resources, when available.
- the gateway 260 can further include various hardware and software components (not shown) necessary to facilitate normal operations.
- the gateway 260 can include a radio frequency transceiver for transmitting and receiving information over the satellite network 250.
- the gateway 260 can further include one or more interfaces for establishing connections to various internal components, as well as terrestrial network connections.
- the terrestrial connections can facilitate, for example, communication between the gateway 260 and the authoritative DNS server 280 via the internet 270.
- the network manager 264 can be configured to generate and distribute configuration information and/or profiles to various components (e.g., terminals, CPEs, etc.) in the system 200.
- the system 200 illustrated in Fig. 2 improves performance of CPEs 230 when DNS queries must be resolved, particularly if DNS responses are digitally signed in accordance with DNSSEC protocols.
- DNS queries are submitted DNS services system 236 using the API 242.
- the storage unit 240 is examined in order to determine if a valid DNS record exists to resolve the DNS query. For example, certain parameters in the DNS query can be compared to various records stored within the storage unit 240. If a valid DNS record exists, it is immediately supplied to the application 234. If a valid record does not exist, the CPE 230 (or software operating therein) establishes a connection with the terminal 210 in order to submit the DNS query.
- the DNS protocol unit 238 can apply DNS SEC protocols to digitally verify the DNS response.
- the terminal 210 can be configured to establish a communication link with the gateway 260 using the satellite network 250, and subsequently forward the DNS query to the gateway 260.
- the gateway DNS server 262 can be configured to examine records maintained in its storage unit and supply a matching record to the CPE 230. If a matching record is not available in the gateway DNS server 262, the DNS query can be submitted to an authoritative DNS server 280 via the external network 270.
- the authoritative DNS server 280 subsequently returns a matching DNS record (i.e., an authoritative record or authoritative DNS record) which can be supplied to the CPE 230.
- a copy of the authoritative record can be stored in the storage unit 240 of the CPE 230 and used to resolve DNS queries until its expiration.
- the DNS protocol unit 238 can be configured to implement domain name system security (DNS SEC) protocols to secure and authenticate information associated with DNS responses (i.e., records).
- DNS SEC domain name system security
- the terminal 210 and gateway 260 can also be configured to implement DNSSEC protocols in order to detect, inspect, and/or forward DNS queries from CPEs 230 and DNS records supplied to the CPEs 230. DNS queries can therefore be submitted in unencrypted format, in accordance with DNS SEC protocols.
- the packet inspector 214 and DNS preload server 212 can examine parameters of DNS queries received from the CPE 230 and DNS records supplied from either the gateway DNS server 262 or the authoritative DNS server 280 without causing an authentication failure.
- the gateway 260 can support multiple terminals 210 that independently submit DNS queries.
- the gateway DNS server 262 can be configured to monitor and analyze DNS queries and authoritative records associated with all supported terminals 210. The analysis can be used to identify any patterns associated with individual terminals, between multiple terminals, etc. Depending on the specific implementation, such analysis can be performed over a predetermined time period, continuously, etc. For example, authoritative records supplied in response to DNS queries can be monitored and analyzed for a period of 1 hr., 2 hrs., 5 hrs., 10 hrs., 24 hrs., etc. Depending on the specific implementation, the analysis can be performed using machine learning techniques, statistical inference algorithms, etc. The results of such analysis can be supplied to the DNS preload server 212, in the form of DNS data, for use in generating the preload list.
- Fig. 3 illustrates a process for improving DNS performance, in accordance with an embodiment.
- a DN S query is received at the terminal.
- the DN S query can originate from various CPEs that are configured to establish communication links to external locations via the terminal.
- an application running on the CPE may require access to a particular website.
- the application would submit the DNS query using a platform specific API for the CPE.
- the DNS query would subsequently be transmitted to the terminal.
- the CPE would only submit the query to the terminal if a valid (e.g., unexpired) record is not available in the storage unit of the DNS services system.
- a record satisfying the DNS query is supplied to the CPE.
- the terminal may receive the record in response to subsequent communication with a gateway DNS server.
- the record is then supplied to the CPE by the terminal.
- the CPE takes appropriate steps to supply the record to the application that initiated the original request.
- DNS queries and records associated with the CPE are analyzed.
- the terminal can be configured to examine the contents of DNS queries received from the CPE, as well as the contents of records being supplied to the CPE. Subsequent network traffic between the CPE and IP addresses contained in the records can also be examined as part of the analysis.
- the terminal may then generate statistical and/or predictive information concerning the behavior of various applications operating on the CPE.
- the terminal generates a preload list based on some, or all, of the information gathered from analyzing the DNS queries and records.
- the preload list can include a list of domains (i.e., domain names) and a time schedule.
- the time schedule can include a specific time associated with each domain, or group of domains.
- the preload lists can also include date associated with each domain. The time schedule specifies the precise time at which DNS queries should be submitted for the associated domains.
- the preload list is transmitted to the DNS preload client operating on the CPE.
- the DNS preload client submits preload DNS queries (i.e., DNS queries or simply queries) based on information contained in the preload list. More particularly, the DNS preload client examines the entries contained in the preload list, and submits a DNS query for each domain at this specific time (and date) specified. If a particular time entry is associated with a group of domains, the DNS preload client submits DNS queries for all domains in the group at the specified time.
- the DNS queries are submitted by the DNS preload client using platform specific APIs and processed in the same manner as other DNS queries submitted by applications on the CPE.
- preload records satisfying the preload DNS queries submitted by the DNS preload client are received by the CPE.
- the DNS services system of the CPE stores a copy of the preload records within its associated storage unit based, in part, on the value specified in the TTL parameter of the preload record.
- the DNS services system also forwards a copy of the preload record to the DNS preload client.
- Fig. 4 illustrates registration of DNS preload clients, according to one or more embodiments.
- a registration request is submitted from the preload client of a CPE (i.e., CPE l) to the DNS preload server located within the terminal.
- the registration request can be in the form of a UDP message containing a timestamp which identifies the time at which the request was transmitted by the DNS preload client.
- the timestamp can be used by the DNS preload server to determine a time offset between the terminal and the CPE. Furthermore, the timestamp can be used compensate the time schedule contained in the preload list.
- the DNS preload client can be supplied with the IP address and port for establishing a connection with DNS preload server during its initial installation on the CPE.
- Other mechanisms such as multicast DNS, can also be used to detect the availability of the DNS preload server. In situations where the CPE does not include a DNS preload client and/or the terminal does not include a DNS preload server, functionality of the CPE or associated DNS operations are not adversely affected.
- the registration request can be repeatedly submitted to the DNS preload server until an acknowledgment is received. This is illustrated at 412.
- the DNS preload server generates a time offset based, in part, on the timestamp.
- the time offset can correspond, for example, to the precise amount of time it takes for messages from the CPE to reach the terminal.
- the time offset can be used to more accurately predict the times provided in the preload list.
- the DNS preload server supplies an instruction to the packet inspector to clear all filters associated with the CPE. Thus, all parameters that were previously used to collect information pertaining to the CPE would be cleared.
- a new context is also created for the CPE to facilitate tracking thereof by the DNS preload server.
- the DNS preload server supplies registration information to the DNS preload client.
- the registration information can include additional data to be used by the DNS preload client.
- the DNS preload client transmits an acknowledgment to the DNS preload server to indicate that the registration information has been successfully received.
- the registration acknowledgment also includes the unique ID which was assigned to the DNS preload client.
- the DNS preload client may include an application list with the registration acknowledgment, as indicated at 422.
- the DNS preload client can be configured to probe the CPE to identify all installed applications and incorporate those applications within the application list.
- the DNS preload client can also collect information pertaining to the frequency with which applications are used, and only supply an application list containing applications that are used with a minimum frequency by the customer.
- the DNS preload server creates new filters to be used for the CPE.
- the DNS preload server also instructs the packet inspector to forward copies of packets with the destination IP address of the CPE and source port 53, which corresponds to DNS responses (or records) for requests originating from the CPE.
- the terminal is capable of supporting multiple CPEs.
- a DNS preload client may or may not be present. Any additional DNS preload clients present on CPEs supported by the terminal, can also be registered with the DNS preload server.
- the DNS preload client on CPE 2 i.e., DNS preload client 2
- the DNS preload server instructs the packet inspector to clear, or reset, all filters associated with CPE 2.
- the DNS preload server supplies registration information to DNS preload client 2.
- the DNS preload server generates a unique identification for each DNS preload client.
- DNS preload client 2 submits a registration acknowledgment to the DNS preload server in order to confirm successful receipt of the registration information.
- DNS preload client 2 also utilizes the assigned ID to distinguish itself from other DNS preload clients registered with the DNS preload server.
- an application list 434 can also be included with the registration acknowledgment. It should be noted, however, that certain DNS preload clients may not be configured to probe the CPE, or may be prevented from examining the contents of data stored within the CPE. In such cases, an application list would not be included with the registration acknowledgment.
- the DNS preload server generates new (or revised) filters to be used by the packet inspector for DNS preload client 2.
- the DNS preload server also instructs the packet inspector to forward copies of packets with the destination IP address of CPE 2 and source port 53. Additional DNS preload clients would be registered in the same manner upon establishing a wired or wireless network connection with the terminal.
- the IP address assigned the CPE may change. This can occur, for example, when the CPE transitions from terrestrial wireless to Wi-Fi, or when the Dynamic Host Configuration Protocol (DCHP) lease assigned by the terminal (or external router) expires.
- the DNS preload server should be informed of any changes to the IP address so that the packet inspection filters can be updated to track the DNS and/or other network activity of the CPE.
- the DNS preload client can be configured to transmit periodic “health report” messages to the DNS preload server. The contents of packets associated with the health report can be examined by the DNS preload server in order to detect IP address changes and update the filters accordingly.
- the DNS preload client can be configured to send an asynchronous message upon detecting changes to the IP address of the CPE.
- Fig. 5 illustrates a process for determining changes in the IP address of a CPE in accordance with one or more embodiments.
- the DNS preload client is registered with the DNS preload server. This can be accomplished, for example, using the process previously described with respect to Fig. 4.
- a source IP address is associated with the filters generated for the DNS preload client. According to various embodiments, the source IP address can correspond to the IP address assigned to the CPE by the terminal.
- a health report is transmitted to the DNS preload server from the DNS preload client. According to the disclosed embodiments, the health report can be periodically transmitted to the DNS preload server at predetermined time intervals (1, 15, 30, 60, 120 minutes, etc.). The time interval can be selected based on the specific system requirements. Factors that may be considered in selecting the time interval can include, without limitation, overall CPE traffic, individual application traffic, number DNS queries submitted, etc.
- the health report is examined by the DNS preload server.
- the DNS preload server determines whether any changes have occurred in the source IP address associated with the health report.
- a change in the source IP address can occur, for example, if the CPE is disconnected from the terminal for an extended period of time, or when the lease associated with the source IP address has expired.
- the DNS preload server assigns a unique ID to each DNS preload client. This ID is included in all communication between the DNS preload client (via the CPE) and the DNS preload server. Accordingly, if the source IP address of the CPE changes, the DNS preload server will still be able to correctly identify the DNS preload client using this ID.
- the DNS preload server updates the filters associated with the CPE at 520.
- the updated filters can then be provided to the packet inspector so that network traffic to/from the CPE can be continually monitored. Control then returns to 514 where periodic health reports continue to be transmitted to the DNS preload server. If there are no changes in the source IP address associated with the health report, control also returns to 514.
- the DNS preload client can be configured to detect any changes in the IP address assigned to the CPE.
- Such embodiments provide an optional capability to monitor changes in the IP address of the CPE, as indicated at 530.
- control would optionally pass to 532 after the DNS preload server updates the filters at 520.
- DNS preload server does not detect a change in the source IP address of the health report (at 518)
- control optionally passes to 532 as well.
- the DNS preload client monitors any changes in the IP address assigned to the CPE.
- the DNS preload client determines whether or not a change has occurred in the source IP address of the CPE. If a change has occurred, the DNS preload client immediately transmits a new health report to the DNS preload server at 536. If no changes are detected, control returns to 514 where periodic health reports continued to be transmitted to the DNS preload server.
- Fig. 6 illustrates network activity tracking according to various embodiments.
- a DNS query is submitted by an application running on the CPE.
- DNS queries i.e., name resolution requests
- applications on the CPE are handled by the DNS services system.
- the exact API used by the applications will depend on the operating system and application frameworks.
- the applications are built using frameworks that provide high level abstraction for submitting/receiving DNS queries/records.
- the result of DNS queries can be delivered synchronously or asynchronously via framework call backs.
- the DNS services system determines if the storage unit contains a valid record capable of satisfying the DNS query. If a record is found within the storage unit of the DNS services system, it is immediately supplied to the application at 614. If a record is not available within the storage unit, the DNS query is submitted to the terminal at 616. More particularly, if no cached results are found for the requested domain (i.e., the DNS query), the DNS services system initiates a lookup using standard DNS protocol procedures. The DNS query is then sent to the DNS preload server at the terminal. The packet inspector examines the contents of the DNS query and tracks any information associated with the filters created for the CPE.
- the DN S query is then submitted to the gateway DN S server at 618. More particularly, the terminal establishes a communication link to the gateway over the satellite network. As previously discussed, all communication carried over the satellite network can be encrypted using layer-2 or layer-3 encryption techniques for security.
- the gateway DNS server searches its storage unit to locate a matching record for the DNS query. Once the record is located, it is supplied to the terminal over the satellite link at 620. Although not illustrated in Fig. 6, there may be situations where a matching record is not available at the gateway DNS server.
- the gateway can be configured to further submit the DNS query to an authoritative DNS server in order to obtain a matching authoritative record.
- the gateway DNS server can be configured to store a copy of the authoritative record within its storage unit in order to resolve any subsequent DNS queries that are received during the life of the record.
- the packet inspector examines its contents based on the filters corresponding to the CPE.
- the record is supplied to the DNS services system of the CPE, where a copy of the record is cached in the storage unit. The precise duration for which the record is cached is determined, in part, by the TTL information contained in the record.
- the DNS services system supplies the record to the application which initiated the DNS query.
- the gateway supports simultaneous connections to multiple terminals.
- the gateway can be configured to collect and analyze data pertaining to DNS queries and records associated with each terminal. Some or all of the analyzed data can optionally be transmitted to the DNS preload server at 626.
- the DNS preload server can further analyze the data received from the gateway in order to refine the information contained in the preload list.
- the packet inspector submits a copy of the record to the DNS preload server.
- the DNS preload server can be configured to decode the record received from the gateway to extract and store the name to IP address mappings in the context maintained for the CPE.
- the DNS preload server can also extract the TTL parameter from the record and store the value in the context maintained for the CPE.
- the DNS preload server creates new filters for the CPE and supplies the filters to the packet inspector. For example, the filters can direct the packet inspector to track packets with source or destination IP addresses matching the list of IP addresses extracted from the record received from the gateway.
- the DNS preload server tracks the expiration of the record using, in part, the TTL parameter contained therein.
- the DNS preload server can be configured to calculate the expiration time by adjusting the value of the TTL parameter in order to compensate for factors such as transmission delay from the gateway, time offset from the CPE, etc.
- the expiration time can subsequently be stored in the context maintained for the CPE.
- the DNS preload server can be configured to implement various secure DNS proxy functions. Such features can advantageously allow the DNS preload server to replace the value of the TTL parameter in the record with an adjusted value after applying the compensation factors.
- the application which submitted the DNS query generates traffic to and from addresses contained in the record received at 624.
- the traffic is carried to the gateway and subsequently to external networks, such as the internet.
- the traffic is carried in the form of packets (TCP or UDP) having a source/destination IP address matching the IP address of the domain name for which the DNS query was originally submitted at 610.
- the packet inspector tracks all of the traffic associated with the CPE at 636.
- the traffic may be identified based, in part, on source and destination IP addresses contained in the filters.
- statistics are updated for all packets that match the filter criteria specified by the DNS preload server. The packet count statistics and the time stamp corresponding to the most recent activity are maintained by the packet inspector until requested to be cleared.
- the results of information collected using the filters are submitted to the DNS preload server.
- the filter results can be submitted to the DNS preload server at predetermined time intervals, or when certain thresholds have been met. For example, once a certain amount of traffic has occurred from the CPE, the results can be supplied to the DNS preload server.
- the DNS preload server may periodically request the information from the packet inspector.
- the DNS preload server analyzes the information received from the packet inspector and either updates or resets the filters. The updated or reset the filters are then supplied to the packet inspector. The packet inspector then continues to monitor network traffic from the CPE as indicated by 642.
- this process can continue until the DNS preload server determines that the CPE no longer requires tracking, or the CPE is disconnected from the network (switches to cellular data, public Wi-Fi, etc.).
- the information collected by the packet inspector is analyzed at periodic intervals to determine the list of domains that are most likely to be requested by applications running on the CPE. While all DNS activity is tracked, only those interactions that show recurring patterns and actual traffic exchanges are considered for inclusion in the preload list.
- the preload list can contain entries based on DNS data supplied by the gateway.
- Fig. 7 illustrates a process for cache refresh according to one or more embodiments.
- the preload list is generated by the DNS preload server and transmitted to the DNS preload client.
- the preload list contains a list of domains and a time schedule at which the DNS preload client should submit DNS queries for those domains.
- the preload list can be created, for example, based on analysis of traffic from applications in the CPE.
- the time schedule contained in the preload list is created to predict when applications on the CPE will submit DNS queries for those domains, so that matching records may be available from the DNS services system of the CPE.
- the information collected by the packet inspector is analyzed at periodic intervals to determine the list of domains that are most likely to be requested by applications running on the CPE. While all DNS activity is tracked, only those interactions that show recurring patterns and with actual traffic exchanges are considered for inclusion in the preload list.
- the preload list can contain entries based on DNS data supplied by the gateway. The preload list is subsequently parsed and stored by the DNS preload client. The newly received preload list also replaces previous lists, if any, that were in use by the DNS preload client.
- filters associated with the CPE are updated or reset, and supplied to the packet inspector. This ensures that stale or unused DNS queries are not utilized for generating the preload list.
- the DNS preload client submits a preload DNS query (or simply DNS query) corresponding to the first entry (i.e., domains and time schedule) contained in the preload list. As previously discussed, such DNS queries are submitted in the same manner as all other applications currently running on the CPE, namely through the use of platform specific APIs. Thus, the preload DNS query (or DNS query) is received and processed by the DNS services system.
- the DNS services system searches the storage unit in order to determine whether or not a matching record exists for the preload DNS query. If a matching record is found, it is supplied to the DNS preload client at 718.
- a matching record should not be available within the DNS services system of the CPE.
- the DNS preload server tracks and analyzes network traffic for the CPE, and is aware of the status of all records that may be stored within the storage unit of the DNS services system. Thus, all entries contained in the preload list will correspond to records that either do not exist, or will expire prior to the time specified in the preload list. If a matching record is not found in the storage unit, the preload DNS query is submitted to the terminal at 720. The packet inspector examines the contents of the preload DNS query (or DNS query) based on information contained in the filters. At 722, the DNS query is submitted to the gateway DNS server via the satellite link.
- a matching record is received from the gateway DNS server.
- the packet inspector again examines the contents of the record based on the current filters.
- the record is supplied to the DNS services system of the CPE.
- a copy of the matching record is supplied to the DNS preload sever at 728.
- the DNS preload server extracts information such as name to IP address mappings at 728.
- the DNS preload server updates or creates new filters for the packet inspector at 730. The filters can subsequently be utilized to track network activity of the CPE.
- the DNS services system supplies the record to the DNS preload client in the same manner in which records are supplied to other applications. Additionally, the DNS services system stores a copy of the record within its storage unit at 734. Thus, the DNS services system of the CPE now contains a valid record matching the DNS query from the preload list. According to the disclosed embodiments, records received by the DNS preload client are ignored, and not utilized to generate subsequent network traffic. The primary purpose of the preload list is to obtain valid records that can be stored within the DNS services system of the CPE prior to being used by other applications.
- the DNS preload client continues to submit DNS queries for each entry contained in the preload list. Thus, the process from 714 to 736 would be repeated for each entry.
- a DNS query is received from an application running in the CPE.
- the DNS services system examines its storage unit and determines that this DNS query can be matched with a record stored as a result of the DNS query previously received from the DNS preload client. Accordingly, at 742, the DNS services system immediately supplies the matching record to the application without the need to submit a new DNS query to the terminal.
- Figs. 8 A and 8B illustrate a process for improving DNS performance using DNS preload client, in accordance with various embodiments.
- the DNS preload client initiates the registration process with the DNS preload server.
- the DNS preload server generates a unique identification that is assigned to each DNS preload client associated with the terminal.
- the terminal may support various types of CPEs, only some of the CPEs may be configured to incorporate a DNS preload client. For example, devices such as Internet of things, security cameras, etc., may not be configured to allow installation and operation of a DNS preload client.
- the DNS preload server creates the filters associated with the particular DNS preload client that has been registered. The filters are supplied to the packet inspector in order to detect and monitor network traffic associated with the CPE containing the DNS preload client.
- changes in the IP address of the CPE are monitored.
- changes in the IP address of the CPE can be detected based by the DNS preload server during examination of health reports received from the DNS preload client.
- the DNS preload client can be configured to detect any internal changes and the IP address of the CPE and immediately supply a health report so that the DNS preload server may detect the change in IP address.
- the DNS preload server updates the filters associated with the DNS preload client at 816. For example, the DNS preload server can modify the filters to reflect the current IP address of the CPE.
- the packet inspector would then discontinue monitoring network traffic associated with the old (or expired) IP address of the and begin tracking the network traffic associated with the new IP address contained in the updated filters.
- the IP address of the CPE is continually monitored in order to detect changes so that the filters can be appropriately updated.
- the packet inspector extracts the source IP address and domain name contained in the DNS query in order to determine if the DNS query originates from the terminal containing the registered DNS preload client. For example, if the DNS query originates from the CPE of the registered DNS preload client, this information would constitute part of the network traffic being monitored. If the DNS query originates from a CPE without a DNS preload client, for example, the source IP address would not match information from the filters and the network traffic from this CPE would not be monitored.
- the DNS query is forwarded to the gateway DNS server using the satellite network. As previously discussed, all information transmitted over the satellite network can be encrypted using layer-2 or layer-3 encryption techniques in order to provide secure communication.
- a matching record is received at the terminal.
- the gateway DNS server would search its storage unit (or cache) in order to retrieve a valid record which matches the DNS query. If a valid record is not available, the gateway DNS server can be further configured to submit the DNS query to an authoritative DNS server via the internet. Accordingly, the matching record received at the terminal can be obtained directly from the gateway DNS server or indirectly from the authoritative DNS server.
- the packet inspector examines the record, and transmits copies to the appropriate destinations. More particularly, at 828, a copy is sent to the CPE from which the DNS query originated. If the record is associated with the previously registered DNS preload client, however, a copy is also sent to the DNS preload server at 830.
- the DNS preload server extracts the destination IP address and address mappings contained in the record.
- the DNS preload server begins tracking the expiration time for the record.
- the DNS preload server can examine the record to obtain the value contained in the TTL parameter. This value can optionally be modified to compensate for various factors including, but not limited to, transmission delays associated with record.
- the DNS preload server can subsequently generate a timer which calculates, or counts down to, the time at which the record will expire.
- statistics associated with network traffic from the CPE are received at the DNS preload server.
- the packet inspector can be configured to automatically supply the network traffic statistics resulting from the filters to the DNS preload server at predetermined or periodic intervals.
- the DNS preload server can also initiate a request for network traffic statistics.
- the DNS preload server performs an analysis of the network activity from the CPE.
- the network activity associated with the CPE can include all requests for name resolution (i.e., DNS requests), as well as subsequent traffic to and from address mappings contained in the matching record. This analysis is used to predict when apps from the CPE may submit DNS queries that require resolution by the gateway DNS server.
- the DNS preload server generates a preload list.
- the preload list contains, for example, various domains and a time schedule at which those domains should be accessed. According to various embodiments, the time schedule is created such that DNS queries pertaining to domains in the preload list are submitted prior to predicted access by applications in the CPE.
- This schedule is determined, at least in part, on the analysis of network activity for the CPE.
- the preload list is transmitted to the DNS preload client.
- the DNS preload client submits DNS queries (i.e., preload DNS queries) for domains contained in the preload list.
- the DNS queries are submitted at the times specified in the schedule.
- the DNS preload server is aware of the records that have been supplied to the CPE as well as the TTL parameters contained in these records.
- the DNS preload server can therefore use this information to track the expiration time of records stored by the CPE. Accordingly, the time schedule is generated such that all preload DNS queries are submitted at a time when records from the DNS services system of the DNS preload client device are either nonexistent or expired.
- the preload DNS queries are therefore submitted to the terminal for resolution by the gateway DNS server.
- a matching record (or preload record) is received from the gateway DNS server.
- the preload record is supplied to the DNS preload client.
- the preload record is supplied to the CPE, and the DNS services system supplies the record to the DNS preload client.
- the preload record corresponds to a matching record for the preload DNS query submitted by the DNS preload client.
- a copy of the preload record is saved in the storage unit of the DNS services system.
- the DNS preload client does not initiate additional network traffic based on the received preload records. Rather, the preload queries are initiated only to insure that valid records are available in the DNS services system at times when applications installed on the CPE are predicted to request resolution for the same domains.
- the DNS services system of the CPE receives one or more DNS queries from applications installed on the CPE. The DNS services system subsequently searches the storage unit and supplies the matching record directly to the application without submitting the DNS query to the terminal. More particularly, since the DNS preload server performs an analysis to predict IP addresses likely to be requested at specific times from applications installed on the CPE, the preload records stored within the storage unit correspond to valid records that can be used to resolve such DNS queries at the time submitted by the applications. The process ends at 856.
- Various features described herein may be implemented via software, hardware (e.g., general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc.), firmware or a combination thereof.
- DSP Digital Signal Processing
- ASIC Application Specific Integrated Circuit
- FPGAs Field Programmable Gate Arrays
- hardware/software/firmware combinations can be incorporated into the previously described terminal, DNS preload server, packet inspector, satellite network transport, configuration handler, CPE, DNS preload client, DNS services system, DNS protocol unit, network manager, gateway, gateway DNS server, transmitters, transceivers, etc.
- such hardware can be interfaced to connect and/or facilitate communication between different components such as the terminal and CPEs, the configuration handler and satellite network transport unit, the DNS protocol unit and storage unit, the network manager and the gateway DNS server, etc.
- software may be used interchangeably and are generally intended to include any sequence of machine or human recognizable instructions intended to program/configure a computer, processor, server, etc. to perform one or more functions.
- Such software can be rendered in any appropriate programming language or environment including, without limitation: C, C++, C#, Python, R, Fortran, COBOL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), Java, JavaScript, etc.
- processor microprocessor, digital processor, and CPU are meant generally to include all types of processing devices including, without limitation, single/multi-core microprocessors, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, gate arrays (e.g., FPGAs), PLDs, reconfigurable compute fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs).
- DSPs digital signal processors
- RISC reduced instruction set computers
- CISC general-purpose
- gate arrays e.g., FPGAs
- PLDs reconfigurable compute fabrics
- array processors e.g., secure microprocessors
- ASICs application-specific integrated circuits
- Fig. 9 is a diagram of a computer system that can be used to implement features of various embodiments.
- the computer system 900 includes a bus 901 or other communication mechanism for communicating information and a processor 903 coupled to the bus 901 for processing information.
- the computer system 900 also includes main memory 905, such as a random access memory (RAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random-access memory (DDR SDRAM), DDR2 SDRAM, DDR3 SDRAM, DDR4 SDRAM, etc., or other dynamic storage device (e.g., flash RAM), coupled to the bus 901 for storing information and instructions to be executed by the processor 903.
- RAM random access memory
- DRAM dynamic random access memory
- SDRAM synchronous dynamic random access memory
- DDR SDRAM double data rate synchronous dynamic random-access memory
- DDR2 SDRAM DDR2 SDRAM
- DDR3 SDRAM DDR3 SDRAM
- DDR4 SDRAM DDR4 SDRAM
- Main memory 905 can also be used for storing temporary variables or other intermediate information during execution of instructions by the processor 903.
- the computer system 900 may further include a read only memory (ROM) 907 or other static storage device coupled to the bus 901 for storing static information and instructions for the processor 903.
- ROM read only memory
- the computer system 900 may be coupled via the bus 901 to a display 911, such as a light emitting diode (LED) or other flat panel displays, for displaying information to a computer user.
- a display 911 such as a light emitting diode (LED) or other flat panel displays
- An input device 913 such as a keyboard including alphanumeric and other keys, is coupled to the bus 901 for communicating information and command selections to the processor 903.
- a cursor control 915 such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor 903 and for controlling cursor movement on the display 911.
- the display 911 can be touch enabled (i.e., capacitive or resistive) in order facilitate user input via touch or gestures.
- the processes described herein are performed by the computer system 900, in response to the processor 903 executing an arrangement of instructions contained in main memory 905.
- Such instructions can be read into main memory 905 from another computer- readable medium, such as the storage device 909.
- Execution of the arrangement of instructions contained in main memory 905 causes the processor 903 to perform the process steps described herein.
- processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory 905.
- hard-wired circuitry may be used in place of or in combination with software instructions to implement exemplary embodiments.
- exemplary embodiments are not limited to any specific combination of hardware circuitry and software.
- the computer system 900 also includes a communication interface 917 coupled to bus 901.
- the communication interface 917 provides a two-way data communication coupling to a network link 919 connected to a local network 921.
- the communication interface 917 may be a digital subscriber line (DSL) card or modem, an integrated services digital network (ISDN) card, a cable modem, fiber optic service (FiOS) line, or any other communication interface to provide a data communication connection to a corresponding type of communication line.
- communication interface 917 may be a local area network (LAN) card (e.g. for EthernetTM or an Asynchronous Transfer Mode (ATM) network) to provide a data communication connection to a compatible LAN.
- LAN local area network
- Wireless links can also be implemented.
- communication interface 917 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
- the communication interface 917 can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a High Definition Multimedia Interface (HDMI), etc.
- USB Universal Serial Bus
- HDMI High Definition Multimedia Interface
- the network link 919 typically provides data communication through one or more networks to other data devices.
- the network link 919 may provide a connection through local network 921 to a host computer 923, which has connectivity to a network 925 such as a wide area network (WAN) or the Internet.
- the local network 921 and the network 925 both use electrical, electromagnetic, or optical signals to convey information and instructions.
- the signals through the various networks and the signals on the network link 919 and through the communication interface 917, which communicate digital data with the computer system 900, are exemplary forms of carrier waves bearing the information and instructions.
- the computer system 900 can send messages and receive data, including program code, through the network(s), the network link 919, and the communication interface 917.
- a server (not shown) might transmit requested code belonging to an application program for implementing an exemplary embodiment through the network 925, the local network 921 and the communication interface 917.
- the processor 903 may execute the transmitted code while being received and/or store the code in the storage device 909, or other non-volatile storage for later execution. In this manner, the computer system 900 may obtain application code in the form of a carrier wave.
- Non-volatile media include, for example, optical or magnetic disks, such as the storage device 909.
- Non-volatile media can further include flash drives, USB drives, microSD cards, etc.
- Volatile media include dynamic memory, such as main memory 905.
- Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 901. Transmission media can also take the form of acoustic, optical, or electromagnetic waves, such as those generated during radio frequency (RF) and infrared (IR) data communications.
- RF radio frequency
- IR infrared
- Common forms of computer- readable media include, for example, a USB drive, micro SD card, hard disk drive, solid state drive, optical disk (e.g., DVD, DVD RW, Blu-ray), or any other medium from which a computer can read.
- Fig. 10 illustrates a chip set 1000 upon which features of various embodiments may be implemented.
- Chip set 1000 is programmed to implement various features as described herein and includes, for instance, the processor and memory components described with respect to Fig. 10 incorporated in one or more physical packages (e.g., chips).
- a physical package includes an arrangement of one or more materials, components, and/or wires on a structural assembly (e.g., a baseboard) to provide one or more characteristics such as physical strength, conservation of size, and/or limitation of electrical interaction.
- the chip set can be implemented in a single chip.
- Chip set 1000, or a portion thereof constitutes a means for performing one or more steps of the figures.
- the chip set 1000 includes a communication mechanism such as a bus 1001 for passing information among the components of the chip set 1000.
- a processor 1003 has connectivity to the bus 1001 to execute instructions and process information stored in, for example, a memory 1005.
- the processor 1003 may include one or more processing cores with each core configured to perform independently.
- a multi-core processor enables multiprocessing within a single physical package. Examples of a multi-core processor include two, four, eight, or greater numbers of processing cores.
- the processor 1003 may include one or more microprocessors configured in tandem via the bus 1001 to enable independent execution of instructions, pipelining, and multithreading.
- the processor 1003 may also be accompanied with one or more specialized components to perform certain processing functions and tasks such as one or more digital signal processors (DSP) 1007, or one or more application- specific integrated circuits (ASIC) 1009.
- DSP digital signal processors
- ASIC application- specific integrated circuits
- a DSP 1007 typically is configured to process real-world signals (e.g., sound) in real time independently of the processor 1003.
- an ASIC 1009 can be configured to performed specialized functions not easily performed by a general purposed processor.
- Other specialized components to aid in performing the inventive functions described herein include one or more field programmable gate arrays (FPGA) (not shown), one or more controllers (not shown), or one or more other special-purpose computer chips.
- FPGA field programmable gate arrays
- the processor 1003 and accompanying components have connectivity to the memory 1005 via the bus 1001.
- the memory 1005 includes both dynamic memory (e.g., RAM, magnetic disk, re-writable optical disk, etc.) and static memory (e.g., ROM, CD-ROM, DVD, BLU-RAY disk, etc.) for storing executable instructions that when executed perform the inventive steps described herein.
- the memory 1005 also stores the data associated with or generated by the execution of the inventive steps.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA3157743A CA3157743A1 (en) | 2019-11-15 | 2020-11-13 | System and method for improving network performance when using secure dns access schemes |
BR112022005665A BR112022005665A2 (en) | 2019-09-25 | 2020-11-13 | System and method for improving network performance when using secure dns access schemes |
EP20869717.7A EP4035336A4 (en) | 2019-09-25 | 2020-11-13 | System and method for improving network performance when using secure dns access schemes |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/583,004 | 2019-09-25 | ||
US16/583,004 US11438763B2 (en) | 2019-09-25 | 2019-09-25 | System and method for improving network performance when using secure DNS access schemes |
US16/685,943 US11949650B2 (en) | 2019-09-25 | 2019-11-15 | System and method for improving network performance when using secure DNS access schemes |
US16/685,943 | 2019-11-15 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021062425A1 true WO2021062425A1 (en) | 2021-04-01 |
Family
ID=74881387
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2020/060445 WO2021062425A1 (en) | 2019-09-25 | 2020-11-13 | System and method for improving network performance when using secure dns access schemes |
Country Status (4)
Country | Link |
---|---|
US (1) | US11949650B2 (en) |
EP (1) | EP4035336A4 (en) |
BR (1) | BR112022005665A2 (en) |
WO (1) | WO2021062425A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112769976B (en) * | 2021-01-13 | 2023-10-24 | 网宿科技股份有限公司 | Domain name resolution method and system |
US11489811B1 (en) * | 2021-08-31 | 2022-11-01 | Check Point Software Technologies Ltd. | On-device protected DNS |
US11863518B2 (en) | 2021-11-24 | 2024-01-02 | Oracle International Corporation | Methods, systems, and computer readable media for automatic domain name system (DNS) configuration for 5G core (5GC) network functions (NFs) using NF repository function (NRF) |
US11652782B1 (en) * | 2021-11-24 | 2023-05-16 | Oracle International Corporation | Methods, systems, and computer readable media for dynamically updating domain name system (DNS) records from registered network function (NF) profile information |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030172183A1 (en) * | 2002-02-25 | 2003-09-11 | Broadcom Corporation | System, method and computer program product for caching domain name system information on a network gateway |
US20040073707A1 (en) * | 2001-05-23 | 2004-04-15 | Hughes Electronics Corporation | Generating a list of network addresses for pre-loading a network address cache via multicast |
US20050259645A1 (en) * | 2004-05-18 | 2005-11-24 | Chen John A | Thwarting denial of service attacks originating in a DOCSIS-compliant cable network |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8533282B2 (en) * | 2002-02-25 | 2013-09-10 | Broadcom Corporation | System, method and computer program product for selectively caching domain name system information on a network gateway |
EP2293561B1 (en) * | 2009-09-07 | 2013-06-26 | Accenture Global Services Limited | Network autodiscovery as a lever to decorrelated service activation through event driven architecture |
US8549148B2 (en) | 2010-10-15 | 2013-10-01 | Brocade Communications Systems, Inc. | Domain name system security extensions (DNSSEC) for global server load balancing |
WO2012061243A1 (en) | 2010-11-05 | 2012-05-10 | Citrix Systems, Inc. | Systems and methods for managing domain name system security (dnssec) |
WO2012094675A2 (en) * | 2011-01-07 | 2012-07-12 | Seven Networks, Inc. | System and method for reduction of mobile network traffic used for domain name system (dns) queries |
US20120297087A1 (en) * | 2011-05-18 | 2012-11-22 | Alcatel-Lucent Usa Inc. | Method And Apparatus For Message Distribution In A Device Management System |
US9015469B2 (en) | 2011-07-28 | 2015-04-21 | Cloudflare, Inc. | Supporting secure sessions in a cloud-based proxy service |
US9215205B1 (en) * | 2012-04-20 | 2015-12-15 | Infoblox Inc. | Hardware accelerator for a domain name server cache |
US9154479B1 (en) | 2012-09-14 | 2015-10-06 | Amazon Technologies, Inc. | Secure proxy |
-
2019
- 2019-11-15 US US16/685,943 patent/US11949650B2/en active Active
-
2020
- 2020-11-13 WO PCT/US2020/060445 patent/WO2021062425A1/en unknown
- 2020-11-13 BR BR112022005665A patent/BR112022005665A2/en unknown
- 2020-11-13 EP EP20869717.7A patent/EP4035336A4/en active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040073707A1 (en) * | 2001-05-23 | 2004-04-15 | Hughes Electronics Corporation | Generating a list of network addresses for pre-loading a network address cache via multicast |
US20030172183A1 (en) * | 2002-02-25 | 2003-09-11 | Broadcom Corporation | System, method and computer program product for caching domain name system information on a network gateway |
US20050259645A1 (en) * | 2004-05-18 | 2005-11-24 | Chen John A | Thwarting denial of service attacks originating in a DOCSIS-compliant cable network |
Non-Patent Citations (1)
Title |
---|
See also references of EP4035336A4 * |
Also Published As
Publication number | Publication date |
---|---|
US20210092088A1 (en) | 2021-03-25 |
EP4035336A1 (en) | 2022-08-03 |
BR112022005665A2 (en) | 2022-06-21 |
EP4035336A4 (en) | 2023-11-08 |
US11949650B2 (en) | 2024-04-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11949650B2 (en) | System and method for improving network performance when using secure DNS access schemes | |
US10778582B2 (en) | Method and apparatus for traffic optimization in virtual private networks (VPNs) | |
US11438763B2 (en) | System and method for improving network performance when using secure DNS access schemes | |
US9800539B2 (en) | Request routing management based on network components | |
US8214451B2 (en) | Network service version management | |
US8166197B2 (en) | Multipath routing process | |
EP2632115B1 (en) | A gateway for communication in a tactical network | |
CN107528862B (en) | Domain name resolution method and device | |
US8938526B1 (en) | Request routing management based on network components | |
JP4965559B2 (en) | Resource address request management method and related gateway device | |
US10187475B2 (en) | Method and system for automatically bypassing network proxies in the presence of interdependent traffic flows | |
US7555306B2 (en) | Method and system for mobile device performance monitoring | |
US20100042725A1 (en) | Contents provider participation type contents delivery system and method, and contents delivery network domain name system server thereof | |
US20160036848A1 (en) | Intercloud security as a service | |
CN102571972B (en) | The distributed file system access of site-aware is carried out from outside enterprise network | |
CN104079683B (en) | A kind of authoritative domain name server directly in response to domain name analytic method and system | |
CN104168339A (en) | Method and device for preventing domain name from being intercepted | |
CN100461719C (en) | System and method for detecting service healthiness | |
US11601518B1 (en) | Managed exit nodes and third party proxies | |
CN106470251A (en) | Domain name analytic method and virtual DNS authority server | |
CA3157743A1 (en) | System and method for improving network performance when using secure dns access schemes | |
JP6014068B2 (en) | Relay device, relay method, and computer program | |
CN105025028A (en) | IP black hole discovering method based on flow analysis | |
KR100509097B1 (en) | Web relay for transporting the web-based message to web user and method thereof using the web relay | |
Data | CROSS-REFERENCE TO RELATED APPLICATIONS |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20869717 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REG | Reference to national code |
Ref country code: BR Ref legal event code: B01A Ref document number: 112022005665 Country of ref document: BR |
|
ENP | Entry into the national phase |
Ref document number: 2020869717 Country of ref document: EP Effective date: 20220425 |
|
ENP | Entry into the national phase |
Ref document number: 3157743 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 112022005665 Country of ref document: BR Kind code of ref document: A2 Effective date: 20220324 |