It would appear that the authoritative nameservers for this domain (dns1.p01.nsone.net
, etc) serve conflicting responses depending on the qtype.
Qtype A
:
$ dig @dns1.p01.nsone.net wego.com A +norec
; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>> @dns1.p01.nsone.net wego.com A +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24735
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wego.com. IN A
;; ANSWER SECTION:
wego.com. 3600 IN CNAME enigma.wego.com.cdn.cloudflare.net.
;; Query time: 0 msec
;; SERVER: 198.51.44.1#53(198.51.44.1)
;; WHEN: Wed Feb 12 07:40:14 UTC 2020
;; MSG SIZE rcvd: 85
$
Qtype MX
:
$ dig @dns1.p01.nsone.net wego.com MX +norec
; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>> @dns1.p01.nsone.net wego.com MX +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51501
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wego.com. IN MX
;; ANSWER SECTION:
wego.com. 3600 IN MX 1 aspmx.l.google.com.
wego.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
wego.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
wego.com. 3600 IN MX 10 alt3.aspmx.l.google.com.
wego.com. 3600 IN MX 10 alt4.aspmx.l.google.com.
;; Query time: 0 msec
;; SERVER: 198.51.44.1#53(198.51.44.1)
;; WHEN: Wed Feb 12 07:40:25 UTC 2020
;; MSG SIZE rcvd: 152
$
That is a different behavior than the scenario that was laid out in the question.
It's not that the MX
that you see is from a different name (as was indicated in the question), the MX
and CNAME
are clearly side by side with their nameservers giving different "views" depending on what you asked for, even though these views are clearly in direct conflict and impossible to combine.
As for what results a client will get, it's probably a toss-up depending on cache state and implementation specifics. If you already have the CNAME
in the cache, you already know that the name is an alias and that is a property of that name itself, the name cannot be an alias for some record types but not for others (hence why CNAME
records cannot coexist with other data).
The behavior of this nameserver implementation is not standards compliant, and I wouldn't expect what it does to work reliably. There is no telling if clients will actually get the response they intended for the given situation or some mix-up based on an already cached CNAME
.