6.2.1. SUBSCRIBE Request
6.2.1. SUBSCRIBE Request
A SUBSCRIBE request begins with the standard DSO 12-byte header [RFC8490], followed by the SUBSCRIBE Primary TLV. A SUBSCRIBE request is illustrated in Figure 1.
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 the purposes here, a MESSAGE ID is in use on this session if either the 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 that it has not yet canceled using UNSUBSCRIBE. In the SUBSCRIBE response, the server MUST echo back the MESSAGE ID value unchanged.
The other header fields MUST be set as described in the DSO specification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields must be zero, and the corresponding four sections must be empty (i.e., absent).
The DSO-TYPE is SUBSCRIBE (0x0040).
The DSO-LENGTH is the length of the DSO-DATA that follows, which specifies the name, type, and class of the record(s) being sought.
The DSO-DATA for a SUBSCRIBE request MUST contain exactly one NAME, TYPE, and CLASS. Since SUBSCRIBE requests are sent over TCP, multiple SUBSCRIBE DSO request messages can be concatenated in a single TCP stream and packed efficiently into TCP segments.
If accepted, the subscription will stay in effect until the client cancels the subscription using UNSUBSCRIBE or until the DSO session between the client and the server is closed.
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. For the purpose of this matching, the established DNS case insensitivity for US-ASCII letters [RFC0020] applies (e.g., "example.com" and "Example.com" are the same). If a server receives such a duplicate SUBSCRIBE message, this is a fatal error and the server MUST forcibly abort the connection immediately.
DNS wildcarding is not supported. That is, an asterisk character ("") in a SUBSCRIBE message matches only a literal asterisk character ("") in a name and nothing else. Similarly, a CNAME in a SUBSCRIBE message matches only a CNAME record with that name in the zone and no other records with that name.
A client may SUBSCRIBE to records that are unknown to the server at the time of the request (providing that the name falls within one of the zone(s) the server is responsible for), and this is not an error. The server MUST NOT return NXDOMAIN in this case. The server MUST accept these requests and send Push Notifications if and when matching records are found in the future.
If neither TYPE nor CLASS are ANY (255), then this is a specific subscription to changes for the given name, type, and class. If one or both of TYPE or CLASS are ANY (255), then this subscription matches all types and/or all classes as appropriate.
NOTE: A little-known quirk of DNS is that in DNS QUERY requests, QTYPE and QCLASS 255 mean "ANY", not "ALL". They indicate that the server should respond with ANY matching records of its choosing, not necessarily ALL matching records. This can lead to some surprising and unexpected results, where a query returns some valid answers, but not all of them, and makes QTYPE = 255 (ANY) queries less useful than people sometimes imagine.
When used in conjunction with SUBSCRIBE, TYPE 255 and CLASS 255 should be interpreted to mean "ALL", not "ANY". After accepting a subscription where one or both of TYPE or CLASS are 255, the server MUST send Push Notification Updates for ALL record changes that match the subscription, not just some of them.