Domain Name System(DNS)

基本介绍

工作原理

If a request for “www.wikipedia.org" is made.

Root Servers

DNS is, at its core, a hierarchical system. At the top of this system is what are known as “root servers”.

Root servers handle requests for information about Top-level domains. So if a request comes in for something a lower-level name server cannot resolve, a query is made to the root server for the domain.

The root servers won’t actually know where the domain is hosted. They will, however, be able to direct the requester to the name servers that handle the specifically requested top-level domain.

So it will find a record for the “org” TLD and give the requesting entity the address of the name server responsible for “org” addresses.

TLD Servers

The requester then sends a new request to the IP address (given to it by the root server) that is responsible for the top-level domain of the request.

It will not find the final record in its files. However, it will find a record listing the IP address of the name server responsible for much more detail. This is getting much closer to the answer we want.

Find a record listing the IP address of the name server responsible for “wikipedia.org”

Domain-Level Name Servers

The name server checks its zone files and it finds that it has a zone file associated with “wikipedia.org”. Inside of this file, there is a record for the “www” host. This record tells the IP address where this host is located. The name server returns the final answer to the requester.

What is a Resolving Name Server?

In almost all cases, the requester will be what we call a “resolving name server” A resolving name server is one configured to ask other servers questions. It is basically an intermediary for a user which caches previous query results to improve speed and knows the addresses of the root servers to be able to “resolve” requests made for things it doesn’t already know about.

Basically, a user will usually have a few resolving name servers configured on their computer system. The resolving name servers are usually provided by an ISP or other organizations. For instance Google provides resolving DNS servers that you can query. These can be either configured in your computer automatically or manually.

When you type a URL in the address bar of your browser, your computer first looks to see if it can find out locally where the resource is located. It checks the “hosts” file on the computer and a few other locations. It then sends the request to the resolving name server and waits back to receive the IP address of the resource.

The resolving name server then checks its cache for the answer. If it doesn’t find it, it goes through the steps outlined above.

Resolving name servers basically compress the requesting process for the end user. The clients simply have to know to ask the resolving name servers where a resource is located and be confident that they will investigate and return the final answer.

Zone Files

Zone files are the way that name servers store information about the domains they know about. Every domain that a name server knows about is stored in a zone file. Most requests coming to the average name server are not something that the server will have zone files for.

If it is configured to handle recursive queries, like a resolving name server, it will find out the answer and return it. Otherwise, it will tell the requesting party where to look next.

The more zone files that a name server has, the more requests it will be able to answer authoritatively.

The zone’s $ORIGIN is a parameter equal to the zone’s highest level of authority by default.

So if a zone file is used to configure the “example.com.” domain, the $ORIGIN would be set to example.com..

Similarly, the $TTL configures the “time to live” of the information it provides. It is basically a timer. A caching name server can use previously queried results to answer questions until the TTL value runs out.

Record Types

Within the zone file, we can have many different record types.

SOA Records

The Start of Authority, or SOA, record is a mandatory record in all zone files. It must be the first real record in a file (although $ORIGIN or $TTL specifications may appear above).

The start of authority record looks something like this:

domain.com.  IN SOA ns1.domain.com. admin.domain.com. (
    12083   ; serial number
    3h      ; refresh interval
    30m     ; retry interval
    3w      ; expiry period
    1h      ; negative TTL
)

Let’s explain what each part is for:

domain.com.: This is the root of the zone. This specifies that the zone file is for the domain.com. domain. Often, you’ll see this replaced with @, which is just a placeholder that substitutes the contents of the $ORIGIN variable we learned about above.
IN SOA: The “IN” portion means internet (and will be present in many records). The SOA is the indicator that this is a Start of Authority record.
ns1.domain.com.: This defines the primary name server for this domain. Name servers can either be primary or secondary, and if dynamic DNS is configured one server needs to be a “primary”, which goes here. If you haven’t configured dynamic DNS, then this is just one of your primary name servers.
admin.domain.com.: This is the email address of the administrator for this zone. The “@” is replaced with a dot in the email address. If the name portion of the email address normally has a dot in it, this is replace with a “\” in this part (your.name@domain.com becomes your\name.domain.com).
12083: This is the serial number for the zone file. Every time you edit a zone file, you must increment this number for the zone file to propagate correctly. Secondary servers will check if the primary server’s serial number for a zone is larger than the one they have on their system. If it is, it requests the new zone file, if not, it continues serving the original file.
3h: This is the refresh interval for the zone. This is the amount of time that the secondary will wait before polling the primary for zone file changes.
30m: This is the retry interval for this zone. If the secondary cannot connect to the primary when the refresh period is up, it will wait this amount of time and retry to poll the primary.
3w: This is the expiry period. If a secondary name server has not been able to contact the primary for this amount of time, it no longer returns responses as an authoritative source for this zone.
1h: This is the amount of time that the name server will cache a name error if it cannot find the requested name in this file.

A and AAAA Records

The “A” record is used to map a host to an IPv4 IP address, while “AAAA” records are used to map a host to an IPv6 address.

1 2	host IN A IPv4_address host IN AAAA IPv6_address

example

So since our SOA record called out a primary server at “ns1.domain.com”, we would have to map this to an address to an IP address since “ns1.domain.com” is within the “domain.com” zone that this file is defining.

The record could look something like this:

1	ns1 IN A 111.222.111.222

Notice that we don’t have to give the full name. We can just give the host, without the FQDN and the DNS server will fill in the rest with the $ORIGIN value. However, we could just as easily use the entire FQDN if we feel like being semantic:

1	ns1.domain.com. IN A 111.222.111.222

In most cases, this is where you’ll define your web server as “www”:

1	www IN A 222.222.222.222

We should also tell where the base domain resolves to. We can do this like this:

1	domain.com. IN A 222.222.222.222

We could have used the “@” to refer to the base domain instead:

1	@ IN A 222.222.222.222

We also have the option of resolving anything that under this domain that is not defined explicitly to this server too. We can do this with the “*” wild card:

1	* IN A 222.222.222.222

All of these work just as well with AAAA records for IPv6 addresses.

CNAME Records

CNAME records define an alias for canonical name for your server (one defined by an A or AAAA record).

example

For instance, we could have an A name record defining the “server1” host and then use the “www” as an alias for this host:

1 2	server1 IN A 111.111.111.111 www IN CNAME server1

Be aware that these aliases come with some performance losses because they require an additional query to the server. Most of the time, the same result could be achieved by using additional A or AAAA records.

One case when a CNAME is recommended is to provide an alias for a resource outside of the current zone.

MX Records

MX records are used to define the mail exchanges that are used for the domain. This helps email messages arrive at your mail server correctly.

Unlike many other record types, mail records generally don’t map a host to something, because they apply to the entire zone. As such, they usually look like this:

1	IN MX 10 mail.domain.com.

Note that there is no host name at the beginning.

Also note that there is an extra number in there. This is the preference number that helps computers decide which server to send mail to if there are multiple mail servers defined. Lower numbers have a higher priority.

The MX record should generally point to a host defined by an A or AAAA record, and not one defined by a CNAME.

So, let’s say that we have two mail servers. There would have to be records that look something like this:

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

In this example, the “mail1” host is the preferred email exchange server.

We could also write that like this:

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

NS Records

This record type defines the name servers that are used for this zone.

You may be wondering, “if the zone file resides on the name server, why does it need to reference itself?”. Part of what makes DNS so successful is its multiple levels of caching. One reason for defining name servers within the zone file is that the zone file may be actually being served from a cached copy on another name server. There are other reasons for needing the name servers defined on the name server itself, but we won’t go into that here.

Like the MX records, these are zone-wide parameters, so they do not take hosts either. In general, they look like this:

1 2	IN NS ns1.domain.com. IN NS ns2.domain.com.

You should have at least two name servers defined in each zone file in order to operate correctly if there is a problem with one server. Most DNS server software considers a zone file to be invalid if there is only a single name server.

As always, include the mapping for the hosts with A or AAAA records:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

PTR Records

The PTR records are used define a name associated with an IP address. PTR records are the inverse of an A or AAAA record.

CAA Records

CAA records are used to specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain.

Domain Name System(DNS)

基本介绍

相关术语