The usual way this is done is to have Alice sign the set of DH parameters to use. This requires Alice's key and certificate to be appropriate for signatures. In two widely deployed protocols:
In SSL/TLS, when Alice (the server) wants to use Diffie-Hellman for key exchange, it selects one of the
DHE cipher suites. The DH parameters and the DH public key (the server's half of the DH) are encoded as a
ServerKeyExchange message, which the server signs with its private key.
In S/MIME, when Alice signs an email, she can include in the signature object (under the cover of the signature) an
SMIMECapabilities attribute which can contain the DH parameters and public key to use, should the recipient wish the respond to Alice with an encrypted email.
It is also possible to have a certificate which contains a DH public key (and parameters) directly, but this is much more rarely done because such certificates cannot be used for signatures, only key exchange.
The DH parameters themselves (not the public key) could also be "well-known" and thus distributed with the software. This is what usually happens with elliptic-curve variants of DH (building your own curve is possible but relatively expensive, and most software only supports a subset of the 15 NIST curves).
Custom extensions means that only your software will be able to process them, which is often restrictive, so this is discouraged. Also, embedding data in the certificate implies that the data (whatever it is) is chosen by the CA and has the same lifetime than the certificate itself, which may or may not be adequate (this is worth considering).