DTLS Listeners add TLS-style encryption and authentication to UDP applications without changing the datagram transport model. Clients establish a DTLS 1.2 or DTLS 1.3 session with the Listener's assigned domain and port. Proxylity decrypts authenticated application data and delivers the plaintext payload to your configured Destinations. Responses from your application are encrypted and sent back through the same DTLS session. Choose a DTLS Listener when your application already supports DTLS or needs encrypted UDP transport while preserving datagram boundaries. Common examples include RADIUS, IoT protocols, real-time telemetry, and custom request-response protocols that cannot use a stream-oriented TLS connection. DTLS is also the first transport layer on Proxylity's roadmap to WebRTC Data Channels. DTLS Listeners are available today for native DTLS clients; SCTP and WebRTC signaling are separate layers and are not provided by a DTLS Listener. Every DTLS Listener receives a server certificate and private key managed by Proxylity. The certificate identifies the Listener's assigned endpoint and is returned through the DtlsServerCertificate CloudFormation attribute. Distribute that certificate or its trust anchor according to your client application's trust model. Change CertRefreshToken when you need CloudFormation to generate a new Listener certificate. Certificate rotation changes the certificate clients see, so coordinate trust updates before rotating production endpoints. For clients that use DTLS-PSK, configure the Psks map. Each map key is the client identity sent during the handshake, and each value is the corresponding base64-encoded key. Store PSK values in AWS Secrets Manager or another protected source rather than committing them to a template. Set RequireCookies to require the DTLS cookie exchange before the Listener performs the full handshake. Cookies help confirm that a client can receive packets at its...