Method, server, and computer software for provisioning a cryptographic domain name system

Abstract

A method for provisioning a cryptographic domain name system (DNS) is provided, the method including receiving a message from a user device requesting an address of a secure DNS server, the message including a client address, the method further including determining the address of the secure DNS server based on the client address, and sending the message including the address of the secure DNS server to the user device.

Description

[Technical Field]

[0001] FIELD OF THE INVENTION This application relates to the Domain Name System (DNS). In particular, the present invention provides an improved method for facilitating the delivery of network-based DNS features along with encrypted DNS traffic. [Background technology]

[0002] background The Domain Name System (DNS) is used to translate domain names (e.g., human-readable domain names such as "www.vodafone.com") into IP addresses (e.g., 18.158.19.118). Thus, DNS servers act as an address book or directory for Internet addresses, linking website domain names with IP addresses that can be used to route IP traffic.

[0003] DNS messages between clients and servers have been sent unencrypted ("in clear text") for a long time. There have been no visible changes to the Domain Name System since its introduction around 1985. However, plans have recently been made to update the DNS by adding an encryption layer and discovery protocols to it. One of the resulting problems of new encryption protocols is that they alter the existing service infrastructure by changing the topology of the network and the entities involved.

[0004] While traditional DNS is provisioned by the network (which users can optionally modify using OS settings), the major encrypted DNS protocols (such as DNS over HTTPS (DoH) or DNS over QUIC (DoQ)) are discovered using new protocols that are currently being standardized. The new protocols are more complex than the plain DNS protocols and allow a level of customization that can help network operators simplify their network topologies and implement new services on top of DNS.

[0005] Advanced services that can be provided with traditional DNS include: Protection from malicious domains Parental Control Enforcing court orders (e.g., blocking specific domains based on local regulations) Traffic analysis Traffic management

[0006] New encrypted protocols are emerging, such as DoH (DNS over HTTPS), DoQ (DNS over Quick), and other variations. Encrypted protocols are desirable because they are more secure and can thwart malicious attacks such as "man-in-the-middle" attacks. Encrypted DNS protocols present several problems, including the following: · It is not easy to implement services as before. · DNS traffic cannot be analyzed on the fly (while messages are in transit). · The network topology becomes more complex. Customer premises equipment (CPE, e.g., a user's home router) cannot be used for encrypted DNS because it cannot automatically decrypt DNS traffic.

[0007] The present invention aims to address the above-mentioned problems. Summary of the Invention [Means for solving the problem]

[0008] overview A method for provisioning a cryptographic domain name system (DNS) is provided, the method comprising: receiving a message from a user device requesting an address (IP address and domain) of a secure DNS server, the message including a client address (IP address of the user device or a home router); determining the address of a secure DNS server based on the client address; sending a message to the user device that includes the address of the secure DNS server.

[0009] Encrypted DNS is complex and can be used to enhance functionality and improve security. However, implementing encrypted DNS also introduces some problems. For example, to implement the service, DNS needs to be able to identify users (e.g., using IP addresses or a combination of IP addresses and MAC addresses). However, implementing this imposes the following requirements on the network topology: DNS must be deployed at the edge of the network, before network address translation. · Support elements also need to be at the edge of the network.

[0010] In some examples, the requirement that a plain or secure DNS server must be able to identify a user is referred to as "customer awareness." For "customer awareness," a plain or secure DNS server may identify a user device using the source IP address (and optionally the MAC address) assigned to the device. Additionally or alternatively, a plain or secure DNS server may identify the user of the device (e.g., based on an IP address associated with the user or assigned to the user by the network).

[0011] These requirements are incompatible with existing network topologies. For various reasons, it is preferable to deploy secure DNS servers and supporting servers centrally within the operator's core network rather than at the edge. One reason for this is that a central location provides benefits in terms of resource allocation, virtualization facilities, management capabilities, and improved server interface connectivity. Encrypted DNS requires more resources than clear-text DNS. Therefore, the availability of these features is more important for encrypted DNS than for clear-text DNS. Furthermore, central deployment typically requires fewer server locations than deployment at the network edge, making server redundancy easier to implement (e.g., implementing N+1 redundancy in three central locations requires three additional servers, while implementing it in ten edge locations requires ten additional servers). Locating the servers centrally also allows for flexibility in resource allocation to support a gradual rollout of the service. Encrypted DNS may be initially deployed on a small scale in the network, and its capacity may be increased as users switch on secure services.

[0012] Therefore, the proposed solution provides encrypted DNS that can be deployed centrally while still providing user awareness, which has many advantages: At the edge of the network, only a basic DNS server is needed (such as a tiny port53 DNS integrated with Radius). User-aware encrypted DNS may be implemented in one or more central locations rather than at the edge of the network. Supporting elements such as session managers can also be deployed centrally. You can configure your CPE to manage DNS traffic.

[0013] If the user device is connected via a fixed-line network, messages between the DNS server and the user device may be routed through the customer premises equipment (CPE). In this case, encrypted DNS may be deployed. This may be advantageous if DoH does not enable a solution on the CPE (and therefore EDNS0 may not be feasible).

[0014] Alternatively, user identification may be implemented on the user device using an application, however this would require user activity to install the application, thus reducing the value to the network operator compared to the proposed solution which is entirely network-based.

[0015] The client address may be an address used by the DNS server to correctly route the response (e.g., the IP address to which the response is sent). This may be the address of the DNS server's immediate client, rather than the final client, which is the user device. If the user device is connected via a mobile network, the immediate client and the final client may be the same. In other words, the client address is the address of the user device. If the user device is connected via a fixed-line network, messages between the DNS server and the user device may be exchanged via a home router. In this case, the client address may be the address of the home router.

[0016] The client address may be a client identifier. For user devices connected via a mobile network, the client address may be the MSISDN (Mobile Subscriber ISDN [Integrated Services Digital Network] Number). For user devices connected via a fixed line, the client address may be the fixed line ID.

[0017] The address of the secure DNS server may include an IP address and / or a domain name. The address of the secure DNS server may include a Uniform Resource Identifier (URI).

[0018] The client address may be the address of the user device, in other words, the address received by the DNS server may be directly related to the user device.

[0019] In some examples, the user device is a mobile device connected to the Internet via a mobile data connection. In this case, the user device is directly connected to the operator network (without a home router). Therefore, the message received by the DNS server includes the address of the user device. The DNS server can respond by sending the message back to this address. The DNS server can identify the user based on the client address, which may be an MSISDN. In this case, the network topology is simpler and clearer than in a scenario where the user device is connected to the Internet via a home router and an Internet service provider (in this case, the client address is the address of the home router).

[0020] Determining the address of the secure DNS server may include retrieving user data associated with the user device from a data store based on the address of the user device. The user data may include one or more of the following: User service profile preferences (e.g., whether the user subscribes to personalized services that require the secure DNS server to know the user identity). User characteristics (e.g., age).

[0021] The step of determining the address of the secure DNS server further comprises: The method may include selecting a secure DNS server from a plurality of secure DNS servers based on user service profile preferences and / or user characteristics.

[0022] In another example, the client is connected to the Internet through a home router, which is in turn connected to the Internet via a fixed-line data connection. In this case, the device is not directly connected to the operator network. The router may perform network address translation (NAT) to route messages to and from the client. Therefore, in this case, the network topology is more complex than in the case described above, where the client is a mobile device connected to the Internet via a mobile data connection.

[0023] Messages received from a user device may be received via a home router (customer premises equipment, or CPE), which may be configured to perform network address translation (NAT). In this case, the client address may be the address of the home router.

[0024] The message received from the user device may further include a user device identifier (e.g., a label assigned to the device, such as a hostname, or a physical identifier, such as a MAC address). The determining step may further be based on the user device identifier.

[0025] The CPE may be configured to provide the user device identifier with EDNS (Extension Mechanisms for DNS). Specifically, EDNS0 may be used. Advantageously, the use of EDNS0 ensures that the MAC address can be reliably forwarded by the CPE to a plain DNS server.

[0026] Determining the address of the secure DNS server may include retrieving user data associated with the user device from a data store based on the address of the home router and the user device identifier, where the user data includes: User service profile preferences (e.g., whether the user subscribes to personalized services); and and user characteristics (e.g., age).

[0027] The method further comprises: The method may include sending a message to an authentication server to request that the authentication server generate a certificate and send the certificate to the home router.

[0028] The step of determining the address of the secure DNS server further comprises: The method may include selecting a secure DNS server from a plurality of secure DNS servers based on user service profile preferences and / or user characteristics. The plurality of secure DNS servers may comprise a home router.

[0029] The method further comprises: The method may include determining one or more DNS parameters based on the client address, wherein the message sent to the user device further includes the one or more DNS parameters.

[0030] One or more of the DNS parameters may be a Service Binding (SVCB) field.

[0031] The one or more DNS parameters may include a user identifier, preferably an encrypted user identifier. the address of your device, or A combination of the home router address and the user device identifier.

[0032] The message received from the user device may be an internet protocol (IP) message.

[0033] Messages received from user devices may be received via IP port 53 .

[0034] The Cryptographic Domain Name System DNS over HTTPS (Secure Hypertext Transfer Protocol) (DoH), or DNS over QUIC (Quick UDP [User Datagram Protocol] Internet Connection (DoQ)) can be selected.

[0035] A server (eg, a DNS server) configured to perform the above-described method is also provided.

[0036] There is also provided computer software comprising instructions which, when executed by a processor of a computer, cause the computer to carry out the above-described method. [Brief explanation of the drawings]

[0037] [Figure 1] FIG. 1 illustrates a standard discovery protocol for encrypted DNS (DoH). [Figure 2A] FIG. 1 illustrates a first example of an advanced discovery protocol for user devices connected via a mobile network. [Figure 2B] FIG. 1 is a flow diagram illustrating a first advanced discovery protocol for user devices connected via a mobile network. [Figure 3A] FIG. 1 illustrates a second example of an advanced discovery protocol for mobile networks. [Figure 3B] FIG. 10 is a flow diagram illustrating a second advanced discovery protocol for a user assigned to a first service profile. [Figure 3C] FIG. 10 is a flow diagram illustrating a second advanced discovery protocol for a user assigned to a second service profile. [Figure 4A] FIG. 1 illustrates an example of an advanced discovery protocol for fixed networks. [Figure 4B]FIG. 1 is a flow diagram illustrating a client with personal services connected to the Internet via a fixed network. DETAILED DESCRIPTION OF THE INVENTION

[0038] Detailed Description The present invention relates to network-based enforcement for encrypted DNS traffic. Figure 1 shows a standard discovery protocol for encrypted DNS (such as DoH or DoQ). This protocol is sometimes called DDR (Discovery of Designated Resolvers).

[0039] In step 101, the user device 110 sends a message to the plain DNS server 120. For example, a first query may be sent to the plain DNS server 120 for "doh.Vodafone.com".

[0040] In step 102, the DNS server 120 responds to the user device 110 and provides the address (IP address) of the secure DNS server 140 (such as a DoH server or a DoQ server). The DNS server 120 may also provide a service binding (SVCB) field to the user device 110.

[0041] In step 103, the user device 110 sends a message to the secure DNS server 140 using the address provided to the user device 110 by the plain DNS server 120. For example, the user device 110 may send the message to "HTTPS: / / doh.Vodafone.com / ?dns".

[0042] The secure DNS server 140 may be located in the center of the network 150 to centralize the secure DNS server 140 for the entire network, providing additional functionality centrally that may not be possible at the edge of the network.

[0043] A first example of an advanced discovery protocol for mobile networks is shown in FIG. 2A. In this first example, the protocol is used to provision encrypted DNS (such as DoH or DoQ) for devices belonging to users who have personal services enabled. To do this, the secure DNS server 240 must be provisioned (have customer knowledge) so that it can identify the user. This is not possible with the standard DDR protocol described in connection with FIG. 1 because the secure DNS server 140 is located in the center of the network and cannot reliably determine user identity based on an IP address (which may be subject to network address translation (NAT)). Therefore, the improved method augments the standard DDR response with a field that the secure DNS server 240 can use to identify the user.

[0044] The plain DNS server 220 is located at the edge of the network, so no network address translation is performed between the user device 210 and the plain DNS server 220. The plain DNS server 220 can identify the user based on the client address (which is the user device address since no network address translation has occurred). Thus, the plain DNS server 220 has awareness of the user (or "customer awareness").

[0045] In step 201, the user device 210 sends a message to the plain DNS server 220. This may be, for example, a first query for "doh.Vodafone.com".

[0046] The plain DNS server 220 identifies the user using the client address (which is also the address of the user device 210). The plain DNS server 220 also determines which services are enabled for a particular user. In this case, the plain DNS server 220 determines that the user has enabled personal services. Therefore, the secure DNS server 240 needs to be able to identify the user (have customer knowledge). To be able to do this, the plain DNS server 220 has the user device send a parameter containing identifying information to the secure DNS server 240. To do this, the plain DNS server 220 may include an encrypted user Id in the SVCB field.

[0047] In step 202, the plain DNS server 220 responds to the user device 210 and provides the address (IP address) of the secure DNS server 240. The plain DNS server 220 also provides the user device 210 with one or more service binding (SVCB) fields containing an encrypted user ID.

[0048] In step 203, the user device 210 sends a message to the secure DNS server 240 at the address provided by the plain DNS server 220. The address includes a parameter that allows the secure DNS server 240 to identify the user. For example, the user device 210 sends the message HTTPS: / / <encrypteduserid>.doh.Vodafone.com / ?dns Here, " <encrypteduserid>" is an encrypted user identifier that allows secure DNS server 240 to determine the user's identity. Because the user identifier is encrypted, it cannot be extracted by simply intercepting traffic or by a "man-in-the-middle" attack.

[0049] The above-described method provides a secure DNS bootstrap mechanism for user devices connected via a mobile network, where the user has personalized services. In this method, the port53 DNS server 220 responds to the user device 210 during the discovery phase by adding a user identifier. A flow diagram is illustrated in Figure 2B.

[0050] 2B illustrates encrypted DNS service discovery. In step 271, the user device 210 sends a DNS resolver message to port 53 on the plain DNS server 220. For example, the user device may send the following message in step 271: dns.resolver.arpa type SVCB In response, the plain DNS server 220 may provide the DoH address and SVCB field to the user device 210. For example, the plain DNS server 220 may provide the following response in step 272: <encrypteduserid>.doh.vodafone.com (dohpath= / dns-query / dns=)

[0051] Due to these provisioning steps during encrypted DNS service discovery, an address (which may be a URI) for the secure DNS server 240 is provided to the user device 210 so that secure DNS requests are directed to the secure DNS server 240 configured to provide the user-specific service. Furthermore, the address of the secure DNS server 240 includes an encrypted user ID. As a result, the secure DNS server 240 can identify the user and determine a personalized policy for that user. In this example, the personalized policy indicates that the user is under 18 years of age. Therefore, content appropriate only for adults should be blocked by the secure DNS server 240.

[0052] 2B illustrates a request for content that is not blocked by a personalized policy for a user. In step 281, the user device 210 sends a message to the secure DNS server 240, which is configured to provide personalized services. The message includes parameters that allow the secure DNS server 240 to identify the user. For example, an encrypted user ID may be provided as part of a domain (e.g., a subdomain) in the address to which the user device 210 is sending the message. Alternatively, the encrypted user ID may be included as a subdirectory or as a query parameter. The message includes the domain name that the user device 210 is attempting to resolve, e.g., www.wikipedia.com type A or AAAA The secure DNS server 240 identifies the user and determines whether the personalized policy allows the user to resolve the requested domain. In this case, the content is not blocked. Therefore, in step 282, the secure DNS server 240 retrieves the IP address of the content server 230 that hosts the requested domain. xx.xx.xx.xx In step 283, the user device 210 requests the content from the content server 230. HTTPS GET www.wikipedia.com

[0053] The third portion 290 of the flow diagram of Figure 2B shows a request for content that is blocked by a personalized policy for the user. In step 291, the user device 210 sends a message to the secure DNS server 240. As described above, the message includes parameters that allow the secure DNS server 240 to identify the user. The message includes a domain name that the user device 210 attempts to resolve. In this example, the domain is for a website that hosts content that is not suitable for users under the age of 18. For example, www.adultsite.com type A or AAAA The secure DNS server 240 identifies the user and determines whether a personalized policy allows the user to resolve the requested domain. In this case, the user is under 18 years old and the content is blocked. Therefore, in step 282, the secure DNS server 240 sends an error message rather than resolving the domain: NXDOMAIN with Extended DNS Error Code 18 - "why we blocked the content"

[0054] A second example of an advanced discovery protocol for mobile networks is shown in FIG. 3A. In this second example, the protocol is used to provision secure DNS servers 342, 344 (e.g., DoH or DoQ servers) for users grouped by service. In other words, users requiring the same services are grouped together, and secure DNS servers 342, 344 configured to provide those services are provisioned for those users. In this case, it is not necessary for the secure DNS servers 342, 344 to identify the user because each user provisioned with a secure DNS server 342, 344 requires the same service. Nevertheless, the plain DNS server 320 must be able to identify the user so that the correct secure DNS server 342, 344 can be provisioned to the user device based on the service the user requires. In the standard DDR protocol described in connection with FIG. 1, only one secure DNS server 140 is provided. Furthermore, the secure DNS server 140 in the standard DDR protocol is not customer-aware. Therefore, different service levels cannot be provided to different groups of users. In contrast, the improved method in the second example enhances the standard DDR response by provisioning different secure DNS servers 342, 344 based on the user's identity (and / or the services the user requests).

[0055] The plain DNS server 320 is located at the edge of the network, so no network address translation is performed between the user device 310 and the plain DNS server 320. The plain DNS server 320 can identify the user based on the client address. Because no network address translation is performed, the client address is the address of the user device 310. Therefore, the plain DNS server 320 can identify the user and therefore has customer awareness.

[0056] In step 301, a user device 310 sends a message to a plain DNS server 320. This may be, for example, a first query for "doh.Vodafone.com".

[0057] The plain DNS server 320 identifies the user using the client address (which may be the IP address of the user device 310). The plain DNS server 320 also determines which services are enabled for the particular user. In this case, the plain DNS server 320 determines that the user has enabled a predetermined selection of services, referred to in this example as "Service A." Accordingly, the plain DNS server 320 provisions the secure DNS server 342 with the user device 310. In this case, the secure DNS server 342 is configured to provide the requested service. To do so, the plain DNS server 320 may include an indication of the requested service profile in the SVCB field.

[0058] In step 302, the plain DNS server 320 responds to the user device 310 and provides the address (e.g., IP address or URI) of the secure DNS server 342. The plain DNS server 320 also provides the user device 310 with one or more service binding (SVCB) fields containing the requested service profile.

[0059] In step 303, the user device 310 sends a message to the secure DNS server 342 at the address provided by the plain DNS server 320. The address may include parameters to identify the secure DNS server 342 configured to provide the requested service profile (e.g., as a subdomain). For example, the user device 310 may HTTPS: / / serviceA.doh.Vodafone.com / ?dns where "serviceA" identifies a secure DNS server configured to provide the required service.

[0060] The above-described method provides a secure DNS bootstrap mechanism for user devices connected via a mobile network, where the user does not have personalized services but rather is grouped with other users who have a common service profile. In this method, the port53 DNS server 320 responds to the user device 310 during the discovery phase by adding a service profile identifier or a secure DNS server identifier.

[0061] 3B shows a flow diagram for a user assigned to a first service profile, where the first service profile defines services for users under the age of 18.

[0062] 3B illustrates DoH service discovery. In step 371, the user device 310 sends a DNS resolver message to port 53 on the plain DNS server 320. For example, the user device 310 may send the following message in step 371: dns.resolver.arpa type SVCB In response, the plain DNS server 320 may provide the DoH address and SVCB field to the user device 310. For example, the plain DNS server 320 may provide the following response to the user device 310 in step 372: Under18.doh.vodafone.com (dohpath= / dns-query / dns=)

[0063] These provisioning steps during encrypted DNS service discovery result in the user device 310 being provided with the address of a secure DNS server 342 configured to provide services appropriate for users belonging to a particular group. As a result, the secure DNS server 342 applies the correct group policy for that user. In this example, the group policy is set for users under the age of 18. Therefore, content appropriate only for adults must be blocked by the secure DNS server 342.

[0064] 3B illustrates a request for content that is not blocked by group policy. In step 381, the user device 310 sends a message to the secure DNS server 342 configured to provide group services. The message includes a domain name that the user device 310 wishes to resolve, e.g., www.wikipedia.com type A or AAAA The secure DNS server 342 determines whether group policy allows the user to resolve the requested domain. If so, the content is not blocked. Therefore, in step 382, ​​the secure DNS server 342 retrieves the IP address of the content server 330 that hosts the requested domain. xx.xx.xx.xx In step 383, the user device 310 requests the content from the content server 330. HTTPS GET www.wikipedia.com

[0065] 3B illustrates a request for content that is blocked by a group policy for a user. In step 391, the user device 310 sends a message to the secure DNS server 342. The message includes a domain name that the user device 310 attempts to resolve. In this example, the domain relates to a website that hosts content that is not suitable for users under the age of 18. For example, www.adultsite.com type A or AAAA The secure DNS server 342 determines whether the personalized policy allows the user to resolve the requested domain. In this case, the user is under 18 years old and the content is blocked. Therefore, in step 382, ​​the secure DNS server 342 sends an error message rather than resolving the domain. NXDOMAIN with Extended DNS Error Code 18 - "why we blocked the content"

[0066] 3C shows a flow diagram for a user assigned to a second service profile, where the second service profile defines services for users over the age of 18.

[0067] 3C illustrates DoH service discovery. In step 376, the user device 310 sends a DNS resolver message to port 53 on the plain DNS server 320. For example, the user device 310 may send the following message in step 376: dns.resolver.arpa type SVCB In response, plain DNS server 320 may provide the address of secure DNS server 344 and the SVCB field to user device 310. The SVCB field may indicate that the user is assigned a service profile "ServiceB" implemented by secure DNS server 344 that is different from secure DNS server 342, which implements the first service profile "ServiceA." For example, plain DNS server 320 may provide the following response to user device 310 in step 377: Over18.doh.vodafone.com (dohpath= / dns-query / dns=)

[0068] These provisioning steps during encrypted DNS service discovery result in the user device 310 being provided with the address of a secure DNS server 344 configured to provide pre-configured services appropriate for users belonging to a particular group. As a result, the secure DNS server 344 applies the correct group policy for that user. In this example, the group policy is set for users over the age of 18. Therefore, content appropriate only for adults should not be blocked by the secure DNS server 344.

[0069] 3B illustrates a request for content that is not blocked by group policy. In step 386, the user device 310 sends a message to the secure DNS server 344 configured to provide group services for the second group. As described above, the message includes a domain name that the user device 310 attempts to resolve, e.g., www.wikipedia.com type A or AAAA The secure DNS server 344 determines whether group policy allows the user to resolve the requested domain. If so, the content is not blocked. Therefore, in step 387, the secure DNS server 344 retrieves the IP address of the content server 330 that hosts the requested domain. xx.xx.xx.xx In step 388, the user device 310 requests the content from the content server 330. HTTPS GET www.wikipedia.com

[0070] 3B illustrates a request for content that is blocked by a group policy for a user. In step 396, the user device 310 sends a message to the secure DNS server 344. The message includes a domain name that the user device 310 attempts to resolve. In this example, the domain relates to a website that hosts content that is not suitable for users under the age of 18. For example, www.adultsite.com type A or AAAA The secure DNS server 344 determines whether group policy allows the user to resolve the requested domain. In this case, the user is over 18 years old and the content is not blocked. Therefore, in step 397, the secure DNS server 344 retrieves the IP address of the content server 330 that hosts the requested domain. yy.yy.yy.yy In step 398, the user device 310 requests the content from the content server 330. HTTPS GET www.adultsite.com

[0071] In the examples described above with reference to Figures 2A, 2B, 3A, 3B, and 3C, the plain DNS server 220, 320 provisions the secure DNS server 240, 342, 344 for the user device based on the services required by the user. In the example described with reference to Figures 2A and 2B, the secure DNS server 240 provides personalized services for the user. In the example described with reference to Figures 3A, 3B, and 3C, the secure DNS server 342 is provided for a group of users with a particular service profile "Service A," while the secure DNS server 344 is provided for a group of users with a different service profile "Service B."

[0072] The scenario for a user device connected via a fixed network is more complex than that for a user device connected via a mobile network. A third example of an advanced discovery protocol for fixed networks is shown in FIG. 4A. In this third example, the protocol is used to provision DoH for a user with personal service and configured to access the Internet through a customer premises equipment CPE 415 (e.g., a home router). To provide personalized services, DoH must be able to identify the user. This is not possible with the standard DDR protocol described in connection with FIG. 1 because the secure DNS server 140 is located in the center of the network and cannot reliably determine user identity based on the IP address (which may be subject to network address translation (NAT)). Therefore, the improved method augments the standard DDR response with a field that DoH can use to identify the user.

[0073] As shown in FIG. 4A , a user device 410 is configured to access the Internet through a CPE 415. A plain DNS server 420 is located at the edge of the network; therefore, no network address translation is performed between the CPE 415 and the plain DNS server 420. Unlike the mobile data connection example illustrated in FIG. 2A , the client address is not sufficient for the plain DNS server 420 to identify the user. This is because the client address is the address of the CPE 415, not the address of the user device 410. Multiple different user devices may be connected to the Internet through the CPE 415. Therefore, to uniquely identify the user device 410, the plain DNS server 420 requires the address of the CPE (client address) and an identifier (e.g., MAC address) of the user device 410. Using the combination of these two identifiers, the DNS server 420 can identify the user. Thus, the plain DNS server 420 has customer awareness.

[0074] In step 401, the user device 410 sends a message to the CPE DNS resolver 415. This may be, for example, a first query for "doh.Vodafone.com".

[0075] In step 402 , the CPE DNS resolver 415 sends a message to a plain DNS server 420 .

[0076] The plain DNS server 420 identifies the user using the IP address of the CPE and the MAC address of the user device 410. The plain DNS server 420 also determines which services are enabled for a particular user. In this case, the plain DNS server 420 determines that the user has enabled personal services. Therefore, the plain DoH server 420 needs to be able to identify the user. Therefore, the plain DNS server 420 causes the user device 410 to send parameters containing identification information to the secure DNS server 440. To do this, the plain DNS server 420 may include the encrypted user Id and MAC address in the SVCB field.

[0077] The plain DNS server 420 responds to the user device 410 and provides the address (IP address, domain, and / or URI) of the secure DNS server 440 (such as a DoH server or a DoQ server). The plain DNS server 420 also provides the user device 410 with one or more service binding (SVCB) fields containing an encrypted user Id and MAC address. Additional fields in the DDR response allow the secure DNS server 440 to identify the user (using the CPE+MAC address combination).

[0078] The plain DNS server 420 also determines that the user is connected via a fixed-line connection and a CPE. Therefore, the plain DNS server 420 provisions a secure DNS server 440 configured for use via the CPE. In order for the CPE 415 to operate as part of the encrypted DNS configuration, the CPE 415 must be provisioned with a certificate unique to each CPE. The certificate may be generated by the authentication server 460 and sent to the CPE 415. This allows the DNS resolver on the CPE 415 to decrypt the secure DNS traffic and correctly route the request to the DoH server 440.

[0079] In this scenario, port53DNS 420 is aware of CPE 415 and responds to the discovery request by creating a DoH URI that includes the user identifier and the CPE DoH resolver domain. For example, <useridentifier> . <cpeidentifier>.vodafone.com During the first connection, the authentication server 460 *.CPEidentifier.vodafone.com Generate a new certificate for the CPE and deploy the certificate to the CPE.

[0080] In step 403, the client 410 sends a message to a DNS responder on a CPE 415 in the user's home network 455. The DNS responder on the CPE 415 can use the certificate provided by the authentication server 460 to securely communicate with the secure DNS server 440 at the address provided by the plain DNS server 220. The address of the secure DNS server includes parameters that allow the secure DNS server 440 to identify the user. For example, the user device 410 can send the message to HTTPS: / / <encryptedUserId+MAC> .CPEdohx.Vodafone.com / ?dns In this case, you can send<encryptedUserId+MAC> " is an encrypted combination of a user identifier and a MAC address that allows the secure DNS server 440 to determine the user's identity.

[0081] The above-described method provides a secure DNS bootstrap mechanism for a user device connected via a fixed network. In this case, the user has personalized services. In this method, the port53 DNS server 420 responds to the user device 410 during the discovery phase by adding a CPE identifier and a user device identifier. Figure 4B shows a flow diagram of a user device 410 with personalized services connected to the Internet via customer premises equipment CPE 415.

[0082] The first portion 465 of the flow diagram in Figure 4B illustrates certificate acquisition. In step 466, CPE 415 requests a certificate from authentication server 460. In step 467, authentication server 460 sends the certificate to CPE 415. For example, authentication server 460 may send CPE 415 a certificate for *.CPEidentifier.vodafone.com. The certificate may only need to be sent to CPE 415 once during setup.

[0083] 4B illustrates DoH service discovery. In step 471, the user device 410 sends a DNS resolver message to the CPE DNS resolver 415. For example, the user device 410 may send the following message in step 471: dns.resolver.arpa type SVCB In response, the plain DNS server 420 may provide the address of the secure DNS server 440 and the SVCB field to the user device 410. For example, the plain DNS server 420 may provide the following response in step 472: <encryptedUserID+MAC> .CPEdohx.vodafone.com (dohpath= / dns-query / dns=)

[0084] The secure DNS address provided to the user device 410 as a result of these provisioning steps during secure DNS service discovery is an address that routes secure DNS requests via the CPE 415 to a secure DNS server 440 configured to provide user-specific services. Additionally, the secure DNS address includes an encrypted user ID and MAC address. As a result, the secure DNS server 440 can identify the user and determine a personalized policy for the user. In this example, the personalized policy indicates that the user is under 18 years of age. Therefore, content appropriate only for adults should be blocked by the secure DNS server 440.

[0085] The third portion 480 of the flow diagram of FIG. 4B shows a request for content that is not blocked by a personalized policy for the user and device. In step 481, the user device 410 sends a message to a secure DNS server 440 configured to provide personalized services. The message includes parameters that allow the secure DNS server 440 to identify the user. For example, an encrypted user ID and MAC address may be provided as part of the address (e.g., a subdomain) of the secure DNS server 440. Alternatively, the encrypted user ID may be included as a subdirectory or as a query parameter. The message includes the domain name that the user device 410 attempts to resolve, e.g., www.wikipedia.com type A or AAAA The secure DNS server 440 identifies the user and determines whether the personalized policy allows the user to resolve the requested domain. In this case, the content is not blocked. Therefore, in step 482, the secure DNS server 440 resolves the requested domain. xx.xx.xx.xx In step 483, the user device 410 requests the content from the content server 430. HTTPS GET www.wikipedia.com

[0086] The fourth portion 490 of the flow diagram in Figure 4B shows a request for content that is blocked by a personalized policy for the user and device. In step 491, the user device 410 sends a message to the secure DNS server 440. As described above, the message includes parameters that allow the secure DNS server 440 to identify the user and device. The message includes a domain name that the user device 410 attempts to resolve. In this example, the domain is for a website that hosts content that is not suitable for users under the age of 18. For example, www.adultsite.com type A or AAAA Secure DNS server 440 identifies the user and determines whether personalized policies allow the user to resolve the requested domain. In this case, the user is under 18 years of age and the content is blocked. Therefore, in step 482, secure DNS server 440 sends an error message rather than resolving the domain. NXDOMAIN with Extended DNS Error Code 18 - "why we blocked the content"

[0087] As used herein, including the claims, the singular form of terms herein should be construed to include the plural, and vice versa, unless the context dictates otherwise. By way of example, when referring to a singular form herein, including the claims, such as "a" or "an," it means "one or more," unless the context dictates otherwise. Throughout the description and claims of this disclosure, the words "comprise," "including," "having," and "contain," as well as variations of these words, such as "comprising," "comprises," or equivalents, mean "including" and are not intended to (and do not) exclude other elements.

[0088] Although embodiments according to the present disclosure are described with reference to particular devices and protocols, and these embodiments have particular advantages in such cases, as discussed herein, approaches according to the present disclosure may also be applied to other types of networks. Particular structural details of platforms and servers, while potentially advantageous (especially given known IP constraints and capabilities), may be significantly modified to arrive at devices and methods with similar or identical operation. Each feature disclosed herein, unless otherwise stated, may be replaced by an alternative feature serving the same, equivalent, or similar purpose. Thus, unless otherwise stated, each disclosed feature is merely one example of a generic series of equivalent or similar features.

[0089] Any examples or use of exemplary language (such as "for instance," "such as," "for example," and similar phrases) provided herein are intended merely to better illustrate the invention and do not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0090] Any steps described herein may be performed in any order, or simultaneously, unless otherwise stated or required otherwise by context.

[0091] All aspects and / or features disclosed herein may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. There may be certain combinations of aspects that provide additional benefits, such as aspects of determining a set of compensation parameters and applying the set of compensation parameters to measurements, as described herein. In particular, preferred features of the present invention are applicable to all aspects of the present invention and may be used in any combination. Similarly, features described in non-essential combinations may be used separately (not in combination).< / cpeidentifier> < / useridentifier> < / encrypteduserid> < / encrypteduserid> < / encrypteduserid>

Claims

1. 1. A method for provisioning a cryptographic domain name system (DNS), comprising: receiving a message from a user device requesting an address of a secure DNS server, the message including a client address, the method further comprising: determining the address of a secure DNS server based on the client address; sending a message to the user device including the address of the secure DNS server.

2. The method of claim 1 , wherein the client address is an address of the user device.

3. Determining the address of a secure DNS server includes retrieving user data associated with the user device from a data store based on the address of the user device, the user data comprising: User identity; User service profile preferences; and user characteristics.

4. The step of determining the address of the secure DNS server further comprises:

10. A method according to any one of the preceding claims, comprising selecting a secure DNS server from a plurality of secure DNS servers based on the user identity, user service profile preferences, and / or user characteristics.

5. 2. The method of claim 1, wherein the message received from the user device is received via a home router, the home router configured to perform network address translation (NAT), and the client address is an address of the home router.

6. The method of claim 5 , wherein the message received from the user device further includes a user device identifier, and the determining step is further based on the user device identifier.

7. determining the address of a secure DNS server includes retrieving user data associated with the user device from a data store based on the address of the home router and the user device identifier, the user data comprising: User service profile preferences; and user characteristics.

8. 8. The method of claim 5, further comprising the step of sending a message to an authentication server to request that the authentication server generate a certificate and send the certificate to the home router.

9. The step of determining the address of the secure DNS server further comprises:

9. The method of claim 5, comprising selecting a secure DNS server from a plurality of secure DNS servers based on the user service profile preferences and / or user characteristics, the plurality of secure DNS servers comprising the home router.

10. determining one or more DNS parameters based on the client address; 10. The method of claim 1, wherein the message sent to the user device further includes the one or more DNS parameters.

11. The method of claim 10 , wherein the one or more DNS parameters is a service binding (SVCB) field.

12. The method according to claim 10 or 11, wherein the one or more DNS parameters comprise a user identifier, preferably an encrypted user identifier.

13. the message received from the user device is an Internet Protocol (IP) message received via IP port 53; and / or 10. The method of any one of the preceding claims, wherein the encrypted domain name system is DNS over HTTPS (DoH) or DNS over QUIC (DoQ).

14. A server configured to perform the method of any one of the preceding claims.

15. Computer software comprising instructions which, when executed by a processor of a computer, cause the computer to carry out the method of any one of claims 1 to 13.

Images