draft-ietf-dnssd-push-00.txt   draft-ietf-dnssd-push-01.txt 
Internet Engineering Task Force T. Pusateri Internet Engineering Task Force T. Pusateri
Internet-Draft Seeking affiliation Internet-Draft Seeking affiliation
Intended status: Standards Track S. Cheshire Intended status: Standards Track S. Cheshire
Expires: September 10, 2015 Apple Inc. Expires: April 21, 2016 Apple Inc.
March 9, 2015 October 19, 2015
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-00 draft-ietf-dnssd-push-01
Abstract Abstract
The Domain Name System (DNS) was designed to efficiently return The Domain Name System (DNS) was designed to efficiently return
matching records for queries for data that is relatively static. matching records for queries for data that is relatively static.
When those records change frequently, DNS is still efficient at When those records change frequently, DNS is still efficient at
returning the updated results when polled. But there exists no returning the updated results when polled. But there exists no
mechanism for a client to be asynchronously notified when these mechanism for a client to be asynchronously notified when these
changes occur. This document defines a mechanism for a client to be changes occur. This document defines a mechanism for a client to be
notified of such changes to DNS records, called DNS Push notified of such changes to DNS records, called DNS Push
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 8 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 8
6.3. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 10 6.3. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 10
6.4. DNS Push Notification Update Messages . . . . . . . . . . 11 6.4. DNS Push Notification Update Messages . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Security Services . . . . . . . . . . . . . . . . . . . . 14 9.1. Security Services . . . . . . . . . . . . . . . . . . . . 14
9.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 14 9.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 14
9.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 14 9.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 15
9.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 15 9.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
DNS records may be updated using DNS Update [RFC2136]. Other DNS records may be updated using DNS Update [RFC2136]. Other
mechanisms such as a Hybrid Proxy [I-D.ietf-dnssd-hybrid] can also mechanisms such as a Hybrid Proxy [I-D.ietf-dnssd-hybrid] can also
skipping to change at page 5, line 10 skipping to change at page 5, line 10
If a server closes the connection, it is informing the client that it If a server closes the connection, it is informing the client that it
can no longer provide updates for the subscribed records. This may can no longer provide updates for the subscribed records. This may
occur because the server application software or operating system is occur because the server application software or operating system is
restarting, the application terminated unexpectedly, the server is restarting, the application terminated unexpectedly, the server is
undergoing maintenance procedures, or the server is overloaded and undergoing maintenance procedures, or the server is overloaded and
can no longer provide the information to all the clients that wish to can no longer provide the information to all the clients that wish to
receive it. The client can try to re-subscribe at a later time or receive it. The client can try to re-subscribe at a later time or
connect to another server supporting DNS Push Notifications for the connect to another server supporting DNS Push Notifications for the
zone. zone.
Connection setup over TCP ensures return reachability and alleviates
concerns of state overload at the server through anonymous
subscriptions. All subscribers are guaranteed to be reachable by the
server by virtue of the TCP three-way handshake. Because TCP SYN
flooding attacks are possible with any protocol over TCP,
implementers are encouraged to use industry best practices to guard
against such attacks [IPJ.9-4-TCPSYN].
Transport Layer Security (TLS) [RFC5246] is well understood and Transport Layer Security (TLS) [RFC5246] is well understood and
deployed across many protocols running over TCP. It is designed to deployed across many protocols running over TCP. It is designed to
prevent eavesdropping, tampering, or message forgery. TLS is prevent eavesdropping, tampering, or message forgery. TLS is
REQUIRED for every connection between a client subscriber and server REQUIRED for every connection between a client subscriber and server
in this protocol specification. in this protocol specification. Additional security measures such as
client authentication during TLS negotiation MAY also be employed to
Connection setup over TCP ensures return reachability and alleviates increase the trust relationship between client and server.
concerns of state overload at the server through anonymous Additional authentication of the SRV target using DNSSEC verification
subscriptions. All subscribers are guaranteed to be reachable by the and DANE TLSA records [RFC7673] is strongly encouraged. See below in
server by virtue of the TCP three-way handshake. Additional security Section 9.2 for details.
measures such as authentication during TLS negotiation MAY also be
employed to increase the trust relationship between client and
server. Because TCP SYN flooding attacks are possible with any
protocol over TCP, implementers are encouraged to use industry best
practices to guard against such attacks [IPJ.9-4-TCPSYN].
5. State Considerations 5. State Considerations
Each DNS Push Notification server is capable and handling some finite Each DNS Push Notification server is capable and 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 connection to a DNS server, allocation. After a client establishes a connection to a DNS server,
each record subscription is individually accepted or rejected. each record subscription is individually accepted or rejected.
Servers may employ various techniques to limit subscriptions to a Servers may employ various techniques to limit subscriptions to a
skipping to change at page 7, line 6 skipping to change at page 7, line 6
then SRV record MUST NOT exist and the SRV query will return a then SRV record MUST NOT exist and the SRV query will return a
negative answer. negative answer.
6. If the zone in question is set up to offer DNS Push Notifications 6. If the zone in question is set up to offer DNS Push Notifications
then this SRV record MUST exist. The SRV "target" contains the then this SRV record MUST exist. The SRV "target" contains the
name of the server providing DNS Push Notifications for the zone. name of the server providing DNS Push Notifications for the zone.
The port number on which to contact the server is in the SRV The port number on which to contact the server is in the SRV
record "port" field. The address(es) of the target host MAY be record "port" field. The address(es) of the target host MAY be
included in the Additional Section, however, the address records included in the Additional Section, however, the address records
SHOULD be authenticated before use as described below in SHOULD be authenticated before use as described below in
Section 9.2 [I-D.ietf-dane-srv]. Section 9.2 [RFC7673].
7. 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" is indicates the weighted probability that the client "weight" is 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 reachable or probabilities of being selected. If a server is not reachable or
skipping to change at page 8, line 15 skipping to change at page 8, line 15
6.2. DNS Push Notification SUBSCRIBE 6.2. DNS Push Notification SUBSCRIBE
A DNS Push Notification client indicates its desire to receive DNS A DNS Push Notification client indicates its desire to receive DNS
Push Notifications for a given domain name by sending a SUBSCRIBE Push Notifications for a given domain name by sending a SUBSCRIBE
request over the established TCP connection to the server. A request over the established TCP connection to the server. A
SUBSCRIBE request is formatted identically to a conventional DNS SUBSCRIBE request is formatted identically to a conventional DNS
QUERY request [RFC1035], except that the opcode is SUBSCRIBE (6) QUERY request [RFC1035], except that the opcode is SUBSCRIBE (6)
instead of QUERY (0). If neither QTYPE nor QCLASS are ANY (255) then instead of QUERY (0). If neither QTYPE nor QCLASS are ANY (255) then
this is a specific subscription to changes for the given name, type this is a specific subscription to changes for the given name, type
and class. If one or both of QTYPE or QCLASS are ANY (255) then this and class. If one or both of QTYPE or QCLASS are ANY (255) then this
is a wildcard subscription to changes for the given name for any type subscription matches any type and/or any class, as appropriate.
and/or class, as appropriate.
In a SUBSCRIBE request the DNS Header QR bit MUST be zero. In a SUBSCRIBE request the DNS Header QR bit MUST be zero.
If the QR bit is not zero the message is not a SUBSCRIBE request. If the QR bit is not zero the message is not a SUBSCRIBE request.
The AA, TC, RD, RA, Z, AD, and CD bits, the ID field, and the RCODE The AA, TC, RD, RA, Z, AD, and CD bits, the ID field, and the RCODE
field, MUST be zero on transmission, and MUST be silently ignored on field, MUST be zero on transmission, and MUST be silently ignored on
reception. reception.
Like a DNS QUERY request, a SUBSCRIBE request MUST contain exactly Like a DNS QUERY request, a SUBSCRIBE request MUST contain exactly
one question. Since SUBSCRIBE requests are sent over TCP, multiple one question. Since SUBSCRIBE requests are sent over TCP, multiple
skipping to change at page 10, line 18 skipping to change at page 10, line 18
revokes the subscription or until the connection between the client revokes the subscription or until the connection between the client
and the server is closed. and the server is closed.
A client MUST not send a SUBSCRIBE message that duplicates the name, A client MUST not send a SUBSCRIBE message that duplicates the name,
type and class of an existing active subscription. For the purpose type and class of an existing active subscription. For the purpose
of this matching, the established DNS case-insensitivity for US-ASCII of this matching, the established DNS case-insensitivity for US-ASCII
letters applies (e.g., "foo.com" and "Foo.com" are the same). If a letters applies (e.g., "foo.com" and "Foo.com" are the same). If a
server receives such a duplicate SUBSCRIBE message this is an error server receives such a duplicate SUBSCRIBE message this is an error
and the server MUST immediately close the TCP connection. and the server MUST immediately close the TCP connection.
Wildcarding is not supported. That is, a wildcard ("*") in a DNS wildcarding is not supported. That is, a wildcard ("*") in a
SUBSCRIBE message matches only a wildcard ("*") in the zone, and SUBSCRIBE message matches only a wildcard ("*") in the zone, and
nothing else. nothing else.
Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message
matches only a CNAME in the zone, and nothing else. matches only a CNAME in the zone, and nothing else.
A client may SUBSCRIBE to records that are unknown to the server at A client may SUBSCRIBE to records that are unknown to the server at
the time of the request and this is not an error. The server MUST the time of the request and this is not an error. The server MUST
accept these requests and send Push Notifications if and when matches accept these requests and send Push Notifications if and when matches
are found in the future. are found in the future.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
This document defines the service name: "_dns-push._tcp". This document defines the service name: "_dns-push._tcp".
It is only applicable for the TCP protocol. It is only applicable for the TCP protocol.
This name is to be published in the IANA Service Name Registry. This name is to be published in the IANA Service Name Registry.
This document defines two DNS OpCodes: SUBSCRIBE with (tentative) This document defines two DNS OpCodes: SUBSCRIBE with (tentative)
value 6 and UNSUBSCRIBE with (tentative) value 7. value 6 and UNSUBSCRIBE with (tentative) value 7.
9. Security Considerations 9. Security Considerations
Strict TLS support is mandatory in DNS Push Notifications. There is TLS support is mandatory in DNS Push Notifications. There is no
no provision for opportunistic encryption using a mechanism like provision for opportunistic encryption using a mechanism like
"STARTTLS". "STARTTLS".
9.1. Security Services 9.1. Security Services
It is the goal of using TLS to provide the following security It is the goal of using TLS to provide the following security
services: services:
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.
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 [I-D.ietf-uta-tls-bcp] for the best current Recommendations [RFC7525] for the best current practices. Keep in
practices. Keep in mind that best practices only exist for a mind that best practices only exist for a snapshot in time and
snapshot in time and recommendations will continue to change. recommendations will continue to change. Updated versions or errata
Updated versions or errata may exist for these recommendations. may exist for these recommendations.
9.2. TLS Name Authentication 9.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
Notification server using an SRV lookup for the record name "_dns- Notification server using an SRV lookup for the record name "_dns-
push._tcp.<zone>". The server connection endpoint SHOULD then be push._tcp.<zone>". The server connection endpoint SHOULD then be
authenticated using DANE TLSA records for the associated SRV record. authenticated using DANE TLSA records for the associated SRV record.
This associates the target's name and port number with a trusted TLS This associates the target's name and port number with a trusted TLS
certificate [I-D.ietf-dane-srv]. This procedure uses the TLS Sever certificate [RFC7673]. This procedure uses the TLS Sever Name
Name Indication (SNI) extension [RFC6066] to inform the server of the Indication (SNI) extension [RFC6066] to inform the server of the name
name the client has authenticated through the use of TLSA records. the client has authenticated through the use of TLSA records.
Therefore, if the SRV record passes DNSSEC validation and a TLSA
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
server it has authenticated. If the target name does not have a
usable TLSA record, then the use of the SNI extension is optional.
9.3. TLS Compression 9.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 the draft version of TLS 1.3 [I-D.ietf-tls-tls13], TLS-
level compression has been removed completely. level compression has been removed completely.
9.4. TLS Session Resumption 9.4. TLS Session Resumption
TLS Session Resumption MUST be disabled on DNS Push Notification TLS Session Resumption is permissible on DNS Push Notification
servers. It is not useful to have subscription state cached for long servers. The server may keep TLS state with Session IDs [RFC5246] or
periods of time. It is also not desirable for subscription state to operate in stateless mode by sending a Session Ticket [RFC5077] to
be maintained while the client is not connected. the client for it to store. However, once the connection is closed,
any existing subscriptions will be dropped. When the TLS session is
resumed, the DNS Push Notification server will not have any
subscription state and will proceed as with any other new connection.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", draft-ietf-dane-srv-11 (work in
progress), February 2015.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Dierks, T. and E. Rescorla, "The Transport Layer Security Rescorla, E., "The Transport Layer Security (TLS) Protocol
(TLS) Protocol Version 1.3", draft-ietf-tls-tls13-04 (work Version 1.3", draft-ietf-tls-tls13-10 (work in progress),
in progress), January 2015. October 2015.
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981. RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
and Support", STD 3, RFC 1123, October 1989. Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
Requirements", RFC 5966, August 2010. Requirements", RFC 5966, DOI 10.17487/RFC5966, August
2010, <http://www.rfc-editor.org/info/rfc5966>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extension Definitions", RFC 6066, January 2011. Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", RFC 6195, March 2011. Considerations", RFC 6195, DOI 10.17487/RFC6195, March
2011, <http://www.rfc-editor.org/info/rfc6195>.
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October
2015, <http://www.rfc-editor.org/info/rfc7673>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-dnssd-hybrid] [I-D.ietf-dnssd-hybrid]
Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
Discovery", draft-ietf-dnssd-hybrid-00 (work in progress), Discovery", draft-ietf-dnssd-hybrid-00 (work in progress),
November 2014. November 2014.
[I-D.sekar-dns-llq] [I-D.sekar-dns-llq]
Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006. llq-01 (work in progress), August 2006.
[IPJ.9-4-TCPSYN] [IPJ.9-4-TCPSYN]
Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The
Internet Protocol Journal, Cisco Systems, Volume 9, Number Internet Protocol Journal, Cisco Systems, Volume 9,
4, December 2006. Number 4, December 2006.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[XEP-0060] [XEP-0060]
Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 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
Seeking affiliation Seeking affiliation
Hilton Head Island, SC Hilton Head Island, SC
 End of changes. 33 change blocks. 
70 lines changed or deleted 105 lines changed or added

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