6.2.2. SUBSCRIBE Response
6.2.2. SUBSCRIBE Response
A SUBSCRIBE response begins with the standard DSO 12-byte header [RFC8490]. The QR bit in the header is set indicating it is a response. The header MAY be followed by one or more optional Additional TLVs such as a Retry Delay Additional TLV. A SUBSCRIBE response is illustrated in Figure 2.
The MESSAGE ID field MUST echo the value given in the MESSAGE ID field of the SUBSCRIBE request. This is how the client knows which request is being responded to.
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).
A SUBSCRIBE response message MUST NOT include a SUBSCRIBE TLV. If a client receives a SUBSCRIBE response message containing a SUBSCRIBE TLV, then the response message is processed but the SUBSCRIBE TLV MUST be silently ignored.
In the SUBSCRIBE response, the RCODE indicates whether or not the subscription was accepted. Supported RCODEs are as follows:
| Mnemonic | Value | Description |
|---|---|---|
| NOERROR | 0 | SUBSCRIBE successful. |
| FORMERR | 1 | Server failed to process request due to a malformed request. |
| SERVFAIL | 2 | Server failed to process request due to a problem with the server. |
| NOTIMP | 4 | Server does not implement DSO. |
| REFUSED | 5 | Server refuses to process request for policy or security reasons. |
| NOTAUTH | 9 | Server is not authoritative for the requested name. |
| DSOTYPENI | 11 | SUBSCRIBE operation not supported. |
Table 1: SUBSCRIBE Response Codes
This document specifies only these RCODE values for SUBSCRIBE Responses. Servers sending SUBSCRIBE Responses SHOULD use one of these values. Note that NXDOMAIN is not a valid RCODE in response to a SUBSCRIBE Request. However, future circumstances may create situations where other RCODE values are appropriate in SUBSCRIBE Responses, so clients MUST be prepared to accept and handle SUBSCRIBE Responses with any other nonzero RCODE error values.
If the server sends a nonzero RCODE in the SUBSCRIBE response, that means:
a. the client is (at least partially) misconfigured, or b. the server resources are exhausted, or c. there is some other unknown failure on the server.
In any case, the client shouldn't retry the subscription to this server right away. If multiple SRV records were returned as described in Section 6.1, Paragraph 9, Item 7, a subsequent server MAY be tried immediately.
If the client has other successful subscriptions to this server, these subscriptions remain even though additional subscriptions may be refused. Neither the client nor the server is required to close the connection, although either end may choose to do so.
If the server sends a nonzero RCODE, then it SHOULD append a Retry Delay Additional TLV [RFC8490] to the response specifying a delay before the client attempts this operation again. Recommended values for the delay for different RCODE values are given below. These recommended values apply both to the default values a server should place in the Retry Delay Additional TLV and the default values a client should assume if the server provides no Retry Delay Additional TLV.
For RCODE = 1 (FORMERR), the delay may be any value selected by the implementer. A value of five minutes is RECOMMENDED to reduce the risk of high load from defective clients.
For RCODE = 2 (SERVFAIL), the delay should be chosen according to the level of server overload and the anticipated duration of that overload. By default, a value of one minute is RECOMMENDED. If a more serious server failure occurs, the delay may be longer in accordance with the specific problem encountered.
For RCODE = 4 (NOTIMP), which occurs on a server that doesn't implement DNS Stateful Operations [RFC8490], it is unlikely that the server will begin supporting DSO in the next few minutes, so the retry delay SHOULD be one hour. Note that in such a case, a server that doesn't implement DSO is unlikely to place a Retry Delay Additional TLV in its response, so this recommended value in particular applies to what a client should assume by default.
For RCODE = 5 (REFUSED), which occurs on a server that implements DNS Push Notifications but is currently configured to disallow DNS Push Notifications, the retry delay may be any value selected by the implementer and/or configured by the operator.
If the server being queried is listed in a "_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is a misconfiguration, since this server is being advertised as supporting DNS Push Notifications for this zone, but the server itself is not currently configured to perform that task. Since it is possible that the misconfiguration may be repaired at any time, the retry delay should not be set too high. By default, a value of 5 minutes is RECOMMENDED.
For RCODE = 9 (NOTAUTH), which occurs on a server that implements DNS Push Notifications but is not configured to be authoritative for the requested name, the retry delay may be any value selected by the implementer and/or configured by the operator.
If the server being queried is listed in a "_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is a misconfiguration, since this server is being advertised as supporting DNS Push Notifications for this zone, but the server itself is not currently configured to perform that task. Since it is possible that the misconfiguration may be repaired at any time, the retry delay should not be set too high. By default, a value of 5 minutes is RECOMMENDED.
For RCODE = 11 (DSOTYPENI), which occurs on a server that implements DSO but doesn't implement DNS Push Notifications, it is unlikely that the server will begin supporting DNS Push Notifications in the next few minutes, so the retry delay SHOULD be one hour.
For other RCODE values, the retry delay should be set by the server as appropriate for that error condition. By default, a value of 5 minutes is RECOMMENDED.
For RCODE = 9 (NOTAUTH), the time delay applies to requests for other names falling within the same zone. Requests for names falling within other zones are not subject to the delay. For all other RCODEs, the time delay applies to all subsequent requests to this server.
After sending an error response, the server MAY allow the session to remain open, or MAY follow it with a DSO Retry Delay operation (using the Retry Delay Primary TLV) instructing the client to close the session as described in the DSO specification [RFC8490]. Clients MUST correctly handle both cases. Note that the DSO Retry Delay operation (using the Retry Delay Primary TLV) is different to the Retry Delay Additional TLV mentioned above.