On a purely technological level? Sure, that's fine.

On an institutional level, you might want to check with your security team to make sure they don't have policies forbidding it. They might consider it a non-permissible leakage of internal network details.

The basic infrastructure, that would make this possible, exists and is called DNS-Based Authentication of Named Entities (DANE) and specified in RFC6698. It works by means of a TLSA resource record, that specifies the certificate or its public key of the end entity or one of its CAs in the chain (There are actually four different types, see the RFC for details).

Adoption

DANE has however not seen widespread adoption yet. VeriSign monitors DNSSEC and DANE adoption and tracks its growth over time:

For comparison, according to VeriSign, there exists about 2.7 million DNS zones, so that means that a bit more than 1% of all zones have at least one TLSA record.

I can't give any authoritative answer, why DANE, but here are my speculations:

DANE suffers from the same problem as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). In order to verify the validity of a presented certificate, a third party must be contacted. Hanno Böck gives a good overview, why this is a big problem in practice. It boils down to the issue of what to do, when you can't reach the third party. Browser vendors opted to soft-fail (aka permit) in this case, which made the whole thing rather pointless and Chrome ultimately decided to disable OCSP in 2012.

DNSSEC

Arguably DNS offers much better availability than the CRL and OCSP servers of CAs, but it still makes offline verification impossible. In addition DANE, should only be used in conjunction with DNSSEC. As normal DNS operates over unauthenticated UDP, it is quite prone to forgery, MITM attacks, etc. The adoption of DNSSEC is much better than the adoption of DANE, but is still far from ubiquitous.

And with DNSSEC we run again into to the soft-fail problem. To the best of my knowledge no major server/client operating systems provides a validating DNSSEC resolver by default.

Then there is also the issue of revocation. DNSSEC has no revocation mechanism and relies on short lived keys instead.

Software Support

All participating software must implement DANE support.

In theory, you might think, that this would be the job of crypto libraries and application developers wouldn't have to do much, but the fact is, cryptographic libraries typically only provide primitives and applications have to do a lot of configuration and setup themselves (and there unfortunately many ways to get things wrong).

I'm not aware, that any major web server (e.g. Apache or nginx) for example implemented DANE or has plans to do it. Web servers are of particular importance here, because more and more stuff is build on web technologies and therefore they are often the first, where things get implemented.

When we look at CRL, OCSP, and OCSP Stapling as comparison, we might be able to infer how the DANE adoption story will go. Only some of the applications, which use OpenSSL, libnss, GnuTLS, etc. support these features. It took a while for major software like Apache or nginx to support it and again referring back to Hanno Böck's article, they got it wrong and their implementation is flawed. Other major software projects, like Postfix or Dovecot don't support OCSP and have very limited CRL functionality, basically pointing to a file in the file system (which isn't necessarily re-read regulary, so you would have to reload your server manually etc). Keep in mind that these are projects, which frequently use TLS. Then you can start looking at things, where TLS is much less common, like PostgreSQL/MySQL for example and maybe they offer CRLs at best.

So I've not even modern web servers implement it and most other software hasn't even got around to implement OCSP and CRL, good luck with your 5 year enterprise application or appliance.

Potential Applications

So where could you actually use DANE? As of now, not on general Internet. If you control the server and the client, maybe its an option, but in this case, you can often resort to Public-Key Pinning.

In the mail space, DANE is getting some traction, because SMTP did not have any kind of authenticated transport encryption for the longest time. SMTP servers did sometimes use TLS between each other, but did not verify that the names in the certificates actually matched, they are now starting to check this through DANE.