< draft-ietf-dnsind-dynDNS-09.txt   draft-ietf-dnsind-dynDNS-10.txt >
DNSIND Working Group Paul Vixie (Ed.) (ISC) DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Susan Thomson (Bellcore) INTERNET-DRAFT Susan Thomson (Bellcore)
<draft-ietf-dnsind-dynDNS-09.txt> Yakov Rekhter (Cisco) <draft-ietf-dnsind-dynDNS-10.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC) Jim Bound (DEC)
Amends: RFC 1035 March 1996 Amends: RFC 1035 November 1996
Dynamic Updates in the Domain Name System (DNS UPDATE) Dynamic Updates in the Domain Name System (DNS UPDATE)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
UPDATE is atomic, i.e., all prerequisites must be satisfied or else UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met. error conditions defined after the prerequisites have been met.
1 - Definitions 1 - Definitions
This document intentionally gives more definition to the roles of This document intentionally gives more definition to the roles of
``Master,'' ``Slave,'' and ``Primary Master'' servers, and their ``Master,'' ``Slave,'' and ``Primary Master'' servers, and their
enumeration in NS RRs, and the SOA MNAME field. In that sense, the enumeration in NS RRs, and the SOA MNAME field. In that sense, the
following server type definitions can be considered an addendum to following server type definitions can be considered an addendum to
[RFC1035], and are intended to be consistent with [NOTIFY]: [RFC1035], and are intended to be consistent with [RFC1996]:
Slave an authoritative server that uses AXFR or IXFR to Slave an authoritative server that uses AXFR or IXFR to
retrieve the zone and is named in the zone's NS retrieve the zone and is named in the zone's NS
RRset. RRset.
Master an authoritative server configured to be the source Master an authoritative server configured to be the source
of AXFR or IXFR data for one or more slave servers. of AXFR or IXFR data for one or more slave servers.
Primary Master master server at the root of the AXFR/IXFR dependency Primary Master master server at the root of the AXFR/IXFR dependency
graph. The primary master is named in the zone's SOA graph. The primary master is named in the zone's SOA
skipping to change at page 3, line 24 skipping to change at page 3, line 24
one WKS RR is possible for this tuple, even if the services one WKS RR is possible for this tuple, even if the services
masks differ. masks differ.
CNAME compare only NAME, CLASS, and TYPE -- it is not possible to CNAME compare only NAME, CLASS, and TYPE -- it is not possible to
have more than one CNAME RR, even if their data fields differ. have more than one CNAME RR, even if their data fields differ.
1.2 - Glue RRs 1.2 - Glue RRs
For the purpose of determining whether a domain name used in the UPDATE For the purpose of determining whether a domain name used in the UPDATE
protocol is contained within a specified zone, a domain name is ``in'' a protocol is contained within a specified zone, a domain name is ``in'' a
zone if it is owned by that zone's domain name. See section 7.19 for zone if it is owned by that zone's domain name. See section 7.18 for
details. details.
1.3 - New Assigned Numbers 1.3 - New Assigned Numbers
CLASS = NONE (TBD: 254) CLASS = NONE (TBD: 254)
RCODE = YXDOMAIN (TBD: 6) RCODE = YXDOMAIN (TBD: 6)
RCODE = YXRRSET (TBD: 7) RCODE = YXRRSET (TBD: 7)
RCODE = NXRRSET (TBD: 8) RCODE = NXRRSET (TBD: 8)
RCODE = NOTAUTH (TBD: 9) RCODE = NOTAUTH (TBD: 9)
RCODE = NOTZONE (TBD: 10?) RCODE = NOTZONE (TBD: 10?)
skipping to change at page 13, line 36 skipping to change at page 13, line 36
else else
if (zone_rrset<rr.name, rr.type>) if (zone_rrset<rr.name, rr.type>)
return (YXRRSET) return (YXRRSET)
if (rr.class == zclass) if (rr.class == zclass)
temp<rr.name, rr.type> += rr temp<rr.name, rr.type> += rr
else else
return (FORMERR) return (FORMERR)
for rrset in temp for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset) if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXDOMAIN) return (NXRRSET)
3.3 - Check Requestor's Permissions 3.3 - Check Requestor's Permissions
3.3.1. Next, the requestor's permission to update the RRs named in the 3.3.1. Next, the requestor's permission to update the RRs named in the
Update Section may be tested in an implementation dependent fashion or Update Section may be tested in an implementation dependent fashion or
using mechanisms specified in a subsequent Secure DNS Update protocol. using mechanisms specified in a subsequent Secure DNS Update protocol.
If the requestor does not have permission to perform these updates, the If the requestor does not have permission to perform these updates, the
server may write a warning message in its operations log, and may either server may write a warning message in its operations log, and may either
signal REFUSED to the requestor, or ignore the permission problem and signal REFUSED to the requestor, or ignore the permission problem and
proceed with the update. proceed with the update.
skipping to change at page 15, line 38 skipping to change at page 15, line 38
3.4.2.1. If any system failure (such as an out of memory condition, or a 3.4.2.1. If any system failure (such as an out of memory condition, or a
hardware error in persistent storage) occurs during the processing of hardware error in persistent storage) occurs during the processing of
this section, signal SERVFAIL to the requestor and undo all updates this section, signal SERVFAIL to the requestor and undo all updates
applied to the zone during this transaction. applied to the zone during this transaction.
3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the
zone. In case of duplicate RDATAs (which for SOA RRs is always the zone. In case of duplicate RDATAs (which for SOA RRs is always the
case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields
both match), the Zone RR is replaced by Update RR. If the TYPE is SOA both match), the Zone RR is replaced by Update RR. If the TYPE is SOA
and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according
to [KRE1996]) than the current Zone SOA RR's SOA.SERIAL, the Update RR to [RFC1982]) than or equal to the current Zone SOA RR's SOA.SERIAL, the
is ignored. In the case of a CNAME Update RR and a non-CNAME Zone RRset Update RR is ignored. In the case of a CNAME Update RR and a non-CNAME
or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME Zone RRset or vice versa, ignore the CNAME Update RR, otherwise replace
Zone RR with the CNAME Update RR. the CNAME Zone RR with the CNAME Update RR.
3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all
Zone RRs with the same NAME are deleted, unless the NAME is the same as Zone RRs with the same NAME are deleted, unless the NAME is the same as
ZNAME in which case only those RRs whose TYPE is other than SOA or NS ZNAME in which case only those RRs whose TYPE is other than SOA or NS
are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not
ANY all Zone RRs with the same NAME and TYPE are deleted, unless the ANY all Zone RRs with the same NAME and TYPE are deleted, unless the
NAME is the same as ZNAME in which case neither SOA or NS RRs will be NAME is the same as ZNAME in which case neither SOA or NS RRs will be
deleted. deleted.
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME, 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME,
skipping to change at page 18, line 21 skipping to change at page 18, line 21
as a system reboot or power failure will cause these update records to as a system reboot or power failure will cause these update records to
be incorporated into the zone the next time the server is started. It be incorporated into the zone the next time the server is started. It
is also reasonable for the server to copy the entire modified zone to is also reasonable for the server to copy the entire modified zone to
nonvolatile storage after each update operation, though this would have nonvolatile storage after each update operation, though this would have
suboptimal performance for large zones. suboptimal performance for large zones.
3.6 - Zone Identity 3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that change If the zone's SOA SERIAL is changed by an update operation, that change
must be in a positive direction (using modulo 2**32 arithmetic as must be in a positive direction (using modulo 2**32 arithmetic as
specified by [KRE1996]). Attempts to replace an SOA with one whose specified by [RFC1982]). Attempts to replace an SOA with one whose
SERIAL is less than the current one will be silently ignored by the SERIAL is less than the current one will be silently ignored by the
primary master server. primary master server.
If the zone's SOA's SERIAL is not changed as a result of an update If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before the operation, then the server shall increment it automatically before the
SOA or any changed name or RR or RRset is included in any response or SOA or any changed name or RR or RRset is included in any response or
transfer. The primary master server's implementor might choose to transfer. The primary master server's implementor might choose to
autoincrement the SOA SERIAL if any of the following events occurs: autoincrement the SOA SERIAL if any of the following events occurs:
(1) Each update operation. (1) Each update operation.
skipping to change at page 19, line 43 skipping to change at page 19, line 43
4.1. From a requestor's point of view, any authoritative server for the 4.1. From a requestor's point of view, any authoritative server for the
zone can appear to be able to process update requests, even though only zone can appear to be able to process update requests, even though only
the primary master server is actually able to modify the zone's master the primary master server is actually able to modify the zone's master
file. Requestors are expected to know the name of the zone they intend file. Requestors are expected to know the name of the zone they intend
to update and to know or be able to determine the name servers for that to update and to know or be able to determine the name servers for that
zone. zone.
4.2. If update ordering is desired, the requestor will need to know the 4.2. If update ordering is desired, the requestor will need to know the
value of the existing SOA RR. Requestors who update the SOA RR must value of the existing SOA RR. Requestors who update the SOA RR must
update the SOA SERIAL field in a positive direction (as defined by update the SOA SERIAL field in a positive direction (as defined by
[KRE1996]) and to preserve the other SOA fields unless the requestor's [RFC1982]) and also preserve the other SOA fields unless the requestor's
explicit intent is to change them. The SOA SERIAL field must never be explicit intent is to change them. The SOA SERIAL field must never be
set to zero (0). set to zero (0).
4.3. If the requestor has reasonable cause to believe that all of a 4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to try zone's servers will be equally reachable, then it should arrange to try
the primary master server (as given by the SOA MNAME field if matched by the primary master server (as given by the SOA MNAME field if matched by
some NS NSDNAME) first to avoid unnecessary forwarding inside the slave some NS NSDNAME) first to avoid unnecessary forwarding inside the slave
servers. (Note that the primary master will in some cases not be servers. (Note that the primary master will in some cases not be
reachable by all requestors, due to firewalls or network partitioning.) reachable by all requestors, due to firewalls or network partitioning.)
skipping to change at page 23, line 19 skipping to change at page 23, line 19
formal specification and any disagreement between this section and any formal specification and any disagreement between this section and any
other section of this document should be resolved in favour of the other other section of this document should be resolved in favour of the other
section. section.
7.1. Using metavalues for CLASS is possible only because all RRs in the 7.1. Using metavalues for CLASS is possible only because all RRs in the
packet are assumed to be in the same zone, and CLASS is an attribute of packet are assumed to be in the same zone, and CLASS is an attribute of
a zone rather than of an RRset. (It is for this reason that the Zone a zone rather than of an RRset. (It is for this reason that the Zone
Section is not optional.) Section is not optional.)
7.2. Since there are no data-present or data-absent errors possible from 7.2. Since there are no data-present or data-absent errors possible from
processing the Update Section, it is necessary to state data-present and processing the Update Section, any necessary data-present and data-
data-absent dependencies in the Prerequisite Section. absent dependencies should be specified in the Prerequisite Section.
7.3. The Additional Data Section can be used to supply a server with out 7.3. The Additional Data Section can be used to supply a server with out
of zone glue that will be needed in referrals. For example, if adding a of zone glue that will be needed in referrals. For example, if adding a
new NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A new NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A
RR for NS.AU.OZ can be included in the Additional Data Section. Servers RR for NS.AU.OZ can be included in the Additional Data Section. Servers
can use this information or ignore it, at the discretion of the can use this information or ignore it, at the discretion of the
implementor. implementor. We discourage caching this information for use in
subsequent DNS responses.
7.4. The Additional Data Section might be used if some of the RRs later 7.4. The Additional Data Section might be used if some of the RRs later
needed for Secure DNS Update are not actually zone updates, but rather needed for Secure DNS Update are not actually zone updates, but rather
ancillary keys or signatures not intended to be stored in the zone (as ancillary keys or signatures not intended to be stored in the zone (as
an update would be), yet necessary for validating the update operation. an update would be), yet necessary for validating the update operation.
7.5. It is expected that in the absence of Secure DNS Update, a server 7.5. It is expected that in the absence of Secure DNS Update, a server
will only accept updates if they come from a source address that has will only accept updates if they come from a source address that has
been statically configured in the server's description of a primary been statically configured in the server's description of a primary
master zone. DHCP servers would be likely candidates for inclusion in master zone. DHCP servers would be likely candidates for inclusion in
skipping to change at page 24, line 36 skipping to change at page 24, line 36
infrequent occurance. Visible (to DNS clients) SOA SERIALs need to infrequent occurance. Visible (to DNS clients) SOA SERIALs need to
differ if the zone differs. Note that the Authority Section SOA in a differ if the zone differs. Note that the Authority Section SOA in a
QUERY response is a form of visibility, for the purposes of this QUERY response is a form of visibility, for the purposes of this
prerequisite. prerequisite.
7.11. A zone's SOA SERIAL should never be set to zero (0) due to 7.11. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the result implementations of DNS. When incrementing an SOA SERIAL, if the result
of the increment is zero (0) (as will be true when wrapping around of the increment is zero (0) (as will be true when wrapping around
2**32), it is necessary to increment it again or set it to one (1). See 2**32), it is necessary to increment it again or set it to one (1). See
[KRE1996] for more detail on this subject. [RFC1982] for more detail on this subject.
7.12. Due to the TTL minimalization necessary when caching an RRset, it 7.12. Due to the TTL minimalization necessary when caching an RRset, it
is recommended that all TTLs in an RRset be set to the same value. is recommended that all TTLs in an RRset be set to the same value.
While the DNS Message Format permits variant TTLs to exist in the same While the DNS Message Format permits variant TTLs to exist in the same
RRset, and this variance can exist inside a zone, such variance will RRset, and this variance can exist inside a zone, such variance will
have counterintuitive results and its use is discouraged. have counterintuitive results and its use is discouraged.
7.13. Zone cut management presents some obscure corner cases to the add 7.13. Zone cut management presents some obscure corner cases to the add
and delete operations in the Update Section. It is possible to delete and delete operations in the Update Section. It is possible to delete
an NS RR as long as it's not the last RR in the RRset. If deleting all an NS RR as long as it is not the last NS RR at the root of a zone. If
RRs from a name, SOA and NS RRs at the top of a zone are unaffected. If deleting all RRs from a name, SOA and NS RRs at the root of a zone are
deleting RRsets, it is not possible to delete either SOA or NS RRsets at unaffected. If deleting RRsets, it is not possible to delete either SOA
the top of a zone. An attempt to add an SOA will be treated as a or NS RRsets at the top of a zone. An attempt to add an SOA will be
replace operation. treated as a replace operation.
7.14. No semantic checking is required in the primary master server when 7.14. No semantic checking is required in the primary master server when
adding new RRs. Therefore a requestor can cause CNAME or NS or any adding new RRs. Therefore a requestor can cause CNAME or NS or any
other kind of RR to be added even if their target name does not exist or other kind of RR to be added even if their target name does not exist or
does not have the proper RRsets to make the original RR useful. Primary does not have the proper RRsets to make the original RR useful. Primary
master servers which implement this kind of checking should take great master servers that DO implement this kind of checking should take great
care to avoid out-of-zone dependencies (whose veracity cannot be care to avoid out-of-zone dependencies (whose veracity cannot be
authoritatively checked) or signals to the requestor during processing authoritatively checked) and should implement all such checking during
of the Update Section after the prescan. the prescan phase.
7.15. Nonterminal or wildcard CNAMEs are not well specified by RFC 1035 7.15. Nonterminal or wildcard CNAMEs are not well specified by [RFC1035]
and their use will probably lead to unpredictable results. Their use is and their use will probably lead to unpredictable results. Their use is
discouraged. discouraged.
7.16. Before adding a delegation to a zone, all RRsets at or below the 7.16. Empty nonterminals (nodes with children but no RRs of their own)
new zone cut should be removed, except for ``glue'' which are A RRs will cause <NOERROR,ANCOUNT=0> responses to be sent in response to a
below the zone cut which are targets of NS RRs at the zone cut. query of any type for that name. There is no provision for empty
terminal nodes -- so if all RRs of a terminal node are deleted, the name
7.17. A primary server implementation may choose to perform part of its is no longer in use, and queries of any type for that name will result
permission checking during the Update Section processing. This may be in an NXDOMAIN response.
needed if the permissions won't be known until the final form of an
RRset is known. In this case, a primary server can signal REFUSED to
the requestor as long as it also undoes all partial updates and restores
the zone to its original state.
7.18. In a deep AXFR dependency graph, it has not historically been an 7.17. In a deep AXFR dependency graph, it has not historically been an
error for slaves to depend mutually upon each other. This configuration error for slaves to depend mutually upon each other. This configuration
has been used to enable a zone to flow from the primary master to all has been used to enable a zone to flow from the primary master to all
slaves even though not all slaves have continuous connectivity to the slaves even though not all slaves have continuous connectivity to the
primary master. UPDATE's use of the AXFR dependency graph for primary master. UPDATE's use of the AXFR dependency graph for
forwarding prohibits this kind of dependency loop, since UPDATE forwarding prohibits this kind of dependency loop, since UPDATE
forwarding has no loop detection analagous to the SOA SERIAL pretest forwarding has no loop detection analagous to the SOA SERIAL pretest
used by AXFR. used by AXFR.
7.19. For UPDATE's purposes, a zone is said to own all names at or below 7.18. For UPDATE's purposes, a zone is said to own all names at or below
the zone's root. This allows an UPDATE message to add or delete names the zone's root. This allows an UPDATE message to add or delete names
below a zone cut so as to create and maintain ``glue'' records needed below a zone cut so as to create and maintain ``glue'' records needed
for delegation when a name server is within the zone being delegated. for delegation when a name server is within the zone being delegated,
even though a query for this data would result in a referral response.
7.20. Previously existing names which are occluded by a new zone cut are 7.19. Previously existing names which are occluded by a new zone cut are
still considered part of the parent zone, for the purposes of zone still considered part of the parent zone, for the purposes of zone
transfers, even though queries for such names will be referred to the transfers, even though queries for such names will be referred to the
new subzone's servers. If a zone cut is removed, all parent zone names new subzone's servers. If a zone cut is removed, all parent zone names
that were occluded by it will again become visible to queries. (This is that were occluded by it will again become visible to queries. (This is
a clarification of RFC 1034.) a clarification of [RFC1034].)
7.21. If a node contains any name server delegations (NS RRs), this node 7.20. If a node contains any name server delegations (NS RRs), this node
is said to be owned by the child zone, and the parent will answer only is said to be owned by the child zone, and the parent will answer only
with a nonauthoritative referral to the child zone's servers if queried with a referral to the child zone's servers if queried for a name at or
for a name at or below the child zone's root, except in the case of an below the child zone's root, except in the case of a QTYPE=NS query at
QTYPE=NS query at the zone cut itself, for which the parent zone's the zone cut itself, for which the parent zone's servers would answer
servers would answer authoritatively. (This is a clarification of RFC authoritatively. (This is a clarification of [RFC1034].)
1034.)
7.22. If a server is authoritative for both a zone and its child, then 7.21. If a server is authoritative for both a zone and its child, then
queries for names at the zone cut between them will be answered queries for names at the zone cut between them will be answered
authoritatively using only data from the child zone. (This is a authoritatively using only data from the child zone. (This is a
clarification of RFC 1034.) clarification of [RFC1034].)
7.23. Update ordering using the SOA RR is problematic since there is no 7.22. Update ordering using the SOA RR is problematic since there is no
way to know which of a zone's NS RRs represents the primary master, and way to know which of a zone's NS RRs represents the primary master, and
the zone slaves can be out of date if their SOA.REFRESH timers have not the zone slaves can be out of date if their SOA.REFRESH timers have not
elapsed since the last time the zone was changed on the primary master. elapsed since the last time the zone was changed on the primary master.
We recommend that a zone needing ordered updates use only servers which We recommend that a zone needing ordered updates use only servers which
implement NOTIFY (see [NOTIFY]) and IXFR (see [IXFR]), and that a client implement NOTIFY (see [RFC1996]) and IXFR (see [RFC1995]), and that a
receiving a prerequisite error while attempting an ordered update simply client receiving a prerequisite error while attempting an ordered update
retry after a random delay period to allow the zone to settle. simply retry after a random delay period to allow the zone to settle.
8 - Security Considerations
In the absence of DNS Security, the protocol described by this document 8 - Security Considerations 8.1. In the absence of [SECUPD] or
makes it possible for anyone who can reach an authoritative name server equivilent technology, the protocol described by this document makes it
to alter the contents of a zone. This strongly indicates a need for out possible for anyone who can reach an authoritative name server to alter
of band access control such as static access control lists enforced by the contents of any zones on that server. This is a serious increase in
the server combined with the strongest possible firewall techniques. vulnerability from the current technology. Therefore it is very
strongly recommended that the protocols described in this document not
be used without [SECUPD] or other equivalently strong security measures,
e.g. IPsec.
At the time of this writing, work is progressing (see [DNSSEC]) on the 8.2. A denial of service attack can be launched by flooding an update
general problem of DNS Security, and for Secure DNS Updates (see forwarder with TCP sessions containing updates that the primary master
[SECUPD]). No updates should be accepted from hosts outside an server will ultimately refuse due to permission problems. This arises
enterprise network's security perimeter until and unless Secure DNS due to the requirement that an update forwarder receiving a request via
Updates have been implemented. For the purpose of this recommendation, TCP use a synchronous TCP session for its forwarding operation. The
a slave server acting as a forwarder, or the primary master itself, is connection management mechanisms of [RFC1035 4.2.2] are sufficient to
outside the security perimeter if it is allowed to exchange DNS messages prevent large scale damage from such an attack, but not to prevent some
with hosts outside that perimeter. queries from going unanswered during the attack.
Acknowledgements Acknowledgements
We would like to thank the IETF DNSIND working group for their input and We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake, assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
Masataka Ohta, Mark Andrews, and Robert Elz. Special thanks to Bill Masataka Ohta, Mark Andrews, and Robert Elz. Special thanks to Bill
Simpson and Ken Wallich for reviewing this document. Simpson, Ken Wallich and Bob Halley for reviewing this document.
References References
[RFC1035] [RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,'' P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987. RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR] [RFC1982]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February R. Elz, ``Serial Number Arithmetic,'' RFC 1982, University of
1996, <draft-ietf-dnsind-ixfr-06.txt>. Melbourne, August 1996.
[NOTIFY] [RFC1995]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes (DNS M. Ohta, ``Incremental Zone Transfer,'' RFC 1995, Tokyo Institute of
NOTIFY),'' Internet Draft, March 1996, <draft-ietf-dnsind- Technology, August 1996.
notify-07.txt>.
[KRE1996] [RFC1996]
R. Elz, ``Serial Number Arithmetic,'' Internet Draft, February 1996, P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,''
<draft-ietf-dnsind-serial-00.txt>. RFC 1996, Internet Software Consortium, August 1996.
[DNSSEC] [DNSSEC]
Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System
Protocol Security Extensions,'' Internet Draft, January 1996, <draft- Protocol Security Extensions,'' Internet Draft, August 1996, <draft-
ietf-dnssec-secext-09.txt>. ietf-dnssec-secext-10.txt>.
[SECUPD] [SECUPD]
Donald E. Eastlake, ``Secure Domain Name System Dynamic Update,'' Donald E. Eastlake, ``Secure Domain Name System Dynamic Update,''
Internet Draft, February 1996, <draft-ietf-dnssec-update-00.txt> Internet Draft, March 1997, <draft-ietf-dnssec-update-02.txt>
Authors' Addresses Authors' Addresses
Yakov Rekhter Susan Thomson Yakov Rekhter Susan Thomson
Cisco Systems Bellcore Cisco Systems Bellcore
170 West Tasman Drive 445 South Street 170 West Tasman Drive 445 South Street
San Jose, CA 95134-1706 Morristown, NJ 07960 San Jose, CA 95134-1706 Morristown, NJ 07960
+1 914 528 0090 +1 201 829 4514 +1 914 528 0090 +1 201 829 4514
<yakov@cisco.com> <set@thumper.bellcore.com> <yakov@cisco.com> <set@thumper.bellcore.com>
 End of changes. 35 change blocks. 
80 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/