draft-ietf-dnssd-push-23.txt   draft-ietf-dnssd-push-24.txt 
Internet Engineering Task Force T. Pusateri Internet Engineering Task Force T. Pusateri
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track S. Cheshire Intended status: Standards Track S. Cheshire
Expires: January 22, 2020 Apple Inc. Expires: February 8, 2020 Apple Inc.
July 21, 2019 August 7, 2019
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-23 draft-ietf-dnssd-push-24
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 are relatively static. When efficiently for queries for data that are 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, as long as the polling rate is not the updated results when polled, as long as the polling rate is not
too high. But there exists no mechanism for a client to be too high. But there exists no mechanism for a client to be
asynchronously notified when these changes occur. This document asynchronously notified when these changes occur. This document
defines a mechanism for a client to be notified of such changes to defines a mechanism for a client to be notified of such changes to
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 22, 2020. This Internet-Draft will expire on February 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 6, line 16 skipping to change at page 6, line 16
(b) A DNS Push Notification client SHOULD NOT routinely keep a DNS (b) A DNS Push Notification client SHOULD NOT routinely keep a DNS
Push Notification subscription active 24 hours a day, 7 days a week, Push Notification subscription active 24 hours a day, 7 days a week,
just to keep a list in memory up to date so that if the user does just to keep a list in memory up to date so that if the user does
choose to bring up an on-screen display of that data, it can be choose to bring up an on-screen display of that data, it can be
displayed really fast. DNS Push Notifications are designed to be displayed really fast. DNS Push Notifications are designed to be
fast enough that there is no need to pre-load a "warm" list in memory fast enough that there is no need to pre-load a "warm" list in memory
just in case it might be needed later. just in case it might be needed later.
Generally, as described in the DNS Stateful Operations specification Generally, as described in the DNS Stateful Operations specification
[RFC8490], a client must not keep a session to a server open [RFC8490], a client must not keep a DSO session to a server open
indefinitely if it has no subscriptions (or other operations) active indefinitely if it has no subscriptions (or other operations) active
on that session. A client MAY close a session as soon as it becomes on that session. A client MAY close a DSO session immediately it
idle, and then if needed in the future, open a new session when becomes idle, and then if needed in the future, open a new session
required. Alternatively, a client MAY speculatively keep an idle when required. Alternatively, a client MAY speculatively keep an
session open for some time, subject to the constraint that it MUST idle DSO session open for some time, subject to the constraint that
NOT keep a session open that has been idle for more than the it must not keep a session open that has been idle for more than the
session's idle timeout (15 seconds by default) [RFC8490]. session's idle timeout (15 seconds by default) [RFC8490].
Note that a DSO session which has an active DNS Push Notification
subscription is not considered idle, even if there is no traffic
flowing for an extended period of time. In this case the DSO
inactivity timeout does not apply, because the session is not
inactive, but the keepalive interval does still apply, to ensure
generation of sufficient messages to maintain state in middleboxes
(such at NAT gateways or firewalls) and for the client and server to
periodically verify that they still have connectivity to each other.
This is described in Section 6.2 of the DSO specification [RFC8490].
4. State Considerations 4. 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
characteristics, network bandwidth, and operating system resource characteristics, network bandwidth, and operating system resource
allocation. After a client establishes a session to a DNS server, allocation. After a client establishes a session to a DNS server,
each subscription is individually accepted or rejected. Servers may each subscription is individually accepted or rejected. Servers may
employ various techniques to limit subscriptions to a manageable employ various techniques to limit subscriptions to a manageable
level. Correspondingly, the client is free to establish simultaneous level. Correspondingly, the client is free to establish simultaneous
skipping to change at page 7, line 29 skipping to change at page 7, line 29
concerns of state overload at the server which is a potential problem concerns of state overload at the server which is a potential problem
with connectionless protocols using spoofed source addresses. All with connectionless protocols using spoofed source addresses. All
subscribers are guaranteed to be reachable by the server by virtue of subscribers are guaranteed to be reachable by the server by virtue of
the TCP three-way handshake. Flooding attacks are possible with any the TCP three-way handshake. Flooding attacks are possible with any
protocol, and a benefit of TCP is that there are already established protocol, and a benefit of TCP is that there are already established
industry best practices to guard against SYN flooding and similar industry best practices to guard against SYN flooding and similar
attacks [SYN] [RFC4953]. attacks [SYN] [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], RACK: a time-based fast
[I-D.dukkipati-tcpm-tcp-loss-probe], and so on. loss detection algorithm for TCP [I-D.ietf-tcpm-rack], and so on.
Transport Layer Security (TLS) [RFC8446] is well understood, and used Transport Layer Security (TLS) [RFC8446] is well understood, and used
by many application-layer protocols running over TCP. TLS is by many application-layer protocols running over TCP. TLS is
designed to prevent eavesdropping, tampering, and message forgery. designed to prevent eavesdropping, tampering, and message forgery.
TLS is REQUIRED for every connection between a client subscriber and TLS is REQUIRED for every connection between a client subscriber and
server in this protocol specification. Additional security measures server in this protocol specification. Additional security measures
such as client authentication during TLS negotiation MAY also be such as client authentication during TLS negotiation MAY also be
employed to increase the trust relationship between client and employed to increase the trust relationship between client and
server. server.
skipping to change at page 15, line 30 skipping to change at page 15, line 30
If neither TYPE nor CLASS are ANY (255) then this is a specific If neither TYPE nor CLASS are ANY (255) then this is a specific
subscription to changes for the given NAME, TYPE and CLASS. If one subscription to changes for the given NAME, TYPE and CLASS. If one
or both of TYPE or CLASS are ANY (255) then this subscription matches or both of TYPE or CLASS are ANY (255) then this subscription matches
any type and/or any class, as appropriate. any type and/or any class, as appropriate.
NOTE: A little-known quirk of DNS is that in DNS QUERY requests, NOTE: A little-known quirk of DNS is that in DNS QUERY requests,
QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the
server should respond with ANY matching records of its choosing, not server should respond with ANY matching records of its choosing, not
necessarily ALL matching records. This can lead to some surprising necessarily ALL matching records. This can lead to some surprising
and unexpected results, where a query returns some valid answers but and unexpected results, where a query returns some valid answers but
not all of them, and makes QTYPE=ANY queries less useful than people not all of them, and makes QTYPE = 255 (ANY) queries less useful than
sometimes imagine. people sometimes imagine.
When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be
interpreted to mean "ALL", not "ANY". After accepting a subscription interpreted to mean "ALL", not "ANY". After accepting a subscription
where one or both of TYPE or CLASS are 255, the server MUST send Push where one or both of TYPE or CLASS are 255, the server MUST send Push
Notification Updates for ALL record changes that match the Notification Updates for ALL record changes that match the
subscription, not just some of them. subscription, not just some of them.
6.2.2. SUBSCRIBE Response 6.2.2. SUBSCRIBE Response
Each SUBSCRIBE request generates exactly one SUBSCRIBE response from Each SUBSCRIBE request generates exactly one SUBSCRIBE response from
skipping to change at page 21, line 36 skipping to change at page 21, line 36
all types in the specified class. all types in the specified class.
For collective remove notifications, if CLASS is 255 (ANY), then for For collective remove notifications, if CLASS is 255 (ANY), then for
the given name this deletes all records of all types in all classes. the given name this deletes all records of all types in all classes.
In this case TYPE MUST be set to zero on transmission, and MUST be In this case TYPE MUST be set to zero on transmission, and MUST be
silently ignored on reception. silently ignored on reception.
Summary of change notification types: Summary of change notification types:
Delete all RRsets from a name, in all classes Delete all RRsets from a name, in all classes
TTL=0xFFFFFFFE, RDLENGTH=0, CLASS=255 (ANY) TTL = 0xFFFFFFFE, RDLEN = 0, CLASS = 255 (ANY)
Delete all RRsets from a name, in given class: Delete all RRsets from a name, in given class:
TTL=0xFFFFFFFE, RDLENGTH=0, CLASS specifies class, TYPE=255 (ANY) TTL = 0xFFFFFFFE, RDLEN = 0, CLASS gives class, TYPE = 255 (ANY)
Delete specified RRset from a name, in given class: Delete specified RRset from a name, in given class:
TTL=0xFFFFFFFE, RDLENGTH=0 TTL = 0xFFFFFFFE, RDLEN = 0
CLASS and TYPE specify the RRset being deleted CLASS and TYPE specify the RRset being deleted
Delete an individual RR from a name: Delete an individual RR from a name:
TTL=0xFFFFFFFF TTL = 0xFFFFFFFF
CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted. CLASS, TYPE, RDLEN and RDATA specify the RR being deleted.
Add individual RR to a name Add individual RR to a name
TTLā©¾0 TTL >= 0 and TTL <= 0x7FFFFFFF
CLASS, TYPE, RDLENGTH, RDATA and TTL specify the RR being added. CLASS, TYPE, RDLEN, RDATA and TTL specify the RR being added.
Note that it is valid for the RDATA of an added or removed DNS Note that it is valid for the RDATA of an added or removed DNS
Resource Record to be empty (zero length). For example, an Address Resource Record to be empty (zero length). For example, an Address
Prefix List Resource Record [RFC3123] may have empty RDATA. Prefix List Resource Record [RFC3123] may have empty RDATA.
Therefore, a change notification with RDLEN=0 does not automatically Therefore, a change notification with RDLEN = 0 does not
indicate a remove notification. If RDLEN=0 and TTL is the in the automatically indicate a remove notification. If RDLEN = 0 and TTL
range 0 - 0x7FFFFFFF, this change notification signals the addition is the in the range 0 - 0x7FFFFFFF, this change notification signals
of a record with the given name, type, class, and empty RDATA. If the addition of a record with the given name, type, class, and empty
RDLEN=0 and TTL = 0xFFFFFFFF, this change notification signals the RDATA. If RDLEN = 0 and TTL = 0xFFFFFFFF, this change notification
removal specifically of that single record with the given name, type, signals the removal specifically of that single record with the given
class, and empty RDATA. name, type, class, and empty RDATA.
If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value
in the range 0 - 0x7FFFFFFF, then the receiver SHOULD silently ignore in the range 0 - 0x7FFFFFFF, then the receiver SHOULD silently ignore
this particular change notification record. The connection is not this particular change notification record. The connection is not
terminated and other valid change notification records within this terminated and other valid change notification records within this
PUSH message are processed as usual. PUSH message are processed as usual.
For efficiency, when generating a PUSH message, a server SHOULD For efficiency, when generating a PUSH message, a server SHOULD
include as many change notifications as it has immediately available include as many change notifications as it has immediately available
to send, rather than sending each change notification as a separate to send, rather than sending each change notification as a separate
skipping to change at page 24, line 19 skipping to change at page 24, line 19
record addition/deletion is silently ignored. Processing of other record addition/deletion is silently ignored. Processing of other
additions and deletions in this message is not affected. The DSO additions and deletions in this message is not affected. The DSO
session is not closed. This is to allow for the unavoidable race session is not closed. This is to allow for the unavoidable race
condition where a client sends an outbound UNSUBSCRIBE while inbound condition where a client sends an outbound UNSUBSCRIBE while inbound
PUSH messages for that subscription from the server are still in PUSH messages for that subscription from the server are still in
flight. flight.
In the case where a single change affects more than one active In the case where a single change affects more than one active
subscription, only one PUSH message is sent. For example, a PUSH subscription, only one PUSH message is sent. For example, a PUSH
message adding a given record may match both a SUBSCRIBE request with message adding a given record may match both a SUBSCRIBE request with
the same TYPE and a different SUBSCRIBE request with TYPE=ANY (255). the same TYPE and a different SUBSCRIBE request with TYPE = 255
It is not the case that two PUSH messages are sent because the new (ANY). It is not the case that two PUSH messages are sent because
record matches two active subscriptions. the new record matches two active subscriptions.
The server SHOULD encode change notifications in the most efficient The server SHOULD encode change notifications in the most efficient
manner possible. For example, when three AAAA records are deleted manner possible. For example, when three AAAA records are deleted
from a given name, and no other AAAA records exist for that name, the from a given name, and no other AAAA records exist for that name, the
server SHOULD send a "delete an RRset from a name" PUSH message, not server SHOULD send a "delete an RRset from a name" PUSH message, not
three separate "delete an individual RR from a name" PUSH messages. three separate "delete an individual RR from a name" PUSH messages.
Similarly, when both an SRV and a TXT record are deleted from a given Similarly, when both an SRV and a TXT record are deleted from a given
name, and no other records of any kind exist for that name, the name, and no other records of any kind exist for that name, the
server SHOULD send a "delete all RRsets from a name" PUSH message, server SHOULD send a "delete all RRsets from a name" PUSH message,
not two separate "delete an RRset from a name" PUSH messages. not two separate "delete an RRset from a name" PUSH messages.
skipping to change at page 31, line 33 skipping to change at page 31, line 33
If a client plans to terminate one or more subscriptions on a session If a client plans to terminate one or more subscriptions on a session
and doesn't intend to keep that session open, then as an efficiency and doesn't intend to keep that session open, then as an efficiency
optimization it MAY instead choose to simply close the session, which optimization it MAY instead choose to simply close the session, which
implicitly terminates all subscriptions on that session. This may implicitly terminates all subscriptions on that session. This may
occur because the client computer is being shut down, is going to occur because the client computer is being shut down, is going to
sleep, the application requiring the subscriptions has terminated, or sleep, the application requiring the subscriptions has terminated, or
simply because the last active subscription on that session has been simply because the last active subscription on that session has been
cancelled. cancelled.
When closing a session, a client should perform an orderly close of When closing a session, a client should perform an orderly close of
the TLS session in order to allow for future TLS session resumption the TLS session. Typical APIs will provide a session close method
with the server (if available). See Section 7.4 below. Typical APIs that will send a TLS close_notify alert (see Section 6.1 of the TLS
will provide a session close method that will send a TLS close_notify 1.3 specification [RFC8446]). This instructs the recipient that the
alert (see Section 6.1 of the TLS 1.3 specification [RFC8446]). This sender will not send any more data over the session. After sending
instructs the recipient that the sender will not send any more data the TLS close_notify alert the client MUST gracefully close the
over the session. After sending the TLS close_notify alert the underlying connection using a TCP FIN, so that the TLS close_notify
client MUST gracefully close the underlying connection using a TCP is reliably delivered. The mechanisms for gracefully closing a TCP
FIN, so that the TLS close_notify is reliably delivered. The connection with a TCP FIN vary depending on the networking API. For
mechanisms for gracefully closing a TCP connection with a TCP FIN example, in the BSD Sockets API, sending a TCP FIN is achieved by
vary depending on the networking API. For example, in the BSD calling "shutdown(s,SHUT_WR)" and keeping the socket open until all
Sockets API, sending a TCP FIN is achieved by calling remaining data has been read from it.
"shutdown(s,SHUT_WR)" and keeping the socket open until all remaining
data has been read from it.
If the session is forcibly closed at the TCP level by sending a RST If the session is forcibly closed at the TCP level by sending a RST
from either end of the connection, data may be lost and TLS session from either end of the connection, data may be lost.
resumption of this session will not be possible.
6.8. Client Fallback to Polling 6.8. Client Fallback to Polling
There are cases where a client may exhaust all avenues for There are cases where a client may exhaust all avenues for
establishing a DNS Push Notification subscription without success. establishing a DNS Push Notification subscription without success.
This can happen if the client's configured recursive resolver does This can happen if the client's configured recursive resolver does
not support DNS over TLS, or supports DNS over TLS but is not not support DNS over TLS, or supports DNS over TLS but is not
listening on TCP port 853, or supports DNS over TLS on TCP port 853 listening on TCP port 853, or supports DNS over TLS on TCP port 853
but does not support DSO on that port, or for some other reason is but does not support DSO on that port, or for some other reason is
unable to provide a DNS Push Notification subscription. In this case unable to provide a DNS Push Notification subscription. In this case
skipping to change at page 36, line 23 skipping to change at page 36, line 23
+-----------------------+------+----------------------+-------------+ +-----------------------+------+----------------------+-------------+
| DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 | | DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 |
| Service Type | | | | | Service Type | | | |
+-----------------------+------+----------------------+-------------+ +-----------------------+------+----------------------+-------------+
Table 4: IANA Service Type Assignments Table 4: IANA Service Type Assignments
This document also defines four new DNS Stateful Operation TLV types This document also defines four new DNS Stateful Operation TLV types
to be recorded in the IANA DSO Type Code Registry. to be recorded in the IANA DSO Type Code Registry.
+-------------+------------+--------+-----------------+-------------+ +-------------+------------+---------+-----------------+------------+
| Name | Value | Early | Status | Definition | | Name | Value | Early | Status | Definition |
| | | Data | | | | | | Data | | |
+-------------+------------+--------+-----------------+-------------+ +-------------+------------+---------+-----------------+------------+
| SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section 6.2 | | SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section |
| PUSH | TBA (0x41) | NO | Standards Track | Section 6.3 | | | | | | 6.2 |
| UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section 6.4 | | PUSH | TBA (0x41) | NO | Standards Track | Section |
| RECONFIRM | TBA (0x43) | NO | Standards Track | Section 6.5 | | | | | | 6.3 |
+-------------+------------+--------+-----------------+-------------+ | UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section |
| | | | | 6.4 |
| RECONFIRM | TBA (0x43) | NO | Standards Track | Section |
| | | | | 6.5 |
+-------------+------------+---------+-----------------+------------+
Table 5: IANA DSO TLV Type Code Assignments Table 5: IANA DSO TLV Type Code Assignments
This document defines no new DNS OPCODEs or RCODEs. This document defines no new DNS OPCODEs or RCODEs.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Kiren Sekar and Marc Krochmal for The authors would like to thank Kiren Sekar and Marc Krochmal for
previous work completed in this field. previous work completed in this field.
skipping to change at page 39, line 5 skipping to change at page 38, line 49
[ST] "Service Name and Transport Protocol Port Number [ST] "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/ Registry", <http://www.iana.org/assignments/
service-names-port-numbers/>. service-names-port-numbers/>.
10.2. Informative References 10.2. Informative References
[DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-10 (work in Service Discovery", draft-ietf-dnssd-hybrid-10 (work in
progress), March 2019. progress), March 2019.
[I-D.dukkipati-tcpm-tcp-loss-probe] [I-D.ietf-tcpm-rack]
Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK:
"Tail Loss Probe (TLP): An Algorithm for Fast Recovery of a time-based fast loss detection algorithm for TCP",
Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work draft-ietf-tcpm-rack-05 (work in progress), April 2019.
in progress), February 2013.
[LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries", [LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries",
draft-sekar-dns-llq-03 (work in progress), March 2019. draft-sekar-dns-llq-03 (work in progress), March 2019.
[obs] "Observer Pattern", [obs] "Observer Pattern",
<https://en.wikipedia.org/wiki/Observer_pattern>. <https://en.wikipedia.org/wiki/Observer_pattern>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
 End of changes. 19 change blocks. 
60 lines changed or deleted 70 lines changed or added

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