TWI568215B - Methods for handling requests between different resource record types and systems thereof - Google Patents

Description

Method and system for processing requests between different resource record types

The present technology generally relates to network communications, and more particularly to systems and methods for processing requests between different resource record types.

Computer networks (such as the Internet) are slowly and steadily switching from Internet Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6): slow because if all network devices are deployed IPv6, IPv6 deployment is the most useful ("network effect"), the difficulty is due to the need to update software and / or hardware. One example solution is DNS64, which is an exemplary mechanism for synthesizing A records used in IPv4 into AAAA resource records (or 4-A records) used in IPv6. However, if the DNS64 software between the DNS client requesting the AAAA resource address and the DNS server has already synthesized the AAAA resource record but cannot sign the synthesized AAAA resource record, the downstream authenticator will synthesize the AAAA resource record type. Marked as invalid because traditional techniques cannot verify synthetic AAAA resource records. When transitioning to IPv6 (for an AAAA response originating from an A response, which is a different resource record type than the AAAA response), the original resource record signature (RRSIG) associated with the IPv4A resource record type becomes invalid. Therefore, the traditional implementation of DNS64 undermines the Domain Name System Security Extension (DNSSEC). Unfortunately, using traditional techniques results in an unverified AAAA resource record response, which poses a security threat to the client device requesting the resource record and causes Its DNSSEC cannot be implemented.

One example of the present technology is a method of processing requests between different resource record types. The method includes receiving, at a traffic management device, a first resource record type from one or more server devices in accordance with a request by a client device. The traffic management device verifies the first resource record type and creates a second resource record type corresponding to the first resource record type after verification. The traffic management device signs the second resource record type to service the request of the client device.

Another example is a computer readable medium storing instructions for processing requests between different resource record types that, when executed by at least one processor, cause the processor to perform a series of steps. The step includes receiving, by the traffic management device, a first resource record type from one or more server devices in response to a request by the client device. In addition, the step includes: verifying, by the traffic management device, the first resource record type, and after the verifying, creating a second resource record type corresponding to the first resource record type; and the traffic management device is configured to the second resource record type Signature to service the request of the client device.

Another example is a traffic management device that includes one or more processors for executing one or more traffic management applications; a memory coupled to the one or more processors via a bus; and the one Or a plurality of processor and memory connected network interface controllers configured to receive data packets from a network involved in executing a plurality of traffic management applications and to process requests between different resource record types. In this example, the At least one of the one or more processors is configured to execute program instructions stored in the memory, and the network interface controller having logic is further configured to implement the following: traffic in response to a request by the client device The management device receives the first resource record type from one or more server devices. The foregoing implementation includes verifying the first resource record type at the traffic management device; and creating a second resource record type corresponding to the first resource record type after verification. The second resource record type is signed to service the request of the client device.

These examples provide a number of benefits for securely processing requests and dynamically converting requests from one resource record type to another in real time or "on the fly". By way of example only, the disclosed technology can dynamically deploy DNSSEC proxy to DNS64 in real time to maintain a complete trust relationship or chain of trust between the IPv4 and IPv6 environments. Even when the AAAA record is synthesized by a DNS64 device (for example, a traffic management device), the chain of trust is maintained because the synthesized AAAA record is verified by attaching a signature to the DNS64 device in which the synthesis occurs. Therefore, when the requested resource record type is not obtained from the server, the verification of the synthesized or created exemplary resource record type AAAA resource record validates the response of the request, thereby satisfying the response device (eg, the server) ) DNSSEC. It should be noted that although the AAAA and A resource record types are discussed in the above example, the technique is also applicable to other types of resource records, including but not limited to Andrew File System Database (AFSDB) records, canonical name (CNAME) records. Host information (HINFO) records, integrated services digital network (ISDN) records, location (LOC) records, mail exchange (MX) records, mail groups Group (MG) record, mailbox (MB) record, mailbox information (MINFO) record, mailbox rename (MR) record, name server (NS) record, network service access protocol (NSAP) record, public key (KEY Records, Responsible Person (RP) records, Reverse Query Point (PTR) records, Path Direction (RT) records, Start of Authority (SOA) records, Text (TXT) records, Accepted Services (WKS) records, X. 400 address mapping (PX) records, X25 address mapping (X25) records, and so on. The above and other advantages, aspects and features will become more apparent from the following detailed description. Non-limiting and non-exhaustive examples are described in conjunction with the drawings. The following drawings and description are to be regarded as illustrative and not restrict

A number of examples in the disclosed technology enable the traffic management device 110 to process requests for the first resource record type from the client device and service these requests based on responses from different or second resource record types of the server device. For example, a client device running in a single IPv6 environment needs to communicate with a server running in a single IPv4 environment. Traffic management device 110 verifies its own composition or response received from the server to respond to the request. In one example, the traffic management device 110 verifies the AAAA resource record type of the IPv6 client device, and when there is an IPv4 A resource record type response from the server, creates an AAAA resource record type at the traffic management device 110, such that the synthesized AAAA resource The record type corresponds to the A resource record type received by the traffic management device 110.

Referring to Figure 1, an exemplary network system 100 is illustrated that includes A traffic management device 110 that requests between different resource record types. By way of example only, network 112 may be based on Hypertext Transfer Protocol (HTTP) based applications, various opinion request (RFC) file guides, or the Common Internet File System (CIFS) or Network File System (NFS) protocol in this example. To receive requests and provide responses, of course, the principles discussed herein are not limited to these examples, but may include other application protocols and other types of requests (eg, File Transfer Protocol (FTP) based requests). The exemplary network system 100 can include a series of one or more client devices, such as client computers 104(1) through 104(n). Client computers 104(1) through 104(n) are coupled to traffic management device 110 by a plurality of load balancing devices 106 including load balancing devices 106(1) through 106(n), each having a resource based record A unique network address in the type format (such as a unique 128-bit IPv6 address). The traffic management device 110 is disposed between the servers 102(1) through 102(n) and the client devices 104(1) through 104(n) to provide one or more of the slave network 112 to the local area network (LAN) 114. Communication channels, of course, may also establish other communication channels directly between devices of network system 100 without network 112 and/or regional network 114. For clarity and brevity, two server devices 102(1) and 102(n) are shown in FIG. 1, but it should be understood that any number of server devices may be used with the exemplary network system 100. Similarly, three client devices 104(1), 104(2), 104(n) and one traffic management device 110 are shown in FIG. 1, but any number of client devices and traffic management devices can also be used. In the exemplary network system 100. Although network 112 and area network 114 are shown, other numbers and types of networks may be used. Ellipsis and symbol "n" denotes an unlimited number of server devices and client devices, respectively.

Servers 102(1) through 102(n) (also referred to as server devices 102(1) through 102(n)) include one or more server computers or devices capable of running one or more web-based applications It may be accessed by network devices in network 112, such as client computers 104(1) through 104(n), via multiple load balancers 106 and traffic management device 110, and may provide representation of the requested resources. Other data, such as domain name services and zones, special web pages corresponding to URL requests, images of entity objects, and any other objects, respond to requests. Of course, servers 102(1) through 102(n) can perform other tasks. And provide other types of resources. In this example, at least one of the servers 102(1) through 102(n) is an IPv4 single device that satisfies various requests from the client computers 104(1) through 104(n). Alternatively or in general, servers 102(1) through 102(n) may be a set of devices that provide different resource record responses than the resource record types requested and processed by client computers 104(1) through 104(n). . It should be noted that although only two servers 102(1) and 102(n) are shown in the network system 100 of FIG. 1, other numbers and types of servers may be coupled to the traffic management device 110. It is also contemplated that one or more of servers 102(1) through 102(n) may be a cluster server managed by a network traffic management device, such as traffic management device 110.

Client computers 104(1) through 104(n) in this example (also referred to as client devices 104(1) through 104(n), client computing devices 104(1) through 104(n), clients 104(1) through 104(n) and client computing systems 104(1) through 104(n) can run, for example, a web browser Interface applications that provide an interface to request (including IPv6 requests) to different web server-based applications via one or more load balancing devices connected to network 112 and/or through traffic management device 110 ) and send data. A series of web applications can run on servers 102(1) through 102(n) that can transmit data requested by client computers 104(1) through 104(n). Servers 102(1) through 102(n) can provide data or receive data in response to respective applications from clients 102(1) through 104(n) for servers 102(1) through 102(n) Request. For example, data packets may be sent from the requesting client computers 104(1) through 104(n) to the servers 102(1) through 102(n) according to the Transmission Control Protocol (TCP) to transmit data, although of course Other protocols (for example, FTP). It will be appreciated that the servers 102(1) through 102(n) may be hardware or hardware implemented on hardware and supported by hardware, or may represent a system having multiple servers, which may include internal or External network. Servers 102(1) through 102(n) may be domain name servers having Domain Name System (DNS) capabilities that host one or more URL regions.

In general, client devices, such as client computers 104(1) through 104(n), can include any computing device that can actually be connected to another computing device to send and receive information, including web-based information. As shown in FIG. 1, the set of devices may include devices that are typically connected using wired (and/or wireless) communication media, such as personal computers (eg, desktops, notebooks), mobile and/or smart phones, and the like. For example, the client device 104(2) is a mobile phone device or smart phone that has a network function in addition to an audio function. In this example, the client device can run browsers and other types of applications. (For example, web-based applications), these applications can provide an interface to make one or more requests to different server-based applications over the network 112, of course, client computers 104(1) through 104(n). You can also request other types of web applications and resources (such as URLs). Client computers 104(1) through 104(n) may be used to present to servers 102(1) through 102(n) through various types of traffic management devices (eg, routers, load balancers, application delivery controllers, etc.) IPv6 AAAA resource record type request.

As will be discussed below, client computers 104(1) through 104(n) may submit requests through a plurality of load balancing devices 106 that forward the request to local or global traffic management device 110 for analysis. In an example, load balancing devices 106(1) through 106(n) are NAT64 devices, although network address translation (NAT) capabilities may also be used, as will be appreciated by those skilled in the art after reading this document. And/or other types of load balancers of other capabilities. In some examples, traffic management device 110 can be part of multiple load balancing devices 106.

A series of web-based and/or other types of protected and unprotected web applications can be used in servers 102(1)-102 to allow transmission of data requested by client computers 104(1) through 104(n). Run on (n). Client computers 104(1) through 104(n) may be further used to pass multiple load balancing devices 106, local domain name servers (LDNS), or use, for example, Secure Sockets Layer (SSL), Internet Protocol Security (IPSec) Modes such as Transport Layer Security (TLS) are in direct communication with traffic management device 110 and/or servers 102(1) through 102(n).

In this example, network 112 includes a public access network having client computers 104(1) through 104(n), such as the Internet, although network 112 may also include other types of dedicated and other devices. Public network. In this example, communications such as requests from client computers 104(1) through 104(n) and responses from servers 102(1) through 102(n) are based on standard network protocols (eg, HTTP and TCP/). The IP protocol is performed over the network 112, but the principles discussed herein are not limited to this example, and may include other protocols (e.g., FTP). In addition, network 112 can include a local area network (LAN), a wide area network (WAN), a direct connection, other types and numbers of network types, and any combination thereof. Routers, switches, hubs, gateways, bridges, crossbars, and other intermediate networks on a set of interconnected regional or other networks (including networks based on different architectures and protocols) Devices can be used as links within and between regional networks and other networks to enable messages and other data to be sent and sent to network devices. In addition, communication links within and between regional networks and other networks typically include twisted pair (eg, Ethernet), coaxial cable, analog telephone lines, and all dedicated to T1, T2, T3, and T4. Or part of a dedicated digital line, Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), wireless links including satellite lines, fiber optics, and communication links known to those skilled in the relevant arts. In general, network 112 includes any communication medium and method that enables data to be transferred between client computers 104(1) through 104(n), servers 102(1) through 102(n), and traffic management device 110, here The devices provided are merely exemplary.

In this example, each server 102(1) to 102(n), traffic The management device 110, the load balancing device 106, and the client computers 104(1) through 104(n) may include a central processing unit (CPU), a controller or processor, a memory, and the like, connected together by a bus or other link. The interface system, of course, can also use other quantities and types of each of the components as well as other configurations and locations of the components. Since these devices are known to those skilled in the relevant art, they will not be described in detail herein.

Additionally, any one of the network systems 100 can be replaced with two or more computing systems or devices. Thus, depending on the circumstances, the principles and advantages of cloud computing and/or decentralized processing, such as redundancy, replication, virtualization, etc., may also be implemented to increase the robustness and performance of the devices and systems of network system 100. Network system 100 can also be implemented on a computer system that is extended to use any suitable interface mechanism and communication technology, including, for example, any suitable form of telecommunications (eg, voice, modem, etc.), public switched telephone. The entire network environment of the network (PSTN), packet data network (PDN), internet, intranet, and combinations thereof.

By way of example and not limitation, the local area network 114 includes a private area network having a traffic management device 110 coupled to one or more servers 102(1) through 102(n), although the regional network 114 may also include Other types of private and public networks for other devices. The network including the regional network has been described in connection with the network 112, as will be understood by those skilled in the relevant art, and will not be described herein.

As shown in the example environment of network system 100 of FIG. 1, traffic management device 110 can be disposed between network 112 and servers 102(1) through 102(n) connected by area network 114 as shown in FIG. . Alternatively, the flow tube The device 110 is part of a plurality of load balancing devices 106 that are peripheral to the network 112 and is connected to the regional network 114 and/or the servers 102(1) through 102(n). Moreover, network system 100 can be configured in other ways, with other numbers and types of devices. In addition, traffic management device 110 is coupled to network 112 via one or more network communication links and intermediate network devices (e.g., routers, switches, gateways, hubs, crossbar switch fabrics, and other devices). It should be understood that the device and special configuration shown in FIG. 1 are by way of example only and not limitation. In addition to a single traffic management device 110, other traffic management devices may be in series and/or in parallel with the traffic management device 110 depending on the particular application to form a cluster. The single traffic management device 110 shown in FIG. 1 is by way of example only and not limitation. .

In general, traffic management device 110 manages from/to these instances between client computers 104(1) through 104(n) and regional network 114 within one or more servers 102(1) through 102(n). Network communication of network 112, which includes one or more client requests and server responses. For example, these requests may be assigned to one or more servers 102(1) through 102(n) and may be taken from network 112, through one or more intermediate network devices, and/or intermediate networks, as described above, until The form of one or more TCP/IP data packets that ultimately arrive at the traffic management device 110. When initiated by client computers 104(1) through 104(n), these requests are in the first resource record type format (eg, IPv6 4-A resource record type request or query) and are provided by different types of resource record formats. The servers 102(1) through 102(n) responding (eg, IPv4 A resource record type response) provide services.

In an example, traffic management device 110 is configured as a global server load balancing device to allocate end user application requests based on service policies, data center conditions, network conditions, user location, and application performance, such that client computer 104(1) Each request to 104(n) automatically points to the nearest or best performing data center that has one or more of the servers 102(1) through 102(n) set to the host. In this example, traffic management device 110 has global server load balancing capabilities, while in other examples, traffic management device 110 may be receiving responses from a Global Server Load Balancing (GSLB) device connected to regional network 114. Local traffic management device. For example only, the global load balancing device may be provided by the state of Washington in Seattle Internet company F5 BIG-IP ^® Global Traffic Manager ^TM. Additionally, it should be noted that although the traffic management device 110 is shown as being separate from the plurality of load balancing devices 106, in some examples, the traffic management device 110 itself may be one of the plurality of load balancing devices 106.

Furthermore, as detailed in connection with Figures 2 and 3, traffic management device 110 is configured to process requests between different resource record types (e.g., IPv6 for IPv4 A resource records from servers 102(1) through 102(n). 4-A request). In any case, the traffic management device 110 can perform a variety of security or non-secure network communications (eg, load balancing, access control, VPN hosting, networking, in accordance with, for example, systems and steps further described in conjunction with FIGS. 2 and 3. Network traffic management related functions such as traffic acceleration, encryption, decryption, cookies, and key management, and a domain name service that provides authentication to manage network communications.

Referring to Figure 2, an exemplary traffic management device 110 is shown. The flow management device 110 includes a connection to the host system 18 via a bridge 25 and A system bus 26 (also referred to as bus 26) that is coupled to an input-output (I/O) device 30. In this example, a single I/O device 30 is shown to represent any number of I/O devices connected to bus bar 26. In an example, bridge 25 is further coupled to host processor 20 via a host input/output (I/O) port 29. The host processor 20 can be further coupled to the network interface controller 24 via the cache memory 21, the host memory 22 (via the memory port 53), and the CPU bus 202. As described above, the host processor 20 includes a host I/O port 29, a memory port 53, and a main processor (not separately shown). In this example, host system 18 includes a verification module 208 that stores algorithms and instructions/codes to attach a resource record signature (RRSIG) to a synthesized resource record type (eg, a synthetic IPv6 AAAA resource record type). The resource records created at the traffic management device 110 are verified and signed. It should be noted that the verification module 208 can be used as a combination of a hardware logic circuit or a logic circuit and execution code thereon. Additionally, although the illustrated verification module 208 is a single module/module, its functionality can be implemented in a distributed manner between the various components of the traffic management device 110. In addition, the verification module 208 can be a standalone device that can be directly connected to the traffic management device 110 via a standard interface port.

In an example, traffic management device 110 can include host processor 20 having any of the following component configuration features: computer readable media and logic circuitry responsive to and processing instructions retrieved from host memory 22; Manufactured by Intel Corporation of Santa Clara, Calif., Motorola, Inc., Schaumburg, Ill., and Transmeta, Inc., Santa Clara, California Microprocessor; RS/6000 processor, for example, an RS/6000 processor manufactured by International Business Machines Corporation (IBM) in Armonk, NY; processor, for example, by San Francisco, California A processor manufactured by AMD, of Sunnyvale; or any other combination of logic circuits capable of performing the systems and methods of the present application. Other examples of host processor 20 may include any combination of the following: a microprocessor, a microcontroller, a single core central processing unit, a dual core central processing unit, or a multi-core central processing unit.

Examples of traffic management device 110 includes a BIG-IP ^® product family offered by Seattle, Washington F5's application delivery network company or more controller devices, of course, also possible to use other types of traffic management equipment. In an exemplary configuration and/or arrangement, traffic management device 110 may include host processor 20 in communication with cache memory 21 via a secondary bus (also referred to as a rear bus), while another of traffic management device 110 The example includes a host processor 20 connected to the cache memory 21 through a system bus 26. In some embodiments, host processor 20 may also use local system bus 26 to interface with multiple types of I/O devices 30. In some examples, local system bus 26 can be any of the following types of bus bars: Video Electronics Standards Association Partial (VESA VL) bus, Industry Standard Architecture (ISA) bus, Extended Industry Standard Architecture (EISA) bus, Micro Channel Architecture (MCA) Bus, Peripheral Component Interconnect (PCI) Bus, PCI-X Bus, PCI-Express Bus, or NuBus. Other example configurations of traffic management device 110 include I/O device 30 (which is a video display, not separately shown) connected to host processor 20 via an advanced graphics port (AGP). Additionally, other forms of traffic management device 110 include host processor 20 coupled to I/O device 30 via one or more of the following: HyperTransport, Rapid I/O, or InfiniBand (unlimited) bandwidth). Other examples of traffic management device 110 include communication connections in which host processor 20 is coupled to one I/O device 30 via a local interconnect bus, and to a second I/O device (not shown separately) through a direct connection. As described above, in some examples, the traffic management device 110 includes one of the host memory 22 and the cache memory 21. In some examples, the cache 21 can be any of the following types of memory: static random access memory (SRAM), burst or synchronous burst random access memory (BSRAM), or enhanced dynamic random access. Memory (EDRAM). Other examples of the traffic management device 110 include the cache memory 21 and the host memory 22, which may be any of the following types of memory: static random access memory, burst static random access memory, or synchronous burst static random. Access memory, dynamic random access memory, fast page mode dynamic random access memory, enhanced dynamic random access memory, extended data output random access memory, extended data output dynamic random access memory, plex Extended data output dynamic random access memory, enhanced dynamic random access memory, synchronous dynamic random access memory, JEDECSRAM (Solid State Technology Association SRAM), PCIOO SDRAM, double data rate synchronous dynamic random access memory, Enhanced Synchronous Dynamic Random Access Memory, Synchronous Linked Dynamic Random Access Memory, Direct Rambus Dynamic Random Access Memory, Ferroelectric Random Memory (FRAM), or any other type of system capable of performing the system and method of the present application Memory device.

In some embodiments, host memory 22 and/or cache memory 21 may include one or more memory devices capable of storing data and allowing host processor 20 to directly access any storage location. The data may be stored in a local database internal or external to the traffic management device 110 connected through one or more input and output ports of the network interface controller 24. Other examples of traffic management device 110 include host processor 20 that can access host memory 22 by one of: system bus 26, memory port 53, or any other device that enables host processor 20 to access host memory 22. Connection, bus, or port.

An example of the traffic management device 110 supports any of the following installation devices: a ZIP floppy disk, a CD-ROM drive, a CD-R/RW drive, a DVD-ROM drive, a USB device, bootable media, for distribution such as GNU/Linux ( For example, KNOPPIX ^® can be a bootable CD, a hard drive, or any other device suitable for installing an application or software. In some examples, an application can include any part of a client agent or a client agent. The traffic management device 110 may also include a storage device (not separately shown), which may be one or more hard disk drives or a separate redundant disk array (RAID), where the storage device is used to store operating systems, software, applications At least part of a program or client agent. Another example of the traffic management device 110 includes a mounting device that serves as a storage device.

In addition, the traffic management device 110 can include a network interface controller 24 for accessing the input-output ports within the network interface controller 24 in a variety of ways including, but not limited to, standard telephone lines, regional networks, or wide area networks ( For example, 802.11, T1, T3, 56 kb, X.25, SNA, DECNET), Broadband connection (eg, ISDN, frame relay, asynchronous transfer mode, Gigabit Ethernet, Ethernet-over-SONET), wireless connection, fiber connection or any combination of all and above, and regional network, wide area network Road or internet connection. Multiple communication protocols are also available (eg, TCP/IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), Fiber Distributed Data Interface (FDDI), Connections are established for RS232, RS485, IEEE 802.11, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, CDMA, GSM, WiMax, and direct asynchronous connections. One form of traffic management device 110 includes a network interface controller 24 for use by any type and/or form of gateway or tunneling protocol (eg, Secure Sockets Layer (SSL) or Transport Layer Security (TLS), or The Citrix Gateway Protocol of Citrix Systems, Inc., located in Fort Lauderdale, Fla., communicates with other computing devices. The network interface controller 24 may be in the form of any of the following: a built-in network adapter, a network interface card, a PCMCIA network card, an external card bus network adapter, a wireless network adapter, a USB network adapter, a modem, or Any other device suitable for connecting the traffic management device 110 to a network capable of communicating and performing the methods and systems of the present application.

In various examples, the traffic management device 110 can include any of the following I/O devices: a keyboard, a pointing device, a mouse, a gesture-based remote control device, a biometric device, an audio device, a trackpad, an optical pen, a trackball , a microphone, a video display, a speaker, or any other input/output device capable of performing the methods and systems of the present application. In some examples, host I/O port 29 can be connected to multiple I/O devices 30 to control one or more I/Os. Device 30. Some examples of I/O device 30 may be used to store or provide installation media, and other examples may provide a universal serial bus (USB) interface to receive USB storage devices, such as USB for devices manufactured by Twintech Industry. Flash memory line. Other examples of the I/O device 30 may be a bridge 25 located between the system bus 26 and an external communication bus, such as a USB bus, an Apple Desktop bus, and an RS- 232 serial connection, small computer system interface (SCSI) bus, FireWire bus, FireWire 800 bus, Ethernet bus, AppleTalk bus, Gigabit Ethernet bus, asynchronous transfer mode Bus, HIPPI (High Performance Parallel Interface) Bus, Super HIPPI Bus, SerialPlus Bus, SCI/LAMP Bus, Fibre Channel Bus, or Serial Attached Small Computer System Interface Bus. According to some examples, the traffic management device 110 includes an authentication module 208 integrated as part of the host system 18 to implement various signatures of resource record types (eg, AAAA resource records) created by the traffic management device 110 by, for example, public key cryptography. Exemplary features.

Accordingly, components of traffic management device 110 include one or more processors (eg, host processor 20) executing one or more traffic management applications, and memory coupled to one or more processors via busbars (eg, , cache memory 21 and/or host memory 22), coupled to one or more processors and host memory 22, and for receiving data packets from the network involved in executing the traffic management application and processing from the client The requested network interface controller 24 of the first resource record type of the computers 104(1) through 104(n), wherein the servers 102(1) through 102(n) pass the second or Responses to different resource record types serve these requests. In this example, at least one of the one or more processors is configured to execute program instructions stored in a memory (eg, cache 21 and/or host memory 22), including a logical network interface The controller 24 can be further configured to receive, at the request of the client device, a first resource record type from the one or more server devices at the traffic management device. The implementation process includes verifying the first resource record type at the traffic management device, and creating a second resource record type corresponding to the first resource record type after the verifying. The traffic management device signs the second resource record type (eg, via the verification module 208) to service the request from the client device.

In the following, in conjunction with FIG. 1 and FIG. 2 together with the flowchart 300 shown in FIG. 3, a request between different resource record types is processed using the traffic management device 110 such as shown in FIGS. 1 and 2 (eg, providing a DNSSEC proxy to the DNS 64). The steps of the example process are explained. Flowchart 300 represents exemplary machine readable instructions for dynamically real-time processing of requests between different resource record types, such as at traffic management device 110. In this example, the machine readable instructions include, by, for example, (a) a processor (eg, host processor 20), (b) a controller, and/or (c) one or more suitable processes within host system 18. The algorithm executed by the device. The algorithm can be executed in software stored on a tangible computer readable medium such as a flash memory, CD-ROM, floppy disk, hard disk drive, digital video (multi-function) compact disc (DVD) or other storage device. However, those skilled in the art will readily appreciate that the entire algorithm and/or a portion of the algorithms may be executed by the device rather than by the processor, and/or executed in firmware or dedicated hardware in a known manner (eg, Can be Application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable logic devices (FPLDs), field programmable gate arrays (FPGAs), discrete logic, etc.). For example, at least a portion of the components of traffic management device 110 can be executed by software, hardware, and/or firmware. Likewise, some or all of the machine readable instructions represented by the steps of flowchart 300 of FIG. 3 may be manually executed at traffic management device 110 by utilizing a command line interface (CLI) prompt window, such as operated by a system administrator. Additionally, although the exemplary algorithms have been described in connection with flowchart 300, those skilled in the art will readily appreciate that many other methods can also be used to execute the example machine readable instructions. For example, the order of execution of the blocks in flowchart 300 can vary, and/or some blocks can be varied, removed, or combined.

Referring to Figure 3, in step 302 of flowchart 300, traffic management device 110 receives a request from one of client computers 104(1) through 104(n). In general, the requested resource record type of client computers 104(1) through 104(n) is different from the resource record type provided by one or more servers 102(1) through 102(n) in response to the request. In an example, the requests from client computers 104(1) through 104(n) are resources provided for IPv4 devices (eg, one or more servers 102(1) through 102(n)) (also referred to as " A "record, which is a 32-bit IPv4 address" 128-bit IPv6 request or query (also known as a 4A or "AAAA" request or query). Since the various standard formats of IPv6 AAAA and IPv4 A resource record requests/queries are known to those skilled in the art, they are not described in detail herein. In addition, other types of resource records can be used, and the IPv4 and IPv6 resource records in question are merely examples and are not limiting.

In step 304, the traffic management device 110 forwards the received IPv6 request, such as the AAAA resource record format, to one of the servers 102(1) through 102(n) after removing the bit and/or the header, thereby The request translates to an IPv4 request that can be identified by the servers 102(1) through 102(n) for the A resource record. The removed bits and/or headers may be at least partially part of a 96-bit preamble that forms an IPv6 address. Since the servers 102(1) through 102(n) cannot recognize the IPv6 address format and the server is in an IPv4 network environment, removing the preamble helps to bring the client computers 104(1) through 104(n). The request is directed to the appropriate one or more servers 102(1) through 102(n).

In step 306, traffic management device 110 receives a response from one of servers 102(1) through 102(n) and a resource record signature (RRSIG) associated with the response. The received response is verified for signature, such as to determine its trusted resources from servers 102(1) through 102(n). Verification can be performed using, for example, a public key cryptography mechanism implemented by the verification module 208 in the traffic management device 110, although other techniques can be used for verification.

In step 308, the traffic management device 110 determines whether the resource record type of the received response is the same as the resource record type requested by the client device. When the resource record type of the received response is the same as the requested resource record type, step 314 is performed, in which the traffic management device 110 forwards the received response to the client computers 104(1) to 104 after verification ( n) The computer that made the request. For example, if the received response is an IPv6 AAAA type response, the traffic management device 110 directly forwards the response to The requesting computer is in the client computers 104(1) through 104(n).

However, in step 310, when the response includes an address record of one or more different resource record type formats (eg, IPv4 format or A resource record), the traffic management device 110 creates a correspondence with the received resource record type. The requested resource record type format (for example, the IPv6 AAAA resource record type with the IPv4 A resource record network address) matches or corresponds to the new resource record type.

Then, step 312 is performed, in which the traffic management device 110 signs a new response (eg, a synthesized AAAA resource record) containing the new resource record type described above according to DNSSEC. In this case, when the traffic management device 110 attaches a new signature (eg, a new RRSIG) to the newly created IPv6 AAAA resource record type response in real time (or "instant"), the old response corresponding to the IPv4 A resource record type response The signature is discarded by the traffic management device because it is no longer valid. By way of example only, as described above, the signature of the synthesized resource record may be implemented by the verification module 208 using a key stored within the traffic management device 110 (e.g., within the host memory 22). Of course, other techniques may also be used for signing. . Thus, the signed AAA resource record, although synthesized at the traffic management device 110, maintains the chain of trust required by DNSSEC before reaching the requesting device in the client device and is not rejected by other downstream validators.

In step 314, the signed composite AAAA resource record is forwarded in response to the requesting computer in client computers 104(1) through 104(n). It should be noted that although in this example, the IPv6 AAAA resource record is referred to as the resource record class requested by the client computers 104(1) through 104(n). Type, but the examples disclosed herein are equally valid for other resource record types, as long as the responses provided by servers 102(1) through 102(n) are different from the type of such resource record, the resource record needs to be verified or needed The composition is converted to the same type of resource record as requested by the client computers 104(1) through 104(n) by synthesis, and then verified, for example, by attaching a signature to the traffic management device 110.

It will be apparent to those skilled in the art <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; Various changes, modifications, and alterations can be made by those skilled in the art, although not described in detail herein. The order in which the methods and steps for providing secure application delivery can also be changed. Additionally, in addition to the network 112 and the regional network 114, there may be multiple networks connected to the traffic management device 110 that receives or transmits network data packets. These variations, improvements, and modifications are suggested by the present disclosure and are within the spirit and scope of the examples. In addition, the order or sequence of processing components, or the use of numbers, letters or other identifiers, is not intended to limit the claimed steps and methods to any order unless specified in the scope of the claims.

18‧‧‧Host system

20‧‧‧Host processor

21‧‧‧Recalling

22‧‧‧Host memory

24‧‧‧Network Interface Controller

25‧‧‧ Bridge

26‧‧‧System Bus

29‧‧‧Host Input/Output (I/O) Port

30‧‧‧Input-Output (I/O) Equipment

53‧‧‧ memory port

100‧‧‧Network System

102(1)-102(n)‧‧‧Server equipment

104(1)-104(n)‧‧‧Client Computer/Equipment

106(1)-106(n)‧‧‧ Load balancing equipment

110‧‧‧Traffic management equipment

114‧‧‧Regional Network (LAN)

202‧‧‧CPU bus

208‧‧‧ verification module

1 is a schematic diagram of an exemplary network system environment for processing requests between different resource record types using a traffic management device; FIG. 2 is a partial schematic and functional block diagram of a traffic management device in the exemplary network environment of FIG. And Figure 3 is an exemplary step of processing requests between different resource record types Flow chart of the method and method.

100‧‧‧Network System

102(1)-102(n)‧‧‧Server equipment

104(1)-104(n)‧‧‧Client Computer/Equipment

106(1)-106(n)‧‧‧ Load balancing equipment

110‧‧‧Traffic management equipment

114‧‧‧Regional Network (LAN)

Claims (12)

A method for processing a request between different resource record types, the method comprising the steps of: obtaining, by a traffic management device, a first resource record from a server device in response to a request from a client device An Internet Protocol version 6 (IPv6) resource record request, wherein the first resource record includes a resource record signature provided by the server device; and determining, by the traffic management device, when the server device can be based on the A type of resource record directly providing a signed IPv6 resource record in response to the IPv6 resource record request, and when the determining step indicates that the server device is unable to directly provide the signed IPv6 resource record in response to the IPv6 resource record request Responding to the first resource record by the traffic management device to confirm whether the server device is trusted, wherein the first resource record is a 32-bit Internet Protocol version 4 (IPv4) A resource record; Creating, by the traffic management device, a second resource record corresponding to the first resource record, where the second resource record is a 128 a AAAA resource record of the meta IPv6; generating a new resource record signature by the traffic management device, and appending the new resource record signature to the second resource record to provide a service for the IPv6 resource record request from the client device; And The second resource record to which the new resource record signature is attached is forwarded to the client device by the traffic management device in response to the IPv6 resource record request. The method of claim 1, wherein the obtaining step comprises receiving a signature associated with the first resource record, and the signature is used in the verifying step. The method of claim 1, wherein the verifying step is performed using public key cryptography. The method of claim 1, wherein the signature used to verify the first resource record is discarded after the verifying step. A computer readable medium having stored thereon instructions for processing requests between different resource record types, the machine executable code included by the instructions, when executed by at least one processor, causing the at least one processor to include The step of: obtaining a first resource record from a server device in response to an Internet Protocol Version 6 (IPv6) resource record request from a client device, wherein the first resource record includes a resource record signature provided by the server device; and determining when the server device can directly provide a signed IPv6 resource record based on a type of the first resource record in response to the IPv6 resource record request, and when the determining step Declaring that the server device cannot directly provide the signed IPv6 resource record in response to the IPv6 resource record request: verifying the first resource record to confirm the server device Is it trustworthy, wherein the first resource record is a 32-bit Internet Protocol version 4 (IPv4) A resource record; and a second resource record corresponding to the first resource record is created, wherein the second resource is Recording as a 128-bit IPv6 AAAA resource record; generating a new resource record signature, and appending the new resource record signature to the second resource record to provide service for the IPv6 resource record request from the client device; The second resource record appended with the new resource record signature is forwarded to the client device in response to the IPv6 resource record request. The computer readable medium of claim 5, wherein the machine executable code, when executed by the at least one processor, further causes the at least one processor to perform one or more other steps, including receiving the first The resource record is associated with a signature and the signature is used in the verification step. The computer readable medium of claim 5, wherein the verifying step is performed using public key cryptography. The computer readable medium of claim 5, wherein a signature used to verify the first resource record is discarded after the verifying step. A traffic management device comprising: a memory including machine executable code stored therein; and a processor coupled to the memory and configured to Executing the machine executable code to: obtain a first resource record from a server device in response to an Internet Protocol Version 6 (IPv6) resource record request from a client device, wherein the first resource Recording includes a resource record signature provided by the server device; and determining when the server device can directly provide a signed IPv6 resource record based on a type of the first resource record in response to the IPv6 resource record request, and When the determining step indicates that the server device cannot directly provide the signed IPv6 resource record in response to the IPv6 resource record request: verifying the first resource record to confirm whether the server device is trusted, wherein the first resource record is a 32-bit Internet Protocol version 4 (IPv4) A resource record; creating a second resource record corresponding to the first resource record, wherein the second resource record is a 128-bit IPv6 AAAA resource record Generating a new resource record signature and appending the new resource record signature to the second resource record as the IP from the client device 6 a resource record request providing a service; and forwarding the second resource record appended with the new resource record signature to the client device in response to the IPv6 resource record request. The traffic management device of claim 9, wherein the processor is further configured to execute the machine executable code to receive A signature associated with the first resource record is received and the signature is used in the verification step. A traffic management device as claimed in claim 9, wherein the verifying step operates using public key cryptography. The traffic management device of claim 9, wherein a signature used to verify the first resource record is discarded after the verifying step.