WO2016082274A1

WO2016082274A1 - Dane extended query method and system supporting carrying of service address information

Info

Publication number: WO2016082274A1
Application number: PCT/CN2014/095172
Authority: WO
Inventors: 延志伟; 张海阔; 胡安磊; 李晓东
Original assignee: 中国科学院计算机网络信息中心
Priority date: 2014-11-27
Filing date: 2014-12-26
Publication date: 2016-06-02
Also published as: CN104468859A; CN104468859B

Abstract

The present invention relates to a DANE extended query method and system supporting carrying of service address information. The method comprises: a client sends a DNS request message for querying a TLSA resource record, the header of the DNS request message being set with a service address flag bit; and in response to the DNS request message sent by the client, a recursive server and an authorized server fill in corresponding address information according to the setting of the service address flag bit, and return the address information and the TLSA resource record to the client through a response data packet. According to the present invention, the flag bit and a data field are added in the TLSA resource record to achieve an extended mechanism of the DANE protocol, and the efficiency of the whole domain name resolution process can be remarkably improved.

Description

DANE extended query method and system supporting carrying service address information

Technical field

The invention belongs to the technical field of network technology and DNS, and particularly relates to a DANE extended query method and system for supporting carrying service address information.

Background technique

Applications that communicate over the Internet face the threat of eavesdropping, tampering, or forgery. For this reason, data transmissions with security requirements on the Internet generally use Transport Layer Security (TLS) to encrypt channels. To ensure the integrity and confidentiality of the data. The TLS protocol uses the key algorithm to provide endpoint identity authentication and communication privacy over the Internet. The basis is the Digital Certification Authority (CA), which binds the public key and related information (including the owner's name, CA) through a digital certificate. Name, validity period of the public key, digital signature of the CA, etc.). The CA will properly keep its private key, issue a digital certificate for the TLS server, and provide its public key to the TLS client. The TLS client treats the CA's own public key as a "trust anchor" and uses this to verify the validity of the TLS server certificate. After the verification is passed, secure communication can be performed between the TLS server and the client. Although the above public CA mode is widely used, there are still some unsatisfactory places, which brings hidden dangers to the secure transmission of information: CA mode allows any CA to issue digital certificates for the TLS server, which makes the system vulnerable. CA violates security commitments, whether for subjective reasons or for objective reasons (such as a private key leak), all of which will result in the loss of security for all digital certificates issued by the CA. For example, Microsoft has issued a CA security alert and found that a CA agency called Comodo issued fraudulent digital certificates, causing damage to websites of companies such as Microsoft and Google.

To this end, the IETF DANE (DNS-Based Authentication of Named Entities) working group designed a new DNS resource record, TLSA (TLSA is only a resource record name, no other meaning), The DNSSEC (Domain Name System Security Extensions) infrastructure is used to store digital certificates or public keys used in the TLS protocol. The core of the DANE protocol is: relying on DNSSEC (DNSSEC is a series of DNS security authentication mechanisms provided by the IETF (refer to RFC2535). It provides source identification and integrity assurance of DNS data) infrastructure to limit the CAs available to the TLS server. The scope so that the zone operator can declare the range of digital signatures available to the TLS client.

Specifically, such statements fall into three broad categories:

(1) CA restriction statement: TLS clients can only accept digital certificates issued by certain specific CAs. If the digital certificates transmitted by the TLS server are not issued by these specific CAs, the TLS client can view these digital certificates as invalid.

(2) Certificate Restriction Statement: The TLS client can only accept a specific digital certificate (or public key) instead of other certificates (or public keys), thus doing a CA digital certificate or public key that can be used for TLS. Further restrictions;

(3) Trust Anchor Statement: The TLS client shall use the trust anchor declared by the zone to verify the digital certificate of the zone.

All of the above three types of declarations can be considered as restrictions on the scope of the trust anchor. The first two categories mainly limit the scope of the existing trust anchor, and the third category provides a new trust anchor for the TLS client.

RFC 6698 defines the specific protocol format of the DANE resource record TLSA. The TLSA resource record contains four options: Cert.Usage, Selector, Matching Type, and CertificateAssociation Data.

Their roles are:

(1) Cert.Usage: used to indicate the specific type of declaration; from the above, there are three types: CA restricted type, certificate limited type, and trust anchor point declaration;

(2) Selector: used to indicate which part of the TLS server certificate the data stored in the Certificate Association Data comes from; the Selector has two options: one for indicating that the stored data is a digital certificate and the other for indicating that the stored data is a public key. ;

(3) Matching Type: used to indicate how the Certificate Association Data in the TLSA resource record matches the original data in the TLS server digital certificate. There are three ways: the original data is directly matched, and the original data is SHA-256 hashed. Match and perform SHA-512 hash matching on the original data;

(4) Certificate Association Data: stores related data, the data type is specified by Selector.

The example of DANE is as follows:

Suppose Alice maintains some Web resources on the zone example.cn. In order to ensure the safe operation of the domain name, Alice does not want any CA to issue a digital certificate for example.cn. Alice needs to specify a CA (assumed Bob). And only the digital certificate issued by the CA for example.cn is valid. At this point, Alice wants to tell all clients that only Bob's digital certificate is valid, and any other CA's digital certificate is invalid. With the TLSA record, this desire is easy to implement, and Alice only needs to add the following to the TLSA resource record:

● Usage: Limit CA

● Selector: Digital certificate

● Matching Type: SHA-256 hash

● Certificate Association Data: SHA-256 hash of the Bob digital certificate

Suppose the client is Charlie. When it accesses the web resource of example.cn, it can receive the above-mentioned TCPA resource record and use the above content to verify the TLS digital certificate it received from example.cn. If the certificate is issued by Bob, it is valid, otherwise it is invalid.

The DANE protocol uses the DNSSEC infrastructure to hold the digital certificates or public keys used in the TLS protocol, which allows the DANE protocol to inherit the various advantages of the DNSSEC protocol. DNSSEC is a set of DNS security authentication mechanisms provided by the IETF to provide an extension of source authentication and data integrity. Although the principle is similar to the CA model, DNSSEC is based on technologies such as digital signature, but it improves the basic CA model in the following three aspects.

(1) The key is bound to the domain name in the DNS, not to any identifier, so that it can be used by various Internet protocols;

(2) The signed public key can be obtained through the DNS system. The client can query the required public key by simply sending a normal DNS request, and the distribution of the public key is very simple;

(3) The key of a zone can only be signed by the key of its parent zone. For example, the key of zone "example.com" can only be signed by zone ".com", and the zone of ".com" is dense. The key can only be signed by the root key.

In the CA model and DNSSEC, the client saves the public key of the trust authority and uses this to verify the legality of the identity information of other entities; the difference is that in DNSSEC, the public key is only stored in a single root domain, but in In the CA model, the public key is stored in a different CA.

The DANE protocol provides configuration flexibility for DNS zone operators and adds security for TLS transmissions, but the addition of the DANE protocol increases the latency of the TLS connection process. In addition to completing the TLS handshake and digital certificate verification, the TLS client has to wait for several DNS round-trip signaling interactions before it can learn the authenticated certificate and the address of the accessible server. This will cause the TLS connection to be extended for a few seconds, making some real-time services unbearable. This is mainly because the DANE query needs to generate a domain name containing special prefix information. The prefix contains the port number supporting the TLS service and the corresponding protocol type, such as:

1) If you request an HTTP server running TLS on port 443, the server domain name is www.example.com, then the corresponding domain name of the TLSA resource record is _443._tcp.www.example.com;

2) If you request an SMTP server running STARTTLS on port 25, the server domain name is mail.example.com, then the corresponding domain name of the TLSA resource record is _25._tcp.mail.example.com.

Therefore, the address information (A record or AAAA record) of the client query server and its TLSA record become two separate steps, which leads to unnecessary increase of protocol overhead and increase of service delay.

Summary of the invention

The present invention is directed to the above problem, and provides a DANE extended query method and system for supporting carrying service address information. By adding a flag bit and a data field in the TLSA resource record, the DANE protocol extension mechanism is implemented, which can significantly improve the entire domain name resolution process. s efficiency.

To achieve the above object, the present invention adopts the following technical solutions:

A DANE extended query method supporting carrying service address information includes the following steps:

1) The client sends a DNS request message for querying the TLSA resource record, where the head of the DNS request message is provided with a service address (SA) flag;

2) The recursive server and the authoritative server respond to the DNS request message sent by the client, fill in the corresponding address information according to the setting of the service address flag, and return the address information and the TLSA resource record to the client through the response packet.

Further, the service address flag is a two-bit flag, and the values are 00, 01, 10, and 11, and the meanings are as follows:

00: The client does not request any address information of the server;

01: The client requests to carry the IPv4 address information of the server while returning the TLSA resource record, and the DNS response message includes not only the server's OTLS resource record but also at least one 32-bit IPv4 address;

10: The client requests to carry the IPv6 address information of the server while returning the TLSA resource record, and the DNS response message includes not only the server's OTLS resource record but also at least one 128-bit IPv6 address;

11: The client requests to carry the IPv4 and IPv6 address information of the server while returning the TLSA resource record. The DNS response message includes not only the server's TTLS resource record, but also at least one 32-bit IPv4 address and at least one 128-bit IPv6 address.

Further, step 2) is implemented by using a recursive server mode: after receiving the DNS request message of the client, the recursive server constructs a corresponding A record query request and/or AAAA record query request according to the service address flag and the service domain name to be queried, and The new request message is sent to the corresponding authoritative server. After receiving the TLSA and A/AAAA record query response from the authoritative server, the recursive server returns it to the client.

Further, step 2) is implemented by using an authoritative server mode: the recursive server sends the DNS request message received from the client to the corresponding authoritative server without modification, and the authoritative server constructs a response message according to the setting of the service address flag bit, and sends the response message. The recursive server is then sent to the client.

A DANE extended query system supporting the service address information, comprising a client, a recursive server and an authoritative server, wherein the header of the DNS request message sent by the client is provided with a service address (Service Address) , SA) flag bit; when the recursive server and the authoritative server respond to the DNS request message sent by the client, the corresponding address information is filled according to the setting of the service address flag bit, and the address information and the TLSA resource record are passed through the response packet. Return to the client.

The invention realizes supporting bearer service address letter by adding flag bits and data fields in its OTLS resource record. The DANE extension mechanism and the DNS query based on the extension mechanism reduce the delay of the TLS connection process, optimize the transmission overhead between the client and the recursive server, and the authoritative server, and significantly improve the efficiency of the entire domain name resolution process. .

DRAWINGS

1 is a schematic diagram of an extended DNS request message in an embodiment.

2 is a flow chart of an extended DNS query in an embodiment.

detailed description

The invention will be further illustrated by the following specific examples and the accompanying drawings.

The invention extends the DANE protocol, adds a flag bit and a data field in its TLSA resource record, and standardizes its protocol flow. The main contents include: adding a two-bit SA (Service Address) flag in the DNS message header. Bit; specifies the 32-bit data field containing the IPv4 address and the 128-bit data field containing the IPv6 address when querying the TLSA resource record; defines the rules and extended DANE protocol flow using the SA flag and its data fields.

1) SA flag

The SA flag is a two-bit flag, and its validity is only present in the type of DNS request message. The header format of the extended DNS request message of the present invention is as shown in FIG. 1:

The SA values are 00, 01, 10, and 11. The meanings are as follows:

● 00: The client does not request any address information of the server;

● 01: The client requests to carry the IPv4 address information of the server while returning the TLSA resource record. If the value is set, the DNS response message should include not only the server's OTLS resource record, but also at least one 32-bit IPv4 address.

● 10: The client requests to carry the IPv6 address information of the server while returning the TLSA resource record. If the value is set, the DNS response message should include not only the server's OTLS resource record, but also at least one 128-bit IPv6 address.

● 11: The client requests to carry the IPv4 and IPv6 address information of the server while returning the TLSA resource record. If this value is set, the DNS response message should include not only the server's OTLS resource record, but also at least one 32-bit IPv4 address. At least one 128-bit IPv6 address.

The four values of the foregoing SA are only for the identification function, so other sequences may be used to correspond to the above four meanings, for example, 01 can also be used to indicate the meaning of 00, 00 can also be used to indicate the meaning of 01, etc., and the present invention is not limited thereto.

2) Address information

The present invention is directed to returning one or more IP addresses in accordance with client requirements in a scalable manner in a TCPA request process. Therefore, it can be fully compatible with the response format using basic DNS messages, so two mechanisms for carrying address information are proposed:

(1) The address information is placed after the TLSA RDATA, so as to flexibly support multiple address information (since the TLSA resource record has only one, the RDLENGTH in the response message can control the size of the RDATA). In addition, in the DNS response message, the type of the address to be included should be indicated, which can be indicated by the TYPE in the response message. In the present invention, the value of TYPE is not specified in the present invention, but in practical applications, the following four types need to be distinguished by TYPE:

● Only contain TLSA resource records;

● Contains TLSA resource records and A resource records;

● Contains TLSA resource records and AAAA resource records;

● Contains TLSA, A, and AAAA resource records.

The number of A and AAAA resource records can be indicated by RDLENGTH in the legacy DNS response message. If the relevant address cannot be returned according to the request type, the error indication should be made in the response message, but the service address should be returned as much as possible. For example, the client requests A and AAAA resource records, but the server does not support IPv6, only the A resource record is returned. .

(2) Another embodiment is to carry the above address information in the Additional field of the DNS response packet.

3) Query mode

Based on the actual application scenario of this extension mechanism, the present invention proposes two query modes:

● Recursive server mode

In this mode, the client that wishes to query the TLSA record and return the service address information first sets the SA flag in the DNS request message. After receiving the DNS request message from the client, the recursive server finds that there is a SA flag set other than 00. It will be considered that the client wants to obtain the TLSA record and can obtain the address information of the service. The recursive server will further query according to the SA flag and pending query. The service domain name constructs a corresponding A record query request or (and) AAAA record query request, and sends the new request message independently to the corresponding authoritative server.

After receiving the TLSA and A/AAAA record query response, the recursive server returns to the client in two modes: 1) constructing a response message, in which the corresponding address information is filled according to the SA flag bit indication; 2) receiving the query of the domain name The response is immediately transmitted to the client in the return order.

● Authoritative server mode

In this mode, the recursive server sends the DNS query request message received from the client to the corresponding authoritative server without modification. The authoritative server constructs a response message according to the setting of the SA flag bit, and sends it back to the recursive server. And sent to the client.

●Compar

In the recursive server mode, the authoritative server does not need to support the mechanism proposed by the present invention, but its optimization degree to the basic protocol is low, that is, only the transmission overhead between the client and the recursive server is optimized; in the authoritative server mode, the authoritative server It is necessary to support the mechanism proposed by the present invention, and of course, to achieve maximum optimization, and significantly improve the efficiency of the entire domain name resolution process. For the latter, you should choose how to carry the address information (that is, whether it is placed in the Additional field) according to the specific implementation.

4) Example

In this embodiment, the client wants to access the HTTP server running TLS on port 443. The server domain name is www.example.com, and the corresponding domain name of the TLSA resource record is _443._tcp.www.example.com. Suppose the client does not have the service address of www.example.com and wants to access the service via IPv4 or IPv6. Therefore, the query through the two modes is shown in Figure 2.

In the mode (1), that is, the recursive server mode, the client first sends a DNS request, where the query domain name is _443._tcp.www.example.com, indicating that the domain name of the TTLS resource record is queried, and the request message includes the setting. The SA flag of 11 indicates that the client wants to query the A and AAAA resource records corresponding to the domain name. After receiving the recursive server, the data packet is split into a DNS request for querying the TCPA type and a DNS request for querying the ANY type of www.example.com (including the DNS request type of multiple records such as A and AAAA of the domain name). Both messages are normal DNS requests, so there is no SA flag. The authoritative server responds to it separately and sends it to the client by the recursive server.

In the mode (2), that is, the authoritative server mode, the client first sends a DNS request, where the query domain name is _443._tcp.www.example.com, indicating that the domain name of the TTLS resource record is queried, and the request message includes the setting. The SA flag of 11 indicates that the client wants to query the A and AAAA resource records corresponding to the domain name. The recursive server directly forwards the query data packet authoritative server. After receiving the query request, the authoritative server realizes that the recursive server wants to obtain the KSA of the domain name and the corresponding address information. So construct a response packet, which also contains the SA flag set to 11, which is then sent to the client by the recursive server.

The above embodiments are only used to illustrate the technical solutions of the present invention, and the present invention is not limited thereto, and those skilled in the art can modify or replace the technical solutions of the present invention without departing from the spirit and scope of the present invention. The scope of protection shall be as stated in the claims.

Claims

A DANE extended query method for supporting carrying service address information, comprising the following steps:

1) The client sends a DNS request message for querying the TLSA resource record, where the head of the DNS request message is provided with a service address flag bit;

2) The recursive server and the authoritative server respond to the DNS request message sent by the client, fill in the corresponding address information according to the setting of the service address flag, and return the address information and the TLSA resource record to the client through the response packet.
The method according to claim 1, wherein said service address flag is a two-bit flag, and the values are 00, 01, 10, and 11, and the meanings thereof are as follows:

00: The client does not request any address information of the server;

01: The client requests to carry the IPv4 address information of the server while returning the TLSA resource record, and the DNS response message includes not only the server's OTLS resource record but also at least one 32-bit IPv4 address;

10: The client requests to carry the IPv6 address information of the server while returning the TLSA resource record, and the DNS response message includes not only the server's OTLS resource record but also at least one 128-bit IPv6 address;

11: The client requests to carry the IPv4 and IPv6 address information of the server while returning the TLSA resource record. The DNS response message includes not only the server's TTLS resource record, but also at least one 32-bit IPv4 address and at least one 128-bit IPv6 address.
The method according to claim 1 or 2, wherein when the recursive server and the authoritative server respond to the client's DNS request message, the address information is placed after the TLSARDATA, or the above is carried in the Additional field of the DNS response packet. Address information.
The method according to claim 3, wherein for the manner in which the address information is placed after the TLSARDATA, the type of the address included by the TYPE is indicated in the DNS response message, and includes four types: only the TLSA resource is included. Record; contains TLSA resource records and A resource records; contains TLSA resource records and AAAA resource records; contains TLSA, A, and AAAA resource records.
The method of claim 4, wherein the number of A and AAAA resource records is indicated by RDLENGTH in the conventional DNS response message; if the relevant address cannot be returned according to the request type, an error indication should be made in the response message.
The method according to claim 1, wherein the step 2) is implemented in a recursive server mode: after receiving the DNS request message of the client, the recursive server constructs a corresponding A record query according to the service address flag and the service domain name to be queried. Request and / or AAAA record query request, and send a new request message to the corresponding authoritative server, hand After the server receives the TLSA and A/AAAA record query response from the authoritative server, it returns it to the client.
The method of claim 6 wherein the recursive server returns the TLSA and the A/AAAA record query response to the client in two modes: a) constructing a response message, wherein the corresponding address is populated according to the service address flag bit indication Address information; b) The query response to the domain name is immediately transmitted to the client in the return order.
The method according to claim 1, wherein the step 2) is implemented in an authoritative server mode: the recursive server sends the DNS request message received from the client to the corresponding authoritative server without modification, and the authoritative server according to the service address flag The setting of the bit constructs a response message and sends it back to the recursive server for transmission to the client.
A DANE extended query system supporting a service carrying address information, comprising a client, a recursive server and an authoritative server, wherein the client sends a DNS request message with a service at the head. Address flag bit; when the recursive server and the authoritative server respond to the DNS request message sent by the client, the corresponding address information is filled according to the setting of the service address flag, and the address information and the TLSA resource record are returned to the response packet. Client.
The system according to claim 9, wherein said service address flag is a two-bit flag, and the values are 00, 01, 10, and 11, and the meanings thereof are as follows:

00: The client does not request any address information of the server;

01: The client requests to carry the IPv4 address information of the server while returning the TLSA resource record, and the DNS response message includes not only the server's OTLS resource record but also at least one 32-bit IPv4 address;

10: The client requests to carry the IPv6 address information of the server while returning the TLSA resource record, and the DNS response message includes not only the server's OTLS resource record but also at least one 128-bit IPv6 address;

11: The client requests to carry the IPv4 and IPv6 address information of the server while returning the TLSA resource record. The DNS response message includes not only the server's TTLS resource record, but also at least one 32-bit IPv4 address and at least one 128-bit IPv6 address.