DDoS Open Threat Signaling (DOTS) Agent Discovery
Extracted elements (28)
A unified discovery priority ordering (explicit config > DHCP > S-NAPTR > DNS-SD) is mandated to ensure operational consistency: if devices freely mix priority preferences, operators face difficulty ensuring correct DOTS server assignment at scale.
IPv4-mapped IPv6 addresses MAY be included in OPTION_V6_DOTS_ADDRESS when no DHCPv4 server can advertise DHCPv4 DOTS options and only IPv4 connectivity to the peer DOTS agent is possible, providing a fallback path.
Multiple discovery mechanisms are specified because no single method is suitable for all deployment scenarios: CPEs naturally use DHCP, S-NAPTR allows the DOTS server administrator to advertise the preferred transport protocol, and some deployments rely on manual configuration when the upstream provider is not the DDoS mitigation provider.
The DHCP options carry both a reference identifier name (FQDN) and IP addresses because PKIX-based authentication requires a domain name reference identifier, but most certificates (~99%) are name-based rather than IP-address-based. Supplying both avoids relying solely on DNS resolution during connection establishment.
On hosts with more than one interface or address family (IPv4/IPv6), the DOTS server discovery procedure must be performed independently for each interface/address-family combination. A DOTS client may limit discovery to desired combinations.
The same discovery mechanisms used by DOTS clients to locate DOTS servers are also used by a Call Home DOTS server to discover its Call Home DOTS client, with 'DOTS-CALL-HOME' application service tag and dedicated SRV names _dots-call-home._udp/_tcp.
All DOTS clients MUST support at least one of the three discovery mechanisms (explicit/DHCP configuration, service resolution via S-NAPTR, DNS-SD) to determine a DOTS server list. All DOTS clients SHOULD implement all three, or as many as are practical for the specific device.
Before retrying a failed S-NAPTR lookup (e.g., NXDOMAIN or timeout), a DOTS client MUST wait a time period appropriate for the encountered error. If no DOTS-specific S-NAPTR records are retrieved, the discovery procedure fails for that domain/interface/IP-version combination.
In DNS-SD, the <Service> portion of the DOTS service instance name MUST be one of: '_dots-signal._udp', '_dots-signal._tcp', '_dots-data._tcp', '_dots-call-home._udp', or '_dots-call-home._tcp'. The TXT record is empty; no DNS-SD keys are defined.
The DHCPv4 client MUST include both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request List option when performing peer DOTS agent discovery.
The DHCPv4 client MUST silently discard multicast and host loopback addresses from OPTION_V4_DOTS_ADDRESS; if more than one OPTION_V4_DOTS_RI is received, only the first instance MUST be used; if OPTION_V4_DOTS_RI contains multiple names (multiple root labels), only the first name MUST be used.
The DHCPv6 client MUST silently discard multicast and host loopback addresses (per RFC 6890) conveyed in OPTION_V6_DOTS_ADDRESS. If more than one instance of OPTION_V6_DOTS_RI or OPTION_V6_DOTS_ADDRESS is received, only the first instance MUST be used.
When the DHCPv4 client receives both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS, the name from OPTION_V4_DOTS_RI MUST NOT be passed to an underlying resolution library; addresses from OPTION_V4_DOTS_ADDRESS are used directly while the name serves only as a PKIX reference identifier.
When the DHCPv6 client receives both OPTION_V6_DOTS_RI and OPTION_V6_DOTS_ADDRESS, the name in OPTION_V6_DOTS_RI MUST NOT be passed to an underlying resolution library; the addresses from OPTION_V6_DOTS_ADDRESS are used directly, and the name is used solely as a PKIX reference identifier for authentication.
DOTS server discovery follows a strict priority order: (1) explicit local/manual configuration or automatic configuration via DHCP, (2) service resolution using S-NAPTR DNS records, (3) DNS-based Service Discovery (DNS-SD). Discovery is re-run on timer expiry, certificate expiry, or attachment to a new network.
Service resolution uses S-NAPTR (RFC 3958) in two steps: first retrieve the DNS domain name (e.g., via DHCP), then perform S-NAPTR lookups using the application service tags 'DOTS' or 'DOTS-CALL-HOME' combined with protocol tags 'signal.udp', 'signal.tcp', or 'data.tcp' to obtain host, port, and protocol tuples.
IANA allocated service names 'dots-data' (TCP, for _dots-data._tcp SRV discovery) and 'dots-call-home' (TCP/UDP, for _dots-call-home._udp/_tcp SRV discovery) in the Service Name and Transport Protocol Port Number registry, and updated port 4646 (TCP/UDP) for the DOTS signal channel.
IANA assigned DHCPv4 Option Codes 147 (OPTION_V4_DOTS_RI, peer DOTS agent name) and 148 (OPTION_V4_DOTS_ADDRESS, minimum length 4, carries N/4 IPv4 addresses) in the BOOTP/DHCP parameters registry.
IANA assigned DHCPv6 Option Codes 141 (OPTION_V6_DOTS_RI) and 142 (OPTION_V6_DOTS_ADDRESS) in the DHCPv6 parameters registry; both are Client ORO options and Singleton Options.
IANA registered S-NAPTR application service tags 'DOTS' and 'DOTS-CALL-HOME', and application protocol tags 'signal.udp', 'signal.tcp', and 'data.tcp' in the S-NAPTR parameters registry for use in service resolution lookups.
An attacker can spoof DHCP responses to redirect DOTS clients to a rogue DOTS agent using a domain-validated certificate. Mitigation includes pre-configuring DOTS agents with a list of trusted DOTS domain names and verifying the DNS-ID in the server certificate's subjectAltName against that list.
An attacker may block discovery protocol messages (e.g., DHCP) to force a DOTS client to fall back to a lower-priority discovery mechanism. The DOTS client constructs a DNS-ID reference identifier from the S-NAPTR lookup domain name; DNSSEC SHOULD be used to authenticate S-NAPTR results.
Contacting a discovered DOTS server via an interface to which it is not bound may increase DOTS channel establishment delay and reveal to external networks both that a DOTS service is enabled and the identity of the DOTS service provider.
For DNS-SD, DNSSEC SHOULD be used where authenticity of information is important, and secure DNS updates (RFC 2136, RFC 3007) SHOULD generally be used to control which clients can update DNS records. DNS over TLS (DoT) or DNS over HTTPS (DoH) can prevent eavesdropping on DNS messages.
DHCPv4 DOTS Address option (OPTION_V4_DOTS_ADDRESS, code 148): 1-octet code, 1-octet length (set to 4*N for N IPv4 addresses), followed by one or more 4-octet IPv4 addresses in order of preference. RFC 3396 MUST be used if the option exceeds 255 octets.
DHCPv4 DOTS Reference Identifier option (OPTION_V4_DOTS_RI, code 147): 1-octet code, 1-octet length, followed by a peer DOTS agent domain name encoded per RFC 8415 Section 10.
DHCPv6 DOTS Address option (OPTION_V6_DOTS_ADDRESS, code 142): 2-octet option-code, 2-octet option-length (MUST be a multiple of 16), followed by one or more 16-octet IPv6 addresses of the peer DOTS agent listed in order of preference.
DHCPv6 DOTS Reference Identifier option (OPTION_V6_DOTS_RI, code 141): 2-octet option-code, 2-octet option-length, followed by a dots-agent-name field carrying the peer DOTS agent FQDN encoded per RFC 8415 Section 10.