Shulou(Shulou.com)06/02 Report--

Recently, I discussed the domain name registered with my friends and remembered the DNS server. I was not very proficient when I was studying at that time, so I took advantage of this time to review the following once again. Let's take a look at the DNS server.

The directory structure of this article is as follows:

What is a DNS server? When do you want to use the DNS server? why use the DNS server? Who can use a DNS server? How to use the DNS server? 1. What is a DNS server?

DNS (Domain Name Server, domain name server) is a server that translates domain names (Domain name) and corresponding IP addresses (IP address). So what is the domain name Ni?

Domain name:

In popular terms, the URL entered every time you surf the Internet can also be understood as a domain name, while Baidu defines a domain name as a string of names separated by dots, usually containing the name of the organization, and always including a two-to three-letter suffix to indicate the type of organization or the country or region in which the domain is located.

two。 When should I use the DNS server?

Because of our memory, now when we go to the Internet, we always remember several domain names, but we don't remember the IP corresponding to each server. So when we are using domain names to access other hosts, the DNS server has quietly played a role, the DNS server will convert the domain names we entered into the corresponding IP and then access other people's hosts.

So when within an enterprise, if you want many hosts to access each other through hostnames, you have to build your own DNS server.

3. Why use a DNS server?

At the beginning of the network, only a few university laboratories joined the network, so people could contact each other by remembering very few IP addresses, and each host at that time had a file for hosts for local resolution, and now it still has this file for local domain name resolution. Where the files are located under these two systems.

Linux system: / etc/hostsWindows:%windir%\ System32\ drivers\ etc\ hosts

But with the development of information technology, more and more users join the network, not all of their memories can remember each other's ip addresses, and if you continue to use the original method (using hosts files), there are more and more entries in hosts files, and each query is becoming more and more tedious, so there is an organization IANA (The Internet Assigned Numbers Authority, Internet Digital Distribution Agency). IANA to save the relationship between each user's hostname and IP entries. Therefore, people no longer have to write their own hosts files, but only need to set a planning task (crontab) to download hosts files from the IANA server to the local place at regular intervals. Although this is feasible, the development of the Internet is explosive, and the growth of users is a geometric multiple, so when the number of users increases again, the strategy of IANA will no longer work. So BIND (Berkeley Internet Name Domain, Berkeley Internet namespace) is developed to use BIND software to build domain name servers. The construction method is very similar to the directory structure of Linux, using an inverted tree structure, as shown below:

Of course, there are many top-level domains I do not list, so now using BIND to divide each domain name into different branches, this not only reduces the pressure on the root server, but also very easy to find and manage, and the root (.) will still be able to manage each domain name, but it can only manage the first-level domain, which can greatly reduce the pressure on the root server. Then we can find the information we need by constantly searching one by one. And IANA no longer provides the original hosts files, becoming a global domain name provider, managing DNS domain name roots and .int, .arpa and other resources. There are 13 related root servers, one of which is the primary root server in the United States. The remaining 12 are secondary root servers, of which 9 are in the United States, 2 in Europe, in the United Kingdom and Sweden, and 1 in Asia in Japan.

4. Who can use a DNS server?

It's hard to answer this question, but I think if you're interested or want to know, you can contact the DNS server.

It's time to really learn more about and configure the DNS server.

5. How do I use the DNS server?

It is a complex problem for how to use the DNS server, so let's learn more about the DNS server through the following steps

First of all, we need to know that the port used by the DNS server is (53max UDP Magazine 53max TCP;) is used by BIND software and is a protocol at the application layer, using the Cmax S architecture. And when we install BIND, we will be able to start the DNS service through the named service, of course, for the real understanding of the DNS server, we still need to know some nouns first, and then we will talk about it slowly.

FQDN:Fully Qualified Domain Name, which is the domain name mentioned above.

Forward parsing: FQDN = = > IP indicates the process of parsing to IP through the DNS server FQDN

Reverse parsing: IP== > FQDN indicates that FQDN is queried from IP through DNS server

Domain: logical concepts, domains

Zone: physical concepts, regions

Server type of DNS: 1 primary DNS server (master) 2 secondary DNS server (slave) 3 cache server 4 transponder (forward)

The following diagram can help us know what domain and zone are.

We can see that there are a lot of resources under each zone. When we visit the resources below, the corresponding host answers us, and each zone has its own authorization server. When we want to query the FQDN in the DNS server, we will return two types of answers, namely, Authority Answer,AA and non-authoritative answers.

First, install BIND software

BIND software can run on most Linux hosts, and in RHEL6.5 and later, the installation file of BIND service is included on the CD of the system.

We first use a simple method to install (yum), first look at the bind-related software packages.

$yum list | grep bind

The functions of some major software are as follows:

Bind: provides the main procedures and related documents for DNS services

Bind-libs: provides the function libraries that bind and bind-utils need to use

Bind-utils: provides testing tools for DNS servers, such as nslookup, etc.

Next we will install bind

$yum install-y bind

2. Configure BIND software

After the installation of the bind software, there will be two very important paths, one is the main configuration file / etc/named.conf and the other is the working directory / var/named.

1. Main configuration of simple DNS server

This is the main configuration file used to start the named service. For a simple DNS server, it is mainly divided into two parts of the definition, the global definition and the zone definition.

Use the following definition for globally defined segments.

Options {directory "/ var/named";}; Note: the named.conf configuration file requires a semicolon at the end of each line.

Configuration means that the Resource Record (RR) files for each region are placed in the / var/named/ directory.

So what exactly is RR, Donzini?

Meng. Remember to look down first

three。 Configuration file

In the / etc/named.conf configuration file, in addition to the global definition just defined, it is the definition of each zone.

Usually the simple definition of each zone is in the following format. Zone "ZONE_NAME" IN {type master | slave | hint | forward; file "ZONE_NAME.zone"}; Note: type indicates the type of DNS server in the region. File is where the RR of this area is placed, the relative path. In particular, the following zone is defined to indicate that this is a dns server for the root domain. Zone "." IN {type hint; file "named.ca"}

Of course, DNS's configuration file also supports the use of acl to customize access control lists. And there are four lists by default, none,any (any host), local (native), and localnet (local network). The definition is as follows:

Acl acl_name {statement;}

If there is no named.ca file in the / var/named/ directory during installation, you can use the dig command to generate the named.ca file. You need to be able to access the Internet, otherwise you can't query the root server.

[root@rs1 named] # dig-t NS. > / var/naemd/named.ca

First build the simplest DNS server, that is, the cached DNS server. Any complex DNS server is becoming more and more difficult by a simple cache server. I think learning is the same truth.

Cache DNS server: not responsible for parsing any zone (except (native) localhost)

/ etc/named.conf is configured as follows

Options {directory "/ var/named";}; / / forward parsing native zone "localhost" IN {type master; file "named.localhost";}; / / reverse parsing native zone "0.0.127.in-addr.arpa" IN {type master; file "named.local";}

Reverse parsing is much more complicated than positive phase parsing, and the region name is relatively special, which is network broken name + in-addr.arpa.

The next step is the RR file for each area mentioned above, in which there are several special definitions.

TTL:Time-To-Live the time to live of each record SOA:Start Of Authority, the initial authorization record, the address record of A:Address IPV4, the address record of AAAA:IPV6, the PTR:Pointer reverse resolution record, generally cannot appear with A record, definition of NS:Name Server dns server, definition of MX:Mail eXchange mail CNAME: canonical name

For each resource record file, the first line defined should be this line

ZONE_NAME [TTL] IN SOA localhost. (ZONE_NAME 's DNS server name) admin.localhost. (administrator's mailbox) (2018091501; (version number) serial 1H; (refresh time) refresh 5m (retry time, should be less than refresh time) retry 1D; (timeout, think the main DNS server is down after a few days of setting attempt) expire 1H; (negative answer, how long does the other party cache) minimum)

If you initially have some files under / var/named/, you can see the following corresponding symbols

TTL 600: set the global TTL time. After definition, you can no longer use TTL$ORIGIN: the default supplementary field. If you use an incomplete FQDN in some places, add the field defined by ORIGIN later. The default is the zone name defined in / etc/named.conf (ZONE_NAME) @: the area defined in / etc/named.conf configuration file.

Therefore, / var/named/named.localhost is defined as follows:

$TTL 600 @ IN SOA localhost. Admin.localhost. (20180913 1H 5m 1D 1H) IN NS localhost.localhost. IN A 127.0.0.1 if the definition of each row is the same as the first column of the previous row, it can be omitted

Corresponding reverse parsed configuration file

$TTL 600 @ IN SOA localhost. Admin.localhost. (20180913 1H 5m 1D 1H) IN NS localhost.1 IN PTR localhost.

Note: 1 indicates the host name, as we said above, if it is not fully written, it will be added with ORIGIN by default, so all of it is 1.0.0.127.in-addr.arpa.

At this point, we have built the simplest caching DNS server. You can use the commands that come with bind to see if there is anything wrong with the configuration file.

Named-checkconfnamed-checkzone zone zone_file

Then we use the dig command to test it

@ is specified as my local server ip, so specify a different ip for different host, and query the help documentation for other details.

Next, let's discuss a more complex question, what happened to a FQDN== > IP?

Iterative query: like the ordinary iterative algorithm, it is to request again and again.

Recursive query: send only one request, one reply

For the client that initiates the query request, the query is triggered only once and the result is obtained once, which is the recursive query, while for the dns server in the current domain, the result is obtained through repeated iterative search, so it is iterative query.

This is a process that can be queried. What will happen if dns cannot find the record we want to query?

For this, an explanation is given in the minimum of the SOA record, for example, we query ftp.a.com, but when dns queries from the root to the domain of a.com, it is found that there is no subdomain of ftp.a.com, so a.com. The domain will give the dns server a negative answer, and then the dns server will answer the negative to the client.

The following is the main process for a dns service to accept a request and then query it.

Detailed introduction of dns server query

1. If the query request is the data in the area that the machine is responsible for, the result should be returned by querying the area data file.

two。 If the query request is not the data in the area to which the machine is responsible, query the cache

3. If there is no answer in the cache, make a query request to the root and iterate over and over again

So let's explore the functions of dns one step further.

We have built a simple DNS cache server above, and now let's turn it into a master DNS server. The steps are very simple.

1. Add our forward resolution domain name and reverse resolution domain name to the main configuration file. two。 Under the working directory, add the appropriate data file. 3. Restart the service, or reload it.

Zone "athlete.run" IN {type master; file "athlete.run.zone";}; zone "159.168.192.in-addr.arpa" IN {type master; file "athlete.reverse";}

Then there is the working directory file, which I define as athlete.run.zone and athlete.reverse, so edit two files.

This is the athlete.run.zone file.

$TTL 60 @ IN SOA ns1 admin (2018091401 1m 5S 1H 1D) IN NS ns1 IN NS ns2 IN MX 10 mailns1 IN A 192.168.159.143ns2 IN A 192.168.159.146www IN A 192.168.159.143mail IN A 192.168.159.143

All that's left is the athlete.reverse file.

$TTL 600 @ IN SOA ns1.athlete.run admin.athlete.run (2018091403 1D 5m 7D 1D) IN NS ns1.athlete.run.143 IN PTR ns1.athlete.run.143 IN PTR www.athlete.run.

Last

# systemctl reload named or # systemctl restart named

Finally, use the dig tool to test it, of course, I may write these two files relatively simple, but can be used.

After introducing so many configurations of DNS, let's change the subject and find out.

If you install bind through YUM, you will be installed with another tool called rndc by default.

Rndc:remote name domain controller, remote name domain controller

You can see the nature of this job by name, so for security reasons, let's use this artifact for the sake of using tcp's 953 port 953/TCP.

First of all, the use of rndc also has a configuration file, where is it?

# rpm-ql bind | grep rndc

However, at the beginning, the file in the / etc/rndc.conf directory does not exist, so we need to implement it manually through the rndc command

It is worth mentioning that if both files exist, you will be warned every time you execute an order, which is annoying, so you can handle it yourself.

Rndc-confgen > / etc/rndc.conf is fine.

It's worth mentioning that the last few lines in this file need to be copied in / etc/named.conf, so check the corresponding vim operation yourself. If everything is done, you can re-read it with a command, and of course you can restart it, but in large-scale work, restarting an application on the server will cause too much loss, so we need to re-apply it by rereading the configuration file.

# rndc reload

The appearance of this flag is a success, if it fails, then check the log file in detail!

# cat / var/log/message

For the other major commands used by rndc, I also summarize them as follows:

Stop: stop DNS server reload: reload configuration file and zone file reload zone: reload a zone file reconfig: reload configuration file and updated zone file status: view details of dns querylog: use query log (not recommended) flush: clear cache

There are some other help documents to use, check it out.

At this point, you should have an intermediate understanding of a DNS server, and the next discussion is a further topic for us.

Subdomain authorization, we can apply for a subdomain by ourselves, such as a.org, so we can add up to 127subdomains for this subdomain, that is to say, the depth of the tree is up to 127layers. In each different deep-seated domain, the authorization is authorized in the upper subdomain. For example, in the example above, the subdomains www.d.org and ftp.d.org of d.org are the subdomains of d.org, respectively, and the dns server authorization of the www.d.org subdomain is done by d.org. In the next step, edu.www.d.org can also make www.d.org authorized subdomains. The dns profile for the corresponding authorized subdomain is defined in the subdomain's own zone.

Forward DNS server

The understanding of this is relatively simple, that is, add forwarders {IP;}; in the main configuration file. The special thing is that the left and right sides of the semicolon need a space. Multiple items can be written in the semicolon, but need to be separated by semicolons. In this way, the local query request can be realized, and this opportunity can be forwarded to the DNS server of the specified IP to query. It is worth mentioning that there is also a category for forwarding.

First: if DNS1 goes to DNS2 to request resolution, and DNS2 does not respond, DNS1 will resolve it itself.

Only: if DNS1 goes to DNS2 to request parsing and DNS2 does not respond, there will be no query result (hopefully all will be given to someone else. )

So if we define forwarding, then add a line of forwarding type, and as a result, we can achieve forwarding.

Forward first | only;forwarders {IP}

Of course, if you put it in the global option segment, it will be forwarded globally, and a specific region will forward it when it is queried.

Master-slave DNS server

For every frequent online server, corresponding redundancy should be made to avoid sudden downtime of the primary server or data loss, but the peculiar thing about the DNS server is that when the primary DNS server goes down, the secondary DNS server tries to reconnect with the primary DNS server many times. If there is no response, the slave DNS server will go down along with the primary DNS server. (two nights and two flights. )

Therefore, we should do a good job of the secondary DNS server to save the data files of the primary DNS server at all times, so as to avoid data loss caused by the downtime of the primary DNS server.

So when it comes to transport, there are two types of zone transfers for DNS servers:

Full incremental transfer: files initially transferred by axfr

Incremental transfer: ixfr when files are transferred from the server in an area, subsequent transfers will be incremental

So we can use the dig command to view the information about the area I defined.

You can see so much important information, so you can't expose it to others in vain, so we can only send it to a specific host, so you need to add it to the main configuration file.

Allow-transfer {IP;}

To define a master-slave DNS, the master server is just what we have been using. The configuration of the slave server is very simple, just start another computer or virtual machine, then use yum to install bind, and add such an area to the configuration file.

Zone "athlete.run" IN {type slave; masters {IP;}; file "slaves/athlete.run.zone"

Of course, slaves is automatically created for us when we install bind, so we can either define it or define the place ourselves, but it is important to note that the processes started by the DNS server belong to named, so the files we create should also be named and have permissions of 640. For such a file can not exist at first, and then start from the server, you can see the corresponding file generation. Of course, when I was doing the experiment, I encountered this phenomenon many times. The file sent from the master server is in the format of data, but it is an ASCII TEXT file, so we need to add such a definition to the master configuration file of the slave server.

Masterfile-format text

In this way, everything is done, and when we change the data file of the master DNS server and increase the version number, the master DNS server will actively remind the DNS server to update the file. Of course, this still requires some additional configuration.

Master-slave synchronization:

Master server: authorization allows synchronization, has NS records from the DNS server, and authorization allows zone delivery

Slave server: define zone

In this way, master-slave replication can be completed.

The last one is the most popular application of DNS server so far, CDN.

CDN:Content Delivery Network, content delivery Network

Like this, it was originally a DNS server, but forcibly split it into two different DNS server domains. The person on the left who accesses the DNS server will then let it access the DNS server on the left according to some judgment, while the person on the right is the same, so this can also be called intelligent DNS, also known as DNS brain fissure. What's the use of this, Nini?

This figure shows that when users in different regions request the same page, the DNS server will detect according to the geographical location of the client, and then return the IP address of its local data file, which reduces the access delay and is equivalent to pushing the data to the door of every Internet user.

With so many introductions, how on earth do you define different regional niches?

View VIEW_NAEM {match-clients {I network segment / mask;}; / / definition of some areas}

Then the matching client will go to the corresponding view for parsing.

There are also points to pay attention to when using views:

1 you may need to parse the same region within more than one view, but use different regions to resolve library files.

two。 Once views are used, all zone can only be defined in view

3. It is only necessary to define the root zone in the view that matches to the client that allows recursive requests

4. After the client request arrives, check the list of clients served by each view from the top down

First of all, go to bind's website to download the bind software package.

Extract it to our local, and then enter the same as the ordinary application software, configure make & & make install

The main reason is that if we install it manually, nothing will be provided to us, which is far less concise than yum, but we can use our own custom software. We mainly need to do the following steps.

1. Modify the PATH environment variable to output the new search path of the binary program

two。 Export library file search path

3. Export header file search path

4. Export help file manual search path

5. Create a profile

At this point, we have finally finished talking about the DNS server, but we still believe that we only know a little bit. I hope we can learn more.

Do not forget the original ideal and ambition, sharpen and move forward.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.