Domain Name System dynamic update: Difference between revisions
imported>Howard C. Berkowitz mNo edit summary |
imported>Howard C. Berkowitz |
||
| Line 23: | Line 23: | ||
| url = http://www.ietf.org/rfc/rfc4033.txt}}</ref> RFC 3007, in turn, requires TSIG [RFC2845] or SIG(0) [RFC2535, RFC2931] transaction-level security, which is not the same as [[Domain Name System security]]. Note that the current dynamic security procedure explicitly rejects the method of RFC 2137. | | url = http://www.ietf.org/rfc/rfc4033.txt}}</ref> RFC 3007, in turn, requires TSIG [RFC2845] or SIG(0) [RFC2535, RFC2931] transaction-level security, which is not the same as [[Domain Name System security]]. Note that the current dynamic security procedure explicitly rejects the method of RFC 2137. | ||
==Operation of Dynamic Update== | ==Operation of Dynamic Update== | ||
Updates, in dynamic DNS, can carry RR-based messages that cause the insertion or deletion of data. | Updates, in dynamic DNS, can carry RR-based messages that cause the insertion or deletion of data. In general, dynamic DNS defines new DNS opcodes and a new interpretation of the DNS message if that opcode is used. An update can specify insertions or deletions of data, along with prerequisites necessary for the updates to occur. | ||
It is restricted in scope to a single zone, and take place at the primary server for that zone. The primary server for a dynamic zone must increment the zone SOA serial number when an update occurs or before the next retrieval of the SOA. | It is restricted in scope to a single zone, and take place at the primary server for that zone. The primary server for a dynamic zone must increment the zone SOA serial number when an update occurs or before the next retrieval of the SOA. | ||
The RRs most relevant to dynamic DNS are A and AAAA, PTR, and CNAME. It MUST NOT modify NXT RRs, because doing so can cause instability. It SHOULD NOT change SOA and NS records SHOULD NOT be modified by normal users, since these | The RRs most relevant to dynamic DNS are A and AAAA, PTR, and CNAME. It MUST NOT modify NXT RRs, because doing so can cause instability. It SHOULD NOT change SOA and NS records SHOULD NOT be modified by normal users, since these RRs create or modify delegation points. | ||
SIG could be | SIG could be modified, although this should be rare in real-world operations. | ||
==Sources of Dynamic Update== | ==Sources of Dynamic Update== | ||
Revision as of 08:26, 14 October 2008
Template:TOC-right Today's Internet Protocol networks, for a variety of reasons, can have rapid, fine-grained changes in name-to-address mapping, and the Domain Name System dynamic update technology was introduced to cope with this need. Dynamic update is an additional security vulnerability, and must be implemented with Domain Name System security (DNSSEC) in mind.
The original intent of the Domain Name System was to replace a completely static file of address-to-name mappings called hosts.txt. While the single file was not scalable and needed to be replaced by the distributed database that is the basic DNS architecture, server in that architecture still tended to be updated in a deliberate, batch-oriented procedure.
Both the rate of appearance of new hosts, as well as operational techniques that temporarily pair addresses and names, it was necessary to expand DNS so it could be updated not only with entire files (i.e., zone transfer), but with transient, dynamically acquired addresses. [1] Such an update is an invitation to attack unless secured, so dynamic DNS update should always be associated with a specific secure update mechanism,[2] within the DNS security architecture.[3] RFC 3007, in turn, requires TSIG [RFC2845] or SIG(0) [RFC2535, RFC2931] transaction-level security, which is not the same as Domain Name System security. Note that the current dynamic security procedure explicitly rejects the method of RFC 2137.
Operation of Dynamic Update
Updates, in dynamic DNS, can carry RR-based messages that cause the insertion or deletion of data. In general, dynamic DNS defines new DNS opcodes and a new interpretation of the DNS message if that opcode is used. An update can specify insertions or deletions of data, along with prerequisites necessary for the updates to occur.
It is restricted in scope to a single zone, and take place at the primary server for that zone. The primary server for a dynamic zone must increment the zone SOA serial number when an update occurs or before the next retrieval of the SOA.
The RRs most relevant to dynamic DNS are A and AAAA, PTR, and CNAME. It MUST NOT modify NXT RRs, because doing so can cause instability. It SHOULD NOT change SOA and NS records SHOULD NOT be modified by normal users, since these RRs create or modify delegation points.
SIG could be modified, although this should be rare in real-world operations.
Sources of Dynamic Update
The most common source of dynamic updates is the Dynamic Host Configuration Protocol (DHCP), used on local area networks but also providing the mapping service, via a proxy, to other dynamic address assignments, such as the PPP Internet Protocol Control Protocol (IPCP)[4] of the Point-to-Point Protocol.[5]
A major new area of dynamic update comes from the Internet Protocol version 6 Stateless Address Configuration (SLAAC) mechanism.
Dynamic Update deployment
References
- ↑ S. Thomson, Y. Rekhter, J. Bound. (April 1997), P. Vixie, ed., Dynamic Updates in the Domain Name System (DNS UPDATE), RFC2136
- ↑ B. Wellington (November 2000), Secure Domain Name System (DNS) Dynamic Update, RFC3007
- ↑ R. Arends, R. Austein, M. Larson, D. Massey, S. Rose (March 2005), DNS Security Introduction and Requirements, RFC4033
- ↑ G. McGregor (May 1992), PPP Internet Protocol Control Protocol (IPCP), RFC1332
- ↑ W. Simpson, ed. (July 1994), Point-to-Point Protocol (PPP), RFC1661