WO2017163104A1 - Système et procédé de réduction des attaques dns - Google Patents

Système et procédé de réduction des attaques dns Download PDF

Info

Publication number
WO2017163104A1
WO2017163104A1 PCT/IB2016/051590 IB2016051590W WO2017163104A1 WO 2017163104 A1 WO2017163104 A1 WO 2017163104A1 IB 2016051590 W IB2016051590 W IB 2016051590W WO 2017163104 A1 WO2017163104 A1 WO 2017163104A1
Authority
WO
WIPO (PCT)
Prior art keywords
dns
query
tcp
response
packet
Prior art date
Application number
PCT/IB2016/051590
Other languages
English (en)
Inventor
Daniel Migault
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/IB2016/051590 priority Critical patent/WO2017163104A1/fr
Publication of WO2017163104A1 publication Critical patent/WO2017163104A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Definitions

  • This disclosure relates generally to systems and methods for protecting against denial of service type attacks on computer and communication networks.
  • a Denial-of-Service (DoS) attack is an attempt by an attacker to render a machine, network or service unusable by its intended users.
  • An attacker can bombard a target network or server with a large volume of traffic to overload the target's available bandwidth, CPU capacity or other system resources.
  • Such attacks can flood services or crash services to the point where they can no longer serve legitimate requests.
  • a Distributed Denial-of-Service (DDoS) is where the attack originates from multiple sources, often thousands of unique IP addresses.
  • spoofing allows the attacker to falsify the source address in a request for network service. This results in the response to this request being sent to the falsified source address (this is also referred to as "reflection"). This also makes it difficult for the victim network to identify the attacker and to defend itself against attack.
  • attackers leverage amplification, the principle that some network protocols return a large answer to a relatively small request. Amplification is of particular interest to an attacker since a small investment in attack traffic can result in large attack volumes.
  • DNS Domain Name System
  • IP Internet Protocol
  • DNS provides a decentralized database of domain names and their associated information. Specifically, DNS translates domain names to the numerical IP addresses needed for the purpose of locating and identifying computer services and devices with the underlying network protocols.
  • the DNS protocol uses two types of DNS messages, queries and replies. A client sends a query to a DNS server requesting information regarding a specific domain name. The server returns a response containing one or more Resource Records (RR), each of which corresponds to the requested domain name.
  • RR Resource Records
  • DNS servers are a favoured target of DDoS attackers due to the bandwidth amplification aspect associated with the DNS protocol.
  • an attacker will send a large number of simultaneous DNS requests in an attempt to overload the capacity of the DNS server.
  • UDP User Datagram Protocol
  • a method for managing transport layer protocols used in a network can be performed by a guard device.
  • the method includes receiving a first Domain Name Service (DNS) query sent from a client device to a DNS server. Responsive to determining that the first DNS request is received in a User Datagram Protocol (UDP) packet, the method includes sending a DNS response to the client device, the DNS response including a transport indicator indicating to send at least one subsequent DNS query in a Transmission Control Protocol (TCP) packet.
  • DNS Domain Name Service
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • a guard device comprising circuitry including a processor and a memory.
  • the memory contains instructions executable by the processor whereby the guard device is operative to receive a first Domain Name Service (DNS) query sent from a client device to a DNS server. Responsive to determining that the first DNS query is received in a User Datagram Protocol (UDP) packet, the guard device is operative to send a DNS response to the client device, the DNS response including a transport indicator indicating to send at least one subsequent DNS request in a Transmission Control Protocol (TCP) packet.
  • DNS Domain Name Service
  • TCP Transmission Control Protocol
  • the DNS response can include a time indicator indicating a time period to send the at least one subsequent DNS query using TCP.
  • the DNS response can further include a resource indicator indicating that the DNS response includes no resource record.
  • the DNS response can further include a truncation indicator indicating that the DNS response is not truncated.
  • the guard device responsive to sending the DNS response including the transport indicator, can receive the first DNS query resent in a TCP packet.
  • the guard device can receive a second DNS query sent from the client device to the DNS server and, responsive to determining that the second DNS query is received in a TCP packet, forward the second DNS query to the DNS server.
  • the transport indicator can be included in an EDNS0 option in the DNS response.
  • the guard device can monitor an IP address associated with the first DNS query sent from the client device. Responsive to determining that there is no TCP session associated with the IP address, the guard device can filter traffic originating from the IP address.
  • a method for managing transport layer protocols used in a network can be performed by a client device.
  • the method includes sending a first Domain Name Service (DNS) query in a User Datagram Protocol (UDP) packet to a DNS server.
  • DNS Domain Name Service
  • UDP User Datagram Protocol
  • a DNS response is received from a guard device, the DNS response including a transport indicator indicating to send at least one subsequent DNS query using Transmission Control Protocol (TCP).
  • TCP Transmission Control Protocol
  • a client device comprising circuitry including a processor and a memory.
  • the memory contains instructions executable by the processor whereby the client device is operative to send a first Domain Name Service (DNS) query in a User Datagram Protocol (UDP) packet to a DNS server.
  • DNS Domain Name Service
  • UDP User Datagram Protocol
  • the client device is operative to receive a DNS response from a guard, the DNS response including a transport indicator indicating to send at least one subsequent DNS query using Transmission Control Protocol (TCP), and to resend the first DNS query to the DNS server in a TCP packet.
  • TCP Transmission Control Protocol
  • the client device responsive to receiving the DNS response including the transport indicator, can send a second DNS query in a TCP packet.
  • the second DNS query can be sent in a TCP packet without a prior sending of the second DNS query in a UDP packet.
  • the DNS response can includes a time indicator indicating a time period to use TCP for sending the at least one subsequent DNS query to the DNS server.
  • a second DNS query can be sent in a TCP packet in accordance with the time indicator.
  • the DNS response can further include a resource indicator indicating that the DNS response includes no resource record.
  • the DNS response can further include a truncation indicator indicating that the DNS response is not truncated.
  • FIG. 1 illustrates a conventional method for switching DNS traffic from
  • Figure 2 is a block diagram of a communication network
  • Figure 3 is a signaling diagram illustrating a method for switching DNS traffic from UDP to TCP ;
  • Figure 4a illustrates a header section of a DNS message
  • Figure 4b illustrates a resource record of a DNS response
  • Figure 4c illustrates an EDNS0 option message format
  • Figure 5 is a flow chart illustrating a method for managing transport layer protocols used in a network:
  • Figure 6 is a flow chart illustrating a method for switching transport layer protocols used in a network
  • Figure 7 is a block diagram of a network device
  • Figure 8 is a block diagram of an example guard device
  • Figure 9 is a block diagram of an example client device.
  • Embodiments of the present disclosure are directed to mechanisms for switching the transport layer protocol of DNS traffic from UDP to Transport Control Protocol (TCP) as an attack mitigation service.
  • TCP Transport Control Protocol
  • DNS packets can also be carried over TCP connections.
  • IETF RFC 1123 and RFC 5966 define capabilities for DNS servers, caches and forwarders to convey DNS packets over TCP.
  • TCP for DNS message exchange was initially considered in order to overcome the 512 byte limit for a DNS response.
  • size of DNS responses has increased over time, it was recommended to use a more reliable transport layer than UDP.
  • switching from UDP to TCP for DNS traffic is commonly employed in the particular scenario when a response exceeds the 512 byte limit.
  • Figure 1 illustrates a conventional method for switching DNS traffic from
  • DNS client 100 sends a DNS request 104 over UDP to DNS server 104.
  • DNS server 104 determines that the response will exceed 512 bytes, so it truncates the response to fit within that limit, sets the TC (Truncation) flag in the header, and sends a truncated DNS reply 106.
  • the DNS client 100 receives response 106, it takes the TC flag as an indication that it should retry the DNS request over TCP. Accordingly, DNS client 100 resends its DNS request over TCP as request 108.
  • the DNS server 102 returns a DNS reply 100 using TCP.
  • TCP connection (or session) is established between the client 100 and server 102.
  • the server 102 Upon receiving request 108 over the TCP connection, the server 102 can be assured that source IP address of the client 100 is legitimate, and returns an appropriate DNS response 110 over the existing TCP connection. The TCP connection is then closed.
  • UDP remains the conventional transport protocol used for DNS queries as it has a much lower overhead (in packet size and connection state) than TCP.
  • the DNS response is limited to 512 bytes, it can still result in a significant reflection factor in a DoS or DDoS attack. Any response lower than 512 bytes will not trigger a switch to TCP, as the TC bit mechanism does not apply to responses within the 512 byte limit. As such, the source of the DNS request cannot be verified. Therefore, the conventional method for switching DNS traffic from UDP to TCP is not sufficient for mitigating attacks.
  • FIG. 2 is a block diagram of a communication network according to embodiments of the present invention.
  • a DNS server 206 communicates with at least one DNS client device 202 via network 200, which can be a wide area network such as the Internet.
  • Guard device 204 can be a middlebox, such as a DNS proxy or network function, configured to protect against potential attacks on DNS server 206.
  • Guard 204 can be configured to intercept some, or all, traffic destined for DNS server 206.
  • guard 204 can be a functional module included in the DNS server 206 itself.
  • Guard device 204 can be a network function such as a virtualized network function.
  • Figure 3 illustrates a method for switching DNS traffic from UDP to TCP.
  • Client 202 transmits a first DNS Request 210 using UDP towards DNS server 206.
  • the request 210 is intercepted and received by guard 204.
  • Guard device 204 returns a DNS reply message 212 to the client 202.
  • guard 204 can send reply 212 on behalf of the DNS server 206.
  • DNS reply 212 can include an indication that DNS client 202 should use TCP for transmitting at least one subsequent DNS query.
  • DNS reply 212 can further include an indication of a period of time that DNS client 202 should utilize TCP for DNS queries.
  • guard device 204 does have access to the database of DNS information accessible by the DNS server 206. In this scenario, guard 204 cannot add truncated DNS information to its response, similar to as was described with respect to Figure 1.
  • Guard 204 can be configured to compose a "void" DNS reply 212 that carries no resource record information in the composed message.
  • DNS reply 212 can comprise only a DNS header with no resource record(s).
  • DNS reply 212 can comprise a DNS header and a resource record that carries no actual DNS data.
  • DNS client 202 receives and processes the reply 212.
  • the DNS client 202 can perform a TCP handshake with the guard 204 and/or the DNS server 206 responsive to receiving the instruction to use TCP as transport layer protocol.
  • the client 202 re-sends the first DNS request using TCP as message 216.
  • request 214 can be intercepted by guard device 204 and forwarded to the DNS server 206.
  • guard 204 only intercepts UDP traffic and allows TCP traffic to pass directly to the DNS server 206.
  • DNS server 206 returns DNS reply 216 using TCP.
  • DNS client 202 sends a second, subsequent DNS request 218 to the DNS Server 206 using TCP.
  • This second DNS request 218 can be sent immediately using TCP, without first attempting to send via UDP.
  • DNS client 202 can verify the specified time period for using TCP prior to sending the second request 218.
  • DNS protocol messages may be beneficial in describing embodiments of the present invention.
  • the DNS protocol uses two types of DNS messages, queries and replies, and they both have the same format.
  • a DNS message includes a header and four sections: question, answer, authority, and an additional space. Header fields (e.g. flags) control the content of these four sections.
  • the question section contains the domain name and type of record to be resolved.
  • the answer section carries the resource record(s) of the queried name.
  • a domain name may occur in multiple records if it has multiple IP addresses associated with it.
  • Figure 4a illustrates a header section 300 of a DNS message.
  • the ID field is a 16 bit identifier assigned by the application and/or device that generates a query. This identifier is included in the corresponding reply and can be used to match up replies with outstanding queries.
  • the QR field specifies whether the message is a query (0) or a response (1).
  • OPCODE is a four bit field specifying the type of query in the message
  • the AA field is the Authoritative Answer, valid only in responses to specify that the responding name server is an authority for the domain name in question.
  • the TC (Truncation) field specifies that the message has been truncated due to having a length greater than that permitted on the transmission channel (e.g. 512 bytes for a UDP packet).
  • the RD (Recursion Desired) field is an optional bit that can be set in a query and copied into the response. When set, it directs the name server to pursue the query recursively.
  • the RA (Recursion Available) bit is set or cleared in a response to denote whether recursive query support is available in the name server.
  • the Z field is reserved for future use.
  • RCODE Response code
  • QDCOUNT is an unsigned 16 bit integer specifying the number of entries in the question section.
  • ANCOUNT is an unsigned 16 bit integer specifying the number of resource records in the answer section.
  • NSCOUNT is an unsigned 16 bit integer specifying the number of name server resource records in the authority records section.
  • ARCOUNT is an unsigned 16 bit integer specifying the number of resource records in the additional records section.
  • Figure 4b illustrates a resource record 310 of a DNS response.
  • the answer, authority, and additional sections of DNS messages all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header.
  • the NAME field specifies a domain name to which the resource record pertains.
  • the TYPE field specifies the meaning of the data in the RDATA field.
  • CLASS specifies the class of the data in the RDATA field.
  • TTL Time to Live
  • RDLENGTH specifies the length of the RDATA field.
  • RDATA is the field used to describe the resource.
  • the format of this information varies according to the TYPE and CLASS of the resource record. For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address.
  • the information carried in the RDATA field can include a domain name, an IPv4 or IPv6 address, as well as key and signature information.
  • EDNS0 adds information to DNS messages in the form of "pseudo-resource-records" included in the "additional data" section of a DNS message.
  • the mechanism is backward compatible, because older DNS responders can ignore any resource records of an unknown OPT type in a request and a newer DNS responder will not include an OPT in a response unless there was one in the request.
  • Figure 4c illustrates an EDNS0 option message 320 format.
  • CODE is to be assigned by I AN A.
  • the OPTION-LENGTH specifies the size of the OPTION-DATA.
  • the OPTION-DATA varies as per the OPTION-CODE, but must be treated as a bit field.
  • an EDNSO option can be used to define an attribute value pair to explicitly signal that TCP should be used as the transport protocol (e.g. as opposed to UDP) for DNS queries.
  • OPTION- CODE can be defined as SWICTH TO_TCP and OPTION-DATA can be defined as SWITCHING_TIME, a 32 bit integer that designates the time (in seconds) for which the DNS client is instructed to use TCP for sending DNS queries.
  • guard 204 receives a DNS query such as request 210. Upon determining that the DNS query was received in a UDP packet, guard 204 can generate a DNS response for return to the client 202.
  • the header section of the DNS response can be configured as follows.
  • the received DNS query can first be copied into the DNS response.
  • the QR field can then be set to 1 to indicate it is a response message.
  • the OPCODE field can remain unchanged.
  • the AA bit can set to 1 to indicate Authoritative server.
  • the RD field can remain unchanged.
  • the RA field can be set to 0.
  • the RCODE field can be set to 0.
  • the QDCOUNT can remain unchanged.
  • Each of the ANSCOUNT, NSCOUNT and ARCOUNT fields can be set to
  • the question section of the request can be copied into the response message.
  • a SWITCH TO TCP EDNSO option can be added to the response message.
  • the source port and destination port from the request can be inverted.
  • UDP length and checksum can be converted.
  • the source IP address and destination IP addresses from the request can also be inverted.
  • the composed DNS response can then be sent from guard 204 to client 202, such as, for example, DNS reply 212.
  • the generated DNS response can be considered to be a DNS response having no ANSWER, AUTHORITATIVE or ADDITIONAL section.
  • An EDNSO option can be added to include an explicit indication that the client 202 should use TCP for sending DNS queries.
  • the EDNSO can be used to convey additional information associated with the transport layer protocol to the client device 202.
  • DNS client 202 will consider the incoming packet as a response to its previously sent query. As the response does not carry the requested information, the DNS client 202 will switch to TCP and re-send the initial DNS query.
  • the response includes a SWITCH TO TCP EDNSO option, there may be additional information or parameters included.
  • a period of time may be specified for the client 202 to use TCP for subsequent DNS queries, such as, for example, DNS request 218. During this time period, the client 202 is expected to not send any DNS queries over UDP.
  • a particular DNS client or resolver may not implement the SWITCH TO TCP EDNSO option.
  • the expected behavior is that such a DNS client will simply ignore the option and operate as usual (e.g. a DNS query will be first sent over UDP and then be re-sent over TCP).
  • the DNS response from the guard 204 may be interpreted as an error by the client device, as it does not actually resolve the query.
  • the guard device 204 can set the TC bit and, optionally, add a resource record to the response such that the packet size of the response reaches 512 bytes. The client device can then switch to TCP as per the conventional methodology.
  • guard 204 can be further configured to detect IP address spoofing. As any DNS query originally sent over UDP will be quickly re-sent over TCP, the guard can be used to detect spoofed IP addresses and ban any future traffic generated by this IP address. Guard 204 can collect the IP source address from a received UDP packet. Guard 204 can then monitor for any TCP session(s) associate with this IP address. If there is a TCP session observed using this address, it can be assumed that it is likely a legitimate IP address. If there are no TCP sessions observed using this address, it can be assumed that it is likely a spoofed IP address. Traffic originating from this IP address can then be blocked or filtered by the guard device 204.
  • Figure 5 is a flow chart illustrating a method for managing transport layer protocols used in a communication network.
  • the method of Figure 5 can be implemented by a guard device as has been described herein.
  • the method begins by the guard receiving a first DNS query sent from a client device to a DNS server (block 400).
  • the step of receiving can include intercepting DNS queries addressed to the DNS server.
  • the transport layer protocol of the received DNS query can be determined. It is determined that the first DNS request was received in a UDP packet (block 410).
  • the guard device can be configured to only intercept DNS queries sent via UDP.
  • a DNS response is sent to the client device including an indication that the client device should use TCP as its transport layer protocol for sending at least one subsequent DNS query (block 420).
  • the guard can generate the DNS response message including an explicit transport indicator/instruction indicating for the client device to switch to TCP.
  • the transport indicator can be included in an EDNS0 option in the DNS response.
  • the DNS response can further include a time indicator specifying how long the DNS client is to remain using TCP for subsequent DNS queries.
  • the time indicator can be expressed as a time period, a counter, a timestamp or a TTL value, for example.
  • the time indicator can also be included in an EDNS0 option in the DNS response.
  • the DNS response can further include an indication that there is no resource record(s) included in the DNS response. This can be indicated in the ANCOUNT, NSCOUNT and/or ARCOUNT fields.
  • the DNS response may include an "empty" resource record carrying no DNS information in its RDATA field.
  • the DNS response can further include an indication that the DNS response is not a truncated response.
  • the guard responsive to receiving the indicator to send subsequent DNS queries using TCP, can receive the first DNS query, resent from the client to the DNS server in a TCP packet.
  • the guard can receive/intercept a second DNS query sent from the client device to the DNS server. Responsive to determining that the second DNS query was received in a TCP packet, the guard can forward the second DNS query to the DNS server. [0081] In some embodiments, the guard can implement an IP address spoof detection procedure. An IP address associated with the first DNS query received from the client device can be determined and monitored for a period of time. Responsive to determining that there are no TCP sessions associated with that IP address, any traffic originating from the IP address can be filtered or blocked.
  • Figure 6 is a flow chart illustrating a method for switching transport layer protocols used in a network. The method of Figure 6 can be implemented by a client device as has been described herein.
  • the method begins by sending a first DNS query in a UDP packet to a DNS server (block 450).
  • a DNS response is received, from a guard, including a transport indicator indicating to the client device to use TCP as its transport layer protocol for sending at least one subsequent DNS query (block 460).
  • the received DNS response further includes a time indicator specifying a period of time for the client device to use TCP for sending any subsequent DNS queries.
  • the indication to use TCP and/or the time period information can be contained in an EDNS0 option included in the received DNS response.
  • the received DNS response can further include an indication that the DNS response carries no resource record(s).
  • the DNS response may include an empty resource record.
  • the received DNS response can further include an indication that the DNS response is not a truncated response.
  • the client device Responsive to receiving the DNS response from the guard, the client device resends the first DNS query to the DNS server in a TCP packet (block 470).
  • the client device is configured to check the time period specified by the time indicator and, accordingly, if the time period is valid, to send a second DNS query to the DNS server in a TCP packet.
  • the second DNS query can be sent in a TCP packet without a prior sending of the second DNS query in a UDP packet.
  • the DNS response message that is sent from the guard device to the client device can include a variety of information indicators.
  • the indicators can be implemented as flags, fields or extensions included in the DNS response, for example.
  • a first type of indicator is a transport indicator indicating to the client device to use TCP for sending at least one subsequent DNS query.
  • the transport indicator can be included in an ENDSO option in the message.
  • a second type of indicator is a time indicator indicating of a period of time for which the client device is to use TCP for sending the subsequent DNS query(ies).
  • the time indicator can also be included in an ENDSO option in the message.
  • a third type of indicator is a resource indicator indicating that there is no resource record(s) included in the DNS response message.
  • the resource indicator can be included in one or more of the ANCOUNT, NSCOUNT, and/or ARCOUNT header fields of the DNS response.
  • a fourth type of indicator is a truncation indicator indicating that the DNS response is not truncated.
  • the truncation indicator can be included in the TC header field of the DNS response.
  • FIG. 7 is a block diagram illustrating an example network device 500 according to embodiments of the present invention.
  • Network device 500 can be any of the guard, DNS client device or DNS server nodes as have been described herein.
  • the network device 500 includes circuitry including a processor 502, a memory or instruction repository 504 and a communication interface 506.
  • the communication interface 506 can include at least one input port and at least one output port.
  • the memory 504 contains instructions executable by the processor 502 whereby the network device 500 is operable to perform the various embodiments as described herein.
  • the network device 500 can included virtualized components hosted by the underlying physical hardware.
  • Network device 500 can be configured to implement any of the methods and procedures illustrated in Figures 1 - 6.
  • device 500 When operative as a guard device, device 500 is configured to receive/intercept a first DNS query sent from a client device to a DNS server. Responsive to determining that the first DNS query is received in a packet, device 500 is configured to send a DNS response to the client. The DNS response can be generated to include a transport indicator indicating to send at least one subsequent DNS request in a TCP packet. In some embodiments, guard 500 can be included as a functional module in a DNS server. [0091] When operative as a client device, device 500 is configured to send a first DNS query sent from a client device to a DNS server. Responsive to determining that the first DNS query is received in a packet, device 500 is configured to send a DNS response to the client. The DNS response can be generated to include a transport indicator indicating to send at least one subsequent DNS request in a TCP packet. In some embodiments, guard 500 can be included as a functional module in a DNS server. [0091] When operative as a client device, device 500
  • Device 500 receives a DNS response from a guard, wherein the DNS response includes a transport indicator indicating to send at least one subsequent DNS query using TCP. Responsive to receiving the DNS response from the guard, device 500 resends the first DNS query to the DNS server in a TCP packet.
  • FIG. 8 is a block diagram of an example guard device 520 according to embodiments of the present invention.
  • Guard device 520 includes a DNS query interception module 522 and a DNS response generation module 524.
  • the DNS query interception module 522 is configured for receiving a first DNS query sent from a client device to a DNS server.
  • the DNS response generation module 524 is configured for, responsive to determining that the first DNS request is received in a UDP packet, sending a DNS response to the client device, the DNS response including a transport indicator indicating to send at least one subsequent DNS query in a TCP packet.
  • FIG. 9 is a block diagram of an example client device 540 according to embodiments of the present invention.
  • Client device 540 includes a DNS query transmission module 542 and a transport protocol management module 544.
  • the DNS query transmission module 542 is configured for sending a first DNS query in a UDP packet to a DNS server.
  • the transport protocol management module 544 is configured for receiving a DNS response from a guard device, the DNS response including a transport indicator indicating to send at least one subsequent DNS query using TCP.
  • the transport protocol management module 544 is further configured for instructing the DNS query transmission module 542 to resend the first DNS query to the DNS server in a TCP packet.
  • Embodiments of the present invention may be represented as a software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein).
  • the non-transitory machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism.
  • the machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to an embodiment of the invention.
  • Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described invention may also be stored on the machine-readable medium.
  • Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

Abstract

La présente invention concerne des systèmes et des procédés permettant de réduire les attaques de type déni de service sur des serveurs de système de noms de domaine (DNS). Un dispositif de protection peut intercepter une requête DNS envoyée par un dispositif client à un serveur DNS. En réponse à la détermination que la requête DNS a été envoyée dans un paquet de protocole de datagramme d'utilisateur (UDP), le dispositif de protection peut envoyer une réponse DNS au dispositif client indiquant d'utiliser un protocole de commande de transmission (TCP) pour envoyer des requêtes DNS ultérieures.
PCT/IB2016/051590 2016-03-21 2016-03-21 Système et procédé de réduction des attaques dns WO2017163104A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2016/051590 WO2017163104A1 (fr) 2016-03-21 2016-03-21 Système et procédé de réduction des attaques dns

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2016/051590 WO2017163104A1 (fr) 2016-03-21 2016-03-21 Système et procédé de réduction des attaques dns

Publications (1)

Publication Number Publication Date
WO2017163104A1 true WO2017163104A1 (fr) 2017-09-28

Family

ID=55640793

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/051590 WO2017163104A1 (fr) 2016-03-21 2016-03-21 Système et procédé de réduction des attaques dns

Country Status (1)

Country Link
WO (1) WO2017163104A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210044678A1 (en) * 2019-08-09 2021-02-11 Cisco Technology, Inc. Optimized quic fallback on access networks and endpoints
CN115296904A (zh) * 2022-08-03 2022-11-04 中国电信股份有限公司 域名反射攻击检测方法及装置、电子设备、存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044352A1 (en) * 2001-08-30 2005-02-24 Riverhead Networks, Inc. Protecting against spoofed DNS messages
US20140344925A1 (en) * 2013-05-15 2014-11-20 Citrix Systems, Inc. Systems and methods for reducing denial of service attacks against dynamically generated next secure records

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044352A1 (en) * 2001-08-30 2005-02-24 Riverhead Networks, Inc. Protecting against spoofed DNS messages
US20140344925A1 (en) * 2013-05-15 2014-11-20 Citrix Systems, Inc. Systems and methods for reducing denial of service attacks against dynamically generated next secure records

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210044678A1 (en) * 2019-08-09 2021-02-11 Cisco Technology, Inc. Optimized quic fallback on access networks and endpoints
CN115296904A (zh) * 2022-08-03 2022-11-04 中国电信股份有限公司 域名反射攻击检测方法及装置、电子设备、存储介质
CN115296904B (zh) * 2022-08-03 2023-10-27 中国电信股份有限公司 域名反射攻击检测方法及装置、电子设备、存储介质

Similar Documents

Publication Publication Date Title
EP3204857B1 (fr) Appareil et procédé pour identifier une tunnélisation, une exfiltration et une infiltration de système d'adressage par domaines
US20230336577A1 (en) Malware detection for proxy server networks
US8661544B2 (en) Detecting botnets
CN114095198B (zh) 用于网络安全应用的高效加密sni过滤的方法和系统
CN109474575B (zh) 一种dns隧道的检测方法及装置
Brownlee et al. DNS measurements at a root server
US8918875B2 (en) System and method for ARP anti-spoofing security
Guo et al. Spoof detection for preventing dos attacks against dns servers
JP2013501466A (ja) ネットワークトラフィックのフィルタリングのための方法およびシステム
US20170264590A1 (en) Preventing dns cache poisoning
US20240022596A1 (en) Malicious C&C channel to fixed IP detection
EP2557759A1 (fr) Construction d'une liste blanche des clients DNS les plus actives
US20220174072A1 (en) Data Processing Method and Device
WO2022235373A1 (fr) Procédés, systèmes et supports lisibles par ordinateur pour cacher des identifiants d'instance de fonction de réseau
Simpson TCP cookie transactions (TCPCT)
Sommese et al. Investigating the impact of DDoS attacks on DNS infrastructure
CN113329039B (zh) 一种缓存污染检测方法、装置、电子设备和存储介质
Kosek et al. Measuring DNS over TCP in the Era of increasing DNS Response Sizes: A View from the Edge
WO2017163104A1 (fr) Système et procédé de réduction des attaques dns
US11658995B1 (en) Methods for dynamically mitigating network attacks and devices thereof
CN111431942B (zh) 一种cc攻击的检测方法、装置及网络设备
Chatzis Motivation for behaviour-based DNS security: A taxonomy of DNS-related internet threats
Arjmandpanah‐Kalat et al. Design and performance analysis of an efficient single flow IP traceback technique in the AS level
US20230231873A1 (en) Slowing requests from malicious network clients
Kristoff et al. RFC 9210: DNS Transport over TCP-Operational Requirements

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16712524

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16712524

Country of ref document: EP

Kind code of ref document: A1