Common DNS Configuration

In the previous article we built a master-slave DNS, but in the actual application, only build up is not enough, the DNS to add a variety of records is the daily maintenance of DNS more common problems, such as the addition of a records, cname,mx,ptr and so on.

Add a record

In the master-slave configuration, the primary DNS is typically modified to synchronize the primary DNS data from DNS.

Edit the Zone profile of the master node to add a row of records directly at the end, with the serial value + 1:

2001; Serial # Change the serial value of the original 2000 to 2001, making the slave synchronous

$ORIGIN test.com.shanks a 1.2.3.4op a 1.2.3.4t a 1.2.3.4trying a 192.168.1.2 # Add a row of records

The rndc Reload is executed to make the configuration file effective, and the zone file on the slave is also updated.

Validation results:

[Email protected] ~]# host trying.test.com 127.0.0.1Using domain server:name:127.0.0.1address:127.0.0.1#53aliases: Trying.test.com has address 192.168.1.2

Add a CNAME record

As with the add a record, a row of records is appended to the end of the file:

Tryingstuff CNAME trying.test.com. # at the end of the "." Cannot be ignored

Will serial +1

Execute RNDC Reload to make the configuration file effective.

Validation results:

[Email protected] ~]# host tryingstuff.test.com 127.0.0.1Using domain server:name:127.0.0.1address:127.0.0.1# 53aliases:tryingstuff.test.com is a alias for trying.test.com.trying.test.com have address 192.168.1.2

Add MX record

Similarly, modify the zone configuration file, serial +1, the zone file at the end of adding a row of results:

# vim/var/named/chroot/etc/test.com.zonemx MX 3 192.168.1.100 # 3 indicates priority, lower number, higher priority

Perform RNDC reload, test results:

[Email protected] ~]# host mx.test.com 127.0.0.1Using domain server:name:127.0.0.1address:127.0.0.1#53aliases: Mx.test.com Mail is handled by 3 192.168.1.100.test.com.

adding PTR records

In many scenarios it is necessary to use PTR reverse parsing, where the PTR record is added on the original basis:

Edit the View profile on master to include the PTR zone:

[[email protected] etc]# cat view.conf view  "View-test"  { zone  " test.com " {    type master;    file " Test.com.zone ";     allow-transfer {    192.168.1.11;};   notify yes;  also-notify {    192.168.1.11;};}; zone  "168.192.in-addr.arpa"  {  #  here is the added reverse resolution domain name, which represents resolving 192.168 segments of the host          type    master;         file     "168.192.zone";  # zone  file name          allow-transfer {                 192.168.1.11;        };         notify  yes;        also-notify {                 192.168.1.11;        };   };};

After you have added a domain with PTR, you need to specify the resolved content in the specified 168.192.zone file:

[[email protected] etc]# cat 168.192.zone  $TTL  3600        ; 1 hour@                  IN SOA  op.test.com. dns.test.com.  (                                  2000        ; serial                                 900         ; refresh  (15 minutes)                                   600        ; retry  (10  minutes)                                  86400       ; expire  (1 day)                                   3600       ; minimum  (1 hour)                                  )                           NS      op.test.com.100.1   in   ptr   a.test.com .  #  added reverse parse record, corresponding IP is  192.168.1.100

Modify the properties of the PTR zone file on master:

Chown named.named 168.192.zone Rndc Reload

When the node on slave is not synchronizing the PTR zone file on master, the zone configuration file needs to be set first.

Modify the configuration of the slave node/var/named/chroot/etc/view.confg to increase the zone configuration of PTR:

Zone "168.192.in-addr.arpa" {type slave;       Masters {192.168.1.10;};       Masterfile-format Text; File "Slave.168.192.zone";};

Execute RNDC Reload, synchronize ptr zone file, at this time, you can see slave synchronized files on slave.

[Email protected] ~]# cat/var/named/chroot/etc/slave.168.192.zone $ORIGIN. $TTL 3600; 1 hour168.192.in-addr.arpa in SOA op.test.com. Dns.test.com. (2001; serial900; refresh (minutes); retry (minutes) 86400; Expire (1 D ay) 3600; Minimum (1 hour)) NS op.test.com. $ORIGIN 168.192.in-addr.arpa.100.1 PTR a.test.com.

Test parsing results:

[Email protected] ~]# host 192.168.1.100 127.0.0.1Using domain server:name:127.0.0.1address:127.0.0.1#53aliases: 100.1.168.192.IN-ADDR.ARPA domain name pointer a.test.com. #返回的结果正确

Using DNS to implement load balancing for services

In the case of multiple IPs for a domain name, DNS polls multiple IPs, which enables the load balancing function. DNS polls only according to its own configuration information and does not detect whether the backend service nodes are available.

Add an A record directly on the zone profile on master, serial The value +1.

T A 192.168.1.111

[Email protected] etc]# host t.test.com 127.0.0.1Using domain server:name:127.0.0.1address:127.0.0.1#53aliases: T.test.com has address 192.168.1.111 # back two lines of information t.test.com has address 1.2.3.4

Configure DNS view (smart DNS)

Intelligent DNS refers to the best service site that is returned to the user by judging the source of the user. The simple thing is to allow the different users of Unicom and telecom to visit the same site, respectively, to resolve the request to the same server as the user network to enhance the user experience. Only DNS can also detect the running state of the backend node, and if a node failure is found on the backend, the request is sent to a host that can provide a normal service.

Configure smart DNS to modify the/etc/named.conf file on master:

Vim/etc/named.conf

ACL group1 {# adds two group configurations to the original base, plus 192.168 before include. 1.10; # Two different DNS servers were specified in two group.}; ACL group2 {192.168.1.11;}; Include "/var/named/chroot/etc/view.conf";

Edit the view.conf file on the master node, add group, and empty the previous view.conf file:

[email protected] etc]# cat View.confview "GROUP1" {match-clients {group1;};      Zone "viewtest.com" {type master; File "Group1.viewtest.com.zone";};};     View "GROUP2" {match-clients {group2;};     Zone "viewtest.com" {type master; File "Group2.viewtest.com.zone";};};

Create two specified zone files, respectively:

[[email protected] ~]# cat /var/named/chroot/etc/group1.viewtest.com.zone  $ORIGIN &NBSP, $TTL  3600 ; 1 hourviewtest.com  IN SOA op.viewtest.com  dns.viewtest.com.  (          2007 ; serial           900       ;  refresh   (15 minutes)           600        ; retry  (10 minutes)            86400     ; expire  (1 day)            3600      ; minimum  (1  hour)           )      NS     op.viewtest.com.$ORIGIN  viewtest.com.view    A   1.2.3.4op       a   1.2.3.4

[[email protected] ~]# cat /var/named/chroot/etc/group2.viewtest.com.zone  $ORIGIN &NBSP, $TTL  3600 ; 1 hourviewtest.com  IN SOA op.viewtest.com  dns.viewtest.com.  (          2007 ; serial           900       ;  refresh   (15 minutes)           600        ; retry  (10 minutes)            86400     ; expire  (1 day)            3600      ; minimum  (1  hour)           )      NS     op.viewtest.com.$ORIGIN  viewtest.com.view    A   1.2.100.100op       a   1.2.100.100

The specified resolved IP of two files is different.

Change the permissions for two files and restart named:

Chown named.named group* systemctl Restart named

The test results, with 192.168.1.10 as the client, initiate a parse request to DNS:

[Email protected] ~]# host view.viewtest.com 192.168.1.10Using domain server:name:192.168.1.10address:192.168.1.10# 53aliases:view.viewtest.com has address 1.2.3.4

With 192.168.1.11 as the client, the DNS initiates the parse request:

[Email protected] ~]# host view.viewtest.com 192.168.1.10Using domain server:name:192.168.1.10address:192.168.1.10# 53aliases:view.viewtest.com has address 1.2.100.100

Different client parsing results are not the same, so that we can meet the requirements.

The process of intelligent DNS parsing:

1, in the named.conf file defines two group,group1 contains the 192.168.1.10 client, group2 contains the 192.168.1.11 of the client. The two group differentiates the source IP, and the source IP of the different group is parsed using a different zone file.

2, when the request to parse view.viewtest.com on 192.168.1.10 (11), found this IP belongs to group1 (group2), so go to view/var/named/chroot/etc/view.conf this file.

3, in the view.conf file, respectively specify the resolution GROUP1 and group2 need to parse the zone file, so the system will automatically select its corresponding zone file according to the source IP.

4, in the zone file of Group1 and group2, respectively, view.viewtest.com corresponding parsing records are specified, respectively, 1.2.3.4 and 1.2.100.100. The system reads the corresponding zone file, returning the client with different parsing results.

Tips:

The synchronization configuration of the view.conf file is emptied here, and the synchronization parameters can be added in the original way. Synchronize settings for each defined domain.

This article is from the "Trying" blog, make sure to keep this source http://tryingstuff.blog.51cto.com/4603492/1880669

Common DNS Configuration