Chapter 10. Advanced FeaturesContents:Address Match Lists and ACLsDNS Dynamic Update DNS NOTIFY (Zone Change Notification) Incremental Zone Transfer (IXFR) Forwarding Views Round Robin Load Distribution Name Server Address Sorting Preferring Name Servers on Certain Networks A Nonrecursive Name Server Avoiding a Bogus Name Server System Tuning Compatibility The ABCs of IPv6 Addressing Addresses and Ports IPv6 Forward and Reverse Mapping The latest BIND name servers, Versions 8.2.3 and 9.1.0, have lots of new features. Some of the most prominent introductions are support for dynamic updates, asynchronous zone change notification (called "NOTIFY" for short), and incremental zone transfer. Of the rest, the most important are related to security: they let you tell your name server whom to answer queries from, whom to offer zone transfers to, and whom to permit dynamic updates from. Many of the security features aren't necessary inside a corporate network, but the other mechanisms will help out the administrators of any name servers. In this chapter, we'll cover these features and suggest how they might come in handy in your DNS infrastructure. (We do save some of the hardcore firewall material 'til the next chapter, though.)
10.1. Address Match Lists and ACLsBefore we introduce the new features, however, we'd better cover address match lists. BIND 8 and 9 use address match lists for nearly every security feature and for some features that aren't security-related at all.An address match list is a list (what else?) of terms that specifies one or more IP addresses. The elements in the list can be individual IP addresses, IP prefixes, or a named address match list (more on those shortly).[70] An IP prefix has the format: [70]And if you're running BIND 9, address match lists can include IPv6 addresses and IPv6 prefixes. These are described later in the chapter. For example, the network 15.0.0.0 with the network mask 255.0.0.0 (eight contiguous ones) would be written 15/8. Traditionally, this would have been thought of as the "class A" network 15. The network consisting of IP addresses 192.168.1.192 through 192.168.1.255, on the other hand, would be written 192.168.1.192/26 (network 192.168.1.192 with the netmask 255.255.255.192, which has 26 contiguous ones). Here's an address match list comprising those two networks:network in dotted-octet format/bits in netmask
A named address match list is just that: an address match list with a name. To be used within another address match list, a named address match list must have been previously defined in named.conf with an acl statement. The acl statement has a simple syntax:15/8; 192.168.1.192/26;
This just makes the name equivalent to that address match list from now on. Although the name of the statement, acl, suggests " access control list," you can use the named address match list anywhere an address match list is accepted, including some places that don't have anything to do with access control.acl name { address_match_list; }; Any time you're going to use one or more of the same terms in a few access control lists, it's a good idea to use an acl statement to associate them with a name. You can then refer to the name in the address match list. For example, let's call 15/8 what it is: "HP-NET." And we'll call 192.168.1.192/26 "internal":
Now we can refer to these address match lists by name in other address match lists. This not only cuts down on typing, but it makes the resulting named.conf file more readable.acl "HP-NET" { 15/8; }; acl "internal" { 192.168.1.192/26; }; We prudently enclosed the names of our ACLs in quotes to avoid collisions with words BIND reserves for its own use. If you're sure your ACL names don't conflict with reserved words, you don't need the quotes. There are four predefined named address match lists:
|
|