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 60Yep, 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".