Meta: Doesn't add much to the dupe but on rereading I notice I missed the "D".
Key establishment and encryption/decryption and authentication processes for TLSv1.2 are specified in RFC 5246 TLSv1.2 plus for ECC key exchanges (not here) RFC 4492 TLS ECC as amended by appendix A.7 of 5246.
These processes also apply to DTLSv1.2 RFC 6347 DTLSv1.2, although the record headers, actual transmission and some error handling differs for DTLS compared to TLS.
SSL/TLS/DTLS key establishment has two parts: one which varies based on (only) the key-exchange algorithm used and produces a "premaster secret", and one which varies based on (only) the bulk-cipher and MAC algorithm(s)/mode selected and uses the premaster secret to produce a master secret and then the several working keys, IVs and nonces.
The encryption/decryption and authentication processes vary similarly.
For TLS_RSA_WITH_AES_256_CBC_SHA256 the key-exchange algorithm is RSA. The premaster secret is chosen by the client, RSA encrypted under the server's public key and sent to the server which RSA decrypts it and checks it. See in 7.4.2 the item for
RSA, 18.104.22.168, and 8.1.1. To do this outside the server you need (a copy of) the server's private key.
The premaster secret is then used with the nonces to derive the master secret as specified in 8.1 using the PRF (PseudoRandom Function) defined in sec 5; this is then used again with the nonces to derive working keys as specified in 6.3 using the same PRF for the sizes in appendix C. For TLS_RSA_WITH_AES_256_CBC_SHA256 the cipher is AES_256_CBC which requires a key of 32 octets in each direction and the MAC is HMAC-SHA256 with a key of 32 octets in each direction.
Each data record is MACed and encrypted by the sender, and decrypted and verified by the receiver. The MAC/verify process is specified by 22.214.171.124 (for all non-AEAD ciphers/suites, and this suite is not AEAD) and the encryption/decryption process for CBC-mode (block) cipher is specified by 126.96.36.199; it does indeed choose a per-record IV and prepend it to the encrypted record data.
For another ciphersuite the outline is the same but in some places different specific sections of RFC 5246, and for ECC-based key exchange (ECDH, ECDHE, or ECDH_anon) RFC 4492, apply.