UNIX System Administration Handbook - Evi Nemeth [257]
domain flags protocol algorithm key;
...
}
Each line represents the trusted key for a particular domain. The flags, protocol, and algorithm are nonnegative integers. The key is a base-64 encoded string.
The trusted-keys construct is intended to be used when a zone is signed but its parent zone is not, so you cannot be sure that the public key for the zone that you get from DNS is really kosher. Entering a trusted key with a trusted-keys statement (using out-of-band methods) ensures that you really have the appropriate key for the domain in question.
DNSSEC is covered in more detail starting on page 464.
The controls statement
The controls statement specifies how ndc controls a running named process. ndc can start and stop named, dump its state, put it in debug mode, etc. ndc is a network program, and without proper configuration it might let anyone on the Internet mess around with your name server. The syntax is:
controls {
inet ip_addr port port# allow { address_match_list | key ... };
unix permission owner group; [0600 0 0]
}
Allowing your name server to be accessed at the listed ip_addr and port sounds both handy and dangerous. Best might be to just leave the inet line out and access your name server only through the UNIX domain socket and the unix keyword. Another alternative is to control access with an authentication key. Slightly riskier would be to configure the address_match_list to accept connections only from 127.0.0.1 and to block that address from the outside world at your firewall. Limiting the inet line to localhost implies that you trust all local users to not mess with your name server; any user could telnet to the control port and type “stop”—quite an effective denial of service attack on the host. The default is to omit the inet clause.
ndc can also contact named through a UNIX domain socket called /var/run/ndc. The unix configuration line sets the permissions and ownerships on that socket and hence restricts access to it. The permission parameter should be an octal number that represents the desired mode of the socket; the owner and group parameters are the UID and GID of the owner of the socket. The defaults are read and write permission only for root.
The view statement
Views are a new feature of BIND 9 that let you show your internal machines a different view of the DNS naming hierarchy than that seen by the outside world. For example, you might reveal all of a zone’s hosts to internal users but restrict the external view to a few well-known servers. Or, you might expose the same set of hosts in both views but supply additional (or different) records to internal users.
This type of configuration (sometimes called “split DNS”) seems to be increasingly popular. In the past, you implemented it by setting up separate servers for the internal and external versions of reality. Local clients pointed at distribution servers that dished out the internal version of the zone, while the parent zone’s NS records pointed at servers that held the external version. BIND 9’s view statement simplifies the configuration by putting both sets of data inside the same copy of named. named uses address match lists to figure out which clients should see which data.
The view statement packages up an access list that controls who sees the view, some options that apply to all the zones in the view, and finally, the zones themselves. The syntax is:
view view-name {
match-clients { address_match_list } ;
view_option; ...
zone_statement; ...
} ;
The match-clients clause controls who can see the view. Views are processed in order, so put the most restrictive views first. Zones in different views can have the same names. Views are an all-or-nothing proposition; if you use them, all zone statements in your named.conf file must appear in the context of a view.
Here is an example from the BIND 9 documentation that mimics the split DNS scheme described above. The two views define the same zone, but with different data.
view "internal" {
match-clients