Install and configure DNS in a firewall Environment

Install and set DNS in a firewall environment-Linux Enterprise Application-Linux server application information. For more information, see the following section. Go to: Install and set DNS in the firewall Environment
Daily huc.zj.cn lh@Hutc.zj.cn
The article can be reprinted, but my MAIL must be retained.

After several days of research on BIND, we finally solved the DNS problem of our Organization.
In a general firewall, servers are deployed in the DMZ zone, external IP addresses are obtained from the DMZ zone for external access, and internal IP addresses are obtained when the DMZ zone is accessed internally.
For example,
Internal IP address <---> IP address of the DMZ web server <-----> external IP address
192.168.1.1 <---> 192.168.0.1 <-----> 211.202.49.1


DNS can be resolved from the following four aspects:

I. iptables Application
1. Core Ideas

The core idea of configuring a dynamic DNS server is to run multiple binds on the DNS server. Each BIND provides resolution for users from different regions, therefore, each BIND should have different configuration files and domain files, and listen on different ports respectively. When a client DNS request is received, the request is redirected to different BIND Service ports based on the customer's IP address. When the BIND responds, rewrite the service port of the corresponding package to the standard port 53. In this way, different resolution results can be returned to the client based on the Client IP address. The entire process is transparent to the client. The key to implementation is to run different binds and use iptables to rewrite IP addresses and ports.

2 configuration process

Step 1: configure the kernel

Netfilter requires that the kernel version be no less than 2.3.5. When compiling a new kernel, You must select a project related to netfilter. These items are usually located under the "Networking options" subitem. Taking the 2.4.0 kernel as an example, we should select the following items:

　　
Kernel/User netlink socket
[] Routing messages
<*> Netlink device emulation
　　
Network packet filtering (replaces ipchains)
.......
Then, in "IP: Netfilter Configuration ---->", select:

Connection tracking (required for masq/NAT)
FTP protocol support
IP tables support (required for filtering/masq/NAT)
Limit match support
MAC address match support
Netfilter MARK match support
Multiple port match support
TOS match support
Connection state match support
Packet filtering
REJECT target support
Full NAT
MASQUERADE target support
REDIRECT target support
Packet mangling
TOS target support
MARK target support
LOG target support
Ipchains (2.2-style) support
Ipfwadm (2.0-style) support

The last two items can be deselected, but if you miss ipchains or ipfwadm, you can also select it to use ipchians or ipfwadm in the 2.4 kernel. However, you must note that iptables is consistent with ipchians/ipfwadm. ipchains/ipfwadm cannot be used simultaneously when iptables is used. After compilation is successful, these module files are located in the following directory
/Lib/modules/2.4.0/kernel/net/ipv4/netfilter

When compiling the new kernel of 2.4.0, you should also select the correct CPU option corresponding to your CPU in "Processor type and features". Otherwise, the new kernel may not work properly.

Step 2. Configure the BIND Service

By default, the BIND service listens on port 53. We can configure BIND to run on different ip addresses and ports. It is not complicated to implement this. Assume that the IP address of our DNS server is 211.163.76.1, and we want to distinguish CERNET and non-CERNET customers. In this case, we must run two binds and use different configuration files. You can use listen-on in the BIND configuration file that uses a non-standard listening port to specify the port on which the BIND listens. For example:

Options {
Listen-on port 54 {211.163.76.1 ;}
Directory "/var/named_cernet ";
};
You can use the-c option of named to specify named to read different configuration files, for example:

/Usr/sbin/named-u named-c/etc/named_cernet.conf
　　
3. Configure redirection rules

Assume that the listening BIND server on the standard port provides DNS resolution for non-CERNET customers, and the listening BIND server on port 54 provides DNS resolution for the CERNET server, we can create the following rule script:

#! /Bin/bash

# Enable port forwarding

Echo 1>/proc/sys/net/ipv4/ip_forward
# Loading related kernel modules

/Sbin/modprobe iptable_filter
/Sbin/modprobe ip_tables
/Sbin/modprobe iptables_nat
# Refresh all rules

/Sbin/iptables-t nat-F
# Add a DNS request forwarding rule from CERNET to forward it to the local port 54. The CERNET address list can be obtained from www.nic.edu.cn/rs/ipstat/

/Sbin/iptables-t nat-a prerouting-p udp-s 163.105.0.0/16 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p tcp-s 163.105.0.0/16 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p udp-s 166.111.0.0/16 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p tcp-s 166.111.0.0/16 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p udp-s 202.4.128.0/19 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p tcp-s 202.4.128.0/19 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p udp-s 202.112.0.0/15 -- dport 53-I eth0-j REDIRECT 54
/Sbin/iptables-t nat-a prerouting-p tcp-s 202.112.0.0/15 -- dport 53-I eth0-j REDIRECT 54
...
# Disguise the source port (Port 54) returned to the cernet dns client data packet as port 53

/Sbin/iptables-t nat-a postrouting-p udp -- sport 54-o eth0-j SNAT -- to 211.163.76.1: 53
/Sbin/iptables-t nat-a postrouting-p tcp -- sport 54-o eth0-j SNAT -- to 211.163.76.1: 53
You can download the script from CERNET and change the DNS_IP and CNET_PORT parameters in the script to your own DNS server address and listening port.
4. Run Dynamic DNS

After the configuration is complete, we start the DNS server and run the corresponding rule script, so that our dynamic DNS server can work normally.



II. Use bind9 cache records
1) The user provides the domain name to be accessed to the browser;
2) the browser calls the domain name resolution library to resolve the domain name. Because CDN has adjusted the domain name resolution process,
Therefore, the parsing function library generally obtains the CNAME record corresponding to the domain name. To obtain the actual IP address,
The browser needs to resolve the obtained CNAME domain name again to obtain the actual IP address. In this process,
Global Server Load balancer DNS resolution is used. For example, you can resolve the corresponding IP address based on the geographical location information so that users can access the IP Address nearby.
3) the IP address of the CDN Cache Server is obtained through this resolution. After the browser obtains the actual IP address,
Sends an access request to the cache server;
4) the Cache server uses the internal dedicated DNS resolution of the Cache based on the domain name to be accessed provided by the browser.
Obtain the actual IP address of the domain name, and then the Cache Server submits an access request to the actual IP address;
5) after the Cache Server obtains the content from the actual IP address, it stores the content locally,
For future use, the acquired data is returned to the client to complete the data service process;
6) after the client obtains the data returned by the cache server, it displays the data and completes the browsing data request process.
1. For a website to be added to the CDN service, domain name resolution (such as www.linuxaid.com.cn, address 202.99.11.120) is required for the CDN service provider, for the domain name resolution record of Linuxaid, you only need to change the record of the www host to CNAME and direct it to cache.cdn.com. Cache.cdn.com is the identifier of the cache server customized by the CDN network. In the/var/named/linuxaid.com.cn domain name resolution record,:


Www in a 202.99.11.120
Change
Www in cname cache.cdn.com.



2. After the CDN operator obtains the domain name resolution right, it obtains the CNAME record of the domain name, pointing to the domain name of the cache server under the CDN network, such as cache.cdn.com, and the global Load Balancing DNS of the CDN network, you need to resolve the CNAME record to an IP address based on the policy. Generally, the IP address of the nearest access is provided.

The basic functions of Bind 9 can resolve the corresponding IP addresses based on different source IP address segments to achieve Load Balancing Based on the proximity of the region, generally, you can use the sortlist option of Bind 9 to return the nearest node IP address based on the Client IP address. The specific process is as follows:

1) set multiple A records for cache.cdn.com. The content of/var/named/cdn.com is as follows:


$ TTL 3600
@ In soa ns.cdn.com. root.ns.cdn.com .(
2002090201; Serial num
10800; Refresh after 3 hours
3600; Retry
604800; Expire
1800; Time to live

In ns ns
Www in a 210.33.21.168
Ns in a 202.96.128.68
Cache in a 202.93.22.13; number of CACHE addresses
Cache in a 210.21.30.90; the number of cache a records
Cache in a 211.99.13.47



2) The content in/etc/named. conf is:


Options {
Directory "/var/named ";
Sortlist {
# This section indicates that when the query is executed locally
# The address will be returned in the order of 202.93.22.13, 210.21.30.90, 211.99.13.47
{Localhost;
{Localnets;
202.93.22.13;
{210.21.30.90; 211.99.13.47 ;};
};
};
# This section indicates that when DNS query is performed in section 202/8
# The address will be returned in the order of 202.93.22.13, 210.21.30.90, 211.99.13.47
{1, 202/8;
{202.93.22.13;
{210.21.30.90; 211.99.13.47 ;};
};
};
# This section indicates that when DNS query is performed in section 211/8
# The address will be returned in the order of 211.99.13.47, 202.93.22.13, 210.21.30.90,
#211.99.13.47 is the node closest to the query location.
{1, 211/8;
{211.99.13.47;
{202.93.22.13; 210.21.30.90 ;};
};
};
{1, 61/8;
{202.93.22.13;
{210.21.30.90; 211.99.13.47 ;};
};
};
};
};

Zone "."{
Type hint;
File "root. cache ";
};

Zone "localhost "{
Type master;
File "localhost ";
};

Zone "cdn.com "{
Type master;
File "cdn.com ";
};

3. Set internal and external DNS
External DNS is a general setting. The key lies in the internal DNS settings.




# Named. conf-configuration for bind
#
# Generated automatically by redhat-config-bind, alchemist et al.
# Any changes not supported by redhat-config-bind shocould be put
# In/etc/named. custom
#
Controls {
Inet 127.0.0.1 allow {localhost;} keys {rndckey ;};
};

Include "/etc/named. custom ";

Include "/etc/rndc. key ";

Options {
Directory "/var/named /";
Forwarders {192.168.22.9;}; // switch to external DNS
};









Zone "0.0.127.in-addr. arpa "{
Type master;
File "0.0.127.in-addr. arpa. zone ";
};
Zone "22.16192.in-addr. arpa "{
Type master;
File "22.16192.in-addr. arpa. zone ";
};
Zone "7.20.172.in-addr. arpa "{
Type master;
File "7.20.172.in-addr. arpa. zone ";
};

Zone "localhost "{
Type master;
File "localhost. zone ";
};
Zone "huc.zj.cn "{
Type master;
File "maid ";
Forwarders {}; // except for internal domain resolution, the rest are placed on external DNS
};

4. Use the view function of bind9

Options {
Directory "/var/named ";
};

Acl "fx_subnet" {192.253.254/24 ;};
View "internal" {// internal view of our zone
Match-clients {"fx-subnet ";};
Zone "fx.movie.edu "{

Type master;
File 'db .fx.moive.edu ";
};
Zone "254.253.192.in-addr. arpa "{
Type master;
File "db.192.253.254 ";
};
};

View "external" {// view corresponding to the rest of the world.
Match-clients {any ;}; // implicitly
Rescursion no; // outside our subnet, they should not request recursive queries

Zone "fx.movie.edu "{
Type master;
File "db.fx.movie.edu. external"; // external data file
};

Zone "254.254.192.in.arpa "{
Type master;
File "db.192.253.254.external"; // external zone data file
};
};

Conclusion: Method 1: It is too complicated and cannot solve the problem of MX record
Method 2: use other ideas to solve internal and external DNS resolution Problems
Method 3: it has been used and can be further restricted by using ACL, that is, compared with method 4, the machine uses a little more
Method 4: I feel the best.