DNS and BIND 5th Edition_7 pdf

Chapter 10 Advanced Features and Security 10.7 Building Up a Large Site−wide Cache with Forwarders Certain network connections discourage sending large volumes of traffic off−site, either because the network connection is pay−per−packet or because the network connection is a slow link with a high delay, like a remote office's satellite connection to the company's network. In these situations, you'll want to limit the off−site DNS traffic to the bare minimum. BIND provides a mechanism to do this: forwarders. If you designate one or more servers at your site as forwarders, all the off−site queries are sent to the forwarders first. The idea is that the forwarders handle all the off−site queries generated at the site, building up a rich cache of information. For any given query in a remote domain, there is a high probability that the forwarder can answer the query from its cache, avoiding the need for the other servers to send packets off−site. Nothing special is done to these servers to make them forwarders; you modify all the other servers at your site to direct their queries through the forwarders. A primary master or slave name server's mode of operation changes slightly when it is directed to use a forwarder. If the requested information is already in its database of authoritative data and cache data, it answers with this information; this part of the operation hasn't changed. However, if the information is not in its database, the name server will send the query to a forwarder and wait a short period for an answer before resuming normal operation and contacting the remote servers itself. What the name server is doing that's different is sending a recursive query to the forwarder, expecting it to find the answer. At all other times, the name server sends out nonrecursive queries to other name servers and deals with responses that only refer to other name servers. For example, here is the forwarders conf file statement − and the equivalent BIND 4 boot file directive − for name servers in the movie.edu domain. Both wormhole and terminator are the site forwarders. This forwarders statement is added to every name server conf file except the conf files for the forwarders, wormhole and terminator: options { forwarders { 192.249.249.1; 192.249.249.3; }; }; The equivalent BIND 4 directive is: forwarders 192.249.249.1 192.249.249.3 When you use forwarders, try to keep your site configuration simple. You can end up with configurations that are really twisted. Avoid having "mid−level" servers forward packets (i.e., avoid having a forwarders line in your mid−level name server's conf file). Mid−level servers mostly refer name servers to subdomain name servers. If they DNS & BIND 319 have been configured to forward packets, do they refer to subdomain name servers or do they contact the subdomain name server to find out the answer? Whichever way it works, you're probably making your site configuration too hard for mere mortals (and subdomain administrators) to understand. NOTE: Avoid chaining your forwarders. Don't configure server A to forward to server B, and configure server B to forward to server C (or worse yet, back to server A). 10.6 Preferring Name Servers on Certain Networks 10.8 A More Restricted Name Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 320 Chapter 10 Advanced Features and Security 10.8 A More Restricted Name Server You may want to restrict your name servers even further − stopping them from even trying to contact an off−site server if their forwarder is down or doesn't respond. You can do this by making the server a forward−only server. (A forward−only server is still a primary master, slave, or caching−only server; don't get confused here. We call it a forward−only server because calling it a primary master, slave, or caching−only forward−only server is just too long a name.) A forward−only server is a variation on a server that uses forwarders. It still answers queries from its authoritative data and cache data. However, it relies completely on its forwarders; it doesn't try to contact other servers to find out information if the forwarders don't give it an answer. Here is an example of what a forward−only server's conf file would contain: options { forwarders { 192.249.249.1; 192.249.249.3; }; forward−only; }; On a BIND 4 name server, that would look like: forwarders 192.249.249.1 192.249.249.3 options forward−only BIND name servers before 4.9 provide the same functionality, using the slave directive instead of the options forward−only directive: forwarders 192.249.249.1 192.249.249.3 slave Don't confuse this old use of the term "slave" with the modern use. "Slave" now means a name server that gets the data that describes a zone from a master server via a zone transfer. You must have the forwarders line in the conf or boot file. It does not make sense to have only the forward−only line. If you do create a forward−only name server, you might want to consider including the forwarders' IP addresses more than once. On a BIND 8 server, that would look like: options { forwarders { 192.249.249.1; 192.249.249.3; 192.249.249.1; 192.249.249.3; }; forward−only; }; On a BIND 4 server, that's: forwarders 192.249.249.1 192.249.249.3 192.249.249.1 192.249.249.3 DNS & BIND 321 options forward−only The forward−only server contacts each forwarder only once, and it waits a short time for the forwarder to respond. Listing the forwarders multiple times directs the forward−only server to retransmit queries to the forwarders, and increases the overall length of time that the forward−only name server will wait for an answer from forwarders. However, you must ask yourself if it ever makes sense to use a forward−only server. A forward−only server is completely dependent on the forwarders. You can achieve much the same configuration (and dependence) by not running a forward−only server at all; instead, create a resolv.conf file that contains nameserver directives that point to the forwarders you were using. Thus, you are still relying on the forwarders, but now your applications are querying the forwarders directly instead of having a forward−only name server query them for the applications. You lose the local caching that the forward−only server would have done, and the address sorting, but you reduce the overall complexity of your site configuration by running fewer "restricted" name servers. 10.7 Building Up a Large Site−wide Cache with Forwarders 10.9 A Nonrecursive Name Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 322 Chapter 10 Advanced Features and Security 10.9 A Nonrecursive Name Server By default, BIND resolvers send recursive queries, and BIND name servers do the work required to answer recursive queries. (If you don't remember how recursion works, look in Chapter 2, How Does DNS Work?.) In the process of finding the answer to recursive queries, the name server builds up a cache of nonauthoritative information about other domains. In some circumstances, it is undesirable for name servers to do the extra work required to answer a recursive query or to build up a cache of data. The root name servers are an example of one of these circumstances. The root name servers are so busy that they should not be spending the extra effort to recursively find the answer to a request. Instead, they send a response based only on the authoritative data they have. The response may contain the answer, but it is more likely that the response contains a referral to other name servers. And since the root servers do not support recursive queries, they do not build up a cache of nonauthoritative data, which is good because their cache would be huge.[2] [2] Note that a root name server wouldn't normally receive recursive queries, unless a name server's administrator configured it to use a root server as a forwarder, a host's administrator configured its resolver to use the root server as a name server, or a user pointed nslookup at the root server. You can induce BIND to run as a nonrecursive name server with the following conf file statement: options { recursion no; }; On a BIND 4.9 server, that's the directive: options no−recursion Now the server will respond to recursive queries as though they were nonrecursive. In conjunction with recursion no, there is one more configuration option necessary if you want to stop your server from building a cache: options { fetch−glue no; }; Or, on BIND 4.9: DNS & BIND 323 options no−fetch−glue This stops the server from fetching missing glue when constructing the additional data section of a response. If you choose to make one of your servers nonrecursive, do not list this name server in any host's resolv.conf file. While you can make your name server nonrecursive, there is no corresponding option to make your resolver work with a nonrecursive name server.[3] [3] In general. Clearly, programs designed to send nonrecursive queries, or that can be configured to send nonrecursive queries, like nslookup, would still work. You can list a nonrecursive name server as one of the servers authoritative for your zone data (i.e., you can tell a parent name server to refer queries about your zone to this server). This works because name servers send nonrecursive queries between themselves. Do not list a nonrecursive name server as a forwarder. When a name server is using another server as a forwarder, it sends the query to the forwarder as a recursive query instead of a nonrecursive query. 10.8 A More Restricted Name Server 10.10 Avoiding a Bogus Name Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 324 Chapter 10 Advanced Features and Security 10.10 Avoiding a Bogus Name Server In your term as name server administrator, you might find some remote name server that responds with bad information. You can attempt to find an administrator to fix the problem. Or, you can save yourself some grief and configure your name server to not ask questions of this server, which is possible with BIND 4.9 and later. Here is the conf file statement: server 10.0.0.2 { bogus yes; }; Or, on a BIND 4.9 server: bogusns 10.0.0.2 Of course, you fill in the correct IP address. If this is the only server for a zone, and you just told your name server to stop talking to that server, don't expect to be able to look up names in that zone. Hopefully, there are other servers for that zone that can provide good information. 10.9 A Nonrecursive Name Server 10.11 Securing Your Name Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 325 Chapter 10 Advanced Features and Security 10.11 Securing Your Name Server BIND 4.9 introduced several important security features that help you protect your name server. BIND 8 continued the tradition by introducing several more. These features are particularly important if your name server is running on the Internet, but they may also be useful on purely internal name servers. We'll start by discussing measures you should take on all name servers for which security is important. Then we'll describe a model in which your name servers are split into two communities, one for serving only resolvers and one for answering other name servers' queries. 10.11.1 BIND Version One of the most important ways you can enhance the security of your name server is to run the latest version of BIND. All versions of BIND before 4.9.7 are susceptible to at least a few known attacks.[4] BIND 8.1.2 is an even better bet, because of the many new security mechanisms it introduced. [4] In fact, part of the reason there is a BIND 4.9.7, and the BIND 4 release stream didn't stop with 4.9.6, was 4.9.6's vulnerability to a particular attack. But don't stop there: New attacks are being thought up all the time, so you'll have to do your best to keep abreast of BIND's vulnerabilities and the latest "safe" version of BIND. One good way to do that is to read the newsgroup comp.protocols.dns.bind regularly. 10.11.2 Restricting Queries Up until BIND 4.9, domain administrators had no way to control who could look up data on their name servers. That makes a certain amount of sense; the original idea behind DNS was to make information easily available all over the Internet. The neighborhood is not such a friendly place anymore, though. In particular, people who run Internet firewalls may have a legitimate need to hide certain parts of their name space from most of the world but to make it available to a limited audience. The BIND 8 allow−query substatement allows you to place an IP address−based access list on queries. The access list can apply to a particular zone, or to any queries received by the server. In particular, the access list specifies which IP addresses are allowed to send queries to the server. DNS & BIND 326 10.11.2.1 Restricting all queries The global form of the allow−query substatement looks like this: options { allow−query { address_match_list; }; }; So to restrict our name server to answering queries from the two main Movie U. networks, we'd use: options { allow−query { 192.249.249/24; 192.253.253/24; }; }; 10.11.2.2 Restricting queries in a particular zone BIND 8 also allows you to apply an access list to a particular zone. In this case, just use allow−query as a substatement of the zone statement for the zone you want to protect: zone "hp.com" { type slave; file "db.hp"; masters { 15.255.152.2; }; allow−query { "HP−NET"; }; }; Any kind of authoritative name server, master or slave, can apply an access list to the zone. Zone−specific access lists take precedence over global access lists for that zone. The zone−specific access list may even be more permissive than the global access list. If there's no zone−specific access list defined, any global access list will apply. In BIND 4.9, this functionality is provided by the secure_zone record. Not only does it limit queries for individual resource records, it limits zone transfers, too. (In BIND 8, restricting zone transfers is done separately.) However, 4.9 servers have no mechanism for restricting who can send your server queries for data in zones your server isn't authoritative for; the secure zones mechanism only works with authoritative zones. To use secure zones, you include one or more special TXT (text) records in your zone data on the primary master name server. The records are conveniently transferred to the zone's slave servers automatically. Of course, only BIND 4.9 slaves will understand them. The TXT records are special because they're attached to the pseudo−domain name secure_zone, and the resource record−specific data has a special format, either: address:mask or: address:H In the first form, address is the dotted−octet form of the IP network to which you want to allow access to the data in this zone. The mask is the netmask for that address. If you want to allow all of net 15 access to your zone data, use 15.0.0.0:255.0.0.0. If you only want to allow the range of IP addresses from 15.254.0.0 to 15.255.255.255 access to your zone data, use 15.254.0.0:255.254.0.0. DNS & BIND 10.11.2 Restricting Queries 327 The second form specifies the address of a particular host you'd like to allow access to your zone data. The H is equivalent to the mask 255.255.255.255; in other words, each bit in the 32−bit address is checked. Therefore, 15.255.152.4:H gives the host with the IP address 15.255.152.4 the ability to look up data in the zone. If we wanted to restrict queries for information in movie.edu to hosts on Movie U.'s networks, we could add the following lines to db.movie on the movie.edu primary: secure_zone IN TXT "192.249.249.0:255.255.255.0" secure_zone IN TXT "192.253.253.0:255.255.255.0" secure_zone IN TXT "192.253.254.0:255.255.255.0" secure_zone IN TXT "127.0.0.1:H" Notice that we included the address 127.0.0.1 in our access list. That's so a resolver can query its local name server. If you forget the :H, you'll see the following syslog message: Aug 17 20:58:22 terminator named[2509]: build_secure_netlist (movie.edu): addr (127.0.0.1) is not in mask (0xff000000) Also, note that the secure zones records here apply only to the zone they're in − that is, movie.edu. If you wanted to prevent unauthorized queries for data in other zones on this server, you'd have to add secure zones records to that zone on its primary master name server, too. 10.11.3 Preventing Unauthorized Zone Transfers Even more important than controlling who can query your name server is ensuring that only your real slave name servers can transfer zones from your name server. Users on remote hosts that can query your name server's zone data can only look up data (e.g., addresses) for hosts whose domain names they already know, one at a time. Users who can start zone transfers from your server can list all of the hosts in your zones. It's the difference between letting random folks call your company's switchboard and ask for John Q. Cubicle's phone number and sending them a copy of your corporate phone directory. BIND 8's allow−transfer substatement and 4.9's xfrnets directive let administrators apply an access list to zone transfers. allow−transfer can restrict transfers of a particular zone as a zone substatement or can restrict all zone transfers as an options substatement. It takes an address match list as an argument. Say the slave servers for your acmebw.com zone have the IP addresses 192.168.0.1 and 192.168.1.1. The zone statement: zone "acmebw.com" { type master; file "db.acmebw"; allow−transfer { 192.168.0.1; 192.168.1.1; }; }; will allow only those slaves to transfer acmebw.com from the primary master name server. Note that since BIND 8's default is to allow any IP address to transfer zones, and because hackers can just as easily transfer the zone from your slaves, you should probably also have a zone statement like this on your slaves: zone "acmebw.com" { type slave; masters { 192.168.0.4; }; DNS & BIND 10.11.3 Preventing Unauthorized Zone Transfers 328 [...]... | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 10.11.6 Resolving Name Server Configuration 334 DNS & BIND Chapter 10 Advanced Features and Security 10.12 Load Sharing Between Mirrored Servers Name servers released since BIND 4.9 have formalized some load−sharing functionality that has existed in patches to BIND for some time Bryan Beecher wrote patches to BIND. .. make DNS queries, one that gives you complete control We'll cover nslookup in this chapter because it's distributed with BIND and with many vendors' systems If you're the explorer type, you might also check out dig; it provides similar functionality, and some people like its user interface better You can pick up source for dig from the tools directory (BIND 4) or src/bin directory (BIND 8) of the BIND. .. Answers 347 DNS & BIND % nslookup − terminator.movie.edu 11.4 Avoiding the Search List 11.6 Less Common Tasks [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 11.5.2 Authoritative Versus Nonauthoritative Answers 348 DNS & BIND Chapter 11 nslookup 11.6 Less Common Tasks These are tricks you'll probably have to use less often, but which are very handy to... resolve the names of any name servers in the RDATA of NS records; to prevent this from happening, and keep your name server from sending any queries of its own, use: options { fetch−glue no; }; on a BIND 8 server, and: options no−fetch−glue on BIND 4.9 10.11.5 "Delegated" Name Server Configuration 331 DNS & BIND 10.11.6 Resolving Name Server Configuration We'll call a name server that serves one or more... transfer), and gives you the > prompt For a noninteractive lookup, include the name you are looking up on the command line: % nslookup carrie Server: terminator.movie.edu Address: 0.0.0.0 Name: carrie.movie.edu Address: 192.253.253.4 11.1 Is nslookup a Good Tool? 11.3 Option Settings [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 339 DNS & BIND Chapter... nslookuprc File 342 DNS & BIND You might also use nslookuprc to set your search list to something other than your host's default search list, or to change the timeouts nslookup uses 11.2 Interactive Versus Noninteractive 11.4 Avoiding the Search List [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 11.3.1 The nslookuprc File 343 DNS & BIND Chapter 11... zone data 10.11.4 Running BIND as a Non−Root User Running a network server such as BIND as the root user can be dangerous − and BIND normally runs as root If a hacker finds a vulnerability in the server through which he can read or write files, he'll have root access to the filesystem If he can exploit a flaw that allows him to execute commands, he'll execute them as root BIND 8.1.2 includes experimental... will be helpful when you're trying to troubleshoot a DNS or BIND problem; they'll enable you to grub around in the packets the resolver sees, and mimic a BIND name server querying another name server or transferring zone data 11.6.1 Seeing the Query and Response Packets If you need to, you can direct nslookup to show you the queries it sends out and the responses it receives Turning on debug shows... the query and response packets As promised, we will go through the packet contents DNS packets are composed of five sections: 1 Header section 2 Question section 3 Answer section 4 Authority section 5 350 DNS & BIND Additional section Header section The header section is present in every query and response The operation code is always QUERY The only other opcodes are inverse query (IQUERY) and status... on another port − for debugging purposes, for example − and nslookup can be directed to use that port 341 DNS & BIND querytype=A By default, nslookup looks up A (address) resource record types In addition, if you type in an IP address (and the nslookup query type is address or pointer), then nslookup will invert the address, append in−addr.arpa, and look up PTR (pointer) data instead class=IN The only . Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 325 Chapter 10 Advanced Features and Security 10.11 Securing Your Name Server BIND. happening, and keep your name server from sending any queries of its own, use: options { fetch−glue no; }; on a BIND 8 server, and: options no−fetch−glue on BIND 4.9. DNS & BIND 10.11.5. Bogus Name Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 324 Chapter 10 Advanced Features and Security 10.10 Avoiding