Catálogo de publicaciones - libros

This chapter introduced DNS security by categorizing the topic into administrative security, zone transfers, dynamic updates, and zone integrity. The first three topics are covered in this chapter; zone integrity using DNSSEC.bis is described in Chapter 11.

The administrative security discussion covered the selection and configuration of DNS servers and discussed software updating, limiting functionality, limiting permissions (including sandboxes or chroot jails), log streaming, and the use of multiple sources of both OS and DNS software to reduce the risks involved in running DNS systems. The packaged installation of a chroot jail on Linux Fedora Core 2 and FreeBSD was described, as well as the manual installation of a chroot jail in the absence of an available package.

The chapter described the use of cryptographic techniques to secure various transactions. The various techniques were described in outline for readers unfamiliar with general cryptographic processes, including symmetric (shared-secret) systems, asymmetric (public-key) systems, message digests, MACs, and digital signatures.

The use of simple BIND statements to secure zone transfers using IP addresses and the use of TSIG (shared-secret) transactions to secure zone transfers was described and illustrated with example files.

The chapter described, with examples, the use of BIND commands to secure dynamic updates using IP addresses. Both SIG(0), using public-key or asymmetric cryptographic techniques, and TSIG (shared-secret) methods to secure dynamic updates were described and again illustrated with example files and configurations.

The next chapter describes the design intent and implementation of DNSSEC (colloquially referred to as DNSSEC.bis) to ensure the source and integrity of zone data during normal query operations.

This chapter described the use and implementation of IPv6 as it relates to the DNS. The chapter started by describing the long history of IPv6 starting around 1995 and suggested that a number of factors are currently causing a rapid increase in the spread and deployment of IPv6. A brief tutorial on IPv6 address notation was provided to allow the reader to become familiar with its format and usage.

The status of DNS support was clarified due to some confusion created by the withdrawal of support for bit labels and the A6 and DNAME RR by the IETF in RFC 3363. The current IETF IPv6 DNS recommendation specifies that forward mapping of IPv6 addresses will use the AAAA (Quad A) RR, and reverse mapping will use the PTR RR under the domain IPV6.ARPA.

In Chapter 6, we move from theory to practice by looking at the installation of BIND 9 on Linux, BSD (FreeBSD), and Windows platforms.

This chapter described the use and implementation of IPv6 as it relates to the DNS. The chapter started by describing the long history of IPv6 starting around 1995 and suggested that a number of factors are currently causing a rapid increase in the spread and deployment of IPv6. A brief tutorial on IPv6 address notation was provided to allow the reader to become familiar with its format and usage.

The status of DNS support was clarified due to some confusion created by the withdrawal of support for bit labels and the A6 and DNAME RR by the IETF in RFC 3363. The current IETF IPv6 DNS recommendation specifies that forward mapping of IPv6 addresses will use the AAAA (Quad A) RR, and reverse mapping will use the PTR RR under the domain IPV6.ARPA.

In Chapter 6, we move from theory to practice by looking at the installation of BIND 9 on Linux, BSD (FreeBSD), and Windows platforms.

This chapter introduced DNS security by categorizing the topic into administrative security, zone transfers, dynamic updates, and zone integrity. The first three topics are covered in this chapter; zone integrity using DNSSEC.bis is described in Chapter 11.

The administrative security discussion covered the selection and configuration of DNS servers and discussed software updating, limiting functionality, limiting permissions (including sandboxes or chroot jails), log streaming, and the use of multiple sources of both OS and DNS software to reduce the risks involved in running DNS systems. The packaged installation of a chroot jail on Linux Fedora Core 2 and FreeBSD was described, as well as the manual installation of a chroot jail in the absence of an available package.

The chapter described the use of cryptographic techniques to secure various transactions. The various techniques were described in outline for readers unfamiliar with general cryptographic processes, including symmetric (shared-secret) systems, asymmetric (public-key) systems, message digests, MACs, and digital signatures.

The use of simple BIND statements to secure zone transfers using IP addresses and the use of TSIG (shared-secret) transactions to secure zone transfers was described and illustrated with example files.

The chapter described, with examples, the use of BIND commands to secure dynamic updates using IP addresses. Both SIG(0), using public-key or asymmetric cryptographic techniques, and TSIG (shared-secret) methods to secure dynamic updates were described and again illustrated with example files and configurations.

The next chapter describes the design intent and implementation of DNSSEC (colloquially referred to as DNSSEC.bis) to ensure the source and integrity of zone data during normal query operations.

This chapter described the protocol messages that pass between DNS servers. This is sometimes called the wire format. In most cases the message, or wire, format can be interpreted using a packet sniffer—there are times, however, when even the best tools either don’t support the latest version or provide less-than-complete interpretation in which the user has to resort to tried and trusted manual methods. Each message has the same format comprising a message header followed by QUESTION, ANSWER, AUTHORITY, and ADDITIONAL SECTIONs. EDNS0 message formats add further complexity to the wire format but are only used with security transactions such as TSIG, SIG(0), TKEY, and DNSSEC.