CN106330708A - System and method for local DNS service - Google Patents

Abstract

The invention provides a system and method for local DNS service. The system according to the present invention includes: a terminal, used to send a data packet to the Internet, and the data packet contains a DNS request; an OpenFlow switch, used to receive the DNS request from the terminal and forward the DNS request; a local DNS service A device for receiving the DNS request from the OpenFlow switch, and generating a DNS response according to the DNS request and sending it to the OpenFlow switch; wherein the OpenFlow switch is also used for receiving the DNS request from the local DNS service device The DNS response is forwarded to the endpoint. Through the present invention, transparent local DNS service can be provided, which can avoid security problems caused by cascading devices, and because the DNS request will not be sent to the Internet, the DNS response from the Internet and the DNS service device can be avoided. Race between DNS responses.

Description

System and method for local DNS service

technical field

The present invention relates to network communication, in particular to DNS service.

Background technique

DNS (Domain Name System, Domain Name System) is a system for mapping domain names and IP addresses on the Internet, which can facilitate users to access the Internet through domain names without remembering the desired IP address. DNS is the actual addressing method used by most applications on the Internet.

The DNS service deployed in the enterprise intranet or within the operator is called local DNS. Local DNS mainly provides the following three functions: (1) providing DNS caching, accelerating domain name resolution, and improving user network experience; (2) traffic traction, coordinating CDN (Content Delivery Network, content distribution network) technology realizes the optimization of network transmission and local differentiated services; (3) DNS filtering, based on the blacklist, realizes the protection of malicious websites and intercepts phishing websites.

However, although local DNS can provide many effective functions, there are significant obstacles in the deployment of local DNS. This is because the existing local DNS service is often implemented in a "non-transparent" manner, that is, all terminals need to be configured with a DNS server address to take effect. Such a configuration process is very cumbersome, and in some scenarios where the terminal is uncontrollable, it is impossible to implement the local DNS service in a non-transparent manner.

There are also some existing local DNS services that are implemented in a "transparent" way. The "transparent" way means that the terminal is not configured, that is, the DNS service is enabled without the terminal knowing the existence of the local DNS service. take effect. However, the transparent DNS service usually needs to connect a DNS server in series on the only way of terminal traffic, which is realized by capturing the DNS request message and assembling the corresponding DNS response message, and the assembled DNS response message also needs to use the original IP spoofing technology to make the terminal think that the response is from its configured DNS server. For the existing transparent DNS method, since its configuration is simple and does not need to modify the client, it has a wide range of application scenarios. However, its serial deployment method brings hidden dangers to the reliability of the network. This is because when implementing network operations, in principle, the number of network function devices connected in series should be reduced as much as possible to reduce the network failure rate.

Considering the hidden dangers caused by connecting DNS servers in series, some existing technologies arrange local DNS service devices in communication bypasses. However, in these existing technologies, in order to realize the bypass deployment of the DNS service device, an optical splitter or other devices supporting port mirroring are usually deployed on the path that the traffic of the terminal must pass through, so as to mirror the traffic of the terminal accessing the Internet to the local DNS service device. Even if the DNS service device is arranged in the bypass, it still cannot avoid the need to connect other devices for mirroring traffic in series on the traffic path, so it is still difficult to guarantee the reliability of the network.

Contents of the invention

Therefore, the object of the present invention is to overcome the above-mentioned defective of prior art, provide a kind of system of local DNS service, comprise:

The terminal is used to send a data packet to the Internet, and the data packet includes a DNS request;

An OpenFlow switch, configured to receive a DNS request from the terminal and forward the DNS request;

A local DNS service device, configured to receive the DNS request from the OpenFlow switch, and generate a DNS response according to the DNS request and send it to the OpenFlow switch;

Wherein, the OpenFlow switch is further configured to forward the DNS response received from the local DNS service device to the terminal.

Preferably, according to the system, it also includes:

The OpenFlow controller is used to deliver flow entries to the OpenFlow switch.

Preferably, according to the system, the OpenFlow controller is further configured to generate a flow entry for modifying the source IP of the DNS response according to the DNS request.

Preferably, according to the system, the local DNS service device is integrated in the OpenFlow controller.

Preferably, according to the system, the OpenFlow controller is further configured to generate a flow entry for modifying the destination IP of the DNS request according to the DNS request.

Preferably, according to the system, the OpenFlow controller is further configured to deliver to the OpenFlow switch a flow entry for forwarding a data packet with a destination port of 53 to the OpenFlow controller.

Preferably, according to the system, the OpenFlow controller is further configured to deliver to the OpenFlow switch a flow entry for forwarding a data packet whose source port is 53 to the terminal.

Moreover, the present invention also provides a method for local DNS service based on the system, including:

1) The OpenFlow switch sends the DNS request in all data packets from the terminal to the local DNS service device according to the flow entry;

2) The local DNS service device sends the generated DNS response to the OpenFlow switch;

3) The OpenFlow switch forwards the DNS response to the terminal according to the flow entry.

Preferably, according to the method, wherein step 3) also includes before:

2.5) The OpenFlow switch modifies the source IP of the DNS response to the destination IP of the DNS request according to the flow entry.

Preferably, according to the method, wherein step 1) also includes before:

The OpenFlow switch modifies the destination IP of the DNS request to the IP address of the local DNS service device according to the flow entry.

Preferably, according to the method, wherein step 1) comprises:

The OpenFlow switch forwards the data packet whose destination port is 53 to the OpenFlow controller as the DNS request according to the flow entry.

Preferably, according to the method, wherein step 3) comprises:

The OpenFlow switch forwards the data packet whose source port is 53 to the terminal according to the flow entry.

Compared with the prior art, the present invention has the advantages of:

Compared with the non-transparent local DNS service, the present invention does not need to configure the terminal, and it does not need to be limited to providing DNS service for the configured terminal.

Compared with the traditional transparent local DNS service, the present invention is based on software-defined technology, and only forwards the DNS request to the DNS service device, without connecting a device in series on the only way of terminal traffic to average all traffic from the terminal. Mirrored to the DNS service device, thereby avoiding the security problem caused by the serial connection device; and, in the present invention, the DNS request will not be sent to the Internet, thus blocking the DNS response from the Internet, thereby avoiding its connection with the Internet. The DNS responses generated by the DNS server create contention.

Description of drawings

Embodiments of the present invention will be further described below with reference to the accompanying drawings, wherein:

FIG. 1 is a schematic diagram of a scenario of a transparent DNS solution in which a DNS service device is deployed in a bypass in the prior art;

Fig. 2 is a schematic diagram of matching items supported by OpenFlow technology;

Fig. 3 is a system schematic diagram of an integrated DNS service solution according to an embodiment of the present invention;

Fig. 4 is a system schematic diagram of an independent DNS service solution according to an embodiment of the present invention.

detailed description

The present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

FIG. 1 shows a scene diagram of a transparent DNS solution in which a DNS service device is deployed in a bypass in the prior art. As shown in FIG. 1 , in this type of prior art, devices such as optical splitters or other devices supporting port mirroring need to be deployed, so as to mirror the traffic of terminals accessing the Internet to the DNS service device deployed on the bypass. Referring to Figure 1, when a terminal sends a DNS request containing domain name information to the Internet, the optical splitter used for mirroring traffic copies the traffic of the DNS request to the DNS service device, so that the DNS service device can transparently reply the DNS response to the terminal , so that the terminal can learn the IP address corresponding to the domain name according to the DNS. At the same time, the DNS request originally sent to the Internet will also return a response (ie, the original DNS response in Figure 1) to the terminal through the Internet. However, since the original DNS response is not blocked, it will compete with the DNS response generated by the local DNS service device, which will be noticed by the terminal.

In the above prior art, no consideration is given to intercepting the DNS request from the terminal. The inventor believes that this is because those skilled in the art believe that the terminal may send various types of data packets to the Internet, but based on most existing protocols, the data packet can only be determined after the destination port in the data packet is determined Is it a DNS request. Moreover, due to various needs, the terminal often needs to send various data packets with a large flow. Therefore, the prior art will not specifically set up a device with the function of extracting the data packet port for the DNS service (such a device is usually complex and prone to failure), but only uses a device such as an optical splitter to mirror the flow, and Send the mirrored flow to the DNS service device.

It can be seen that the traditional solution of setting the DNS service device in the bypass mode is to add serially connected devices to the network, and the serially connected devices will bring hidden dangers to the reliability of the network.

The SDN (Software Defined Network, Software Defined Network) technology, which has developed rapidly in recent years, has the advantages of network programmability and centralized control. Among them, OpenFlow, which is the most mature, has been widely used, and more and more networks have deployed switches that support OpenFlow.

The inventors found that the OpenFlow technology can be combined with the local DNS service, so that the OpenFlow technology can be used to determine whether the traffic from the terminal belongs to the DNS request in a simple manner. In addition, the inventor also found that the original DNS response from the Internet can be blocked by setting the OpenFlow flow entry (that is, the forwarding rule), so as to achieve the purpose of blocking the response from the Internet. In order to realize the above process, OpenFlow switches and controllers and devices for providing DNS services can be used, and special forwarding rules can be set using OpenFlow flow tables.

In the OpenFlow technology, each flow entry represents a forwarding rule, including: matching item, counting item and operation item. The OpenFlow switch compares the matching items of each flow entry in turn, and if the match is matched, executes the operation item of the flow entry, and jumps to the next flow table until the end. As shown in Figure 2, OpenFlow can support the matching of fields from layer 1 to layer 4 in the seven-layer network model, including ingress port (Ingress Port), destination MAC address (Dst MAC), source MAC address (Src MAC), Ethernet type ( Ether Type), VLAN tag (VLAN ID), VLAN priority (VLAN Priority), source IP (SrcIP), destination IP (Dst IP), IP protocol (IP Proto), TCP/UDP source port number (Src Port), TCP/UDP destination port number (Dst Port); the count item counts the packets that match successfully; the operation item can perform operations such as forwarding (Output), reporting to the controller (Packet-in), and setting field (Set-field). In addition, the OpenFlow controller can also use the Packet-out message to send data packets from a specific port of the OpenFlow switch, and the Flow-mod message to add, delete and modify flow entries of the OpenFlow switch. Therefore, the inventor believes that these flow entries of OpenFlow can be used to realize bypass and transparent DNS service.

As mentioned above, setting the DNS service device to bypass can improve the reliability of the network, so in the present invention, the DNS service device is also set to bypass. According to an embodiment of the present invention, the DNS service device is set as a functional module on the OpenFlow controller, and its specific implementation will be described in detail in Embodiment 1 below. According to another embodiment of the present invention, the DNS service device is deployed on a separate device, and its specific implementation will be described in detail in Embodiment 2 below.

Embodiment 1: Integrated DNS service technical solution

Fig. 3 shows a system in which a DNS service device is integrated in an OpenFlow controller according to an embodiment of the present invention. The system includes one or more terminals, one or more OpenFlow switches, an OpenFlow controller connected to the OpenFlow switch through a local area network, and a DNS service device integrated in the OpenFlow controller. Among them, the terminal sends the DNS request to the DNS service device integrated in the OpenFlow controller through the OpenFlow switch, and one OpenFlow controller can correspond to multiple OpenFlow switches (only a pair of OpenFlow switches and OpenFlow controllers are shown in Figure 3 ). Wherein, the OpenFlow switch extracts the port address of the data packet from the terminal, judges whether the data packet is a DNS request according to the port address, and sends the DNS request to the DNS service device. Since the destination port of the legitimate DNS request is 53, a corresponding OpenFlow flow entry can be set, so that when the destination port is 53, the action of forwarding the data packet to the OpenFlow controller is performed. For example, the flow entry is set as follows: the matching item is Dst_Port=53, and the operation item is reporting to the controller (Packet-in).

Referring to Figure 3, the method of local DNS service is introduced in detail, including:

1. The terminal sends a DNS request to the Internet (1).

For example, the IP address of a terminal is 192.168.1.1, and the IP address of the DNS server in the Internet that it expects to access is 8.8.8.8 (that is, the terminal hopes to obtain DNS services by accessing the IP address of the DNS server), the terminal Make DNS requests over port 1234. At this point, the DNS request packet sent by the terminal should be:

source IP Destination IP source port destination port content 192.168.1.1 8.8.8.8 1234 53 DNS request

2. The OpenFlow switch that receives the data packet from the terminal performs the following operations on the received data packet according to the flow entry: if the destination port of the data packet is 53, forward the data packet (ie DNS request) to the integrated OpenFlow controller (2) with DNS service device. This step can be realized through the flow entry of OpenFlow, thereby intercepting the DNS request data packet in all the data packets from the terminal, and sending the intercepted DNS request data packet to the local DNS service device. The local DNS service device here can provide DNS service instead of the DNS server in the Internet.

Continuing the example in the above step 1, the OpenFlow switch that receives the data packet reports the DNS request data packet in the received data packet to the OpenFlow controller according to the flow entry. At this time, the flow entry 1 is pre-set by the OpenFlow controller and sent to the OpenFlow switch, and its content is:

matches action item Dst_Port=53 Packet-in

Packet-in here refers to reporting data packets to the OpenFlow controller.

3. The DNS service module on the OpenFlow controller generates a DNS response corresponding to the received DNS request according to the local cache. If there is no IP address corresponding to the domain name in the DNS request in the local cache, then a recursive query is made to the Internet, as shown in Figure 3, addressing (i) to the Internet to return the IP address corresponding to the domain name in the DNS request IP address of (ii).

Continuing with the above example, if there is corresponding information in the local cache or the corresponding information is obtained through recursive query, the DNS service module generates the following DNS response data packet, so as to prevent the terminal from being aware that the DNS service is provided by the local DNS service device instead of being served by the DNS server:

source IP Destination IP source port destination port content 8.8.8.8 192.168.1.1 53 1234 DNS response

In addition, the OpenFlow controller sends a Packet-out control message to the OpenFlow switch, so that the OpenFlow switch sends a DNS response data packet to the designated port of the terminal.

4. The OpenFlow switch returns a DNS response to the terminal (4).

Continuing with the above example, the OpenFlow switch returns the received DNS response data packet to the terminal through a designated port (for example, a downlink port). The purpose of using the designated port here is to ensure that the terminal can receive the DNS response data packet.

Embodiment 2: Independent DNS service technical solution

Fig. 4 shows a system in which DNS service devices are set independently according to another embodiment of the present invention. The system includes one or more terminals, one or more OpenFlow switches, an OpenFlow controller connected to the OpenFlow switch through a local area network, and an independently deployed DNS service device. Wherein, the terminal sends the DNS request to the DNS service device through the OpenFlow switch. When the terminal sends the DNS request for the first time (or when there is no corresponding flow entry in the OpenFlow switch), it needs to generate a new flow entry through the OpenFlow controller and Send it to the OpenFlow switch. Also, one OpenFlow controller may correspond to multiple OpenFlow switches. Similar to Embodiment 1, the OpenFlow switch extracts the port address of the data packet from the terminal, judges whether the data packet is a DNS request according to the port address, and sends the DNS request to the DNS service device.

Referring to Fig. 4 below, the method for independently setting the local DNS service of the DNS service device according to the present invention is specifically introduced, including:

1. The terminal sends a DNS request (a) to the Internet.

For example, the IP address of a terminal is 192.168.1.1, and the IP address of the DNS server in the Internet that it expects to access is 8.8.8.8 (that is, the terminal hopes to obtain DNS services by accessing the IP address of the DNS server), the terminal Make DNS requests over port 1234. At this point, the DNS request packet sent by the terminal should be:

source IP Destination IP source port destination port content 192.168.1.1 8.8.8.8 1234 53 DNS request

2. The OpenFlow switch that receives the data packet from the terminal performs the following operations on the received data packet according to the flow entry: if the destination port of the data packet is 53, the data packet (ie DNS request) is forwarded to OpenFlow controller (b).

Continuing with the example in the above step 1, the flow entry 1 at this time is pre-set by the OpenFlow controller and sent to the OpenFlow switch, and its content is:

matches action item Dst_Port=53 Packet-in

The purpose of sending the DNS request packet to the OpenFlow controller here is to enable the OpenFlow controller to generate new flow entries (i.e. flow entry 2' and 3'), and send the generated new flow table item to the OpenFlow switch, thereby using the new flow table item to forward the DNS request packet to the DNS service device, and the DNS response data generated by the DNS service device The packet is sent back to the terminal.

3. According to the IP header of the received DNS request packet, the OpenFlow controller sends the flow table item for setting the field (Set-field) operation to the OpenFlow switch, so as to realize the DNS request packet and the DNS response packet. Redirect (c), and send the DNS request packet (d) through the uplink port of the OpenFlow switch designated by the Packet-out message.

It is assumed that, in the embodiment of the present invention, the IP address of the independently configured DNS service device is IP _a . And, according to the TCP/IP protocol, the IP header of the data packet contains the source address and the destination address of the data packet, so the IP address of the terminal that sends the request can be determined according to the IP header of the DNS request packet (that is, the source of the DNS request packet address IP _c ) and the IP address of the DNS server that the terminal expects to access (ie, the destination address IP _b of the DNS request data packet).

Accordingly, the following flow entry will be generated to redirect the destination address IP _b of the DNS request packet to the DNS service device IP _a , and the flow entry 2' will be sent to the OpenFlow switch:

matches action item Src_IP= _IPc ,Dst_Port=53 Set-Field: Dst_IP＝IP _a , Output: Uplink port

Using the above flow entry, the uplink port of the OpenFlow switch can be used to send a redirected DNS request packet.

In addition, in order to prevent the terminal from noticing that the DNS service response does not come from the IP address of the DNS server requested by it, another corresponding flow entry can be generated and sent to the OpenFlow switch, so that the DNS response data generated by the DNS service device The source port IP _a of the packet is redirected to the source address IP _b in the DNS request packet. The flow entry 3' generated accordingly should be:

matches action item Dst_IP=IP _a , Src_Port=53 Set-Field: Src_IP＝IP _b , Output: Downlink port

Using the above flow entry, the downlink interface of the OpenFlow switch can be used to send a redirected DNS response data packet.

4. The OpenFlow switch forwards the DNS request packet (e) modified according to the flow entry to the independently configured DNS service device.

Continuing the above example, the source address IP _c of the DNS request packet received by the OpenFlow controller is 192.168.1.1, and the destination address IP _b is 8.8.8.8 (it should be understood that the step of parsing the IP header of the DNS request packet here can also be performed in carried out in step 2). That is, the original DNS request packet sent from the terminal is:

According to the flow entry 2' in step 3, the OpenFlow controller redirects the DNS request packet to the DNS service device, assuming that the IP address IP _a of the DNS service device is 192.168.1.2. At this point, the modified DNS request packet is:

source IP Destination IP source port destination port content 192.168.1.1 192.168.1.2 1234 53 DNS request

5. The DNS service device that is set independently receives the DNS request packet from the OpenFlow controller, and generates a DNS response corresponding to the DNS request received according to the local cache, to send the generated DNS response back to the OpenFlow switch (f ). If the local cache does not have the IP address corresponding to the domain name in the DNS request, a recursive query is made to the Internet, as shown in (i)(ii) in Figure 4.

Continuing with the above example, if there is corresponding information in the local cache or the corresponding information is obtained through recursive query, the DNS service device generates the following DNS response packet:

source IP Destination IP source port destination port content 192.168.1.2 192.168.1.1 53 1234 DNS response

6. The OpenFlow switch sends the DNS response packet from the DNS service device to the terminal (g).

Here, in order to make the terminal not aware that the DNS response is not from the IP address of the requested DNS server, that is, to realize transparent DNS service, the flow entry 3' issued by the OpenFlow controller in step 3 can be used correspondingly, Change the source address IP _a of the DNS response data packet to the address IP _b requested by the terminal.

Continuing with the above example, according to the flow entry, the DNS response packet is modified as:

source IP Destination IP source port destination port content 8.8.8.8 192.168.1.1 53 1234 DNS response

When the OpenFlow switch already has a pair of redirected flow entries (i.e., flow entries 2 and 3) of the corresponding terminal, the subsequent DNS service does not need stages (b, c, d), only stages (a, e, f, g).

In the embodiment of the present invention, a transparent and bypass DNS service technical solution based on OpenFlow is shown. It can be seen that the present invention does not need to connect a device in series on the necessary path for terminal traffic, thereby avoiding the security problems caused by the series connection of devices, and the present invention can also block DNS responses from the Internet to Avoid it competing with DNS responses generated by DNS services.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than limit them. Although the present invention has been described in detail above with reference to the embodiments, those skilled in the art should understand that modifications or equivalent replacements to the technical solutions of the present invention do not depart from the spirit and scope of the technical solutions of the present invention, and all of them should be covered in Within the scope of the claims of the present invention.

Claims (12)

1. a system for local dns service, including:

Terminal, for sending packet to the Internet, comprises DNS request in described packet；

OpenFlow switch, from the DNS request of described terminal and forwards described DNS request for reception；

Local dns service unit, for receiving the described DNS request from described OpenFlow switch, and according to described DNS request generates DNS and responds and be sent to described OpenFlow switch；

Wherein, described OpenFlow switch is additionally operable to be transmitted to described by the DNS received from local dns service unit response Terminal.

System the most according to claim 1, the most also includes:

OpenFlow controller, for issuing stream list item to OpenFlow switch.

System the most according to claim 2, wherein said OpenFlow controller, it is additionally operable to according to described DNS request raw Become the stream list item for revising the source IP that described DNS responds.

System the most according to claim 2, wherein said local dns service unit is integrated in described OpenFlow controller In.

5. according to the system described in Claims 2 or 3, wherein said OpenFlow controller, it is additionally operable to according to described DNS request Generate the stream list item being used for revising purpose IP of described DNS request.

6. according to the system described in Claims 2 or 3, wherein said OpenFlow controller, it is additionally operable to described OpenFlow Switch issues the stream list item for the packet that destination interface is 53 is forwarded to described OpenFlow controller.

7. according to the system described in Claims 2 or 3, wherein said OpenFlow controller, it is additionally operable to described OpenFlow Switch issues the stream list item for the packet that source port is 53 is forwarded to described terminal.

8. a method for local dns based on system described in claim 1 service, including:

1) described OpenFlow switch is according to stream list item, and the DNS request in the entire packet of self terminal sends to institute in the future State local dns service unit；

2) the DNS response generated is sent to described OpenFlow switch by described local dns service unit；

3) described OpenFlow switch is according to stream list item, and described DNS response is forwarded to described terminal.

Method the most according to claim 8, wherein step 3) also include before:

2.5) described OpenFlow switch is according to stream list item, and the source IP responded by described DNS is revised as the mesh of described DNS request IP.

Method the most according to claim 8 or claim 9, wherein step 1) also include before:

Purpose IP of described DNS request, according to stream list item, is revised as described local dns service dress by described OpenFlow switch The IP address put.

11. method according to claim 8 or claim 9, wherein steps 1) including:

The packet that destination interface is 53, according to stream list item, is forwarded to by described OpenFlow switch as described DNS request Described OpenFlow controller.

12. method according to claim 8 or claim 9, wherein steps 3) including:

The packet that source port is 53, according to stream list item, is forwarded to described terminal by described OpenFlow switch.