DNS server: How to apply firewall when using

Some organizations want to hide DNS names and not let outsiders know. Many experts believe that hiding DNS names is of little value, but it is also a known option if the site or enterprise policy enforces the need to hide domain names. Another reason you may have to hide the domain name is whether you have a non-standard addressing scheme on your internal network. Don't delude yourself into thinking that if you hide your DNS name, it can add to your attacker's difficulty when it comes to your firewall. Information about your network can easily be obtained from the network layer. If you are interested in confirming this, "ping" a network broadcast address on the LAN, and then perform "arp-a". Also, it should be explained that hiding the domain names in DNS does not solve the problem of "leaking" hostnames from headers, news articles, and so on.


This approach is one of many methods that is useful for organizations that want to conceal their host names to the Internet. The success of this approach depends on the fact that a DNS client on a single machine does not have to talk to a DNS server on the same machine. In other words, it is because there is a DNS server on one machine that it is not improper (and often beneficial) to redirect the DNS client activity of this machine to a DNS server on another machine.


First, you set up a DNS server on a bridgehead host that can communicate with the outside world. You build this server so it announces the right to access your domain. In fact, this server knows what you want the outside world to know: the name and address of your gateway, your wildcard MX record, and so on. This server is a "public" server.


then, establish a DNS server on the internal machine. This server also declares power over your domain name, which, unlike a public server, "speaks the truth". It is your "normal" naming server, where you can put all your "normal" DNS names on this server. You then set up this server so that it can forward queries it cannot resolve to the public server (for example, using the "forwarders" line in/etc/named.boot on Unix machines--forwarder lines).


Finally, set up all your DNS clients (for example,/etc/resolv.conf files on Unix machines) to use internal servers, which include DNS clients on the machine where the public server resides. This is the key. (www.3lian.com)


Ask an internal client for information about an internal host to ask a question to the internal server and get an answer; Ask an internal client for information about an external host to query the internal server, and the internal client queries the public server again, and the public servers query the Internet, And then get the answers back in one step. Clients on the public server also work in the same way. However, an external client that asks about an internal host's information can only get a "restrictive" answer from the public server.


This approach assumes that there is a packet filtering firewall between the two servers that allows the server to pass DNS to each other, but in addition to restricting DNS between other hosts.

Another useful technique for
This approach is to use the wildcard PTR record in your In-addr.aroa domain. This will cause the lookup of "Address to name" (Address-to-name) on any non-public host to return like "unknown." YOUR. DOMAIN, rather than returning an error. This meets the requirements like an anonymous FTP site. Such sites require the name of the computer with which they are communicating. This approach does not work when communicating with a site that has a DNS cross check. In a cross check, the hostname matches its address, and the address matches the host name.