The concept and mechanism of domain name (2)

2.6. Resource records

The domain name marks the node, each node has the resource information set, some sets can be empty. The resource information set is associated with the special name of the detached resource set (RR). There is no relationship between the RR order in the set, the tag has this thing, it doesn't have to be saved by name server, Resovler or other parts of DNS, only here. The specific RR we think has the following:

Owner	RR can be found by the domain name
It is a 16-bit value that specifies the type of resource within the RR, which refers to an abstract resource with the following specific tags:
A	Host Address
CNAME	A uniform naming of a quasi-name
HINFO	Tag is used by the host to use a folded CPU and OS
Mx	Mark a mail exchange resource for a domain
Ns	Authoritative authenticated name server for this domain
Ptr	Pointers to other domain space
Soa	The beginning of the Mark Area authentication Authority
Class	It is a 16-bit value, a tag protocol family or an instance of a protocol, which is used in to represent the Internet system, and CH represents the chaos system
Ttl	It is the lifetime of the RR, which is a 32-bit integer, in seconds, and it is primarily used for resolver cache RRs for how long
It is a type, sometimes a data-dependent class, that describes the following resources:
A	For class is in, it is a 32-bit IP address, and for Ch It is a domain name followed by a 16-bit octal chaos address
CNAME	Domain name
Mx	The host name of the Mail Service resource for a domain, with a 16-bit configuration value after the host name
Ns	Host Name
Ptr	Domain name
Soa	Some domain

The name of the owning resource is usually implicit and does not form part of the RR. TTL time only affects the data in the buffer and does not affect the stored authentication data in the zone. The TTL is usually set by the administrator, and Ttl=0 indicates that buffering is prohibited. The data within the rdata is a mixture of binary strings and domain names. Domain names typically use pointers to other data within DNS.

Textual representation of 2.6.1. RR

RRs are represented in binary form in DNS, and are stored in the name server or resolver in a compressed-encoding manner. In this article, we use the same representation as in the main file, the uncompressed method, to display the contents of the RR. At the beginning of the line, the person who owns the RR, if vacated, indicates that the owner of the bank RR and the owner of the RR above is one. followed by the class of Ttl,type and RR. The rdata part of the RR is based on the presentation type of the current data. Here are some examples of RR:

Isi.edu. MX Ten VENERA. Isi.edu.

MX Ten Vaxa. Isi.edu.

VENERA. Isi.edu. A 128.9.0.32

A 10.1.0.52

Vaxa. Isi.edu. A 10.2.0.27

A 128.9.0.33

One of the things we noticed about the MX part is that the rdata part of it is a 16-digit number followed by a domain name. And the rest will not speak. This example shows 6 RRs, and the third domain has two RRs. Here is an example that shows how to represent a different class:

Xx. Lcs. Mit.edu. In A 10.0.0.44

CH A mit.edu. 2420

2.6.2. Aliases and uniform naming

The existing systems sometimes have different names for the same resources, not only the host, but also the mailbox, and different names point to the same location. Most systems can specify a single name for multiple names, and the other is aliases. The domain Name System provides the use of a uniform naming mechanism (CNAME RR), CNAME RR marks its owner name as an alias, and indicates the corresponding uniform naming in the Rdata section. If a node exists CNAME RR, there should be no other data, which guarantees that the uniform name and its alias cannot be different. This also enables buffered CNAME to provide services without retrieving the authoritative server. In the case of a CNAME RR, DNS software checks if a domain-related resource is not available, checking that there is a CNAME in the resource set that has a matching class, and if so, include the CNAME record in the answer returned by the name server and start a new query based on the data specified in CNAME. Let's look at an example, assuming that the name server processes queries against USC-ISIC.ARPA, it requires query a information, and the following are the contents of the RR:

Usc-isic. ARPA in CNAME c.isi.edu

c.isi.edu in A 10.0.0.52

All two RRs are returned as responses, and only the CNAME query returns CNAME.

A domain name in a RR that points to another name should point to the primary name rather than the alias, which avoids too many steering queries in the query. For example, for the above RR, its in-addr.arpa record should be:

52.0.0.10.in-addr. ARPA in PTR c.isi.edu

The last point is c.isi.edu, not usc-isic.arpa, of course a robust domain name software will not fail because of the CNAME of the cycle.

2.7. Query

A query is a request that sends a response to a name server. On the Internet, this request is transmitted either by UDP or TCP, and the response of the name server can be the result of the query, or the address of another moniker, or an error message. Typically, a user does not send a request directly, but instead sends a request to the resolver, resolver one or more requests to the name server in turn, and handles the error condition. Requests and responses have a standard format, which includes a header and a fixed domain, followed by four parts that include query parameters and RRs. The most important field in the header is something called an operator, which indicates what action to take. In all possible 16 values, the standard query is required, the reverse query and the status query are optional, a full query is obsolete, and the others have not been specified. The four sections mentioned above are as follows:

Question	Include query name and other parameters
Answer	RR that includes query results
Authority	Includes a RR, but this RR includes a different name server
Additional	Includes information that is useful when using RRS in other parts

Note that depending on the operator (code) in the header, the contents of these sections may be different, but the format is the same.

2.7.1. Standard Query

The standard query specifies a target domain name (QNAME), a query type (qtype) and a query class (Qclass), and then looks for the appropriate RR, which accounts for the vast majority of DNS queries, which are generally referred to if there are no special instructions.

The Qtype and Qclass fields are 16-bit and are a superset of the defined type and class. Qtype fields can include:

• : The RR matches just that type matches the corresponding types. (e.g., A, PTR).

• AXFR: A specific area specified by Qtype

• MAILB: All mailboxes related to RRs

• *: All RR types

Qclass fields can include:

• : RR that matches the corresponding class

• *: All RR Classes

Using the query domain name, qtype and Qclass, the name server checks for the appropriate RR, and the server can return a server name that may include the corresponding RR. For example, if you want to send an email to Mockapetris@ISI.EDU, the application will ask resolver for information about isi.edu, which will produce the following query: Qname=isi.edu,qtype=mx,qclass=in, Possible areas of response may be:

Isi.edu. MX Ten VENERA. Isi.edu.

MX Ten Vaxa. Isi.edu.

In addition to this, there are:

Vaxa. Isi.edu. A 10.2.0.27

A 128.9.0.33

VENERA. Isi.edu. A 10.1.0.52

A 128.9.0.32

The server assumes that if the requester wants to receive mail exchange (Exchange) information, it will immediately request the address of the Exchange server, so two were found. Note the qclass=* type of query, because the server cannot know the information available to all classes in the domain Name system and it is not the authentication authority of all classes, so such queries cannot be authenticated.

2.7.2. Reverse query (optional)

A name server can reflect the mapping relationship between resources and domain names. Standard queries can map domain names to SOA RRS, and corresponding reverse queries map SOA RRs to domain names.

This implementation is optional for the name server, but all name servers must be able to understand the reverse query message at least, not the message that is sent. The domain Name system does not guarantee the full and unique nature of the reverse query, because the system is arranged according to the domain name rather than the host address or other resource type. Reverse queries are primarily used for debugging, as well as for activities related to database support. A reverse query can not return the correct TTL, nor does it indicate that the RR is a member of a collection, and we do not know if it is unique, so the result of the reverse query is not buffered. The reverse query is not appropriate for mapping the host address to the host name, and the IN-ADDR.ARPA domain is used at this time.

2.8. Status query (in the experiment)

Not defined

2.9. Complete query (OBSOLETE)

Here is not to say, the future may support the redesign (redegsign) service.

3. Name server

3.1. Introduce

The name server holds a lot of information that makes up the domain database. The database is divided into zones, which are saved on different servers. The server can have different optional functions and data sources, its most basic work is to respond to the query, its response is a simple form, the response can only be based on local data, or other related server to make. A given region can be based on a different server to ensure its effectiveness, through the management commands, users can query by at least two servers saved in a district of data, multiple servers to save information to ensure proper redundancy.

A given name server usually supports one or more zones, but only serves as a small subset of the domain tree's authentication authority. It has a buffer of non authenticated information, which is the other part of the domain tree, in response to the query when the name server will give what it is certified, what is it buffered.

3.2. How the database is divided into district

There are two ways to divide a database, one is based on class, the other is separated by the nodes in the namespace, and we call this partition cut. Class (which we refer to as classes) is relatively simple, traditionally, namespaces and all classes are one thing, and delimited classes can be considered as a series of parallel namespace trees. The usual reason to create a new class is to create a new data format for an existing type or to separate the existing namespaces. In a class that can be cut at two adjacent nodes (what we call segmentation), after all the segmentation is complete, each group of connected spaces is a separate zone. This area is the authoritative authority for all data in the connected area.

This approach means that all of the zones have at least one node, and the domain name is connected to all nodes within a particular zone. Given the tree structure must have a point closer to the root, we use this point to mark the area. Although it may be of little use, you can divide each domain name into different areas, or you can have all nodes in one area. In addition, the database can also be divided according to the control of the name of different enterprises, some enterprises may want to manage a certain part of the domain name subtree, then the enterprise can add or remove the corresponding domain name, you can add their own next level domain name. Of course, the enterprise can also be the name of their own management space for further division.

3.2.1. Technical issues

There are four parts of the data describing one area:

1. Authentication data for all nodes in the zone

2. Defines the data for the top node in the zone (this data can be considered part of the certified data)

3. Describes data that represents a child area

4. Accessing data from the server's glue (also known as "related" data)

All of these data are represented as RR, and all extents can be described in the form of a RR set. By transmitting RRs, you can transfer the entire zone, either by transferring the corresponding text file via FTP or by transmitting it over a network message. The authentication data for a zone is all RR, which is associated with all nodes in the tree, or is the node association after the segmentation. The RR that describes the top node is particularly important for district management, which has two types, name Server RR, which describes the list of servers in the zone, and the SOA RR, which describes the management parameters of the zone.

The RRS that describe the segmentation are NS RR, because the segmentation is done between the nodes, and all RRs are not part of the zone authentication data and should be consistent with the corresponding top nodes in the child area. Because the name server is usually related to the district boundary, the NS RR is only available on the top node of some districts. In the data that makes up a zone, the NS RR appears at the top node and at the edge of the boundary, not elsewhere.

One of the objectives of a zone structure is to have enough data in any zone to establish communication with any child area. That is, the parent area has enough information to access any of the name servers in the child area. The NS RR names the child zone server, which is not sufficient to complete the above requirements, and therefore has a name but still does not know the address. In particular, if the name of the server is itself within the child area, we will not be able to know any information through it. To address this problem, an associated RR is included in the zone, which is not part of the authenticated authoritative data, but it represents the address of the server. If the name server name is under segmentation, these RRs are required.

3.2.2. Management issues

When some organizations want to master their own domain, the first step is to mark the appropriate parent, and then get permission to manage the nodes in the parent zone. There are no specific technical problems when it comes to management, but there are some rules that can be used for midsize areas without these rules, but small is not. This article does not specifically discuss this issue, you are interested to refer to the relevant information.

Once you have selected the name of the child area, the new management node for this zone is supported by a redundant name server. Note: The server for a zone is not required to have a name on the host in this domain. In many cases, a zone wants to be more easily accessible to the best place to spread the content, not to be lumped together. Now many countries name servers are placed in another country, so that when the name resolution is not to send the request to the remote host. The final step in the configuration is to select the NS RR and the associated RR.

3.3. Deep Name server

3.3.1. Queries and Responses

The main content of the name server is to respond to standard queries. Queries and responses have a dedicated format, and queries include Qtype,qclass and QName, which describe the type of data that is required, classes (class), and names. The response of the server depends on its support for circular queries that are not supported:

• The simplest is not to support the circular query, it returns either local information, or an error code, tell the user the information you want is not here, and then return to a neighboring server address, let users go there to check.

• If you support circular queries, the name of the server if the appropriate information can not be found locally, instead of the user to the other server to query, then it is in place of the user to play the role of Resolver, until the end of the results found (and may not be the result, then return error), and returned to the user.

Use circular queries to support both client and server. This information is exchanged through two bits in the query and response:

• If a circular query is allowed to set the RA bit, the server can set the bit directly regardless of whether the customer makes a request

• In the query, if the request loop query sets the RD bit, the customer will be able to cycle the query request only after they know that the server side supports a circular query

The customer can set both RA and RD bits in the response to confirm that the circular query request is supported. Please note that the server does not loop itself when the customer does not indicate an RD bit.

If a circular query is requested and a circular query is supported, the response to the query is one of the following:

• Query-specified CNAME RR has multiple aliases

• The specified name server does not exist

• Temporary error

If you do not request a circular query or do not support circular queries, the response can be:

-Authentication authority server indicates that the name does not exist

-Temporary errors

It also provides information about whether the queried RR is coming from one area or is not being cached, and that the name server indicates that a server has the same record, and that the server is closer to the ancestor of the name being queried.