Answer

The short answer to your specific question of listing CNAMEs is that you cannot without permission to do zone transfers (see How to list all CNAME records for a given domain?).

That said, if your company's DNS server still supports the ANY query, you can use dig to list the other records by doing:

dig +noall +answer +multiline yourdomain.yourtld any 

These ... +noall +answer +multiline ... are strictly optional and are simply output formatting flags to make the output more easily human readable (see dig man page ).

Example

$ dig +noall +answer +multiline bad.horse any

Returns:

bad.horse.              7200 IN A 162.252.205.157
bad.horse.              7200 IN CAA 0 issue "letsencrypt.org"
bad.horse.              7200 IN CAA 0 iodef "mailto:abuse@sandwich.net"
bad.horse.              7200 IN MX 10 mx.sandwich.net.
bad.horse.              7200 IN NS a.sn1.us.
bad.horse.              7200 IN NS b.sn1.us.
bad.horse.              7200 IN SOA a.sn1.us. n.sn1.us. (
                                2017032202 ; serial
                                1200       ; refresh (20 minutes)
                                180        ; retry (3 minutes)
                                1209600    ; expire (2 weeks)
                                60         ; minimum (1 minute)
                                )

Caveats (RFC8482)

Note that, since around 2019, most public DNS servers have stopped answering most DNS ANY queries usefully. For background on that, see: https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any/

If ANY queries do not enumerate multiple records, the only option is to request each record type (e.g. A, CNAME, or MX) individually.

Well, I solved it. Turns out the sysadmin before me had forced all outgoing queries onto port 53. extremehosting.ca's name servers seem to block incoming connections on port 53, which originate on port 53, and as such I wasn't able to communicate with them.

By removing these lines from named.conf:

query-source    port 53;
query-source-v6 port 53;

and confirming the firewall wouldn't cause any further issue, name resolution works again.

Also, I found this article which helps determine your name resolver's source-port behaviour to be hugely helpful. The side effect of sorting out this DNS problem is that I've also plugged a potential name-cache poisoning vulnerability.

Thanks to all who've commented.