< draft-ietf-dnssd-push-19.txt   draft-ietf-dnssd-push-20.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: September 25, 2019 Apple Inc. Expires: December 20, 2019 Apple Inc.
March 24, 2019 June 18, 2019
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-19 draft-ietf-dnssd-push-20
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 September 25, 2019. This Internet-Draft will expire on December 20, 2019.
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 2, line 32 skipping to change at page 2, line 32
6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20
6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20
6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25
6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25 6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25
6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27
6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28 6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28
6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30 6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30
6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31 6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32
7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 32 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33
7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Domain Name System (DNS) records may be updated using DNS Update Domain Name System (DNS) records may be updated using DNS Update
[RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can [RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can
also generate changes to a DNS zone. This document specifies a also generate changes to a DNS zone. This document specifies a
protocol for DNS clients to subscribe to receive asynchronous protocol for DNS clients to subscribe to receive asynchronous
notifications of changes to RRSets of interest. It is immediately notifications of changes to RRSets of interest. It is immediately
relevant in the case of DNS Service Discovery [RFC6763] but is not relevant in the case of DNS Service Discovery [RFC6763] but is not
limited to that use case, and provides a general DNS mechanism for limited to that use case, and provides a general DNS mechanism for
skipping to change at page 10, line 14 skipping to change at page 10, line 14
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 desired zone.
The client begins by opening a DSO Session to its normal configured The client begins by opening a DSO Session to its normal configured
DNS recursive resolver and requesting a Push Notification DNS recursive resolver and requesting a Push Notification
subscription. This connection is made to TCP port 853, the default subscription. This connection is made to TCP port 853, the default
port for DNS-over-TLS DNS over TLS [RFC7858]. If the request for a port for DNS-over-TLS [RFC7858]. If the request for a Push
Push Notification subscription is successful, then the recursive Notification subscription is successful, then the recursive resolver
resolver will make a corresponding Push Notification subscription on will make a corresponding Push Notification subscription on the
the client's behalf (if the recursive resolver doesn't already have client's behalf (if the recursive resolver doesn't already have an
an active subscription for that name, type, and class), and pass on active subscription for that name, type, and class), and pass on any
any results it receives back to the client. This is closely results it receives back to the client. This is closely analogous to
analogous to how a client sends normal DNS queries to its configured how a client sends normal DNS queries to its configured DNS recursive
DNS recursive resolver, which issues queries on the client's behalf resolver, which issues queries on the client's behalf (if the
(if the recursive resolver doesn't already have appropriate answer(s) recursive resolver doesn't already have appropriate answer(s) in its
in its cache), and passes on any results it receives back to the cache), and passes on any results it receives back to the client.
client.
In many contexts, the recursive resolver will be able to handle Push In many contexts, the recursive resolver will be able to handle Push
Notifications for all names that the client may need to follow. Use Notifications for all names that the client may need to follow. Use
of VPN tunnels and split-view DNS can create some additional of VPN tunnels and split-view DNS can create some additional
complexity in the client software here; the techniques to handle VPN complexity in the client software here; the techniques to handle VPN
tunnels and split-view DNS for DNS Push Notifications are the same as tunnels and split-view DNS for DNS Push Notifications are the same as
those already used to handle this for normal DNS queries. those already used to handle this for normal DNS queries.
If the recursive resolver does not support DNS over TLS, or does If the recursive resolver does not support DNS over TLS, or does
support DNS over TLS but is not listening on TCP port 853, or does support DNS over TLS but is not listening on TCP port 853, or does
skipping to change at page 30, line 25 skipping to change at page 30, line 25
C-A: Client request or unidirectional message, additional TLV C-A: Client request or unidirectional message, additional TLV
CRP: Response back to client, primary TLV CRP: Response back to client, primary TLV
CRA: Response back to client, additional TLV CRA: Response back to client, additional TLV
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
| TLV Type | C-P | C-U | C-A | CRP | CRA | | TLV Type | C-P | C-U | C-A | CRP | CRA |
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
| SUBSCRIBE | X | | | | | | SUBSCRIBE | X | | | | |
| PUSH | | | | | | | PUSH | | | | | |
| UNSUBSCRIBE | | X | | | | | UNSUBSCRIBE | | X | | | |
| RECONFIRM | X | | | | | | RECONFIRM | | X | | | |
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
Table 2: DSO TLV Client Context Summary Table 2: DSO TLV Client Context Summary
The server TLV contexts are: The server TLV contexts are:
S-P: Server request message, primary TLV S-P: Server request message, primary TLV
S-U: Server unidirectional message, primary TLV S-U: Server unidirectional message, primary TLV
S-A: Server request or unidirectional message, additional TLV S-A: Server request or unidirectional message, additional TLV
SRP: Response back to server, primary TLV SRP: Response back to server, primary TLV
skipping to change at page 32, line 17 skipping to change at page 32, line 17
The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS
Push Notifications [RFC8310]. Cleartext connections for DNS Push Push Notifications [RFC8310]. Cleartext connections for DNS Push
Notifications are not permissible. Since this is a new protocol, Notifications are not permissible. Since this is a new protocol,
transition mechanisms from the Opportunistic Privacy profile are transition mechanisms from the Opportunistic Privacy profile are
unnecessary. unnecessary.
Also, see Section 9 of the DNS over (D)TLS Usage Profiles document Also, see Section 9 of the DNS over (D)TLS Usage Profiles document
[RFC8310] for additional recommendations for various versions of TLS [RFC8310] for additional recommendations for various versions of TLS
usage. usage.
As a consequence of requiring TLS, client certificate authentication
and verification may also be enforced by the server for stronger
client-server security or end-to-end security. However,
recommendations for security in particular deployment scenarios are
outside the scope of this document.
DNSSEC is RECOMMENDED for the authentication of DNS Push Notification DNSSEC is RECOMMENDED for the authentication of DNS Push Notification
servers. TLS alone does not provide complete security. TLS servers. TLS alone does not provide complete security. TLS
certificate verification can provide reasonable assurance that the certificate verification can provide reasonable assurance that the
client is really talking to the server associated with the desired client is really talking to the server associated with the desired
host name, but since the desired host name is learned via a DNS SRV host name, but since the desired host name is learned via a DNS SRV
query, if the SRV query is subverted then the client may have a query, if the SRV query is subverted then the client may have a
secure connection to a rogue server. DNSSEC can provided added secure connection to a rogue server. DNSSEC can provided added
confidence that the SRV query has not been subverted. confidence that the SRV query has not been subverted.
7.1. Security Services 7.1. Security Services
skipping to change at page 32, line 41 skipping to change at page 32, line 47
Confidentiality: All application-layer communication is encrypted Confidentiality: All application-layer communication is encrypted
with the goal that no party should be able to decrypt it except with the goal that no party should be able to decrypt it except
the intended receiver. the intended receiver.
Data integrity protection: Any changes made to the communication in Data integrity protection: Any changes made to the communication in
transit are detectable by the receiver. transit are detectable by the receiver.
Authentication: An end-point of the TLS communication is Authentication: An end-point of the TLS communication is
authenticated as the intended entity to communicate with. authenticated as the intended entity to communicate with.
Anti-replay protection: TLS provides for the detection of and
prevention against messages sent previously over a TLS connection
(such as DNS Push Notifications). Prior messages cannot be re-
sent at a later time as a form of a man-in-the-middle attack.
Deployment recommendations on the appropriate key lengths and cypher Deployment recommendations on the appropriate key lengths and cypher
suites are beyond the scope of this document. Please refer to TLS suites are beyond the scope of this document. Please refer to TLS
Recommendations [RFC7525] for the best current practices. Keep in Recommendations [RFC7525] for the best current practices. Keep in
mind that best practices only exist for a snapshot in time and mind that best practices only exist for a snapshot in time and
recommendations will continue to change. Updated versions or errata recommendations will continue to change. Updated versions or errata
may exist for these recommendations. may exist for these recommendations.
7.2. TLS Name Authentication 7.2. TLS Name Authentication
As described in Section 6.1, the client discovers the DNS Push As described in Section 6.1, the client discovers the DNS Push
 End of changes. 11 change blocks. 
21 lines changed or deleted 31 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/