dig +short for MX when the record is broken gives confusing answer
A confused user said that dig +short for an MX record did not report the preference level. The example he gave was:
# dig +short cyclonit.com MX HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
When given without +short, the reason becomes clear:
# dig cyclonit.com MX ; <<>> DiG 9.16.10 <<>> cyclonit.com MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: b0e8599a68ce3729dc85d51e6003a03d038d9864e7c2e63c (good) ;; QUESTION SECTION: ;cyclonit.com. IN MX ;; ANSWER SECTION: cyclonit.com. 10544 IN CNAME HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com. ;; AUTHORITY SECTION: elb.us-east-1.amazonaws.com. 53 IN SOA ns-1826.awsdns-36.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60
Yep, it's the dreaded "CNAME and MX at the same level" issue. However, +short hides that in a confusing way.
Proposal: dig +short for broken names such as this should instead reply "CNAME target", or possibly "Bad CNAME target".