draft-ietf-dnssd-push-11.txt   draft-ietf-dnssd-push-12.txt 
Internet Engineering Task Force T. Pusateri Internet Engineering Task Force T. Pusateri
Internet-Draft Seeking affiliation Internet-Draft Seeking affiliation
Intended status: Standards Track S. Cheshire Intended status: Standards Track S. Cheshire
Expires: December 19, 2017 Apple Inc. Expires: January 3, 2018 Apple Inc.
June 17, 2017 July 2, 2017
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-11 draft-ietf-dnssd-push-12
Abstract Abstract
The Domain Name System (DNS) was designed to return matching records The Domain Name System (DNS) was designed to return matching records
efficiently for queries for data that is relatively static. When efficiently for queries for data that is relatively static. When
those records change frequently, DNS is still efficient at returning those records change frequently, DNS is still efficient at returning
the updated results when polled. But there exists no mechanism the updated results when polled, as long as the polling rate is not
for a client to be asynchronously notified when these changes occur. too high. But there exists no mechanism for a client to be
This document defines a mechanism for a client to be notified asynchronously notified when these changes occur. This document
of such changes to DNS records, called DNS Push Notifications. defines a mechanism for a client to be notified of such changes to
DNS records, called DNS Push Notifications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2017. This Internet-Draft will expire on January 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. State Considerations . . . . . . . . . . . . . . . . . . . . 7 5. State Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 11 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 12
6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 12 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13
6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 15 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16
6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 18 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 19
6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 19 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20
6.3.2. PUSH Response . . . . . . . . . . . . . . . . . . . . 22 6.3.2. PUSH Response . . . . . . . . . . . . . . . . . . . . 23
6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 23 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 24
6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 24 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 25
6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 26 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 27
6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 28 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 29
6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 29 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 30
6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 31 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 32
6.6. Client-Initiated Termination . . . . . . . . . . . . . . 33 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
7.1. Security Services . . . . . . . . . . . . . . . . . . . . 34 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 35
7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 34 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 35
7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 35 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 36
7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 35 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
DNS records may be updated using DNS Update [RFC2136]. Other DNS records may be updated using DNS Update [RFC2136]. Other
mechanisms such as a Discovery Proxy [DisProx] can also generate mechanisms such as a Discovery Proxy [DisProx] can also generate
changes to a DNS zone. This document specifies a protocol for DNS changes to a DNS zone. This document specifies a protocol for DNS
clients to subscribe to receive asynchronous notifications of changes clients to subscribe to receive asynchronous notifications of changes
to RRSets of interest. It is immediately relevant in the case of DNS to RRSets of interest. It is immediately relevant in the case of DNS
Service Discovery [RFC6763] but is not limited to that use case, and Service Discovery [RFC6763] but is not limited to that use case, and
provides a general DNS mechanism for DNS record change notifications. provides a general DNS mechanism for DNS record change notifications.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
for all group members to receive. Therefore, Multicast DNS already for all group members to receive. Therefore, Multicast DNS already
has asynchronous change notification capability. However, when DNS has asynchronous change notification capability. However, when DNS
Service Discovery [RFC6763] is used across a wide area network using Service Discovery [RFC6763] is used across a wide area network using
Unicast DNS (possibly facilitated via a Discovery Proxy [DisProx]) it Unicast DNS (possibly facilitated via a Discovery Proxy [DisProx]) it
would be beneficial to have an equivalent capability for Unicast DNS, would be beneficial to have an equivalent capability for Unicast DNS,
to allow clients to learn about DNS record changes in a timely manner to allow clients to learn about DNS record changes in a timely manner
without polling. without polling.
The DNS Long-Lived Queries (LLQ) [I-D.sekar-dns-llq] mechanism is an The DNS Long-Lived Queries (LLQ) [I-D.sekar-dns-llq] mechanism is an
existing deployed solution to provide asynchronous change existing deployed solution to provide asynchronous change
notifications, used by Apple's Back to My Mac Service [RFC6281]. notifications, used by Apple's Back to My Mac Service [RFC6281]
Back to My Mac was designed in an era when the data centre operations introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was
staff asserted that it was impossible for a server to handle large designed in an era when the data centre operations staff asserted
numbers of mostly-idle TCP connections, so LLQ had to defined as a that it was impossible for a server to handle large numbers of
UDP-based protocol, effectively replicating much of TCP's connection mostly-idle TCP connections, so LLQ had to defined as a UDP-based
state management logic in user space, and creating its own poor protocol, effectively replicating much of TCP's connection state
imitations of existing TCP features like the three-way handshake, management logic in user space, and creating its own poor imitations
flow control, and reliability. of existing TCP features like the three-way handshake, flow control,
and reliability.
This document builds on experience gained with the LLQ protocol, with This document builds on experience gained with the LLQ protocol, with
an improved design. Instead of using UDP, this specification uses an improved design. Instead of using UDP, this specification uses
TCP, and therefore doesn't need to reinvent existing TCP TCP, and therefore doesn't need to reinvent existing TCP
functionality. Using TCP also gives long-lived low-traffic functionality. Using TCP also gives long-lived low-traffic
connections better longevity through NAT gateways without resorting connections better longevity through NAT gateways without resorting
to excessive keepalive traffic. Instead of inventing a new to excessive keepalive traffic. Instead of inventing a new
vocabulary of messages to communicate DNS zone changes as LLQ did, vocabulary of messages to communicate DNS zone changes as LLQ did,
this specification adopts the syntax and semantics of DNS Update this specification adopts the syntax and semantics of DNS Update
messages [RFC2136]. messages [RFC2136].
skipping to change at page 6, line 29 skipping to change at page 6, line 29
4. Transport 4. Transport
Implementations of DNS Update [RFC2136] MAY use either User Datagram Implementations of DNS Update [RFC2136] MAY use either User Datagram
Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP) Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP)
[RFC0793] as the transport protocol, in keeping with the historical [RFC0793] as the transport protocol, in keeping with the historical
precedent that DNS queries must first be sent over UDP [RFC1123]. precedent that DNS queries must first be sent over UDP [RFC1123].
This requirement to use UDP has subsequently been relaxed [RFC7766]. This requirement to use UDP has subsequently been relaxed [RFC7766].
In keeping with the more recent precedent, DNS Push Notification is In keeping with the more recent precedent, DNS Push Notification is
defined only for TCP. DNS Push Notification clients MUST use TLS defined only for TCP. DNS Push Notification clients MUST use TLS
over TCP, see RFC 7858 [RFC7858]. over TCP [RFC7858].
Connection setup over TCP ensures return reachability and alleviates Connection setup over TCP ensures return reachability and alleviates
concerns of state overload at the server through anonymous concerns of state overload at the server through anonymous
subscriptions. All subscribers are guaranteed to be reachable by the subscriptions. All subscribers are guaranteed to be reachable by the
server by virtue of the TCP three-way handshake. Flooding attacks server by virtue of the TCP three-way handshake. Flooding attacks
are possible with any protocol, and a benefit of TCP is that there are possible with any protocol, and a benefit of TCP is that there
are already established industry best practices to guard against SYN are already established industry best practices to guard against SYN
flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953]. flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953].
Use of TCP also allows DNS Push Notifications to take advantage of Use of TCP also allows DNS Push Notifications to take advantage of
current and future developments in TCP, such as Multipath TCP (MPTCP) current and future developments in TCP, such as Multipath TCP (MPTCP)
[RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP)
[I-D.dukkipati-tcpm-tcp-loss-probe], and so on. [I-D.dukkipati-tcpm-tcp-loss-probe], and so on.
Transport Layer Security (TLS) [RFC5246] is well understood and Transport Layer Security (TLS) [RFC5246] is well understood and
deployed across many protocols running over TCP. It is designed to deployed across many protocols running over TCP. It is designed to
prevent eavesdropping, tampering, or message forgery. TLS is prevent eavesdropping, tampering, and message forgery. TLS is
REQUIRED for every connection between a client subscriber and server REQUIRED for every connection between a client subscriber and server
in this protocol specification. Additional security measures such as in this protocol specification. Additional security measures such as
client authentication during TLS negotiation MAY also be employed to client authentication during TLS negotiation MAY also be employed to
increase the trust relationship between client and server. increase the trust relationship between client and server.
5. State Considerations 5. State Considerations
Each DNS Push Notification server is capable of handling some finite Each DNS Push Notification server is capable of handling some finite
number of Push Notification subscriptions. This number will vary number of Push Notification subscriptions. This number will vary
from server to server and is based on physical machine from server to server and is based on physical machine
skipping to change at page 9, line 9 skipping to change at page 9, line 9
client while the client's UNSUBSCRIBE message cancelling that client while the client's UNSUBSCRIBE message cancelling that
subscription is simultaneously in flight from client to server. subscription is simultaneously in flight from client to server.
The exchange between client and server terminates when either end The exchange between client and server terminates when either end
closes the TCP connection with a TCP FIN or RST. closes the TCP connection with a TCP FIN or RST.
6.1. Discovery 6.1. Discovery
The first step in DNS Push Notification subscription is to discover The first step in DNS Push Notification subscription is to discover
an appropriate DNS server that supports DNS Push Notifications for an appropriate DNS server that supports DNS Push Notifications for
the desired zone. The client MUST also determine which TCP port on the desired zone.
the server is listening for connections, which need not be (and often
is not) the typical TCP port 53 used for conventional DNS, or TCP The client begins by opening a DNS Session to its normal configured
port 853 used for DNS over TLS [RFC7858]. DNS recursive resolver and requesting a Push Notification
subscription. If this is successful, then the recursive resolver
will make appropriate Push Notification subscriptions on the client's
behalf, and the client will recieve appropriate results. If the
recursive resolver does not support Push Notification subscriptions,
then it will return an error code, and the client should proceed to
discover the appropriate server to talk to directly. The client MUST
also determine which TCP port on the server is listening for
connections, which need not be (and often is not) the typical TCP
port 53 used for conventional DNS, or TCP port 853 used for DNS over
TLS [RFC7858].
1. The client begins the discovery by sending a DNS query to its 1. The client begins the discovery by sending a DNS query to its
local resolver, with record type SOA [RFC1035] for the record to local resolver, with record type SOA [RFC1035] for the record to
which it wishes to subscribe. As an example, if it wishes to which it wishes to subscribe. As an example, if it wishes to
subscribe to PTR records with the name subscribe to PTR records with the name
_printers._tcp.foo.example.com, it sends an SOA query for _printers._tcp.foo.example.com, it sends an SOA query for
_printers._tcp.foo.example.com. The goal is to determine the _printers._tcp.foo.example.com. The goal is to determine the
authoritative server for foo.example.com. authoritative server for _printers._tcp.foo.example.com.
2. If the SOA record exists as exactly specified in the query, it is 2. If the SOA record exists as exactly specified in the query, it is
expected to be returned in the Answer section with a NOERROR expected to be returned in the Answer section with a NOERROR
response code. If the exact SOA record does not exist, the response code. If the exact SOA record does not exist, the
client may get back a NOERROR/NODATA response or it may get back client may get back a NOERROR/NODATA response or it may get back
a NXDOMAIN/Name Error response. This depends on the resolver a NXDOMAIN/Name Error response. This depends on the resolver
implementation and whether the domain exists. The client is implementation and whether the domain exists. The client is
looking for an SOA record to be returned in either the Answer looking for an SOA record to be returned in either the Answer
section or the Authority section with a NOERROR response code. section or the Authority section with a NOERROR response code.
If the client receives an NXDOMAIN/Name Error response code, it If the client receives an NXDOMAIN/Name Error response code or a
should strip the leading label from the query name and if the response containing no SOA record, it should strip the leading
resulting name has at least one label in it, the client should label from the query name and if the resulting name has at least
send a new SOA query, repeating this until a NOERROR response one label in it, the client should send a new SOA query,
code is received or the query name is empty. In the case of an repeating this until a NOERROR response code is received or the
empty name, the client may retry the operation at a later time, query name is empty. In the case of an empty name, the client
of the client's choosing, such after a change in network may retry the operation at a later time, of the client's
attachment. choosing, such after a change in network attachment.
3. In the example above, if an SOA record query is sent for 3. In the example above, if an SOA record query is sent for
_printers._tcp.foo.example.com and an NXDOMAIN/Name Error is _printers._tcp.foo.example.com and an NXDOMAIN/Name Error is
returned with an SOA record in the Authority section for returned with an SOA record in the Authority section for
foo.example.com, the client should strip the leading label and foo.example.com, the client should strip the leading label and
query an SOA record for _tcp.foo.example.com. If a NOERROR/ query an SOA record for _tcp.foo.example.com. If a NOERROR/
NODATA response is received with an SOA record in the Authority NODATA response is received with an SOA record in the Authority
section for foo.example.com, this is sufficent. If an NXDOMAIN/ section for foo.example.com, this is sufficent. If an NXDOMAIN/
Name Error response is received, the client should again strip Name Error response is received, the client should again strip
the leading label and query an SOA record for foo.example.com. the leading label and query an SOA record for foo.example.com.
skipping to change at page 13, line 4 skipping to change at page 14, line 4
is not using for any other active operation on this connection. For is not using for any other active operation on this connection. For
the purposes here, a MESSAGE ID is in use on this connection if the the purposes here, a MESSAGE ID is in use on this connection if the
client has used it in a request for which it has not yet received a client has used it in a request for which it has not yet received a
response, or if the client has used it for a subscription which it response, or if the client has used it for a subscription which it
has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response
the server MUST echo back the MESSAGE ID value unchanged. the server MUST echo back the MESSAGE ID value unchanged.
The other header fields MUST be set as described in the DNS Session The other header fields MUST be set as described in the DNS Session
Signaling specification [SessSig]. The DNS Opcode is the Session Signaling specification [SessSig]. The DNS Opcode is the Session
Signaling Opcode (tentatively 6). The four count fields MUST be Signaling Opcode (tentatively 6). The four count fields MUST be
empty, and the corresponding four sections MUST be empty (i.e., zero, and the corresponding four sections MUST be empty (i.e.,
absent). absent).
The SSOP-TYPE is SUBSCRIBE (tentatively 0x40). The SSOP-LENGTH is The SSOP-TYPE is SUBSCRIBE (tentatively 0x40). The SSOP-LENGTH is
the length of the SSOP-DATA that follows, which specifies the name, the length of the SSOP-DATA that follows, which specifies the name,
type, and class of the record(s) being sought. type, and class of the record(s) being sought.
The SSOP-DATA for a SUBSCRIBE request MUST contain exactly one The SSOP-DATA for a SUBSCRIBE request MUST contain exactly one
question. The SSOP-DATA for a SUBSCRIBE request has no QDCOUNT field question. The SSOP-DATA for a SUBSCRIBE request has no QDCOUNT field
to specify more than one question. Since SUBSCRIBE requests are sent to specify more than one question. Since SUBSCRIBE requests are sent
over TCP, multiple SUBSCRIBE request messages can be concatenated in over TCP, multiple SUBSCRIBE request messages can be concatenated in
a single TCP stream and packed efficiently into TCP segments. a single TCP stream and packed efficiently into TCP segments.
If accepted, the subscription will stay in effect until the client If accepted, the subscription will stay in effect until the client
cancels the subscription using UNSUBSCRIBE or until the connection cancels the subscription using UNSUBSCRIBE or until the connection
between the client and the server is closed. between the client and the server is closed.
SUBSCRIBE requests on a given connection MUST be unique. A client SUBSCRIBE requests on a given connection MUST be unique. A client
MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and
CLASS of an existing active subscription on that TLS/TCP connection. CLASS of an existing active subscription on that TLS/TCP connection.
For the purpose of this matching, the established DNS case- For the purpose of this matching, the established DNS case-
insensitivity for US-ASCII letters applies (e.g., "foo.com" and insensitivity for US-ASCII letters applies (e.g., "example.com" and
"Foo.com" are the same). If a server receives such a duplicate "Example.com" are the same). If a server receives such a duplicate
SUBSCRIBE message this is an error and the server MUST immediately SUBSCRIBE message this is an error and the server MUST immediately
terminate the connection with a TCP RST (or equivalent for other terminate the connection with a TCP RST (or equivalent for other
protocols). protocols).
DNS wildcarding is not supported. That is, a wildcard ("*") in a DNS wildcarding is not supported. That is, a wildcard ("*") in a
SUBSCRIBE message matches only a literal wildcard character ("*") in SUBSCRIBE message matches only a literal wildcard character ("*") in
the zone, and nothing else. the zone, and nothing else.
Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message
matches only a literal CNAME record in the zone, and nothing else. matches only a literal CNAME record in the zone, and nothing else.
skipping to change at page 16, line 10 skipping to change at page 17, line 10
these values. However, future circumstances may create situations these values. However, future circumstances may create situations
where other RCODE values are appropriate in SUBSCRIBE Responses, so where other RCODE values are appropriate in SUBSCRIBE Responses, so
clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE
value. value.
If the server sends a nonzero RCODE in the SUBSCRIBE response, either If the server sends a nonzero RCODE in the SUBSCRIBE response, either
the client is (at least partially) misconfigured, the server the client is (at least partially) misconfigured, the server
resources are exhausted, or there is some other unknown failure on resources are exhausted, or there is some other unknown failure on
the server. In any case, the client shouldn't retry the subscription the server. In any case, the client shouldn't retry the subscription
right away. Either end can terminate the connection, but the client right away. Either end can terminate the connection, but the client
may want to try this subscription again or it may have other may want to try this subscription again, or it may have other
successful subscriptions that it doesn't want to abandon. If the successful subscriptions that it doesn't want to abandon. If the
server sends a nonzero RCODE then it SHOULD append a Retry Delay server sends a nonzero RCODE then it SHOULD append a Retry Delay
Modifier TLV [SessSig] to the response specifying a delay before the Modifier TLV [SessSig] to the response specifying a delay before the
client attempts this operation again. Recommended values for the client attempts this operation again. Recommended values for the
delay for different RCODE values are given below: delay for different RCODE values are given below:
For RCODE = 1 (FORMERR) the delay may be any value selected by the For RCODE = 1 (FORMERR) the delay may be any value selected by the
implementer. A value of five minutes is RECOMMENDED, to reduce implementer. A value of five minutes is RECOMMENDED, to reduce
the risk of high load from defective clients. the risk of high load from defective clients.
skipping to change at page 17, line 23 skipping to change at page 18, line 23
value of 5 minutes is RECOMMENDED. value of 5 minutes is RECOMMENDED.
For RCODE = 9 (NOTAUTH), the time delay applies to requests for other For RCODE = 9 (NOTAUTH), the time delay applies to requests for other
names falling within the same zone. Requests for names falling names falling within the same zone. Requests for names falling
within other zones are not subject to the delay. For all other within other zones are not subject to the delay. For all other
RCODEs the time delay applies to all subsequent requests to this RCODEs the time delay applies to all subsequent requests to this
server. server.
After sending an error response the server MAY allow the connection After sending an error response the server MAY allow the connection
to remain open, or MAY send a DNS Push Notification Retry Delay to remain open, or MAY send a DNS Push Notification Retry Delay
Operation TLV asserting the client close the TCP connection, as Operation TLV instructing the client to close the TCP connection, as
described in the DNS Session Signaling specification [SessSig]. described in the DNS Session Signaling specification [SessSig].
Clients MUST correctly handle both cases. Clients MUST correctly handle both cases.
6.3. DNS Push Notification Updates 6.3. DNS Push Notification Updates
Once a subscription has been successfully established, the server Once a subscription has been successfully established, the server
generates PUSH messages to send to the client as appropriate. In the generates PUSH messages to send to the client as appropriate. In the
case that the answer set was non-empty at the moment the subscription case that the answer set was non-empty at the moment the subscription
was established, an initial PUSH message will be sent immediately was established, an initial PUSH message will be sent immediately
following the SUBSCRIBE Response. Subsequent changes to the answer following the SUBSCRIBE Response. Subsequent changes to the answer
skipping to change at page 20, line 16 skipping to change at page 21, line 16
is not currently using for any other active outgoing request that it is not currently using for any other active outgoing request that it
has sent on this connection. The MESSAGE ID in the outgoing PUSH has sent on this connection. The MESSAGE ID in the outgoing PUSH
message is selected by the server and has no relationship to the message is selected by the server and has no relationship to the
MESSAGE ID in any of the client subscriptions it may relate to. In MESSAGE ID in any of the client subscriptions it may relate to. In
the PUSH response the client MUST echo back the MESSAGE ID value the PUSH response the client MUST echo back the MESSAGE ID value
unchanged. unchanged.
The other header fields MUST be set as described in the DNS Session The other header fields MUST be set as described in the DNS Session
Signaling specification [SessSig]. The DNS Opcode is the Session Signaling specification [SessSig]. The DNS Opcode is the Session
Signaling Opcode (tentatively 6). The four count fields MUST be Signaling Opcode (tentatively 6). The four count fields MUST be
empty, and the corresponding four sections MUST be empty (i.e., zero, and the corresponding four sections MUST be empty (i.e.,
absent). absent).
The SSOP-TYPE is PUSH (tentatively 0x41). The SSOP-LENGTH is the The SSOP-TYPE is PUSH (tentatively 0x41). The SSOP-LENGTH is the
length of the SSOP-DATA that follows, which specifies the changes length of the SSOP-DATA that follows, which specifies the changes
being communicated. being communicated.
The SSOP-DATA contains one or more Update records. A PUSH Message The SSOP-DATA contains one or more Update records. A PUSH Message
MUST contain at least one Update record. If a PUSH Message is MUST contain at least one Update record. If a PUSH Message is
received that contains no Update records, this is a fatal error, and received that contains no Update records, this is a fatal error, and
the receiver MUST immediately terminate the connection with a TCP RST the receiver MUST immediately terminate the connection with a TCP RST
skipping to change at page 22, line 12 skipping to change at page 23, line 12
record aging resumes and records are removed from the local cache record aging resumes and records are removed from the local cache
when their TTL reaches zero. when their TTL reaches zero.
6.3.2. PUSH Response 6.3.2. PUSH Response
Each PUSH message generates exactly one PUSH response from the Each PUSH message generates exactly one PUSH response from the
receiver. receiver.
A PUSH response message begins with the standard DNS Session A PUSH response message begins with the standard DNS Session
Signaling 12-byte header [SessSig], possibly followed by one or more Signaling 12-byte header [SessSig], possibly followed by one or more
optional Modifier TLVs, such as a Retry Delay Modifier TLV. optional Modifier TLVs.
The MESSAGE ID field MUST echo the value given in the ID field of the The MESSAGE ID field MUST echo the value given in the ID field of the
PUSH message. PUSH message.
A PUSH response message MUST NOT contain a Session Signaling A PUSH response message MUST NOT contain a Session Signaling
Operation TLV. The Session Signaling Operation TLV is NOT copied Operation TLV. The Session Signaling Operation TLV is NOT copied
from the PUSH message. from the PUSH message.
In a PUSH response the RCODE MUST be zero. Receiving a PUSH response In a PUSH response the RCODE MUST be zero. Receiving a PUSH response
with a nonzero RCODE is a fatal error, and the receiver MUST with a nonzero RCODE is a fatal error, and the receiver MUST
skipping to change at page 30, line 5 skipping to change at page 31, line 5
is not using for any other active operation on this connection. For is not using for any other active operation on this connection. For
the purposes here, a MESSAGE ID is in use on this connection if the the purposes here, a MESSAGE ID is in use on this connection if the
client has used it in a request for which it has not yet received a client has used it in a request for which it has not yet received a
response, or if the client has used it for a subscription which it response, or if the client has used it for a subscription which it
has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response
the server MUST echo back the MESSAGE ID value unchanged. the server MUST echo back the MESSAGE ID value unchanged.
The other header fields MUST be set as described in the DNS Session The other header fields MUST be set as described in the DNS Session
Signaling specification [SessSig]. The DNS Opcode is the Session Signaling specification [SessSig]. The DNS Opcode is the Session
Signaling Opcode (tentatively 6). The four count fields MUST be Signaling Opcode (tentatively 6). The four count fields MUST be
empty, and the corresponding four sections MUST be empty (i.e., zero, and the corresponding four sections MUST be empty (i.e.,
absent). absent).
The SSOP-TYPE is RECONFIRM (tentatively 0x43). The SSOP-LENGTH is The SSOP-TYPE is RECONFIRM (tentatively 0x43). The SSOP-LENGTH is
the length of the data that follows, which specifies the name, type, the length of the data that follows, which specifies the name, type,
class, and content of the record being disputed. class, and content of the record being disputed.
The SSOP-DATA for a RECONFIRM request MUST contain exactly one The SSOP-DATA for a RECONFIRM request MUST contain exactly one
record. The SSOP-DATA for a RECONFIRM request has no count field to record. The SSOP-DATA for a RECONFIRM request has no count field to
specify more than one record. Since RECONFIRM requests are sent over specify more than one record. Since RECONFIRM requests are sent over
TCP, multiple RECONFIRM request messages can be concatenated in a TCP, multiple RECONFIRM request messages can be concatenated in a
skipping to change at page 32, line 30 skipping to change at page 33, line 30
RCODE value NOTAUTH indicates that the server is not authoritative RCODE value NOTAUTH indicates that the server is not authoritative
for the requested name, and can do nothing to remedy the apparent for the requested name, and can do nothing to remedy the apparent
error. Note that there may be future cases in which a server is able error. Note that there may be future cases in which a server is able
to pass on the RECONFIRM request to the ultimate source of the to pass on the RECONFIRM request to the ultimate source of the
information, and in these cases the server should return NOERROR. information, and in these cases the server should return NOERROR.
RCODE value SSOPNOTIMP indicates that the server does not support RCODE value SSOPNOTIMP indicates that the server does not support
RECONFIRM requests. RECONFIRM requests.
Similarly, a server would only generate SSOPNOTIMP if it did not
support Push Notifications, and if the server does not support Push
Notifications then it should not be possible for a client to have an
active subscription to cancel.
Nonzero RCODE values SERVFAIL, REFUSED and SSOPNOTIMP are benign from Nonzero RCODE values SERVFAIL, REFUSED and SSOPNOTIMP are benign from
the client's point of view. The client may log them to aid in the client's point of view. The client may log them to aid in
debugging, but otherwise they require no special action. debugging, but otherwise they require no special action.
Nonzero RCODE values other than these three indicate a serious Nonzero RCODE values other than these three indicate a serious
problem with the client. After sending an error response other than problem with the client. After sending an error response other than
one of these three, the server SHOULD send a DNS Session Signaling one of these three, the server SHOULD send a DNS Session Signaling
Retry Delay Operation TLV and then close the TCP connection, as Retry Delay Operation TLV and then close the TCP connection, as
described in the DNS Session Signaling specification [SessSig]. described in the DNS Session Signaling specification [SessSig].
 End of changes. 19 change blocks. 
68 lines changed or deleted 75 lines changed or added

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