USRE47019E1 - Methods for DNSSEC proxying and deployment amelioration and systems thereof - Google Patents

Abstract

A method, computer readable medium, and device for providing authenticated domain name service includes forwarding at a traffic management device a request for a domain name from a client device to one or more servers coupled to the traffic management device. The traffic management device receives a first response comprising at least a portion of the domain name from the one or more servers. The traffic management device attaches a first signature to the first response when the first response is determined by the traffic management device to be an unauthenticated response, and provides the first response with the first signature to the client device.

Description

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 12/836,053, filed Jul. 14, 2010, which is hereby incorporated by reference in its entirety.

TECHNOLOGICAL FIELD

This technology generally relates to securing network applications, and more particularly, to systems and methods for Domain Name System Security Extensions (DNSSEC) proxying and deployment amelioration.

BACKGROUND

Global Internet Domain Name System, also referred to as the Domain Name System (DNS), defines a tree of names starting with root, “.”, immediately below which are top level domain names such as “.com” and “.us”. Below top level domain names there are normally additional levels of names. Domain Name System (DNS) was invented as a technology for enabling humans to identify computers, services, and resources connected to a network (e.g., Internet) by corresponding names rather than network addresses (e.g., Internet Protocol (IP) addresses) in a number format. DNS translates human readable names into unique binary information of network devices to enable users to find the devices they need. Unfortunately, conventional DNS is not secure and is highly prone to malicious interception. The insecure nature of DNS has been known to cause substantial loss of privacy, data, and identity theft, among many other problems. For example, one of the ways in which DNS can be exploited is called DNS cache poisoning. When a client device inputs a Uniform Resource Locator (URL) into a client browser, a DNS resolver checks the Internet for the proper name/number translation and location. Typically, DNS will accept the first response or answer obtained without question and direct the client device to the site referred to in the response. The server receiving the DNS response will also cache that information for a period of time until it expires, so upon the next request for that name/number, the site is immediately delivered to the requesting client device. Since users at client devices assume they are getting the correct information, when a malicious system responds to the DNS query first with modified, false information, security of the client device is breached. Not only does that single computer get sent to the wrong place, but if the malicious server is answering for a service provider, then thousands of users can get sent to a rogue system. This misdirection of a URL request can last for hours to days, depending on how long the server stores the information, and all the other DNS servers that propagate the information can also be affected. The imminent dangers posed by a rogue site include delivering malware, committing fraud, and stealing personal or sensitive information.

To overcome some of the drawbacks of conventional DNS systems, Domain Name System Security Extensions (DNSSEC) were introduced as an attempt to add security to DNS while maintaining the backward compatibility needed to scale with the Internet as a whole. DNSSEC adds a digital signature to ensure the authenticity of certain types of DNS transactions and, therefore, the integrity of the information. DNSSEC is a series of DNS protocol extensions, described in Request for Comments (RFCs) 4033, 4034, and 4035, hereby incorporated by reference in their entireties, that ensures the integrity of data returned by domain name lookups by incorporating a chain of trust into the DNS hierarchy. The chain is built using public key infrastructure (PKI), with each link in the chain consisting of a public/private key pair. Deploying DNSSEC involves signing zones with public/private key encryption and returning DNS responses with signatures. A client's trust in the signatures is based on the chain of trust established across administrative boundaries, from parent to child zone, using a Domain Name System Key (DNSKEY) and delegation signer (DS) resource records, which were not defined in DNS specifications. In DNSSEC, since an unbroken chain of trust is established from the root at the top through the top-level domain (TLD) and down to individual registrants, the client device's answer always receives an authenticated response. All zones are authenticated by “signing,” in that a publisher of a zone signs that zone prior to publication, and the parent of that zone publishes the keys of that zone. With millions of zones, it is likely that the keys expire before the DNS records are updated. As a result, zone operators require techniques to automatically allocate keys to DNS records before these keys expire. Unfortunately, conventional systems are unable to handle management of keys for DNSSEC. Further, conventional DNS systems are unable to translate non-DNSSEC responses to DNSSEC responses.

Furthermore, conventional network systems are unable to handle DNSSEC signatures when zone names are dynamically updated. For example, consider a zone name that was previously signed statically. Subsequently, when the zone name is updated or changed, the DNSSEC signature for the earlier version of the zone is rendered invalid, and since the new zone is unsigned, there is no method for conventional systems to automatically enable DNSSEC for the dynamic update to the zone in real time.

In another related scenario, for global server load balancing (GSLB)-type DNS responses in which the Internet Protocol (IP) answer in a response to a request from a client device can change depending on the requesting client device, conventional systems are unable to provide DNSSEC for such dynamically changing domain names while at the same time performing global load balancing. Since GSLB can provide different answers to different clients for the same domain name, GSLB and DNSSEC are fundamentally at odds in the original design specifications. DNSSEC, as originally conceived, was focused solely on traditional static DNS and never considered the requirements of GSLB, or intelligent DNS. Unfortunately it is difficult for conventional systems to provide DNSSEC for dynamic DNS, and to provide DNSSEC for GSLB-type DNS responses in a load balancing scenario where there might be two different answers for the same request and the GSLB has to forward a signed response to the client device.

SUMMARY

One example of the technology is a method for providing authenticated domain name service. The method includes forwarding at a traffic management device a request for a domain name from a client device to one or more servers coupled to the traffic management device. The traffic management device receives a first response comprising at least a portion of the domain name from the one or more servers. The traffic management device attaches a first signature to the first response when the first response is determined by the traffic management device to be an unauthenticated response, and provides the first response with the first signature to the client device.

Another example includes a computer readable medium having stored thereon instructions for providing authenticated domain name service, which when executed by at least one processor, causes the processor to perform a number of steps. The steps include forwarding at a traffic management device a request for a domain name from a client device to one or more servers coupled to the traffic management device. The traffic management device receives a first response comprising at least a portion of the domain name from the one or more servers. The traffic management device attaches a first signature to the first response when the first response is determined by the traffic management device to be an unauthenticated response, and provides the first response with the first signature to the client device.

Another example is that of a traffic management device, which includes one or more processors executing one or more traffic management applications, a memory coupled to the one or more processors by a bus, a network interface controller coupled to the one or more processors and the memory and configured to receive data packets from a network that relate to the executing traffic management applications, and provide authenticated domain name service. In this example, at least one of the one or more processors is configured to execute programmed instructions stored in the memory and the network interface controller including logic capable of being further configured to implement forwarding at a traffic management device a request for a domain name from a client device to one or more servers coupled to the traffic management device. The traffic management device receives a first response comprising at least a portion of the domain name from the one or more servers. The traffic management device attaches a first signature to the first response when the first response is determined by the traffic management device to be an unauthenticated response, and provides the first response with the first signature to the client device.

The examples offer numerous advantages. By way of example only, technology disclosed enables signing DNS responses in real time and deploying DNSSEC quickly and easily in an existing network environment, thereby ensuring that answers to domain name requests received by the client devices when asking for name resolution come from a trusted name server, and not a hacker. The examples support Federal Information Processing Standard (FIPS) storage of the private keys, and are able to securely synchronize the keys between multiple FIPS devices. Additionally, examples of the disclosed technology use a cryptographic module or storage chip on a motherboard of a traffic management device to secure a unique hardware key as part of the multi-layer encryption process. When a response from a non-DNSSEC server is returned, the response is signed in real time to ensure continuous signing. The potential attacker cannot forge the signed response without the corresponding private key.

Further, the examples enable compliance with federal DNSSEC mandates and help protect valuable domain names and web properties from rogue servers sending invalid responses. Furthermore, the examples of the technology enable global server load balancing (GSLB)-type DNSSEC responses in which the IP answer can change depending on the requesting client by signing answers at the time the traffic management device (with load balancing functionality) decides what the answer to a request should be. These and other advantages, aspects, and features will become more apparent from the following detailed description when viewed in conjunction with the accompanying drawings. Non-limiting and non-exhaustive examples are described with reference to the following drawings. Accordingly, the drawings and descriptions below are to be regarded as illustrative in nature, and not as restrictive or limiting.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary network system environment using traffic management device for DNSSEC proxying and deployment amelioration;

FIG. 2 is a partly schematic and partly functional block diagram of traffic management device in the exemplary network environment ofFIG. 1; and

FIG. 3 is a flow chart of an exemplary process and method for DNSSEC proxying and deployment amelioration when a DNSSEC request is to be serviced using non-DNSSEC server devices.

DETAILED DESCRIPTION

Various examples of the technology disclosed enable atraffic management device110 to handle mismatches between non-DNSSEC and DNSSEC environments. For example, client devices operating in a DNSSEC environment need to communicate with servers operating in a non-DNSSEC environment.Traffic management device110 provides secure conversion from one environment to another and prevents malicious “man-in-the-middle” attacks.

Referring toFIG. 1, anexemplary network system100 includingtraffic management device110 that is configured to provide authenticated domain name service, for example, to requesting client computers104(1) to104(n) is illustrated. By way of example only, anetwork112 can provide responses and requests according to the Hyper-Text Transfer Protocol (HTTP) based application, request for comments (RFC) document guidelines or the Common Internet File System (CIFS) or network file system (NFS) protocol in this example, although the principles discussed herein are not limited to these examples and can include other application protocols and other types of requests (e.g., File Transfer Protocol (FTP) based requests). Theexemplary network system100 can include a series of one or more client devices such as client computers104(1) to104(n). Client computers104(1)-104(n) are coupled totraffic management device110 via a local domain name server (LDNS)106. In some examples,LDNS106 is optional and client computers104(1)-104(n) are coupled totraffic management device110 directly or via anetwork112.Traffic management device110 is interposed in between servers102(1) to102(n) and the client devices104(1) to104(n) for providing one or more communication channels throughnetwork112 and a Local Area Network (LAN)114, although other communication channels may be directly established between various devices innetwork system100 withoutnetwork112 and/orLAN114. For clarity and brevity, inFIG. 1 two server devices102(1) and102(n) are shown, but it should be understood that any number of server devices can use theexemplary network system100. Likewise, two client devices104(1)-104(n), oneLDNS106, and onetraffic management device110 are shown inFIG. 1, but any number of client devices, LDNSs, and traffic management devices can also use theexemplary network system100 as well. Althoughnetwork112 andLAN114 are shown, other numbers and types of networks could be used. The ellipses and the designation “n” denote an unlimited number of server devices and client devices, respectively.

Servers102(1)-102(n) comprise one or more server computing machines or devices capable of operating one or more Web-based applications that may be accessed by network devices in thenetwork112, such as client computers104(1)-104(n) (also referred to as client devices104(1)-104(n)), viatraffic management device110, and may provide other data representing requested resources, such as domain name services and zones, particular Web page(s) corresponding to URL request(s), image(s) of physical objects, and any other objects, responsive to the requests, although the servers102(1)-102(n) may perform other tasks and provide other types of resources. It should be noted that while only two servers102(1) and102(n) are shown in thenetwork system100 depicted inFIG. 1, other numbers and types of servers may be coupled to thetraffic management device110. It is also contemplated that one or more of the servers102(1)-102(n) may be a cluster of servers managed by a network traffic management device such astraffic management device110. In one example, servers102(1)-102(n) are DNS servers in a DNS environment. In another example, servers102(1)-102(n) are DNSSEC servers in a DNSSEC environment. In yet another example, servers102(1)-102(n) are a mix of DNS and DNSSEC servers, as can be understood by those of ordinary skill in the art upon reading this disclosure. In some examples, servers102(1)-102(n) are Berkeley Internet Name Domain (BIND) servers.

The client computers104(1)-104(n) in this example (also interchangeably referred to as client devices104(1)-104(n), client computing devices104(1)-104(n), clients104(1)-104(n), and client computing systems104(1)-104(n)) can run interface applications such as Web browsers that can provide an interface to make requests for and send data, including DNS and DNSSEC requests, to different Web server-based applications viaLDNS106 connected to thenetwork112 and/or viatraffic management device110. A series of network applications can run on the servers102(1)-102(n) that allow the transmission of data that is requested by the client computers104(1)-104(n). Servers102(1)-102(n) can provide data or receive data in response to requests directed toward the respective applications on the servers102(1)-102(n) from the client computers104(1)-104(n). For example, as per the Transmission Control Protocol (TCP), packets can be sent to the servers102(1)-102(n) from the requesting client computers104(1)-104(n) to send data, although other protocols (e.g., FTP) may be used. It is to be understood that the servers102(1)-102(n) can be hardware or software executing on and supported by hardware, or can represent a system with multiple servers, which can include internal or external networks. Servers102(1)-102(n) can be domain name servers with DNS capabilities hosting one or more website zones. Alternatively, servers102(1)-102(n) can be DNSSEC servers in a DNSSEC environment hosting one or more website zones. For example, the servers102(1)-102(n) can be any BIND version of Microsoft Domain Controllers provided by Microsoft Corporation of Redmond, Wash., although other types of servers can be used. Further, additional servers can be coupled to thenetwork112 and/orLAN114 and many different types of applications can be available on servers coupled to thenetwork112 and/orLAN114.

Generally, the client devices such as the client computers104(1)-104(n) can include virtually any computing device capable of connecting to another computing device to send and receive information, including Web-based information. The set of such devices can include devices that typically connect using a wired (and/or wireless) communications medium, such as personal computers (e.g., desktops, laptops), mobile and/or smart phones and the like. In this example, the client devices can run browsers and other types of applications (e.g., web-based applications) that can provide an interface to make one or more requests to different server-based applications vianetwork112, although requests for other types of network applications and resources, for example URLs, may be made by client computers104(1)-104(n). Client computers104(1)-104(n) can be configured to make DNSSEC and non-DNSSEC requests to servers102(1)-102(n), or other types of traffic management devices (e.g., routers, load balancers, application delivery controllers, and the like).

Client computers104(1)-104(n) can submit requests to LDNS106.LDNS106 can respond to the requests when resources are locally stored onLDNS106, for example, in a local cache memory. For example, a client computer may request for a URL www.example.com. IfLDNS106 has a valid copy of www.example.com, it can directly provide this URL to the requesting client computer. In other scenarios,LDNS106 forwards the requests totraffic management device110 vianetwork112.LDNS106 can be configured to expedite requests for network resources (e.g., URLs) based upon a history of requests from one or more client computers104(1)-104(n). In one example,LDNS106 can provide an initial response to a requesting one of client computers104(1)-104(n) while additional resources are being fetched from severs102(1)-102(n) resulting in a faster initial response for a request from client computers104(1)-104(n). By way of example only,LDNS106 can be a proxy server, or a server similar to servers102(1)-102(n) but located between client computers104(1)-104(n) andtraffic management device110.

A series of Web-based and/or other types of protected and unprotected network applications can run on servers102(1)-102(n) that allow the transmission of data that is requested by the client computers104(1)-104(n). The client computers104(1)-104(n) can be further configured to engage in a secure communication directly with thetraffic management device110 and/or the servers102(1)-102(n), viaLDNS106, or otherwise, using mechanisms such as Secure Sockets Layer (SSL), Internet Protocol Security (IPSec), Transport Layer Security (TLS), and the like.

In this example,network112 comprises a publicly accessible network, such as the Internet, which includes client computers104(1)-104(n), althoughnetwork112 may comprise other types of private and public networks that include other devices. Communications, such as requests from client computers104(1)-104(n) and responses from servers102(1)-102(n), take place overnetwork112 according to standard network protocols, such as the HTTP and TCP/IP protocols in this example, but the principles discussed herein are not limited to this example and can include other protocols (e.g., FTP). Further,network112 can include local area networks (LANs), wide area networks (WANs), direct connections, other types and numbers of network types, and any combination thereof. On an interconnected set of LANs or other networks, including those based on different architectures and protocols, routers, switches, hubs, gateways, bridges, crossbars, and other intermediate network devices may act as links within and between LANs and other networks to enable messages and other data to be sent from and to network devices. Also, communication links within and between LANs and other networks typically include twisted wire pair (e.g., Ethernet), coaxial cable, analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, optical fibers, and other communications links known to those of ordinary skill in the relevant arts. Generally,network112 includes any communication medium and method by which data may travel between client devices104(1)-104(n), servers102(1)-102(n), andtraffic management device110, and these devices are provided by way of example only.

In this example, each of the servers102(1)-102(n),traffic management device110,LDNS106, and client computers104(1)-104(n) can include a central processing unit (CPU), controller or processor, a memory, and an interface system which are coupled together by a bus or other link, although other numbers and types of each of the components and other configurations and locations for the components can be used. Since these devices are well known to those of ordinary skill in the relevant art(s), they will not be described in further detail herein.

In addition, two or more computing systems or devices can be substituted for any one of the systems in thenetwork system100. Accordingly, principles and advantages of cloud computing and/or distributed processing, such as redundancy, replication, virtualization, and the like, can also be implemented, as appropriate, to increase the robustness and performance of the devices and systems of thenetwork system100. Thenetwork system100 can also be implemented on a computer system or systems that extend across any network environment using any suitable interface mechanisms and communications technologies including, for example telecommunications in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, combination(s) thereof, and the like.

By way of example only and not by way of limitation,LAN114 comprises a private local area network that includes thetraffic management device110 coupled to the one or more servers102(1)-102(n), although theLAN114 may comprise other types of private and public networks with other devices. Networks, including local area networks, besides being understood by those of ordinary skill in the relevant art(s), have already been described above in connection withnetwork112, and thus will not be described further here.

As shown in the example environment ofnetwork system100 depicted inFIG. 1, thetraffic management device110 can be interposed between thenetwork112 and the servers102(1)-102(n) coupled viaLAN114 as shown inFIG. 1. Again, thenetwork system100 could be arranged in other manners with other numbers and types of devices. Also, thetraffic management device110 is coupled tonetwork112 by one or more network communication links, and intermediate network devices, such as routers, switches, gateways, hubs, crossbars, and other devices. It should be understood that the devices and the particular configuration shown inFIG. 1 are provided for exemplary purposes only and thus are not limiting. Although a singletraffic management device110, additional traffic management devices may be coupled in series and/or parallel to thetraffic management device110, thereby forming a cluster, depending upon specific applications, and the singletraffic management device110 shown inFIG. 1 is by way of example only, and not by way of limitation.

Generally, thetraffic management device110 manages network communications, which may include one or more client requests and server responses, to/from thenetwork112 between the client computers104(1)-104(n) and one or more of the servers102(1)-102(n) inLAN114 in these examples. These requests may be destined for one or more servers102(1)-102(n), and, as alluded to earlier, may take the form of one or more TCP/IP data packets originating from thenetwork112, passing through one or more intermediate network devices and/or intermediate networks, until ultimately reaching thetraffic management device110, for example.

In one example,traffic management device110 is configured as a global server load balancing device that distributes end-user application requests based on business policies, data center conditions, network conditions, user location, and application performance, such that each request from client computers104(1)-104(n) is automatically directed to the closest or best-performing data center hosting one or more servers102(1)-102(n). In this example,traffic management device110 provides DNSSEC signed responses even when zone names have been dynamically updated. Although in this example,traffic management device110 has global server load balancing capabilities, in alternative examplestraffic management device110 may receive responses from a global server load balancing (GSLB) device coupled toLAN114. By way of example only, such a global load balancing device can be a BIG-IP® Global Traffic Manager™ provided by F5 Networks, Inc., of Seattle, Wash.

In addition, as discussed in more detail with reference toFIGS. 2-3,traffic management device110 is configured to provide authenticated domain name service. In any case, thetraffic management device110 may manage the network communications by performing several network traffic management related functions involving network communications, secured or unsecured, such as load balancing, access control, VPN hosting, network traffic acceleration, encryption, decryption, cookie, and key management and providing authenticated domain name service in accordance with the systems and processes described further below in connection withFIGS. 2-3, for example.

Referring toFIG. 2, an exemplarytraffic management device110 is illustrated. Included within thetraffic management device110 is a system bus26 (also referred to as bus26) that communicates with ahost system18 via abridge25 and with an input-output (I/O)device30. In this example, a single I/O device30 is shown to represent any number of I/O devices connected tobus26. In one example,bridge25 is in further communication with ahost processor20 via host input output (I/O)ports29.Host processor20 can further communicate with anetwork interface controller24 via aCPU bus202, a host memory22 (via a memory port53), and acache memory21. As outlined above, included within thehost processor20 are host I/O ports29,memory port53, and a main processor (not shown separately). In this example,host system18 includes acryptography module208.

In one example,traffic management device110 can include thehost processor20 characterized by anyone of the following component configurations: computer readable medium and logic circuits that respond to and process instructions fetched from thehost memory22; a microprocessor unit, such as: those manufactured by Intel Corporation of Santa Clara, Calif.; those manufactured by Motorola Corporation of Schaumburg, Ill.; those manufactured by Transmeta Corporation of Santa Clara, Calif.; the RS/6000 processor such as those manufactured by International Business Machines of Armonk, N.Y.; a processor such as those manufactured by Advanced Micro Devices of Sunnyvale, Calif.; or any other combination of logic circuits capable of executing the systems and methods described herein. Still other examples of thehost processor20 can include any combination of the following: a microprocessor, a microcontroller, a central processing unit with a single processing core, a central processing unit with two processing cores, or a central processing unit with more than one processing core.

Examples of thetraffic management device110 include one or more application delivery controller devices of the BIG-IP® product family provided by F5 Networks, Inc. of Seattle, Wash., although other types of traffic management devices may be used. In an exemplary structure and/or arrangement,traffic management device110 can include thehost processor20 that communicates withcache memory21 via a secondary bus also known as a backside bus, while another example of thetraffic management device110 includes thehost processor20 that communicates withcache memory21 via thesystem bus26. Thelocal system bus26 can, in some examples, also be used by thehost processor20 to communicate with more than one type of I/O devices30. In some examples, thelocal system bus26 can be anyone of the following types of buses: a VESA VL bus; an ISA bus; an EISA bus; a Micro Channel Architecture (MCA) bus; a PCI bus; a PCI-X bus; a PCI-Express bus; or a NuBus. Other example configurations of thetraffic management device110 include I/O device30 that is a video display (not shown separately) that communicates with thehost processor20 via an Advanced Graphics Port (AGP). Still other versions of thetraffic management device110 includehost processor20 connected to I/O device30 via any one or more of the following connections: HyperTransport, Rapid I/O, or InfiniBand. Further examples of thetraffic management device110 include a communication connection where thehost processor20 communicates with one I/O device30 using a local interconnect bus and with a second I/O device (not shown separately) using a direct connection. As described above, included within some examples of thetraffic management device110 is each ofhost memory22 andcache memory21. Thecache memory21, will, in some examples, be any one of the following types of memory: SRAM; BSRAM; or EDRAM. Other examples includecache memory21 andhost memory22 that can be anyone of the following types of memory: Static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDECSRAM, PCIOO SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus DRAM (DRDRAM), Ferroelectric RAM (FRAM), or any other type of memory device capable of executing the systems and methods described herein.

Thehost memory22 and/or thecache memory21 can, in some examples, include one or more memory devices capable of storing data and allowing any storage location to be directly accessed by thehost processor20. Such storage of data can be in a local database internal totraffic management device110, or external totraffic management device110 coupled via one or more input output ports ofnetwork interface controller24. Further examples oftraffic management device110 include ahost processor20 that can access thehost memory22 via one of either:system bus26;memory port53; or any other connection, bus or port that allows thehost processor20 to accesshost memory22.

One example of thetraffic management device110 provides support for anyone of the following installation devices: a floppy disk drive for receiving floppy disks such as 3.5-inch, 5.25-inch disks or ZIP disks, a CD-ROM drive, a CD-R/RW drive, a DVD-ROM drive, tape drives of various formats, USB device, a bootable medium, a bootable CD, a bootable compact disk (CD) for GNU/Linux distribution such as KNOPPIX®, a hard-drive or any other device suitable for installing applications or software. Applications can, in some examples, include a client agent, or any portion of a client agent. Thetraffic management device110 may further include a storage device (not shown separately) that can be either one or more hard disk drives, or one or more redundant arrays of independent disks; where the storage device is configured to store an operating system, software, programs applications, or at least a portion of the client agent. A further example of thetraffic management device110 includes an installation device that is used as the storage device.

Furthermore, thetraffic management device110 can includenetwork interface controller24 to communicate, via an input-output port insidenetwork interface controller24, with a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25, SNA, DECNET), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), wireless connections, optical connections, or some combination of any or all of the above. Connections can also be established using a variety of communication protocols (e.g., TCP/IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, RS485, IEEE 802.11, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, CDMA, GSM, WiMax and direct asynchronous connections). One version of thetraffic management device110 includesnetwork interface controller24 configured to communicate with additional computing devices via any type and/or form of gateway or tunneling protocol such as Secure Socket Layer (SSL) or Transport Layer Security (TLS), or the Citrix Gateway Protocol manufactured by Citrix Systems, Inc. of Fort Lauderdale, Fla. Versions of thenetwork interface controller24 can comprise anyone of: a built-in network adapter; a network interface card; a PCMCIA network card; a card bus network adapter; a wireless network adapter; a USB network adapter; a modem; or any other device suitable for interfacing thetraffic management device110 to a network capable of communicating and performing the methods and systems described herein.

In various examples, thetraffic management device110 can include any one of the following I/O devices30: a keyboard; a pointing device; a mouse; a gesture based remote control device; a biometric device; an audio device; track pads; an optical pen; trackballs; microphones; drawing tablets; video displays; speakers; inkjet printers; laser printers; and dye sublimation printers; or any other input/output device able to perform the methods and systems described herein. Host I/O ports29 may in some examples connect to multiple I/O devices30 to control the one or more I/O devices30. Some examples of the I/O devices30 may be configured to provide storage or an installation medium, while others may provide a universal serial bus (USB) interface for receiving USB storage devices such as the USB Flash Drive line of devices manufactured by Twintech Industry, Inc. Still other examples of an I/O device30 may bebridge25 between thesystem bus26 and an external communication bus, such as: a USB bus; an Apple Desktop Bus; an RS-232 serial connection; a SCSI bus; a FireWire bus; a FireWire800 bus; an Ethernet bus; an AppleTalk bus; a Gigabit Ethernet bus; an Asynchronous Transfer Mode bus; a HIPPI bus; a Super HIPPI bus; a SerialPlus bus; a SCI/LAMP bus; a FibreChannel bus; or a Serial Attached small computer system interface bus.

According to some examples,traffic management device110 includescryptography module208 integrated as part ofhost system18 for carrying out various exemplary functions of storing private and public keys. Alternatively,cryptography module208 may be a part of an autonomous application security manager module integrated with or communicating independently with thetraffic management device110. An exemplary application security manager is the BIG-IP® Application Security Manager™ provided by F5 Networks, Inc. of Seattle, Wash. In one example,cryptography module208 includes a crypto-storage chip on the motherboard to secure one or more unique hardware keys as part of the multi-layer encryption process employed bytraffic management device110 to secure keys.

Accordingly, components oftraffic management device110 include one or more processors (e.g., host processor20) executing one or more traffic management applications, memory (e.g.,cache memory21, and/or host memory22) coupled to the one or more processors by a bus,network interface controller24 coupled to the one or more processors and thehost memory22 and configured to receive data packets from a network that relate to the executing traffic management applications, and provide authenticated domain name service. In this example, at least one of the one or more processors is configured to execute programmed instructions stored in the memory (e.g.,cache memory21, and/or host memory22) and thenetwork interface controller24 including logic capable of being further configured to implement forwarding at traffic management device110 a request for a domain name from a client device (e.g., one or more of client computers104(1)-104(n)) to one or more servers (e.g., servers102(1)-102(n)) coupled totraffic management device110. Thetraffic management device110 receives a first response comprising at least a portion of the domain name from the one or more servers102(1)-102(n). Thetraffic management device110 attaches a first signature to the first response when the first response is determined by thetraffic management device110 to be an unauthenticated response, and provides the first response with the first signature to the client device (e.g., one or more of client computers104(1)-104(n)).

The operation of example processes for providing authenticated domain name service usingtraffic management device110 shown inFIGS. 1-2, will now be described with reference back toFIGS. 1-2 in conjunction with flow diagram orflowchart300 shown inFIG. 3, respectively. Theflowchart300 is representative of example machine readable instructions for implementing in dynamic real-time authenticated domain name service, for example, at thetraffic management device110. In this example, the machine readable instructions comprise an algorithm for execution by: (a) a processor (e.g., host processor20), (b) a controller, and/or (c) one or more other suitable processing device(s) withinhost system18, for example. The algorithm may be implemented in software stored on tangible computer readable media such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital video (versatile) disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a processor and/or implemented in firmware or dedicated hardware in a well known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), a field programmable gate array (FPGA), discrete logic, or the like). For example, at least some of the components of thetraffic management device110 could be implemented by software, hardware, and/or firmware. Also, some or all of the machine readable instructions represented by the process offlowchart300 ofFIG. 3 may be implemented manually at thetraffic management device110, for example, using a command line interface (CLI) prompt window operated by a system administrator. Further, although the example algorithm is described with reference toflowchart300, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks inflowchart300 may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

Referring now toFIG. 3,flowchart300 discusses a scenario where responses received from servers102(1)-102(n) are not signed. It is to be noted servers102(1)-102(n) may be able to sign some responses but are unable to sign some other responses, depending upon the request from client computers104(1)-104(n).

Instep302 of theflowchart300,traffic management device110 receives a request from one of client computers104(1)-104(n). In this example, the request from the client computers104(1)-104(n) can be a DNSSEC request for an address record (also referred to as an ‘A’ record) that requires a signed response, or an authenticated response from one or more servers102(1)-102(n). In this example, servers102(1)-102(n) may not be able to provide an authenticated response to the request since the servers102(1)-102(n) are in a conventional DNS only environment. By way of example only, the request can include a URL for a website www.example.com, where “.” is the root, “.com” is a top-level domain, and “.example” is a second level domain, and so on, as can be understood by those of ordinary skill in the art. Further by way of example only and not by way of limitation, other types of top-level domains such as “.gov,” “.org,” “.net,” and/or country specific domains (e.g., “.us”) may be a part of the request from client computers104(1)-104(n). The request from one of the client computers104(1)-104(n) can come viaLDNS106, which may or may not have a cached copy of the requested resource for providing an initial response to the request. It is to be noted that the requests can be originating from anywhere around the earth, and are not geographically or otherwise restricted in their origin.

Instep304,traffic management device110 forwards the received request to one of the servers102(1)-102(n) after removing bits and/or headers to convert the request into a regular DNS request that can be understood by servers102(1)-102(n). Although in this example servers102(1)-102(n) are not DNSSEC enabled, they are still on a trusted network (e.g., on LAN114).

Instep306,traffic management device110 receives a response from one of servers102(1)-102(n). In one example, the response includes a resource record set (RRSET) including one or more address records. The RRSET includes all the records of a given type for a given domain included in the original request, as known to those of ordinary skill in the art. In this example, the response can be for the root “.”. Alternatively, the response can be for the top level domain “.com” and/or second level domain “.example”. The response can include a plurality of responses in succession starting from the root, which is the highest level, to the lowest level domain, and can therefore comprise building a chain of trust for signing response received from servers102(1)-102(n). For example, each of the responses from servers102(1)-102(n) for root, top level, and second level domains, can be respectively analyzed for a signature, determined by the traffic management device110 (e.g., instep310 below). In the example ofFIG. 3, since servers102(1)-102(n) are regular DNS servers that are authoritative for the requested zone but do not have the capability to sign, the responses for root, top level, and second level domains will not be signed responses. As a result, the response received from servers102(1)-102(n) in this example will not be DNSSEC compliant. For example, in one scenario a requested domain name, e.g., www.example.com, will not have a signature attached to it when received by thetraffic management device110. In another scenario, there will be dynamic updates to www.example.com records. In this scenario, a previously authenticated response forwarded by thetraffic management device110 to the requesting one of client computers104(1)-104(n) will no more have a valid signature, and will need to be signed again at thetraffic management device110, as discussed below forstep318.

Instep308,traffic management device110 determines whether the received response from one of the servers102(1)-102(n) is a denial of existence response for the requested resource. Denial of existence can occur, for example, when the original request from the client computers104(1)-104(n) is for a non-existent domain name. Alternatively, a denial of existence response may be received when one or more data records within a zone does not exist. For example, the name www.example.com may exist but an address record (or, ‘A’ record) at www.example.com may not exist and result in a denial of existence response from servers102(1)-102(n). Since A records are well known to those of ordinary skill in the art, they will not be described in detail here. If the received response from one of the servers102(1)-102(n) is a denial of existence, the flow proceeds to step316, and if not, the flow proceeds to step310.

Instep316, when thetraffic management device110 determines the received response from one of the servers102(1)-102(n) is a denial of existence response,traffic management device110 creates one or more next secure (NSEC3) resource records belonging to a cryptographically hashed domain name. Since NSEC3 resource records are known to those of ordinary skill in the art, they will not be described in detail here. In one example,traffic management device110 dynamically manufactures the NSEC3 resource record based upon the request from the client, with no knowledge of the actual content of the relevant zone on domain name servers102(1)-102(n), such that the manufactured NSEC3 resource record can be used by the client to prove non-existence of the requested name. In another example,traffic management device110 may dynamically manufacture the NSEC3 resource record based upon the request from the client with some knowledge of the actual content of the relevant zone on domain name servers102(1)-102(n). In yet another example,traffic management device110 may dynamically manufacture the NSEC3 resource record based upon the request from the client with complete knowledge of the actual content of the relevant zone on domain name servers102(1)-102(n). By way of example only, creating the NSEC3 resource record includes utilizing one of Secure Hash Algorithms (SHAs), although other types of hashing algorithms may be used. In this example, resource records created bytraffic management device110 as a response to a denial of existence of original resource from servers102(1)-102(n) are trusted by client computers104(1)-104(n), sincetraffic management device110 itself is a trusted device for client computers104(1)-104(n). Signatures to the created zone are then attached bytraffic management device110 as described instep318 below.

One example of how the NSEC3 resource record is created bytraffic management device110 is by taking the requested non-existent name, say www.example.com and performing hashing using one of the DNSSEC specified secure hashing algorithms (e.g., SHA1) prior to sending the response to the requesting one of the client computers104(1)-104(n). Assuming, by way of example only and not by way of limitation, the resulting hash is equal to “12345”. The requesting one of client computers104(1)-104(n) may need a “spanning” NSEC3 record for its proof of non-existence (i.e., the closest enclose proof as disclosed in RFC 5155), or it may need a “matching” NSEC3 record (i.e., the exact enclose proof as also disclosed in RFC 5155). For a spanning record, this example would take the hashed name “12345” and perform, for example, a “+1” or “−1” on the number the hash represents. Accordingly, in this case two numbers “12344” and “12346” are generated. These new hash values would span the original hashed non-existent name and would be used to create a spanning NSEC3 record attraffic management device110. Similarly, for a matching record, two hash values are required, however, only the “+1” is created and paired with the original name bytraffic management device110, resulting in an NSEC3 record containing “12345” and “12346”. It is to be noted that although in the examples above “+/−1” values were used, any increment method, for example “+/−N” where N is an integer, may be used and the “+/−1” is only an illustrative example and is not limiting. Additionally, this example represents a method to manufacture an NSEC3 resource record attraffic management device110 in substantially real-time upon receipt of the response instep306 with no knowledge of the actual set of names in the zone. As discussed above, additional scenarios wheretraffic management device110 may have some or complete knowledge of contents of the zone may use this example for generating NSEC3 records. Since spanning and matching records are known to those of ordinary skill in the art, and are disclosed in RFC 5155 hereby incorporated by reference in its entirety, the will not be described in detail herein.

Instep310,traffic management device110 determines if the response received from one of the servers102(1)-102(n) was a DNSSEC response that included signatures for a top level domain, a second level domain, a sub-level domain, and/or all levels of the domain name. This determination can be made by thetraffic management device110 by checking whether or not the received response from servers102(1)-102(n) includes a resource record signature (RRSIG), although other methods of determining may be used. Since RRSIG records that were introduced as a part of DNSSEC are known to those of ordinary skill in the art, they will not be described in detail here. If the received response includes an RRSIG, the flow proceeds to step314. If not, thetraffic management device110 determines the response is unauthenticated, and the flow proceeds to step318.

Instep318,traffic management device110 dynamically in real-time generates one or more cryptographic signatures (e.g., RRSIG records) and attaches the signatures to the response received from one or more servers102(1)-102(n). Attaching the signature can be performed in one or more of the following exemplary ways, although other ways of attaching signatures “on the fly” may be contemplated by those of ordinary skill in the art after reading this disclosure. For attaching a signature,traffic management device110 is configured to allocate zone signing keys (ZSKs) and Key Signing Keys (KSKs) for the received response from servers102(1)-102(n). In this example, KSKs are used to sign other DNSKEY records, while ZSKs are used to sign all resource record sets (RRSETs). By way of example only, both KSKs and ZSKs can be made stronger by using more bits in the key material, and for security reasons, can be rotated at different time intervals (e.g., KSK every 12 months and the ZSK every one to two months). The public key infrastructure enables client computers104(1)-104(n) to validate the integrity of the response received from non-DNSSEC servers102(1)-102(n) signed with the private key. Since the private key of the public/private key pair could be used to impersonate a valid signer, those keys are kept secure, by way of example only, by storing them as hardware keys incryptography module208. By way of example only,cryptography module208 supports FIPS storage of the private keys. Additionally,traffic management device110 is configured to securely synchronize the keys between multiple FIPS devices, e.g., multiple traffic management devices. In one example,cryptography module208 includes a crypto-storage chip on the motherboard to secure a unique hardware key as part of the multi-layer encryption process employed bytraffic management device110 to secure KSKs and ZSKs. Alternatively, KSKs and ZSKs may be secured, by way of example only and not by way of limitation, using secure SSL-encrypted storage systems. Accordingly,traffic management device110 encrypts the response using the one or more keys, as discussed above.

Instep312,traffic management device110 forwards the response with the signature, along with a public key to the requesting one of the client computers104(1)-104(n). Sincetraffic management device110 signs the response from servers102(1)-102(n) and client computers104(1)-104(n) trust thetraffic management device110, client computers104(1)-104(n) can use the DNSKEY to validate the RRSET using RRSIG included in the forwarded response fromtraffic management device110. The flow ends instep320.

Example Use Case

In one exemplary global server load balancing (GSLB)-type scenario,traffic management device110 configured as a load balancing device can provide responses that can change depending on the requesting client out of client computers104(1)-104(n). Alternatively,traffic management device110 may receive responses routed from a global load balancer connected toLAN114. For example, for a request www.example.com,traffic management device110 may receive two different responses—one from a server102(1) and another from a server102(2). Out of the two responses, it is possible that the response from server102(1) may be the only one that is signed and the response from server102(2) may not be signed. However, the response from server102(2) might be the most current updated response with updated resource records. In such a scenario,traffic management device110 will sign the response from server102(2) according to the steps offlowchart300, and forward the signed response to the client computers104(1)-104(n), instead of sending the older signed response from server102(1)-102(n).

Servers102(1)-102(n) have DNS entries that are statically signed. Each time a DNS entry is updated, signatures associated with the DNS entries become outdated and those DNS entries have to be signed again either manually or offline. A change to a DNS entry means a change to an IP address that the DNS entry is translated into. Therefore, for updates to DNS entries,traffic management device110 signs or authenticates the new responses including updated IP addresses, and performs load balancing based on the new signed IP addresses, while discarding the outdated or older IP addresses (and hence, older DNS entries).

The examples of the technology described herein provide numerous advantages. For example, when client computers104(1)-104(n) are in a DNSSEC environment requiring authenticated responses, examples disclosed herein enable such client computers104(1)-104(n) to communicate with non-DNSSEC servers102(1)-102(n) on a real time basis without any upgrades to software on client computers104(1)-104(n). Such dynamic “on-the-fly” authentication performed bytraffic management device110 when servers102(1)-102(n) are unable to sign the responses, ensure that the client computers104(1)-104(n) receive valid resource records that are from a trusted source, and not from a rogue server or site. The technology described also enables administrators of large non-DNSSEC DNS deployments to quickly become DNSSEC compliant by interposingtraffic management device110 according to the examples disclosed in such legacy deployments resulting in an easy and fast DNSSEC compliance solution.

Having thus described the basic concepts, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. The order that the measures and processes for providing secure application delivery are implemented can also be altered. Furthermore, multiple networks in addition tonetwork112 andLAN114 could be associated withtraffic management device110 from/to which network packets can be received/transmitted, respectively. These alterations, improvements, and modifications are intended to be suggested by this disclosure, and are within the spirit and scope of the examples. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes and methods to any order except as can be specified in the claims.

Claims (36)

What is claimed is:

1. A method for providing authenticated domain name service comprising:

forwarding at a traffic management device a domain name system security extension (DNSSEC) type request for a domain name received from a client device to one or more domain name system (DNS) servers;

receiving at the traffic management device a response for at least a portion of the domain name from the one or more servers, wherein the one or more servers are not domain name system security extension (DNSSEC) compliant;

creating at the traffic management device a resource record when the response is determined to be a denial of existence response for the requested domain name;

generating at the traffic management device a signature and signing the response or the resource record using the signature; and

sending at the traffic management device the signed resource record or response to the client device in response to the request.

2. The method as set forth inclaim 1, wherein the one or more servers are authoritative for a zone associated with the at least a portion of the domain name.

3. The method as set forth inclaim 1, wherein the signing further comprises encrypting the response or the resource record using a stored private key, the method further comprising performing at the traffic management device a hash of the encrypted response or resource record prior to the sending.

4. The method as set forth inclaim 1, wherein the at least a portion of the domain name comprises a top-level domain name that is known to be authenticated.

5. The method as set forth inclaim 1, wherein at least one of the first or second server is authoritative for a zone associated with the at least a portion of the domain name.

6. A non-transitory computer readable medium having stored thereon instructions for providing authenticated domain name service comprising machine executable code which when executed by at least one processor, causes the processor to perform steps comprising:

forwarding a domain name system security extension (DNSSEC) type request for a domain name received from a client device to one or more domain name system (DNS) servers;

receiving a response for at least a portion of the domain name from the one or more servers, wherein the one or more servers are not domain name system security extension (DNSSEC) compliant;

creating a resource record when the response is determined to be a denial of existence response for the requested domain name;

generating a signature and signing the response or the resource record using the signature; and

sending the signed resource record or response to the client device in response to the request.

7. The medium as set forth inclaim 6, wherein the one or more servers are authoritative for a zone associated with the at least a portion of the domain name.

8. The medium as set forth inclaim 6, wherein the signing further comprises encrypting the response or the resource record using a stored private key, the medium further having stored thereon instructions comprising machine executable code which when executed by the at least one processor causes the processor to perform steps further comprising performing a hash of the encrypted response or resource record prior to the sending.

9. The medium as set forth inclaim 6, wherein the at least a portion of the domain name comprises a top-level domain name that is known to be authenticated.

10. A traffic management device comprising:

at least one processor; and

a memory coupled to the at least one processor which is configured to be capable of executing programmed instructions stored in the memory to perform steps comprising:

forwarding a domain name system security extension (DNSSEC) type request for a domain name received from a client device to one or more domain name system (DNS) servers;

receiving a response for at least a portion of the domain name from the one or more servers, wherein the one or more servers are not domain name system security extension (DNSSEC) compliant;

creating a resource record when the response is determined to be a denial of existence response for the requested domain name;

generating a signature and signing the response or the resource record using the signature; and

sending the signed resource record or response to the client device in response to the request.

11. The device as set forth inclaim 10, wherein the one or more servers are authoritative for a zone associated with the at least a portion of the domain name.

12. The device as set forth inclaim 10, wherein the signing further comprises encrypting the response or the resource record using a stored private key, the at least one processor further configured to be capable of executing programmed instructions stored in the memory to perform steps further comprising performing a hash of the encrypted first response or resource record prior to the sending.

13. The device as set forth inclaim 10, wherein the at least a portion of the domain name comprises a top-level domain name that is known to be authenticated.

14. A method for providing authenticated domain name service comprising:

forwarding at a traffic management device a domain name system security extension (DNSSEC) type request for a domain name received from a client device to a global server load balancer coupled to at least first domain name system (DNS) server that is not DNSSEC compliant and a second DNS server that is DNSSEC compliant;

receiving at the traffic management device first and second responses for at least a portion of the domain name from the global server load balancer, wherein the first response is from the first server and the second response is from the second server;

generating at the traffic management device a signature and signing the first response using the signature when the first response is determined to be more current than the second response; and

sending at the traffic management device the signed first response to the client device in response to the request.

15. The method as set forth inclaim 1, wherein the first and second responses are denial of existence responses and the method further comprises:

creating at the traffic management device a resource record;

generating at the traffic management device a signature and signing the first or second response or the resource record using the signature; and

sending at the traffic management device the signed resource record or first or second response to the client device in response to the request.

16. The method as set forth inclaim 15, wherein the signing further comprises encrypting the first or second response or the resource record using a stored private key, the method further comprising performing at the traffic management device a hash of the encrypted first or second response or resource record prior to the sending.

17. A non-transitory computer readable medium having stored thereon instructions for providing authenticated domain name service comprising machine executable code which when executed by at least one processor, causes the processor to perform steps comprising:

forwarding a domain name system security extension (DNSSEC) type request for a domain name received from a client device to a global server load balancer coupled to at least first domain name system (DNS) server that is not DNSSEC compliant and a second DNS server that is DNSSEC compliant;

receiving first and second responses for at least a portion of the domain name from the global server load balancer, wherein the first response is from the first server and the second response is from the second server;

generating a signature and signing the first response using the signature when the first response is determined to be more current than the second response; and

sending the signed first response to the client device in response to the request.

18. The medium as set forth inclaim 17, wherein the first and second responses are denial of existence responses and the medium further has stored thereon instructions comprising machine executable code which when executed by the at least one processor causes the processor to perform steps further comprising:

creating at the traffic management device a resource record;

generating at the traffic management device a signature and signing the first or second response or the resource record using the signature; and

sending at the traffic management device the signed resource record or first or second response to the client device in response to the request.

19. The medium as set forth inclaim 18, wherein the signing further comprises encrypting the first or second response or the resource record using a stored private key, the medium further having stored thereon instructions comprising machine executable code which when executed by the at least one processor causes the processor to perform steps further comprising performing a hash of the encrypted first or second response or resource record prior to the sending.

20. The medium as set forth inclaim 17, wherein at least one of the first or second server is authoritative for a zone associated with the at least a portion of the domain name.

21. A traffic management device comprising:

at least one processor; and

a memory coupled to the at least one processor which is configured to be capable of executing programmed instructions stored in the memory to perform steps comprising:

forwarding a domain name system security extension (DNSSEC) type request for a domain name received from a client device to a global server load balancer coupled to at least first domain name system (DNS) server that is not DNSSEC compliant and a second DNS server that is DNSSEC compliant;

receiving first and second responses for at least a portion of the domain name from the global server load balancer, wherein the first response is from the first server and the second response is from the second server;

generating a signature and signing the first response using the signature when the first response is determined to be more current than the second response; and

sending the signed first response to the client device in response to the request.

22. The device as set forth inclaim 21, wherein the first and second responses are denial of existence responses and the at least one processor is further configured to be capable of executing programmed instructions stored in the memory to perform steps further comprising:

creating at the traffic management device a resource record;

generating at the traffic management device a signature and signing the first or second response or the resource record using the signature; and

sending at the traffic management device the signed resource record or first or second response to the client device in response to the request.

23. The device as set forth inclaim 22, wherein the signing further comprises encrypting the first or second response or the resource record using a stored private key, the at least one processor further configured to be capable of executing programmed instructions stored in the memory to perform steps further comprising performing a hash of the encrypted first or second response or resource record prior to the sending.

24. The device as set forth inclaim 21, wherein at least one of the first or second server is authoritative for a zone associated with the at least a portion of the domain name.

25. A non-transitory computer readable medium having stored thereon instructions for providing authenticated domain name service comprising machine executable code which when executed by at least one processor, causes the processor to:

receive a domain name system security extension (DNSSEC) request for a domain name from a DNSSEC compliant computing device;

generate a domain name system (DNS) request corresponding to the DNSSEC request for the domain name;

send the DNS request for the domain name to one or more DNS servers that are not DNSSEC compliant;

receive a DNS compliant response for at least a portion of the domain name from the one or more DNS servers;

create a signed resource record that is DNSSEC compliant when the DNS compliant response from the one or more DNS servers is a denial of existence response for the requested domain name; and

send the signed resource record to the requesting DNSSEC compliant computing device.

26. The medium as set forth in claim 25, wherein the DNS servers are authoritative for a zone associated with the at least a portion of the domain name.

27. The medium as set forth in claim 25, wherein the executable code, when executed by the processor, further causes the processor to:

encrypt the signed resource record using a stored private key; and

perform a hash of the encrypted signed resource record prior to sending the signed resource record to the requesting DNSSEC compliant computing device.

28. The medium as set forth in claim 25, wherein the at least a portion of the domain name comprises a top-level domain name that is known to be authenticated.

29. A method for providing authenticated domain name service implemented by a system comprising one or more network traffic management devices, one or more servers, or one or more clients, the method comprising:

receiving a domain name system security extension (DNSSEC) request for a domain name from a DNSSEC compliant computing device;

generating a domain name system (DNS) request corresponding to the DNSSEC request for the domain name;

sending the DNS request for the domain name to one or more DNS servers that are not DNSSEC compliant;

receiving a DNS compliant response for at least a portion of the domain name from the one or more DNS servers;

creating a signed resource record that is DNSSEC compliant when the DNS compliant response from the one or more DNS servers is a denial of existence response for the requested domain name; and

sending the signed resource record to the requesting DNSSEC compliant computing device.

30. The method as set forth in claim 29, wherein the DNS servers are authoritative for a zone associated with the at least a portion of the domain name.

31. The method as set forth in claim 29, further comprising:

encrypting the signed resource record using a stored private key; and

performing a hash of the encrypted signed resource record prior to sending the signed resource record to the requesting DNSSEC compliant computing device.

32. The method as set forth in claim 25, wherein the at least a portion of the domain name comprises a top-level domain name that is known to be authenticated.

33. A system comprising one or more network traffic management devices, one or more servers, or one or more clients, the system comprising:

one or more processors; and

memory comprising programmed instructions stored in the memory, the one or more processors configured to be capable of executing the programmed instructions stored in the memory to:

receive a domain name system security extension (DNSSEC) request for a domain name from a DNSSEC compliant computing device;

generate a domain name system (DNS) request corresponding to the DNSSEC request for the domain name;

send the DNS request for the domain name to one or more DNS servers that are not DNSSEC compliant;

receive a DNS compliant response for at least a portion of the domain name from the one or more DNS servers;

create a signed resource record that is DNSSEC compliant when the DNS compliant response from the one or more DNS servers is a denial of existence response for the requested domain name; and

send the signed resource record to the requesting DNSSEC compliant computing device.

34. The system as set forth in claim 33, wherein the DNS servers are authoritative for a zone associated with the at least a portion of the domain name.

35. The system as set forth in claim 33, wherein the one or more processors are further configured to be capable of executing the programmed instructions stored in the memory to:

encrypt the signed resource record using a stored private key; and

perform a hash of the encrypted signed resource record prior to sending the signed resource record to the requesting DNSSEC compliant computing device.

36. The system as set forth in claim 33, wherein the at least a portion of the domain name comprises a top-level domain name that is known to be authenticated.

Images