draft-ietf-dnssd-push-14.txt   draft-ietf-dnssd-push-15.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 19, 2018 Apple Inc. Expires: March 21, 2019 Apple Inc.
March 18, 2018 September 17, 2018
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-14 draft-ietf-dnssd-push-15
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 19, 2018. This Internet-Draft will expire on March 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 20 skipping to change at page 3, line 20
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
DNS record change notifications. Familiarity with the DNS protocol DNS record change notifications. Familiarity with the DNS protocol
and DNS packet formats is assumed [RFC1034] [RFC1035] [RFC6895]. and DNS packet formats is assumed [RFC1034] [RFC1035] [RFC6895].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
and "OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described in
in "Key words for use in RFCs to Indicate Requirement Levels", "Key words for use in RFCs to Indicate Requirement Levels", when, and
when, and only when, they appear in all capitals, as shown here only when, they appear in all capitals, as shown here [RFC2119]
[RFC2119] [RFC8174]. [RFC8174].
2. Motivation 2. Motivation
As the domain name system continues to adapt to new uses and changes As the domain name system continues to adapt to new uses and changes
in deployment, polling has the potential to burden DNS servers at in deployment, polling has the potential to burden DNS servers at
many levels throughout the network. Other network protocols have many levels throughout the network. Other network protocols have
successfully deployed a publish/subscribe model following the successfully deployed a publish/subscribe model following the
Observer design pattern [obs]. XMPP Publish-Subscribe [XEP0060] and Observer design pattern [obs]. XMPP Publish-Subscribe [XEP0060] and
Atom [RFC4287] are examples. While DNS servers are generally highly Atom [RFC4287] are examples. While DNS servers are generally highly
tuned and capable of a high rate of query/response traffic, adding a tuned and capable of a high rate of query/response traffic, adding a
skipping to change at page 5, line 19 skipping to change at page 5, line 19
resource record sets (RRSets) on the zone's server. resource record sets (RRSets) on the zone's server.
This specification adopts a simplified subset of these existing This specification adopts a simplified subset of these existing
syntax and semantics, and uses them for DNS Push Notification syntax and semantics, and uses them for DNS Push Notification
messages going in the opposite direction, from server to client, to messages going in the opposite direction, from server to client, to
communicate changes to a zone. The client subscribes for Push communicate changes to a zone. The client subscribes for Push
Notifications by connecting to the server and sending DNS message(s) Notifications by connecting to the server and sending DNS message(s)
indicating the RRSet(s) of interest. When the client loses interest indicating the RRSet(s) of interest. When the client loses interest
in receiving further updates to these records, it unsubscribes. in receiving further updates to these records, it unsubscribes.
The DNS Push Notification server for a zone is any server capable The DNS Push Notification server for a zone is any server capable of
of generating the correct change notifications for a name. generating the correct change notifications for a name. It may be a
It may be a master, slave, or stealth name server [RFC7719]. primary, secondary, or stealth name server [RFC7719]. Consequently,
Consequently, the "_dns-push-tls._tcp.<zone>" SRV record for a the "_dns-push-tls._tcp.<zone>" SRV record for a zone MAY reference
zone MAY reference the same target host and port as that zone's the same target host and port as that zone's
"_dns-update-tls._tcp.<zone>" SRV record. When the same target host "_dns-update-tls._tcp.<zone>" SRV record. When the same target host
and port is offered for both DNS Updates and DNS Push Notifications, and port is offered for both DNS Updates and DNS Push Notifications,
a client MAY use a single TCP connection to that server for both DNS a client MAY use a single TCP connection to that server for both DNS
Updates and DNS Push Notification Queries. Updates and DNS Push Notification Subscriptions.
Supporting DNS Updates and DNS Push Notifications on the same server Supporting DNS Updates and DNS Push Notifications on the same server
is OPTIONAL. A DNS Push Notification server does NOT also have to is OPTIONAL. A DNS Push Notification server does NOT also have to
support DNS Update. support DNS Update.
DNS Updates and DNS Push Notifications may be handled on different DNS Updates and DNS Push Notifications may be handled on different
ports on the same target host, in which case they are not considered ports on the same target host, in which case they are not considered
to be the "same server" for the purposes of this specification, and to be the "same server" for the purposes of this specification, and
communications with these two ports are handled independently. communications with these two ports are handled independently.
skipping to change at page 9, line 30 skipping to change at page 9, line 30
to it. Once the client has indicated willingness to use DSO by to it. Once the client has indicated willingness to use DSO by
sending one of its own, either side of the session may then initiate sending one of its own, either side of the session may then initiate
further DSO messages at any time. further DSO messages at any time.
A DNS Push Notification exchange begins with the client discovering A DNS Push Notification exchange begins with the client discovering
the appropriate server, using the procedure described in Section 6.1, the appropriate server, using the procedure described in Section 6.1,
and then making a TLS/TCP connection to it. and then making a TLS/TCP connection to it.
A typical DNS Push Notification client will immediately issue a DSO A typical DNS Push Notification client will immediately issue a DSO
Keepalive operation to request a session timeout or keepalive Keepalive operation to request a session timeout or keepalive
interval longer than the the 15-second defaults, but this is not interval longer than the the 15-second default, but this is not
required. A DNS Push Notification client MAY issue other requests on required. A DNS Push Notification client MAY issue other requests on
the session first, and only issue a DSO Keepalive operation later if the session first, and only issue a DSO Keepalive operation later if
it determines that to be necessary. it determines that to be necessary. However, Push Notification
subscriptions can also be used to establish the DSO session.
Once the session is made, the client may then add and remove Push In accordance with the current set of active subscriptions, the
Notification subscriptions. In accordance with the current set of server sends relevant asynchronous Push Notifications to the client.
active subscriptions the server sends relevant asynchronous Push Note that a client MUST be prepared to receive (and silently ignore)
Notifications to the client. Note that a client MUST be prepared to Push Notifications for subscriptions it has previously removed, since
receive (and silently ignore) Push Notifications for subscriptions it there is no way to prevent the situation where a Push Notification is
has previously removed, since there is no way to prevent the in flight from server to client while the client's UNSUBSCRIBE
situation where a Push Notification is in flight from server to message cancelling that subscription is simultaneously in flight from
client while the client's UNSUBSCRIBE message cancelling that client to server.
subscription is simultaneously in flight from client to server.
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. If this is successful, then the recursive resolver subscription. If this is successful, then the recursive resolver
skipping to change at page 11, line 35 skipping to change at page 11, line 35
configuration error which should not happen and the client gives configuration error which should not happen and the client gives
up. The client may retry the operation at a later time, of the up. The client may retry the operation at a later time, of the
client's choosing, such after a change in network attachment. client's choosing, such after a change in network attachment.
5. Once the SOA is known (either by virtue of being seen in the 5. Once the SOA is known (either by virtue of being seen in the
Answer Section, or in the Authority Section), the client sends a Answer Section, or in the Authority Section), the client sends a
DNS query with type SRV [RFC2782] for the record name DNS query with type SRV [RFC2782] for the record name
"_dns-push-tls._tcp.<zone>", where <zone> is the owner name of "_dns-push-tls._tcp.<zone>", where <zone> is the owner name of
the discovered SOA record. the discovered SOA record.
6. If the zone in question does not offer DNS Push Notifications 6. If the zone in question is set up to offer DNS Push Notifications
then SRV record MUST NOT exist, and the SRV query will return a
negative answer. (The "_dns-push-tls._tcp" service type is
allocated by IANA for this purpose, and, like any allocated IANA
service type, MUST NOT be used for other services. Other
services that require an IANA service type should use a unique
service type allocated by IANA for that service [RFC6335][ST].)
7. If the zone in question is set up to offer DNS Push Notifications
then this SRV record MUST exist. (If this SRV record does not then this SRV record MUST exist. (If this SRV record does not
exist then the zone is not correctly configured for DNS Push exist then the zone is not correctly configured for DNS Push
Notifications as specified in this document.) The SRV "target" Notifications as specified in this document.) The SRV "target"
contains the name of the server providing DNS Push Notifications contains the name of the server providing DNS Push Notifications
for the zone. The port number on which to contact the server is for the zone. The port number on which to contact the server is
in the SRV record "port" field. The address(es) of the target in the SRV record "port" field. The address(es) of the target
host MAY be included in the Additional Section, however, the host MAY be included in the Additional Section, however, the
address records SHOULD be authenticated before use as described address records SHOULD be authenticated before use as described
below in Section 7.2 and in the specification for using DANE TLSA below in Section 7.2 and in the specification for using DANE TLSA
Records with SRV Records [RFC7673]. Records with SRV Records [RFC7673], if applicable.
8. More than one SRV record may be returned. In this case, the 7. More than one SRV record may be returned. In this case, the
"priority" and "weight" values in the returned SRV records are "priority" and "weight" values in the returned SRV records are
used to determine the order in which to contact the servers for used to determine the order in which to contact the servers for
subscription requests. As described in the SRV specification subscription requests. As described in the SRV specification
[RFC2782], the server with the lowest "priority" is first [RFC2782], the server with the lowest "priority" is first
contacted. If more than one server has the same "priority", the contacted. If more than one server has the same "priority", the
"weight" indicates the weighted probability that the client "weight" indicates the weighted probability that the client
should contact that server. Higher weights have higher should contact that server. Higher weights have higher
probabilities of being selected. If a server is not willing to probabilities of being selected. If a server is not willing to
accept a subscription request, or is not reachable within a accept a subscription request, or is not reachable within a
reasonable time, as determined by the client, then a subsequent reasonable time, as determined by the client, then a subsequent
skipping to change at page 13, line 38 skipping to change at page 13, line 38
The MESSAGE ID field MUST be set to a unique value, that the client The MESSAGE ID field MUST be set to a unique value, that the client
is not using for any other active operation on this session. For the is not using for any other active operation on this session. For the
purposes here, a MESSAGE ID is in use on this session if the client purposes here, a MESSAGE ID is in use on this session if the client
has used it in a request for which it has not yet received a 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 DSO The other header fields MUST be set as described in the DSO
specification [DSO]. The DNS Opcode is the DSO Opcode (tentatively specification [DSO]. The DNS Opcode is the DSO Opcode. The four
6). The four count fields MUST be zero, and the corresponding four count fields MUST be zero, and the corresponding four sections MUST
sections MUST be empty (i.e., absent). be empty (i.e., absent).
The DSO-TYPE is SUBSCRIBE (tentatively 0x40). The DSO-LENGTH is the The DSO-TYPE is SUBSCRIBE. The DSO-LENGTH is the length of the DSO-
length of the DSO-DATA that follows, which specifies the name, type, DATA that follows, which specifies the name, type, and class of the
and class of the record(s) being sought. record(s) being sought.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID | \ | MESSAGE ID | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| Opcode | Z | RCODE | | |QR| Opcode | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = SUBSCRIBE (tentatively 0x40) | | DSO-TYPE = SUBSCRIBE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| | \ | | \
\ NAME \ | \ NAME \ |
\ \ | \ \ |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| CLASS | / | CLASS | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 1: SUBSCRIBE Request Figure 1: SUBSCRIBE Request
The DSO-DATA for a SUBSCRIBE request MUST contain exactly one The DSO-DATA for a SUBSCRIBE request MUST contain exactly one NAME,
question. The DSO-DATA for a SUBSCRIBE request has no QDCOUNT field Type, and CLASS. Since SUBSCRIBE requests are sent over TCP,
to specify more than one question. Since SUBSCRIBE requests are sent multiple SUBSCRIBE request messages can be concatenated in a single
over TCP, multiple SUBSCRIBE request messages can be concatenated in 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 DSO session cancels the subscription using UNSUBSCRIBE or until the DSO session
between the client and the server is closed. between the client and the server is closed.
SUBSCRIBE requests on a given session MUST be unique. A client MUST SUBSCRIBE requests on a given session MUST be unique. A client MUST
NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and CLASS NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and CLASS
of an existing active subscription on that DSO session. For the of an existing active subscription on that DSO session. For the
purpose of this matching, the established DNS case-insensitivity for purpose of this matching, the established DNS case-insensitivity for
US-ASCII letters applies (e.g., "example.com" and "Example.com" are US-ASCII letters applies (e.g., "example.com" and "Example.com" are
skipping to change at page 18, line 12 skipping to change at page 18, line 14
for the requested name, the retry delay may be any value selected for the requested name, the retry delay may be any value selected
by the implementer and/or configured by the operator. by the implementer and/or configured by the operator.
This is a misconfiguration, since this server is listed in a This is a misconfiguration, since this server is listed in a
"_dns-push-tls._tcp.<zone>" SRV record, but the server itself is "_dns-push-tls._tcp.<zone>" SRV record, but the server itself is
not currently configured to support DNS Push Notifications for not currently configured to support DNS Push Notifications for
that zone. Since it is possible that the misconfiguration may be that zone. Since it is possible that the misconfiguration may be
repaired at any time, the retry delay should not be set too high. repaired at any time, the retry delay should not be set too high.
By default, a value of 5 minutes is RECOMMENDED. By default, a value of 5 minutes is RECOMMENDED.
For RCODE = 11 (DNS Push SUBSCRIBE operation not supported), which For RCODE = 11 (DSOTYPENI), which occurs on a server that doesn't
occurs on a server that doesn't implement DNS Push Notifications, implement DNS Push Notifications, it is unlikely that the server
it is unlikely that the server will begin supporting DNS Push will begin supporting DNS Push Notifications in the next few
Notifications in the next few minutes, so the retry delay SHOULD minutes, so the retry delay SHOULD be one hour.
be one hour.
For other RCODE values, the retry delay should be set by the For other RCODE values, the retry delay should be set by the
server as appropriate for that error condition. By default, a server as appropriate for that error condition. By default, a
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.
skipping to change at page 19, line 19 skipping to change at page 19, line 19
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
set are then communicated to the client in subsequent PUSH messages. set are then communicated to the client in subsequent PUSH messages.
6.3.1. PUSH Message 6.3.1. PUSH Message
A PUSH message begins with the standard DSO 12-byte header [DSO], A PUSH message begins with the standard DSO 12-byte header [DSO],
followed by the PUSH TLV. A PUSH message is illustrated in Figure 2. followed by the PUSH TLV. A PUSH message is illustrated in Figure 2.
The MESSAGE ID field MUST be zero. There is no client response to a In accordance with the definition of DSO unidirectional messages, the
PUSH message. MESSAGE ID field MUST be zero. There is no client response to a PUSH
message.
The other header fields MUST be set as described in the DSO The other header fields MUST also be set as described in the DSO
specification [DSO]. The DNS Opcode is the DSO Opcode (tentatively specification [DSO]. The DNS Opcode is the DSO Opcode. The four
6). The four count fields MUST be zero, and the corresponding four count fields MUST be zero, and the corresponding four sections MUST
sections MUST be empty (i.e., absent). be empty (i.e., absent).
The DSO-TYPE is PUSH (tentatively 0x41). The DSO-LENGTH is the The DSO-TYPE is PUSH (tentatively 0x41). The DSO-LENGTH is the
length of the DSO-DATA that follows, which specifies the changes length of the DSO-DATA that follows, which specifies the changes
being communicated. being communicated.
The DSO-DATA contains one or more Update records. A PUSH Message The DSO-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 zero Update records, this is a fatal error,
the receiver MUST immediately terminate the connection with a TCP RST and the receiver MUST immediately terminate the connection with a TCP
(or equivalent for other protocols). The Update records are RST (or equivalent for other protocols). The Update records are
formatted in the customary way for Resource Records in DNS messages. formatted in the customary way for Resource Records in DNS messages.
Update records in a PUSH Message are interpreted according to the Update records in a PUSH Message are interpreted according to the
same rules as for DNS Update [RFC2136] messages, namely: same rules as for DNS Update [RFC2136] messages, namely:
Delete all RRsets from a name: Delete all RRsets from a name:
TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY.
Delete an RRset from a name: Delete an RRset from a name:
TTL=0, CLASS=ANY, RDLENGTH=0; TTL=0, CLASS=ANY, RDLENGTH=0;
TYPE specifies the RRset being deleted. TYPE specifies the RRset being deleted.
skipping to change at page 19, line 52 skipping to change at page 20, line 4
Delete an RRset from a name: Delete an RRset from a name:
TTL=0, CLASS=ANY, RDLENGTH=0; TTL=0, CLASS=ANY, RDLENGTH=0;
TYPE specifies the RRset being deleted. TYPE specifies the RRset being deleted.
Delete an individual RR from a name: Delete an individual RR from a name:
TTL=0, CLASS=NONE; TTL=0, CLASS=NONE;
TYPE, RDLENGTH and RDATA specifies the RR being deleted. TYPE, RDLENGTH and RDATA specifies the RR being deleted.
Add to an RRset: Add to an RRset:
TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID | \ | MESSAGE ID (MUST BE ZERO) | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| Opcode | Z | RCODE | | |QR| Opcode | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = PUSH (tentatively 0x41) | | DSO-TYPE = PUSH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TTL | | | TTL | |
skipping to change at page 22, line 9 skipping to change at page 22, line 9
of that fact. Consequently, a client does not have to poll to verify of that fact. Consequently, a client does not have to poll to verify
that the record is still there. Once a subscription is cancelled that the record is still there. Once a subscription is cancelled
(individually, or as a result of the DSO session being closed) record (individually, or as a result of the DSO session being closed) record
aging resumes and records are removed from the local cache when their aging resumes and records are removed from the local cache when their
TTL reaches zero. TTL reaches zero.
6.4. DNS Push Notification UNSUBSCRIBE 6.4. DNS Push Notification UNSUBSCRIBE
To cancel an individual subscription without closing the entire DSO To cancel an individual subscription without closing the entire DSO
session, the client sends an UNSUBSCRIBE message over the established session, the client sends an UNSUBSCRIBE message over the established
DSO session to the server. The UNSUBSCRIBE message is encoded in a DSO session to the server. The UNSUBSCRIBE message is encoded as a
DSO [DSO] message. This specification defines a DSO TLV for DNS Push DSO [DSO] unidirectional message. This specification defines a DSO
Notification UNSUBSCRIBE Requests/Responses (tentatively DSO Type TLV for DNS Push Notification UNSUBSCRIBE Requests/Responses
Code 0x42). (tentatively DSO Type Code 0x42).
A server MUST NOT initiate an UNSUBSCRIBE request. If a server does A server MUST NOT initiate an UNSUBSCRIBE request. If a server does
send an UNSUBSCRIBE request over a DSO session initiated by a client, send an UNSUBSCRIBE request over a DSO session initiated by a client,
this is a fatal error and the client should immediately abort the this is a fatal error and the client should immediately abort the
connection with a TCP RST (or equivalent for other protocols). connection with a TCP RST (or equivalent for other protocols).
6.4.1. UNSUBSCRIBE Request 6.4.1. UNSUBSCRIBE Request
An UNSUBSCRIBE request begins with the standard DSO 12-byte header An UNSUBSCRIBE request begins with the standard DSO 12-byte header
[DSO], followed by the UNSUBSCRIBE TLV. An UNSUBSCRIBE request [DSO], followed by the UNSUBSCRIBE TLV. An UNSUBSCRIBE request
message is illustrated in Figure 3. message is illustrated in Figure 3.
The MESSAGE ID field MUST be zero. There is no server response to a The MESSAGE ID field MUST be zero. There is no server response to a
UNSUBSCRIBE message. UNSUBSCRIBE message.
The other header fields MUST be set as described in the DSO The other header fields MUST be set as described in the DSO
specification [DSO]. The DNS Opcode is the DSO Opcode (tentatively specification [DSO]. The DNS Opcode is the DSO Opcode. The four
6). The four count fields MUST be zero, and the corresponding four count fields MUST be zero, and the corresponding four sections MUST
sections MUST be empty (i.e., absent). be empty (i.e., absent).
In the UNSUBSCRIBE TLV the DSO-TYPE is UNSUBSCRIBE (tentatively In the UNSUBSCRIBE TLV the DSO-TYPE is UNSUBSCRIBE. The DSO-LENGTH
0x42). The DSO-LENGTH is 2 octets. is 2 octets.
The DSO-DATA contains the MESSAGE ID field of the value given in the The DSO-DATA contains the MESSAGE ID field of the value given in the
ID field of an active SUBSCRIBE request. This is how the server ID field of an active SUBSCRIBE request. This is how the server
knows which SUBSCRIBE request is being cancelled. After receipt of knows which SUBSCRIBE request is being cancelled. After receipt of
the UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. the UNSUBSCRIBE request, the SUBSCRIBE request is no longer active.
It is allowable for the client to issue an UNSUBSCRIBE request for a It is allowable for the client to issue an UNSUBSCRIBE request for a
previous SUBSCRIBE request for which the client has not yet received previous SUBSCRIBE request for which the client has not yet received
a SUBSCRIBE response. This is to allow for the case where a client a SUBSCRIBE response. This is to allow for the case where a client
starts and stops a subscription in less than the round-trip time to starts and stops a subscription in less than the round-trip time to
the server. The client is NOT required to wait for the SUBSCRIBE the server. The client is NOT required to wait for the SUBSCRIBE
response before issuing the UNSUBSCRIBE request. response before issuing the UNSUBSCRIBE request.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID | \ | MESSAGE ID (MUST BE ZERO) | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| Opcode | Z | RCODE | | |QR| Opcode | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = UNSUBSCRIBE (tentatively 0x42) | | DSO-TYPE = UNSUBSCRIBE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (2 octets) | | DSO-LENGTH (2 octets) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| SUBSCRIBE MESSAGE ID | > DSO-DATA | SUBSCRIBE MESSAGE ID | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 3: UNSUBSCRIBE Request Figure 3: UNSUBSCRIBE Request
6.5. DNS Push Notification RECONFIRM 6.5. DNS Push Notification RECONFIRM
skipping to change at page 24, line 45 skipping to change at page 24, line 45
The MESSAGE ID field MUST be set to a unique value, that the client The MESSAGE ID field MUST be set to a unique value, that the client
is not using for any other active operation on this DSO session. For is not using for any other active operation on this DSO session. For
the purposes here, a MESSAGE ID is in use on this session if the the purposes here, a MESSAGE ID is in use on this session 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 DSO The other header fields MUST be set as described in the DSO
specification [DSO]. The DNS Opcode is the DSO Opcode (tentatively specification [DSO]. The DNS Opcode is the DSO Opcode. The four
6). The four count fields MUST be zero, and the corresponding four count fields MUST be zero, and the corresponding four sections MUST
sections MUST be empty (i.e., absent). be empty (i.e., absent).
The DSO-TYPE is RECONFIRM (tentatively 0x43). The DSO-LENGTH is the The DSO-TYPE is RECONFIRM (tentatively 0x43). The DSO-LENGTH is the
length of the data that follows, which specifies the name, type, 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.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID | \ | MESSAGE ID | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| Opcode | Z | RCODE | | |QR| Opcode | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = RECONFIRM (tentatively 0x43) | | DSO-TYPE = RECONFIRM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA \ / \ RDATA \ /
skipping to change at page 29, line 8 skipping to change at page 29, line 8
If a client has performed operations on this session that it would If a client has performed operations on this session that it would
not want lost (like DNS updates) then the client SHOULD do an orderly not want lost (like DNS updates) then the client SHOULD do an orderly
disconnect, sending a TLS close_notify followed by a TCP FIN. (In disconnect, sending a TLS close_notify followed by a TCP FIN. (In
the BSD Sockets API, sending a TCP FIN is achieved by calling the BSD Sockets API, sending a TCP FIN is achieved by calling
"shutdown(s,SHUT_WR)" and keeping the socket open until all remaining "shutdown(s,SHUT_WR)" and keeping the socket open until all remaining
data has been read from it.) data has been read from it.)
7. Security Considerations 7. Security Considerations
The Strict Privacy Usage Profile for DNS over TLS is strongly The Strict Privacy Usage Profile for DNS over TLS is strongly
recommended for DNS Push Notifications as defined in "Authentication recommended for DNS Push Notifications as defined in "Usage Profiles
and (D)TLS Profile for DNS-over-(D)TLS" for DNS over TLS and DNS over DTLS" [RFC8310]. The Opportunistic
[I-D.ietf-dprive-dtls-and-tls-profiles]. The Opportunistic Privacy Privacy Usage Profile is permissible as a way to support incremental
Usage Profile is permissible as a way to support incremental
deployment of security capabilities. Cleartext connections for DNS deployment of security capabilities. Cleartext connections for DNS
Push Notifications are not permissible. Push Notifications are not permissible.
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
skipping to change at page 30, line 13 skipping to change at page 30, line 12
record. This associates the target's name and port number with a record. This associates the target's name and port number with a
trusted TLS certificate [RFC7673]. This procedure uses the TLS Sever trusted TLS certificate [RFC7673]. This procedure uses the TLS Sever
Name Indication (SNI) extension [RFC6066] to inform the server of the Name Indication (SNI) extension [RFC6066] to inform the server of the
name the client has authenticated through the use of TLSA records. name the client has authenticated through the use of TLSA records.
Therefore, if the SRV record passes DNSSEC validation and a TLSA Therefore, if the SRV record passes DNSSEC validation and a TLSA
record matching the target name is useable, an SNI extension must be record matching the target name is useable, an SNI extension must be
used for the target name to ensure the client is connecting to the used for the target name to ensure the client is connecting to the
server it has authenticated. If the target name does not have a server it has authenticated. If the target name does not have a
usable TLSA record, then the use of the SNI extension is optional. usable TLSA record, then the use of the SNI extension is optional.
See Authentication and (D)TLS Profile for DNS-over-(D)TLS See Usage Profiles for DNS over TLS and DNS over DTLS [RFC8310] for
[I-D.ietf-dprive-dtls-and-tls-profiles] for more information on more information on authenticating domain names. Also note that a
authenticating domain names. Also note that a DNS Push server is an DNS Push server is an authoritative server and a DNS Push client is a
authoritative server and a DNS Push client is a standard DNS client. standard DNS client. While the terminology in Usage Profiles for DNS
While the terminology in Authentication and (D)TLS Profile for DNS- over TLS and DNS over DTLS [RFC8310] explicitly states it does not
over-(D)TLS [I-D.ietf-dprive-dtls-and-tls-profiles] explicitly states apply to authoritative servers, it does in this case apply to DNS
it does not apply to authoritative servers, it does in this case Push Notification clients and servers.
apply to DNS Push Notification clients and servers.
7.3. TLS Compression 7.3. TLS Compression
In order to reduce the chances of compression-related attacks, TLS- In order to reduce the chances of compression-related attacks, TLS-
level compression SHOULD be disabled when using TLS versions 1.2 and level compression SHOULD be disabled when using TLS versions 1.2 and
earlier. In the draft version of TLS 1.3 [I-D.ietf-tls-tls13], TLS- earlier. In TLS 1.3 [RFC8446], TLS-level compression has been
level compression has been removed completely. removed completely.
7.4. TLS Session Resumption 7.4. TLS Session Resumption
TLS Session Resumption is permissible on DNS Push Notification TLS Session Resumption is permissible on DNS Push Notification
servers. The server may keep TLS state with Session IDs [RFC5246] or servers. The server may keep TLS state with Session IDs [RFC5246] or
operate in stateless mode by sending a Session Ticket [RFC5077] to operate in stateless mode by sending a Session Ticket [RFC5077] to
the client for it to store. However, once the DSO session is closed, the client for it to store. However, once the DSO session is closed,
any existing subscriptions will be dropped. When the TLS session is any existing subscriptions will be dropped. When the TLS session is
resumed, the DNS Push Notification server will not have any resumed, the DNS Push Notification server will not have any
subscription state and will proceed as with any other new DSO subscription state and will proceed as with any other new DSO
session. Use of TLS Session Resumption allows a new TLS connection session. Use of TLS Session Resumption allows a new TLS connection
to be set up more quickly, but the client will still have to recreate to be set up more quickly, but the client will still have to recreate
any desired subscriptions. any desired subscriptions.
8. IANA Considerations 8. IANA Considerations
This document defines the service name: "_dns-push-tls._tcp". This document defines a new service name to be published in the IANA
It is only applicable for the TCP protocol. Registry Service Types [RFC6335][ST] that is only applicable for the
This name is to be published in the IANA Registry Service Types TCP protocol.
[RFC6335][ST].
This document defines four DNS Stateful Operations TLV types: This document also defines four new DNS Stateful Operation TLV types
SUBSCRIBE with (tentative) value 0x40 (64), PUSH with (tentative) to be recorded in the IANA DSO Type Code Registry.
value 0x41 (65), UNSUBSCRIBE with (tentative) value 0x42 (66), and
RECONFIRM with (tentative) value 0x43 (67). +----------------------------+----------------------+---------------+
| Name | Value | Definition |
+----------------------------+----------------------+---------------+
| DNS Push Notifcation | "_dns-push-tls._tcp" | Section 6.1 |
| Service Type | | |
| SUBSCRIBE | TBA (tentatively | Section 6.2 |
| | 0x40) | |
| PUSH | TBA (tentatively | Section 6.3.1 |
| | 0x41) | |
| UNSUBSCRIBE | TBA (tentatively | Section 6.4 |
| | 0x42) | |
| RECONFIRM | TBA (tentatively | Section 6.5.1 |
| | 0x43) | |
+----------------------------+----------------------+---------------+
Table 1: IANA Assignments
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.
This draft has been improved due to comments from Ran Atkinson, Tim This draft has been improved due to comments from Ran Atkinson, Tim
Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju
Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara
Dickinson, and Andrew Sullivan. Dickinson, and Andrew Sullivan.
10. References 10. References
10.1. Normative References 10.1. Normative References
[DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Mankin, A., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
draft-ietf-dnsop-session-signal-05 (work in progress), draft-ietf-dnsop-session-signal-14 (work in progress),
January 2018. August 2018.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-26 (work in progress),
March 2018.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
skipping to change at page 33, line 9 skipping to change at page 33, line 19
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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-08 (work in Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
progress), March 2018. progress), March 2018.
[I-D.dukkipati-tcpm-tcp-loss-probe] [I-D.dukkipati-tcpm-tcp-loss-probe]
Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis,
"Tail Loss Probe (TLP): An Algorithm for Fast Recovery of "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of
Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work
in progress), February 2013. in progress), February 2013.
[I-D.ietf-dprive-dtls-and-tls-profiles]
Dickinson, S., Gillmor, D., and T. Reddy, "Usage and
(D)TLS Profiles for DNS-over-(D)TLS", draft-ietf-dprive-
dtls-and-tls-profiles-11 (work in progress), September
2017.
[LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- [LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006. llq-01 (work in progress), August 2006.
[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>.
skipping to change at page 34, line 43 skipping to change at page 35, line 6
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <https://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8010] Sweet, M. and I. McDonald, "Internet Printing [RFC8010] Sweet, M. and I. McDonald, "Internet Printing
Protocol/1.1: Encoding and Transport", RFC 8010, Protocol/1.1: Encoding and Transport", STD 92, RFC 8010,
DOI 10.17487/RFC8010, January 2017, DOI 10.17487/RFC8010, January 2017,
<https://www.rfc-editor.org/info/rfc8010>. <https://www.rfc-editor.org/info/rfc8010>.
[RFC8011] Sweet, M. and I. McDonald, "Internet Printing [RFC8011] Sweet, M. and I. McDonald, "Internet Printing
Protocol/1.1: Model and Semantics", RFC 8011, Protocol/1.1: Model and Semantics", STD 92, RFC 8011,
DOI 10.17487/RFC8011, January 2017, DOI 10.17487/RFC8011, January 2017,
<https://www.rfc-editor.org/info/rfc8011>. <https://www.rfc-editor.org/info/rfc8011>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The [SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The
Internet Protocol Journal, Cisco Systems, Volume 9, Internet Protocol Journal, Cisco Systems, Volume 9,
Number 4, December 2006. Number 4, December 2006.
[XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Subscribe", XSF XEP 0060, July 2010. Subscribe", XSF XEP 0060, July 2010.
Authors' Addresses Authors' Addresses
Tom Pusateri Tom Pusateri
 End of changes. 41 change blocks. 
118 lines changed or deleted 120 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/