DNS Push Notifications
Extracted elements (30)
DNS Push Notifications use TCP (via DSO over TLS) instead of UDP, unlike the earlier LLQ protocol. This avoids reimplementing TCP features (flow control, reliability, three-way handshake) in user space, and gives better NAT traversal for long-lived low-traffic connections without depending on NAT-PMP or PCP.
The guiding principle is that clients using DNS Push Notifications will receive the same results as sufficiently rapid polling, just more efficiently. Subscription matching rules are identical to existing DNS query matching rules (RFC 1034), including case-insensitive name comparison and CNAME handling.
TYPE 255 in a SUBSCRIBE is interpreted as 'ALL' (not 'ANY' as in normal DNS QUERY), requiring the server to deliver notifications for every matching record, not just a server-chosen subset. This avoids the well-known surprising behavior of QTYPE=ANY queries.
A client MUST be prepared to receive (and silently ignore) Push Notifications for subscriptions it has previously removed, due to the unavoidable race condition between an in-flight PUSH from the server and an in-flight UNSUBSCRIBE from the client.
Standard DNS queries MAY be sent over a DNS Push Notification (DSO) session. For authoritative zones, the server MUST respond authoritatively; for recursive resolver mode, DNS Push Notification support implies standard query support for the same names.
A client MUST NOT send a PUSH message. If a client does send a PUSH message, or a PUSH message is sent with the QR bit set, this is a fatal error and the receiver MUST forcibly abort the connection immediately.
A server MUST NOT send a SUBSCRIBE request over an existing session from a client. If a server does send a SUBSCRIBE request, this is a fatal error and the client MUST forcibly abort the connection immediately.
DNS Push Notification clients MUST NOT recklessly create an excessive number of Push Notification subscriptions. Subscriptions SHOULD be canceled as soon as the need for the data ends.
DNS Push Notification clients MUST use DNS Stateful Operations (DSO) running over TLS over TCP. Cleartext connections are not permissible.
DNSSEC is RECOMMENDED for the authentication of DNS Push Notification servers, because TLS alone does not prevent a client from being directed to a rogue server via a subverted SRV query.
In the fallback-to-polling case, the interval between successive DNS queries for the same name, type, and class SHOULD be at least the minimum of 900 seconds (15 minutes) or two seconds more than the TTL of the answer RRset.
Servers MUST NOT generate PUSH messages larger than 16,382 bytes (counting from the start of the DSO 12-byte header). If a client receives a PUSH message larger than this, it MUST forcibly abort the connection immediately.
Servers MUST silently ignore UNSUBSCRIBE messages that do not match any currently active subscription, to handle the race condition where a client sends UNSUBSCRIBE before receiving an error response to SUBSCRIBE.
SUBSCRIBE requests on a given session MUST be unique. A client MUST NOT send a SUBSCRIBE message that duplicates the name, type, and class of an existing active subscription on that DSO session. If a server receives a duplicate SUBSCRIBE, it MUST forcibly abort the connection.
The server MUST NOT return NXDOMAIN in response to a SUBSCRIBE request for records that are unknown to the server at the time. The server MUST accept such requests and send Push Notifications if matching records are found in the future.
The Strict Privacy profile for DNS over TLS is REQUIRED for DNS Push Notifications. Cleartext connections for DNS Push Notifications are not permissible.
When processing records in a PUSH message, the receiving client MUST validate that the records correspond with at least one currently active subscription on that session.
When TYPE 255 and CLASS 255 are used in a SUBSCRIBE, the server MUST send Push Notification Updates for ALL record changes that match the subscription, not just some of them.
Discovery uses the SRV record '_dns-push-tls._tcp.<zone>' to locate the Push Notification server for a zone. The client performs iterative SOA queries to find the authoritative zone, then queries for this SRV record.
DNS Push Notifications use four DSO TLV types: SUBSCRIBE (0x0040, client request), PUSH (0x0041, server unidirectional), UNSUBSCRIBE (0x0042, client unidirectional), and RECONFIRM (0x0043, client unidirectional).
The RECONFIRM message allows a client to ask the server to re-verify potentially stale data (e.g., an SRV record referencing a non-responding target). For a Discovery Proxy, this triggers new Multicast DNS queries.
This document registers four DSO TLV type codes in the IANA 'DSO Type Codes' registry: SUBSCRIBE (0x0040, early data OK), PUSH (0x0041), UNSUBSCRIBE (0x0042), and RECONFIRM (0x0043), all Standards Track.
This document registers the service type '_dns-push-tls._tcp' (no assigned port) in the IANA 'Service Name and Transport Protocol Port Number Registry' for DNS Push Notification service discovery.
TLS Early Data (0-RTT) is permitted for SUBSCRIBE TLVs but is not forward secret and provides no replay protection between connections. Servers MAY implement rate-limiting for spurious subscription requests arising from replayed early data.
TLS provides confidentiality, data integrity, authentication, and anti-replay protection. TLS 1.3 is used per RFC 8446, and the Strict Privacy profile (RFC 8310) is required; opportunistic cleartext is not permitted.
TLS session resumption is permitted, but closing the TLS connection terminates the DSO session and all subscription state. After resumption, the client must recreate all subscriptions from scratch.
The PUSH message DSO-DATA contains one or more change notification records formatted as DNS RRs: NAME, TYPE (16-bit), CLASS (16-bit), TTL (32-bit unsigned), RDLEN (16-bit), RDATA. TTL values 0–0x7FFFFFFF indicate addition; 0xFFFFFFFF indicates individual removal; 0xFFFFFFFE indicates collective removal.
The RECONFIRM message DSO-DATA contains NAME, TYPE (16-bit), CLASS (16-bit), and RDATA (length inferred from DSO-LENGTH; no RDLEN field). TYPE and CLASS MUST NOT be 255 (ANY).
The SUBSCRIBE request begins with a standard DSO 12-byte header followed by DSO-TYPE = 0x0040. The DSO-DATA contains exactly one NAME (variable), TYPE (16-bit), and CLASS (16-bit) identifying the RRset to subscribe to.
The UNSUBSCRIBE message has DSO-LENGTH = 2 and DSO-DATA containing the 2-octet MESSAGE ID of the SUBSCRIBE request being canceled. MESSAGE ID in the header MUST be zero (unidirectional message).