0

Should email to [email protected] work?

test.com CNAME something.else.com
else.com MX 1 <google mx>

I think there are some references out there requiring RFC1912 not having CNAME records along with other records on the same domain but should this be an acceptable use?

There is no MX record for something.else.com but there are MX records for else.com. I get different results with dig, when I run it multiple times:

$ dig +short @8.8.8.8 test.com. mx
something.else.com
$ dig +short @8.8.8.8 test.com. mx
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

The domain in question is wego.com, attempting to send an email to an address in that domain.

1
  • It is better to use real domain or "common" example.com domain. In case of provided response there is missing more relevant records which are involved in the question... At this level of detail and without real domain I am afraid it is possible to answer just with general information... See my answer if it is OK for you like this.
    – Kamil J
    Feb 12, 2020 at 0:04

2 Answers 2

1

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.

3
  • I didn't try this as this situation shouldn't happen.... E.g. Bind server refuse zone in case of parallel CNAME and other record... I have reproduce this answers without issue so it seems DNS server is OK with this situation. So once CNAME is cached it will be kept in the queue as undelivery and with the retry it may be delivered. The result may be "random" delivery delay similar to gray listing.
    – Kamil J
    Feb 12, 2020 at 10:41
  • thanks! I didn't know about the +norec option, that is useful. If the MX were removed from the wego.com domain, what would be the expected behavior? A query would be done on enigma.wego.com.cdn.cloudflare.net for MX, which doesn't exist so a mail server could potentially use the A record (if configured to do so)? I suspect this won't go up the chain to the root domain cloudflare.net.
    – Anil J
    Feb 12, 2020 at 15:18
  • MX for the questioned FQDN. In case of CNAME (or other alias like DNAME) there is new query for new FQDN. Once the MX is not exists there is "fall back" to A or AAAA. Once none of this works it would stay in queue as undelivered and retrying until the message will expire... This is for the case that there is temporary failure on existing domain so until the message expire in the queue the mail mail server try new DNS query for MX and then A or AAAA. Once the connection is established and refuse during SMTP communication the message is not re-queued and it is returned to sender directly.
    – Kamil J
    Feb 12, 2020 at 20:03
2

there are some references out there requiring RFC1912 not having CNAME records along with other records on the same domain

That is true, once you have CNAME, you can't have other type of record for the same domain (FQDN). In your example you are passing this "requirements". For the better approach please let assume example.com and example.net domains.

example.com. CNAME sub.example.net.

example.net. MX 10 192.0.2.10
example.net. A 192.0.2.15

sub.example.net. A 192.0.2.20

Both example.net MX and A records are irrelevant as CNAME related to example.com redirecting to sub.example.net so subdomain of example.net. In general once there is CNAME there would be following request for sub.example.net. First would be for MX record(s) and in case it doesn't exists there would be another query for A or AAAA.

In this use case the e-mail would be delivered to 192.0.2.20 as it is A records on the "target" domain where is missing MX record.

Note: To explain your returned answers you should provide more relevant information or correct domain to check. After your "anonymization" process and level of details it is not possible to answer with details...

5
  • In this case it seems like the email is getting delivered to the MX (and not the sub.example.net A record). The domain in question is wego.com - not my domain, just domain we're trying to send email to, so don't need to anonymize it.
    – Anil J
    Feb 12, 2020 at 0:22
  • The domain wego.com is CNAMEd to cloudflare - enigma.wego.com.cdn.cloudflare.net.. There is no MX record for this domain. "Nearest" upper level domain with MX record is cloudflare.net. pointing to google mail servers. There are few A records but I suppose there is nothing listening the mail delivery. In case of NonExistece record there is passed SOA record for cloudflare.net. In case of this query the MX records exists. The most probably this is the way how you have reached google servers. I am not sure it is 100% correct approach but it seem to be applied based on your comment.
    – Kamil J
    Feb 12, 2020 at 0:37
  • Yes, it's strange that dig provides two different outputs (one with Google mail servers and another with the CNAME record). Testing with SMTP delivery also hits Google servers (on my test server). Either way, thanks for your reply. It's a strange implementation. I guess this could be used as a way to "manage" MX records for a domain you may not have access to.
    – Anil J
    Feb 12, 2020 at 3:54
  • As MX record for "targeted" system doesn't exists simple CNAME record is proper answer. CNAME followed with the result of seubrequest (new FQDN base on CNAME value) is expected.
    – Kamil J
    Feb 12, 2020 at 10:34
  • @Håkan Lindqvist targeted the source of the situation. I can only agree that this situation is not compliant with the standards / RFCs. In long period of time the e-mail would be deliverable but there will be the most probably random delay in delivery based on actual DNS cache.
    – Kamil J
    Feb 12, 2020 at 10:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .