WO2023164314A2

WO2023164314A2 - Method of obtaining and using tunneling information for packets in a computer network

Info

Publication number: WO2023164314A2
Application number: PCT/US2023/023645
Authority: WO
Inventors: Iii Donald E. Eastlake; Haoyu Song
Original assignee: Futurewei Technologies, Inc.
Priority date: 2022-05-27
Filing date: 2023-05-26
Publication date: 2023-08-31
Also published as: WO2023164314A3

Abstract

A method performed by a DNS server to provide tunneling information. The method includes the DNS server receiving a DNS query for a TUNNEL RR corresponding to a DNS name. The TUNNEL RR includes the tunneling information used to encapsulate a packet. The DNS server determines whether data corresponding to the DNS name includes the TUNNEL RR in response to receiving the DNS query. The DNS server transmits a DNS response that includes the TUNNEL RR when the data corresponding to the DNS name includes the TUNNEL RR.

Description

Method of Obtaining and Using Tunneling Information for Packets in a Computer Network

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional application 63/346,728 filed on May 27, 2022, by Futurewei Technologies, Inc., and titled “Obtaining and Using Tunneling Information for Packets in a Computer Network,” which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

[0002] The present disclosure is generally related to network communications, and in particular to techniques for obtaining and using tunneling information for packets in a computer network.

BACKGROUND

[0003] The Domain Name System (DNS) is a hierarchical, distributed, highly available database with a variety of security features used for bi-directional mapping between domain names and addresses, for electronic mail (email) routing, and for other information as described in Internet Engineering Task Force (IETF) document Request for Comments (RFCs) including RFC 1034 entitled “Domain Names - Concepts And Facilities” by P. Mockapetris, published November 1987 (RFC 1034), and in a companion IETF document RFC 1035 entitled “Domain Names - Implementation And Specification” by P. Mockapetris, published November 1987 (RFC 1035). DNS terminology is defined in IETF document RFC 8499 entitled “DNS Terminology” by P. Hoffman, published lanuary 2019 (RFC 8499). [0004] DNS data is formatted/stored into resource records (RRs) whose content type and structure are indicated by an RR Type field. Some currently defined RRs contain an address such as an Internet Protocol (IP) version 6 (IPv6) address defined in IETF document RFC 8200 entitled “Internet Protocol, Version 6 (IPv6) Specification” by S. Deering, published July 2017 (RFC 8200), IP version 4 (IPv4) address defined in IETF document RFC 791 entitled “Internet Protocol” by the Defense Advanced Research Projects Agency (DARPA) published September 1981 (RFC 791), MAC address defined in IETF document RFC 7043 entitled “Resource Records for EUI-48 and EUI-64 Addresses in the DNS” by J. Abley, published October 2013 (RFC 7043), or other types of addresses. IETF document RFC 2782 entitled “A DNS RR for specifying the location of services (DNS SRV)” by A. Gulbrandsen, published February 2000 (RFC 2782) provides a port number for specifying the location of services. A DNS Service Binding (SVCB) RR defined in IETF document draft-ietf-dnsop-svcb-https-11 entitled “Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)” by B. Schwartz, dated 10 October 2022 (Schwartz) extends RFC 2782 by providing additional extensible connection parameters (e.g., transport protocol configuration and keys for encrypting a Transport Layer Security (TLS) ClientHello).

SUMMARY

[0005] A first aspect relates to a method performed by a Domain Name System (DNS) server. The method includes receiving, from a client device, a DNS query for a TUNNEL resource record (RR) corresponding to a DNS name, wherein the TUNNEL RR comprises tunneling information used to encapsulate a packet; determining whether data corresponding to the DNS name comprises the TUNNEL RR in response to receiving the DNS query; and [0006] transmitting, to the client device, a DNS response, wherein the DNS response comprises the TUNNEL RR when the data comprises the TUNNEL RR.

[0007] Optionally, in a first implementation according to the first aspect, the DNS response indicates an error when the DNS name is not found or when the data does not comprise the TUNNEL RR.

[0008] Optionally, in a second implementation according to the first aspect or any implementation thereof, the TUNNEL RR comprises a priority field indicating a priority of using a tunnel specified in the TUNNEL RR to a target.

[0009] Optionally, in a third implementation according to the first aspect or any implementation thereof, the TUNNEL RR further comprises a tunnel type, a tunnel parameters length, tunnel parameters type-length-values (TLVs), and a target name.

[0010] Optionally, in a fourth implementation according to the first aspect or any implementation thereof, the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs.

[0011] Optionally, in a fifth implementation according to the first aspect or any implementation thereof, the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

[0012] Optionally, in a sixth implementation according to the first aspect or any implementation thereof, the target name is an uncompressed domain name of an ultimate destination node.

[0013] A second aspect relates to a method performed by a DNS server. The method includes receiving, from a client device, a DNS query for a Service Binding (SVCB) RR corresponding to a DNS name; determining whether data corresponding to the DNS name comprises the SVCB RR in response to receiving the DNS query; and transmitting, to the client device, a DNS response, wherein the DNS response comprises the SVCB RR when the data comprises the SVCB RR, and wherein the SVCB RR comprises tunneling information used to encapsulate a packet.

[0014] Optionally, in a first implementation according to the second aspect, the DNS response indicates an error when the DNS name is not found or when the data does not comprise the SVCB RR.

[0015] Optionally, in a second implementation according to the second aspect or any implementation thereof, the SVCB RR comprises a tunnel service parameter that carries the tunneling information.

[0016] Optionally, in a third implementation according to the second aspect or any implementation thereof, the tunnel service parameter comprises a tunnel type, a tunnel parameters length, and tunnel parameters TLVs that specifies a value for a SvcParam Value parameter of the tunnel service parameter.

[0017] Optionally, in a fourth implementation according to the second aspect or any implementation thereof, the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs specifying tunneling parameters.

[0018] Optionally, in a fifth implementation according to the second aspect or any implementation thereof, the tunneling information comprises tunnel egress endpoint, differentiated services field, and UDP destination port.

[0019] A third aspect relates to a method performed by a client device. The method includes transmitting a DNS query for a TUNNEL RR corresponding to a DNS name; receiving a DNS response to the DNS query; determining whether the DNS response comprises the TUNNEL RR; inserting, when the DNS response comprises the TUNNEL RR, tunneling information from the TUNNEL RR into one or more headers of a first packet that encapsulates a second packet; and transmitting the first packet towards a destination node.

[0020] Optionally, in a first implementation according to the third aspect, the DNS response indicates an error when the DNS name is not found or when data corresponding to the DNS name does not comprise the TUNNEL RR.

[0021] Optionally, in a second implementation according to the third aspect or any implementation thereof, the TUNNEL RR comprises a priority field indicating a priority of using a tunnel specified in the TUNNEL RR to a target.

[0022] Optionally, in a third implementation according to the third aspect or any implementation thereof, the DNS query comprises a query type code corresponding to a TUNNEL RR type.

[0023] Optionally, in a fourth implementation according to the third aspect or any implementation thereof, the TUNNEL RR further comprises a tunnel type, a tunnel parameters length, tunnel parameters TLVs, and a target name.

[0024] Optionally, in a fifth implementation according to the third aspect or any implementation thereof, the tunneling information comprises a tunnel egress endpoint, a differentiated services field, or a UDP destination port.

[0025] Afourth aspect relates to a method performed by a client device. The method includes transmitting a DNS query for a SVCB RR corresponding to a DNS name; receiving a DNS response to the DNS query; determining whether the DNS response comprises tunneling information; inserting, when the DNS response comprises the tunneling information, the tunneling information into one or more headers of a first packet that encapsulates a second packet; and transmitting the first packet towards a destination node. [0026] Optionally, in a first implementation according to the fourth aspect, the DNS response indicates an error when the DNS name is not found or when data corresponding to the DNS name does not comprise the SVCB RR.

[0027] Optionally, in a second implementation according to the fourth aspect or any implementation thereof, the SVCB RR comprises a tunnel service parameter that carries the tunneling information.

[0028] Optionally, in a third implementation according to the fourth aspect or any implementation thereof, the tunnel service parameter comprises a tunnel type, a tunnel parameters length, and tunnel parameters TLVs that specifies a value for a SvcParam Value parameter of the tunnel service parameter.

[0029] Optionally, in a fourth implementation according to the fourth aspect or any implementation thereof, the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs specifying tunneling parameters.

[0030] Optionally, in a fifth implementation according to the fourth aspect or any implementation thereof, the tunneling information comprises a tunnel egress endpoint, a differentiated services field, or a UDP destination port.

[0031] A fifth aspect relates to a DNS server comprising a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the DNS server to perform the method according to the first aspect, the second aspect, or any implementation thereof.

[0032] A sixth aspect relates to a client device comprising a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the client device to perform the method according to the third aspect, the fourth aspect, or any implementation thereof.

[0033] A seventh aspect relates to a computer program product comprising computerexecutable instructions stored on a non-transitory computer-readable storage medium, the computer-executable instructions when executed by a processor of an apparatus, cause the apparatus to perform the method according to any of the preceding aspects or any implementation thereof.

BRIEF DESCRIPTION OF DRAWINGS

[0034] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0035] FIG. 1 illustrates a packet that encapsulates another packet for tunneling according to an embodiment of the present disclosure.

[0036] FIG. 2 is a schematic diagram illustrating a network according to an embodiment of the present disclosure.

[0037] FIG. 3 is a schematic diagram illustrating a DNS message format according to an embodiment of the present disclosure.

[0038] FIG. 4 is a schematic diagram illustrating a header format of a DNS query or a DNS response according to an embodiment of the present disclosure.

[0039] FIG. 5 is a schematic diagram illustrating a question format of a DNS query or a DNS response according to an embodiment of the present disclosure.

[0040] FIG. 6 is a schematic diagram illustrating an RR format according to an embodiment of the present disclosure. [0041] FIG. 7 is a schematic diagram illustrating a TUNNEL RR type data format according to an embodiment of the present disclosure.

[0042] FIG. 8 illustrates a SVCB tunnel service parameter according to an embodiment of the present disclosure.

[0043] FIG. 9 is a flowchart illustrating a method for obtaining tunneling information from the DNS according to an embodiment of the present disclosure.

[0044] FIG. 10 is a flowchart illustrating a method for providing tunneling information according to an embodiment of the present disclosure.

[0045] FIG. 11 is a schematic diagram of an apparatus according to an embodiment of the present disclosure.

DESCRIPTION OF EMBODIMENTS

[0046] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents. In the present disclosure, path and tree, branch and sub-tree, node number and node index, leaf and egress are used interchangeably.

[0047] The present disclosure provides techniques for obtaining and using tunneling information for packets in a computer network. In network communications, tunneling refers to a technique used to encapsulate one network protocol within another network protocol. Tunneling allows the transmission of network traffic between two endpoints through a tunnel over a network that may not support the encapsulated protocol directly. A tunnel is a virtual pathway established within a public or shared network infrastructure which may also provide security. Tunnels can be established using various protocols, such as Internet Protocol Security (IPsec), Secure Sockets Layer/Transport Layer Security (SSL/TLS), Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and others. These protocols define the mechanisms for encapsulating the data packets, and in some cases encrypting and authenticating them to ensure secure communication between the tunnel endpoints. When data is encapsulated, the data is placed inside a new packet that has a new/different outer protocol header. This new packet can then be transmitted over a network that understands and supports the outer protocol. Later in the path, to or at its destination, the packet is decapsulated, and the original data is extracted and processed.

[0048] Tunneling is commonly used in situations where two networks with different protocols need to communicate with each other. Thus, tunneling provides a way to “tunnel” traffic from one network through another network, even if the intermediate network does not natively support the protocol being transmitted. Tunneling can also add outer labeling and/or provide for security. [0049] FIG. 1 illustrates a packet 100 that encapsulates another packet for tunneling according to an embodiment of the present disclosure. The packet 100 includes an outer transport header 102, a tunneling header 104, an inner transport header 106, and a tunneled/encapsulated packet 108. The tunneled/encapsulated packet 108 is the packet being tunneled/encapsulated (i.e., the original packet).

[0050] The outer transport header 102 contains the addressing and control information used for routing the packet 100 between the tunnel endpoints. The format and contents of the outer transport header 102 depend on the specific tunneling protocol being used. For example, in IP- in-TP (TP encapsulation within TP) tunneling, the outer transport header 102 is an TP header that includes source and destination IP addresses, as well as protocol information.

[0051] The tunneling header 104 contains the necessary information to differentiate the tunneled/encapsulated packet 108 from the packet 100 and allow proper decapsulation at the receiving end of the tunnel. The format and contents of the tunneling header 104 also depend on the tunneling protocol being used. For example, in protocols like Generic Routing Encapsulation (GRE), the tunneling header 104 includes fields such as the protocol type being encapsulated, sequence numbers, and additional control information. In some cases, such as IP-in-IP, the tunneling header 104 may be null.

[0052] The inner transport header 106 is the original transport layer header of the tunneled/encapsulated packet 108. The inner transport header 106 may include source and destination port numbers, sequence numbers, acknowledgment numbers, and other relevant information specific to the original protocol being encapsulated. The format and contents of the inner transport header 106 depend on the specific protocol being encapsulated, such as Transmission Control Protocol (TCP) or UDP

[0053] The addition of the outer transport header 102 and the tunneling header 104 results in the size of the packet 100 being bigger than the original tunneled/encapsulated packet 108, which may result in the need for fragmentation. Some tunneling protocols support fragmentation, but for those that do not, fragmentation of the tunneled/encapsulated packet 108 before encapsulation may be required.

[0054] A problem with tunneling is that in order for a first network device to encapsulate a packet for transport to a second network device, the first network device must know what encapsulation protocol to use for transporting different sorts of packets to the second network device. For instance, the first network device must also know how to fill in the various fields of the outer transport header 102 and the tunneling header 104. With certain encapsulation types, this knowledge may be acquired by default or through manual configuration. Other encapsulation protocols have fields such as session identifier (ID), key, or cookie that must be filled in. It would not be desirable to require every network device to be manually configured with the required encapsulation information for tunneling to every destination to which it might send a packet that needs tunneling.

[0055] A current solution to address the above issue is to encode the encapsulation protocols that may be used, as well as whatever additional information, if any, needed to properly use those protocols in a Border Gateway Protocol (BGP) Tunnel Encapsulation attribute as described in IETF document RFC 9012 entitled “The BGP Tunnel Encapsulation Attribute” by K. Patel, published April 2021 (RFC 9012). However, as the name implies, the BGP tunnel encapsulation attribute can only distribute the tunneling information between BGP speakers in a BGP domain, and does not work across the global Internet.

[0056] Thus, the present disclosure seeks to resolve one or more of the above issues by providing a simple, easily to use, and rapidly deployable method to enable distribution of tunneling information in a network using the DNS. The disclosed embodiments do not need major reconfiguration, network control system changes, or the use of the BGP. In particular, embodiments of the present disclosure include a new DNS SVCB service parameter type and a new DNS TUNNEL RR type that includes tunneling information for a DNS name of a host or service. The TUNNEL and SVCB RR types, along with other RR types, are stored at a network device known as a DNS name server. When the DNS name server receives a query for the SVCB or TUNNEL RR type corresponding to a DNS name from a client device, the DNS name server performs a lookup, and when the RR of type TUNNEL or SVCB corresponding to the DNS name is found, the DNS name server returns a DNS RR response that includes the SVCB or TUNNEL RR type corresponding to the DNS name to the client device. The client device can use the tunneling information included in the RR of type SVCB or TUNNEL to encapsulate data into one or more packets and transmit the encapsulated packets to the host to access the desired service.

[0057] FIG. 2 is a schematic diagram illustrating a network 200 according to an embodiment of the present disclosure. In the network 200, a plurality of client devices (client) 202 can communicate with a DNS server 208 over an IP network 206. The IP network 206 may include both private and public IP networks (e.g., the Internet). The DNS server 208 is part of a global distributed system, referred to as the DNS, that provides secure, reliable, and a convenient method of storing and retrieving data at hierarchically organized names. As stated above, the DNS is described in various IETF RFCs including RFC 1034 and RFC 1035. In general, DNS names are names of a specific instance of a service (e.g., a Voice over Internet Protocol (VoIP) or Instant Messaging (IM) service) or names of hosts. A DNS name comprises a series of labels. Each label represents a specific level in the DNS hierarchy. The rightmost label is known as the toplevel domain (TLD), such as .com, .org, and .net. The labels to the left of the TLD are subdomains, forming a hierarchical structure. A host name, also known as a domain name, is a user-friendly and human-readable label used to identify and access computer resources on the Internet. A host name is used when a client (e.g., a web browser application on a client 202) request data or services from a host (e.g., the host 210). The host 210 is a network device that host/provides data or services to the client 202. For example, the client 202 may be a device of a user, and the host 210 may be a server that hosts/provides a banking website, a search engine, or a commercial store front to the user. [0058] Host names are mapped to TP addresses, but a host name and an IP address do not have a one-to-one relationship (e.g., the host name “www.example.com” may be hosted on multiple servers and mapped to multiple corresponding IP addresses for load balancing and redundancy purposes). The DNS server 208 is responsible for translating, either based on locally stored data or by communicating with other DNS name servers, host/domain names into the corresponding IP address of the host. The DNS server 208 then returns the IP address of the host, if found, to the client 202 to enable the client to communicate with the host. Hence, the DNS server 208 enables users to use simple host names such as “example.com” instead of remembering complex IP addresses like “192.0.33.8”.

[0059] As described above, the data retrieved from the DNS server 208 is commonly addressing information (e.g., IPv4 or IPv6 addresses) corresponding to a DNS name. However, the DNS server 208 can provide other types of data stored in various defined RR types. For example, the DNS server 208 can provide information for an email domain (using a mail exchanger “MX” RR type), an authoritative DNS name server for a domain (using a nameserver “NS” RR type), admin information about a domain (using a start of authority “SOA” RR type), port information for specific services (using a services “SRV” RR type), and public keys certificates (using a “CERT” RR type).

[0060] To obtain a particular type of data from the DNS server 208, the client 202, using a program or a set of dynamic library routines referred to as a resolver, sends one or more requests or queries to the DNS server 208 that specify the host name and the desired type of resource information. DNS queries and responses are carried in a DNS message format as described below. [0061] FIG. 3 is a schematic diagram illustrating a DNS message format 300 of a DNS query or a DNS response according to an embodiment of the present disclosure. The DNS message format 300 includes the following five sections: header 302, question 304, answer 306, authority 308, and additional 310.

[0062] The header 302 section is always present. The header 302 section, as shown in FIG.

3, includes fields that specify which of the remaining sections are present and that specify whether the message is a query or a response, a standard query or some other opcode, etc.

[0063] The question 304 section contains fields that describe a question and other query parameters to a name server. The question 304 section may include zero or more questions (also referred to as an entry). The number of entries in the question 304 section is specified in the header 302 in a QDCOUNT field as shown and described in FIG. 3. Each entry or question is specified using the question format 400 as shown and described in FIG. 4.

[0064] The answer 306 section contains RRs, if any, that answer the question. The authority 308 section contains RRs, if any, that point toward an authoritative name server. The authoritative name server directly holds the DNS RRs associated with a domain. The additional 310 section contains RRs, if any, holding additional information which relate to the query, but are not strictly answers for the question. For example, the additional 310 section may include RRs that may be helpful in using the RRs in the answer 306 section and/or the authority 308 section. All RRs have the same top level format as shown and described in FIG. 6.

[0065] FIG. 4 is a schematic diagram illustrating a header format 400 of a DNS query or a DNS response according to an embodiment of the present disclosure. The header format 400 may be the format used for the header 302 section in the DNS message format 300 of FIG. 3. The header format 400 includes the following fields: identifier (ID) 402, query/response (QR) 404, operation code (OPCODE) 406, authoritative answer (AA) 408, truncation (TC) 410, recursion desired (RD) 412, recursion available (RA) 414, reserved (Z) 416, response code (RCODE) 418, question count (QDCOUNT) 420, answer count (ANCOUNT) 422, name server count (NSCOUNT) 424, and additional records count (ARCOUNT) 426.

[0066] The ID 402 field specifies a 16 bit identifier assigned by the program that generates the query. This identifier is copied in the corresponding reply and can be used to match replies to queries. The QR 404 field is a one bit field that specifies whether this message is a query (0), or a response (1). The OPCODE 406 field is a four bit field that specifies the kind of query in this message. For example, 0 indicates a standard query, 1 an inverse query, and 2 a server status request. This value is set by the originator of a query and copied into the response. The AA408 field is a one bit field used in query responses to specify that the responding name server is an authority for the domain name specified in the question 304 section of the DNS message format 300 of FIG. 3. The TC 410 field is a one bit field that indicates whether the message was truncated due to length greater than that permitted on the transmission channel. The RD 412 field is a one bit field that may be set in a query to request the name server to pursue the query recursively. The RA 414 field is a one bit field that is set or cleared in a response to denote whether recursive query support is available in the name server. The Z 416 field is a reserved field that is set to zero in all queries and responses. The Authentic Data (AD) bit 418 in a query can be set as a signal indicating that the requester understands and is interested in the value of the AD bit 418 in the response. The Checking Disabled (CD) bit 420 in a query can be set to indicate a resolver should attempt to return all response data, even data that has failed DNS Security Extensions (DNSSEC) validation. The RCODE 422 field is a 4 bit field that is set in responses to indicate whether an error occurred and the type of error.

[0067] The QDCOUNT 424 field specifies an unsigned 16 bit integer indicating the number of entries in the question 304 section of the DNS message format 300 of FIG. 3. The ANCOUNT 426 field specifies an unsigned 16 bit integer indicating the number of RRs in the answer 306 section of the DNS message format 300 of FIG. 3. The NSCOUNT 428 field specifies an unsigned 16 bit integer indicating the number of name server RRs in the authority 308 section of the DNS message format 300 of FIG. 3. The ARCOUNT 430 field specifies an unsigned 16 bit integer indicating the number of RRs in the additional 310 section of the DNS message format 300 of FIG. 3. The QDCOUNT 424 field, ANCOUNT 426 field, and NSCOUNT 428 field have the same structure and data type for a DNS Update, which provides section access, but are instead the counts for the zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional information (ARCOUNT) sections.

[0068] FIG. 5 is a schematic diagram illustrating a question format 500 of a DNS query or a DNS response according to an embodiment of the present disclosure. The question format 500 may be used to specify a question in the question 304 section of the DNS message format 300 of a DNS query or a DNS response as shown and described in FIG. 3.

[0069] The question format 500 includes a query domain name (QNAME) 502 field, a query type (QTYPE) 504 field, and a query class (QCLASS) 506 field. The QNAME 502 field specifies a domain name, which is represented as a sequence of labels. The QTYPE 504 field specifies a two octet code indicating a query type. The type values for the query type are the same as the type values for a RR type. Thus, the QTYPE 504 field correspondingly indicates the RR type to return in a DNS response to the query. Various query/RR types and their assigned values are defined in RFC 1035 and other subsequent documents. The QCLASS 506 field specifies a two octet code indicating the class of the query (e.g., IN for the Internet), and correspondingly the class of the RR type to return in a DNS response to the query. Most often, the QCLASS 506 field contains a class value of 1 for “IN” or Internet address class, which is common for DNS RRs involving Internet hostnames, servers, or TP addresses. Other classes exist, but are rarely used.

[0070] FIG. 6 is a schematic diagram illustrating an RR format 600 according to an embodiment of the present disclosure. The RR format 600 may be used to encode one or more RRs for the answer 206 section, the authority 208 section, and/or the additional 210 section of a DNS response to DNS query using the DNS message format 200 as shown and described in FIG.

2. The RR format 600 includes the following fields: name 602, type 604, class 606, time to live (TTL) 608, resource data length (RDLENGTH) 610, and resource data (RD ATA) 612.

[0071] The name 602 field is a variable length field that specifies a domain name (e.g., example.com) to which this resource record pertains.

[0072] The type 604 field is a two octets field containing an RR type code/value indicating an RR type. The type 604 field provides context or meaning to the data in the RD ATA 612 field as described below. For example, a value of 1 in the type 604 field indicates the RR is an “A” RR type and the data in the RDATA 612 field is an IPv4 host address. As stated above, the values of various RR types are defined in RFC 1035 and other subsequent documents.

[0073] The class 606 field is a two octets field containing one of the RR CLASS codes indicating an address class. Each class is an independent name space with potentially different root servers and delegations of DNS zones. Similar to the QCLASS 506 field of the question format 500 as shown and described in FIG. 5, the class 606 field often contains a class value of 1 for TN or Internet address class.

[0074] The TTL 608 field contains a 32 bit signed integer that specifies the time interval in seconds that the RR may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached.

[0075] The RDLENGTH 610 field contains an unsigned 16 bit integer that specifies the length in octets of the RD ATA 612 field.

[0076] The RD ATA 612 field contains a variable length string of octets that describes the RR (i.e., carries the data portion of the RR). The format of this information varies according to the RR type (specified in the type 604 field) and RR class (specified in the class 606 field) of the RR. For example, when the RR type is 1 indicating an address or “A” type RR and RR class is 1 indicating an IN or Internet class type, then the data in the RDATA612 field are IPv4 host addresses. When the RR type is 28 indicating an “AAAA” type RR and RR class is 1, then the data in the RD ATA 612 field are IPv6 host addresses.

[0077] As stated above, current methods of distributing tunneling information are limited to BGP speakers in a BGP domain, and do not work across the global Internet. To address this problem, embodiments of the present disclosure include a new DNS RR type that includes tunneling information for a DNS name of a host or service (referred as a TUNNEL RR type). In an embodiment, the TUNNEL RR type utilizes the RR format 600 as shown and described in FIG. 6. The type value associated with the TUNNEL RR type is to be determined (TBD) by the Internet Assigned Numbers Authority (IANA). The class value associated with the TUNNEL RR type is 1 for “IN” or Internet address class. The new TUNNEL RR type enables the DNS to store, retrieve, and return tunneling information for a DNS name to a client device that requests the tunneling information at a DNS name.

[0078] FIG. 7 is a schematic diagram illustrating a TUNNEL RR type data format 700 according to an embodiment of the present disclosure. The TUNNEL RR type data format 700 is used to carry tunneling information in the RD ATA 612 field of the new TUNNEL RR type that enables tunneling information to be distributed using the DNS.

[0079] In the depicted embodiment, the TUNNEL RR type data format 700 includes the following fields: priority 702, tunnel type 704, tunnel parameters length 706, tunnel parameters TLVs 708, and target name 710. The priority 702 is a 2 byte unsigned integer using network byte order that indicates the priority of using this tunnel to the target. In an embodiment, a client must use the tunnel with the lowest priority RR that meets the following 3 conditions: the client implements the tunnel type, the client can resolve the target name, and the type of packet being tunneled is not prohibited by an optional protocol type tunnel parameters TLV as described in Section 3.4.1 of RFC 9012. For example, the tunneling could be restricted to TCP packets. The tunnel type 704 is the tunnel type from the IANA “BFP Tunnel Encapsulation Attribute Tunnel Types” registry as specified in RFC 9012. The tunnel parameters length 706 is a 2 byte unsigned integer using network byte order giving the number of octets/bytes in the tunnel parameters TLVs 708 field. The tunnel parameters TLVs 708 field comprises “tunnel encapsulation attribute sub- TLVs” as specified in RFC 9012. The sub-TLVs can specify a variety of tunneling parameters including, but not limited to, tunnel egress endpoint, differentiated services field, and UDP destination port. These tunneling parameters may be useful in the outer transport header 102 of packet 100 in FIG. 1. The target name 710 field stores the uncompressed domain name of the ultimate/final destination in DNS wire encoding format (i.e., encoded using the DNS message format 300), which is used to obtain the destination address for the construction of the inner transport header 106 of packet 100.

[0080] In an alternative embodiment for obtaining tunneling information using the DNS, FIG. 8 illustrates a SVCB tunnel service parameter 800 according to an embodiment of the present disclosure. The SVCB tunnel service parameter 800 is a new parameter for a SVCB RR type (RR type 64) as specified in Schwartz (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb- https/12/) for storing and retrieving tunneling/encapsulation information in the DNS. In general, the SVCB RR type provides, when used in the “service mode,” for the encoding of a variety of service parameters to assist in connecting to a service. By providing more information to the client before the client attempts to establish a connection, SVCB RRs offer potential benefits to both performance and privacy. For example, the SVCB RR type can be used to locate alternative endpoints for a service. An alternative endpoint is a hostname, port number, and other associated instructions to the client on how to reach an instance of service. The SVCB RR, not shown, has two required fields (SvcPriority and TargetName) and one optional SvcParams field. The SvcPriority field indicates the priority of the RR relative to other SVCB RRs, the TargetName field specifies the alternative endpoint (when used in the “service mode”), and the SvcParams field can be used to provide service parameters associated with each of these alternative endpoints. The service parameters in the SvcParams field are represented by pairs comprising a SvcParamKey and a SvcParam Value. Each SvcParamKey has a presentation name and a registered number. Values are in a format specific to the SvcParamKey. For example, the SVCB tunnel service parameter 800 can be assigned “tunnel” as a presentation name and TBD integer as a registered number as a SvcParamKey. In an embodiment, the SvcParam Value corresponding to the tunnel SvcParamKey has a value specified in a tunnel type field 802, a tunnel parameters length field 804, and a tunnel parameters TLVs field 806 of the SVCB tunnel service parameter 800. Tn an embodiment, the presentation format for this value is hexadecimal. The tunnel type field 802, tunnel parameters length field 804, and tunnel parameters TLVs field 806 are the same as the tunnel type 704, tunnel parameters length 706, tunnel parameters TLVs 708 of the TUNNEL RR type data format 700 in FIG. 7 respectively.

[0081] FIG. 9 is a flowchart illustrating a method 900 for obtaining tunneling information from the DNS according to an embodiment of the present disclosure. The method 900 can be performed by a client device such as client 202 as shown and described in FIG. 2. At step 902, the client device transmits a DNS query for a SVCB RR or a TUNNEL RR corresponding to a DNS name. The DNS name may be associated with a host or service. For example, the DNS query may be encoded using the DNS message format 300 as shown and described in FIG. 3, where the question 304 section includes an entry/ question indicating a value (TBD) corresponding to a TUNNEL RR in the QTYPE 504 field as shown and described in FIG. 5. Alternatively, the question 304 section may include an entry/question indicating a value of 64 assigned to a SVCB RR type in the QTYPE 504 field.

[0082] At step 904, the client device receives a DNS response to the DNS query. When the requested TUNNEL RR is found at the DNS name, the DNS response includes the requested TUNNEL RR. Alternatively, if the SVCB RR is requested and found, the DNS response includes the SVCB RR.

[0083] At step 906, the client device determines whether the DNS response comprises tunneling information (e.g., whether the DNS response includes a TUNNEL RR or a SVCB RR that includes a SVCB tunnel service parameter 800 as described in FIG. 8). In some embodiments, the DNS response indicates an error when the DNS name is not found or when data at the DNS name does not include the requested TUNNEL RR or SVCB RR. In some embodiments, when the DNS response does not includes tunneling information (e.g., when DNS response indicates an error or SVCB RR does not include tunneling information), the client device, at step 912, indicates an error, in which case, packets that cannot be forwarded may be dropped.

[0084] When the DNS response includes tunneling information, at step 908, the client device inserts the tunneling information contained in the TUNNEL RR or SVCB RR into one or more headers (e.g., the outer transport header 102, the tunneling header 104, and/or the inner transport header 106 of packet 100 in FIG. 1) of one or more packets that encapsulates another packet (e.g., the tunneled/ encapsulated packet 108 in FIG. 1). At step 910, the client device transmits the one or more packets towards a destination node.

[0085] FIG. 10 is a flowchart illustrating a method 1000 for providing tunneling information according to an embodiment of the present disclosure. The method 1000 can be performed by a DNS server such as DNS server 208 in FIG. 2. At step 1002, the DNS server receives a DNS query for a TUNNEL RR or SVCB RR corresponding to a DNS name from a device such as the client 202 in FIG. 2. At step 1004, the DNS server performs a DNS lookup based on the DNS query to determine whether data corresponding to the DNS name comprises the TUNNEL RR or the SVCB RR. A DNS lookup, in a general sense, is the process by which the DNS server identifies the data stored under the DNS name so that the DNS server can respond with the requested data when found. In an embodiment, if the DNS lookup fails, either because the DNS name (step 1006) or a TUNNEL RR or SVCB RR corresponding to the DNS name is not found (step 1008), the DNS server, at step 1012, transmits a DNS response indicating an error to the client device that sent the query When the DNS name and the requested TUNNEL RR or SVCB RR specified in the DNS query are found, the DNS server, at step 1010, transmits a DNS response that includes tunnel information (i.e., from the requested TUNNEL RR or from an SVCB RR that includes tunneling information (e.g., specified according to the SVCB tunnel service parameter 800 in FIG. 8) to the client device that transmitted the query.

[0086] FIG. 11 is a schematic diagram of an apparatus 1100 according to an embodiment of the present disclosure. The apparatus 1100 is suitable for implementing the disclosed embodiments as described herein. In an embodiment, the apparatus 1100 may be a client device (e.g., the client 202 in FIG. 2) or a DNS server (e.g., DNS server 208 in FIG. 2) that is specially configured to obtain or provide tunneling information using the DNS as disclosed herein (e.g., as described in method 900 in FIG. 9 and method 1000 in FIG. 10).

[0087] The apparatus 1100 comprises ingress ports 1110 (or input ports 1110) and receiver units (Rx) 1120 for receiving data; one or more processors, logic units, or central processing units (CPUs) 1130 to process data; transmitter units (Tx) 1140 and egress ports 1150 (or output ports 1150) for transmitting data; and a memory 1160 for storing data. The apparatus 1100 may also comprise other components (not shown) such as, but not limited to, optical-to-electrical (OE) components and electrical-to-optical (EG) components coupled to the ingress ports 1110, the receiver units 1120, the transmitter units 1140, and the egress ports 1150 for egress or ingress of optical or electrical signals.

[0088] The one or more processors 1130 may be implemented by hardware, software, or a combination thereof. In some embodiments, the one or more processors 1130 may be implemented as one or more central processing unit (CPU) chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and digital signal processors (DSPs). The one or more processors 1130 are in communication with the ingress ports 1110, receiver units 1120, transmitter units 1140, egress ports 1150, and memory 1160. [0089] Tn an embodiment, the memory 1160 comprises a DNS module 1170. The DNS module 1170 includes instructions and data for implementing the disclosed embodiments. For instance, the DNS module 1170 includes instructions that when executed by the one or more processors 1130 implements, processes, prepares, or provides the various DNS operations for querying or responding to queries for a TUNNEL or SVCB RRthat provide tunneling information. The inclusion of the DNS module 1170 therefore provides a substantial improvement to the functionality of the apparatus 1100 and effects a transformation of the apparatus 1100 to a different state.

[0090] The memory 1160 may comprise one or more disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory 1160 may be, for example, volatile and/or non-volatile and may be a read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM). In some instances, the memory 1160 may reside or be a component of the one or more processors 1130.

[0091] Using the disclosed embodiments, an application on a client or host, without significant system changes, can simply query the DNS for tunneling information. Thus, embodiments of the present disclosure provide a rapidly usable method to enable distribution of tunneling information in a network without major reconfiguration, network control system changes, or the use of the BGP [0092] While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. For example, the disclosed embodiments include a computer program product comprising computer-executable instructions stored on a non-transitory computer-readable storage medium, the computerexecutable instructions when executed by a processor of an apparatus, cause the apparatus to perform the methods disclosed herein. A person skilled in the art would understand how to combine any or all of the above techniques in a vast variety of permutations and combinations.

[0093] The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0094] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method performed by a Domain Name System (DNS) server, the method comprising: receiving, from a client device, a DNS query for a TUNNEL resource record (RR) corresponding to a DNS name, wherein the TUNNEL RR comprises tunneling information used to encapsulate a packet; determining whether data corresponding to the DNS name comprises the TUNNEL RR in response to receiving the DNS query; and transmitting, to the client device, a DNS response, wherein the DNS response comprises the TUNNEL RR when the data comprises the TUNNEL RR.

2. The method according to claim 1, wherein the DNS response indicates an error when the DNS name is not found or when the data does not comprise the TUNNEL RR.

3. The method according to any of claims 1 -2, wherein the TUNNEL RR comprises a priority field indicating a priority of using a tunnel specified in the TUNNEL RR to a target.

4. The method according to any of claims 1-3, wherein the TUNNEL RR further comprises a tunnel type, a tunnel parameters length, tunnel parameters type-length-values (TLVs), and a target name.

5. The method according to any of claims 1-4, wherein the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs.

6. The method according to any of claims 1 -5, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

7. The method according to any of claims 1-6, wherein the target name is an uncompressed domain name of an ultimate destination node.

8. A method performed by a Domain Name System (DNS) server, the method comprising: receiving, from a client device, a DNS query for a Service Binding (SVCB) resource record

(RR) corresponding to a DNS name; determining whether data corresponding to the DNS name comprises the SVCB RR in response to receiving the DNS query; and transmitting, to the client device, a DNS response, wherein the DNS response comprises the SVCB RR when the data comprises the SVCB RR, and wherein the SVCB RR comprises tunneling information used to encapsulate a packet.

9. The method according to claim 8, wherein the DNS response indicates an error when the DNS name is not found or when the data does not comprise the SVCB RR.

10. The method according to any of claims 8-9, wherein the SVCB RR comprises a tunnel service parameter that carries the tunneling information.

11. The method according to claim 10, wherein the tunnel service parameter comprises a tunnel type, a tunnel parameters length, and tunnel parameters type-length-values (TLVs) that specifies a value for a SvcParam Value parameter of the tunnel service parameter.

12. The method according to claim 11 , wherein the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs specifying tunneling parameters.

13. The method according to any of claims 8-12, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

14. A method performed by a client device, the method comprising: transmitting a Domain Name System (DNS) query for a TUNNEL resource record (RR) corresponding to a DNS name; receiving a DNS response to the DNS query; determining whether the DNS response comprises the TUNNEL RR; inserting, when the DNS response comprises the TUNNEL RR, tunneling information from the TUNNEL RR into one or more headers of a first packet that encapsulates a second packet; and transmitting the first packet towards a destination node.

15. The method according to claim 14, wherein the DNS response indicates an error when the DNS name is not found or when data corresponding to the DNS name does not comprise the TUNNEL RR.

16. The method according to any of claims 14-15, wherein the TUNNEL RR comprises a priority field indicating a priority of using a tunnel specified in the TUNNEL RR to a target.

17. The method according to any of claims 14-16, wherein the DNS query comprises a query type code corresponding to a TUNNEL RR type.

18. The method according to any of claims 14-17, wherein the TUNNEL RR further comprises a tunnel type, a tunnel parameters length, tunnel parameters type-length- values (TLVs), and a target name.

19. The method according to any of claims 14-18, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

20. A method performed by a client device, the method comprising: transmitting a Domain Name System (DNS) query for a Service Binding (SVCB) resource record (RR) corresponding to a DNS name; receiving a DNS response to the DNS query; determining whether the DNS response comprises tunneling information; inserting, when the DNS response comprises the tunneling information, the tunneling information into one or more headers of a first packet that encapsulates a second packet; and transmitting the first packet towards a destination node.

21. The method according to claim 20, wherein the DNS response indicates an error when the DNS name is not found or when data corresponding to the DNS name does not comprise the SVCB RR.

22. The method according to any of claims 20-21, wherein the SVCB RR comprises a tunnel service parameter that carries the tunneling information.

23. The method according to claim 22, wherein the tunnel service parameter comprises a tunnel type, a tunnel parameters length, and tunnel parameters type-length- values (TLVs) that specifies a value for a SvcParamValue parameter of the tunnel service parameter.

24. The method according to claim 23, wherein the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs specifying tunneling parameters

25. The method according to any of claims 20-24, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

26. ADomain Name System (DNS) server comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the DNS server to: receive, from a client device, a DNS query for a TUNNEL resource record (RR) corresponding to a DNS name, wherein the TUNNEL RR comprises tunneling information used to encapsulate a packet; determine whether data corresponding to the DNS name comprises the TUNNEL RR in response to receiving the DNS query; and transmit, to the client device, a DNS response, wherein the DNS response comprises the TUNNEL RR when the data comprises the TUNNEL RR.

27. The DNS server according to claim 26, wherein the DNS response indicates an error when the DNS name is not found or when the data does not comprise the TUNNEL RR.

28. The DNS server according to any of claims 26-27, wherein the TUNNEL RR comprises a priority field indicating a priority of using a tunnel specified in the TUNNEL RR to a target.

29. The DNS server according to any of claims 26-28, wherein the TUNNEL RR further comprises a tunnel type, a tunnel parameters length, tunnel parameters type-length- values (TLVs), and a target name.

30. The DNS server according to any of claims 26-29, wherein the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs.

31. The DNS server according to any of claims 26-30, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

32. The DNS server according to any of claims 26-31, wherein the target name is an uncompressed domain name of an ultimate destination node.

33. A Domain Name System (DNS) server comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the DNS server to: receive, from a client device, a DNS query for a Service Binding (SVCB) resource record (RR) corresponding to a DNS name; determine whether data corresponding to the DNS name comprises the SVCB RR in response to receiving the DNS query; and transmit, to the client device, a DNS response, wherein the DNS response comprises the SVCB RR when the data comprises the SVCB RR, and wherein the SVCB RR comprises tunneling information used to encapsulate a packet.

34. The DNS server according to claim 33, wherein the SVCB RR comprises a tunnel service parameter that carries the tunneling information.

35. The DNS server according to claim 34, wherein the tunnel service parameter comprises a tunnel type, a tunnel parameters length, and tunnel parameters type-length- values (TLVs) that specifies a value for a SvcParamValue parameter of the tunnel service parameter.

36. The DNS server according to claim 35, wherein the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs specifying tunneling parameters.

37. The DNS server according to any of claims 33-36, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

38. A client device comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the client device to: transmit a Domain Name System (DNS) query for a TUNNEL resource record (RR) corresponding to a DNS name; receive a DNS response to the DNS query; determine whether the DNS response comprises the TUNNEL RR; insert, when the DNS response comprises the TUNNEL RR, tunneling information from the TUNNEL RR into one or more headers of a first packet that encapsulates a second packet; and transmit the first packet towards a destination node.

39. The client device according to claim 38, wherein the DNS response indicates an error when the DNS name is not found or when data corresponding to the DNS name does not comprise the TUNNEL RR.

40. The client device according to any of claims 38-39, wherein the TUNNEL RR comprises a priority field indicating a priority of using a tunnel specified in the TUNNEL RR to a target.

41. The client device according to any of claims 38-40, wherein the DNS query comprises a query type code corresponding to a TUNNEL RR type.

42. The client device according to any of claims 38-41, wherein the TUNNEL RR further comprises a tunnel type, a tunnel parameters length, tunnel parameters type-length- values (TLVs), and a target name.

43. The client device according to any of claims 38-42, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User Datagram Protocol (UDP) destination port.

44. A client device comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the client device to: transmit a Domain Name System (DNS) query for a Service Binding (SVCB) resource record (RR) corresponding to a DNS name; receive a DNS response to the DNS query; determine whether the DNS response comprises tunneling information; insert, when the DNS response comprises the tunneling information, the tunneling information into one or more headers of a first packet that encapsulates a second packet; and transmit the first packet towards a destination node.

45. The client device according to claim 44, wherein the DNS response indicates an error when the DNS name is not found or when data corresponding to the DNS name does not comprise the SVCB RR.

46. The client device according to any of claims 44-45, wherein the SVCB RR comprises a tunnel service parameter that carries the tunneling information.

47. The client device according to claim 46, wherein the tunnel service parameter comprises a tunnel type, a tunnel parameters length, and tunnel parameters type-length-values (TLVs) that specifies a value for a SvcParam Value parameter of the tunnel service parameter.

48. The client device according to claim 47, wherein the tunnel parameters TLVs comprises one or more tunnel encapsulation attribute sub-TLVs specifying tunneling parameters.

49. The client device according to any of claims 44-48, wherein the tunneling information comprises at least one of a tunnel egress endpoint, a differentiated services field, or a User

Datagram Protocol (UDP) destination port.

50. A computer program product comprising computer-executable instructions stored on a non-transitory computer-readable storage medium, the computer-executable instructions when executed by a processor of an apparatus, cause the apparatus to perform a method according to any of claims 1-25.