Должна ли работать электронная почта на hello@test.com?
test.com CNAME something.else.com
else.com MX 1 <google mx>
Я думаю, что есть некоторые ссылки, требующие RFC1912 не наличие записей CNAME вместе с другими записями в том же домене, но должно ли это быть приемлемым использованием?
Нет записи MX для something.else.com, но есть записи MX для else.com. Я получаю разные результаты с dig, когда запускаю его несколько раз:
$ 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.
Рассматриваемый домен Полет, пытаясь отправить электронное письмо на адрес в этом домене.
есть некоторые ссылки, требующие, чтобы RFC1912 не имел записей CNAME вместе с другими записями в том же домене
Это правда, если у вас есть CNAME, у вас не может быть другого типа записи для того же домена (FQDN). В вашем примере вы передаете эти «требования». Для лучшего подхода предположим example.com и example.net домены.
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
Обе example.net Записи MX и A не имеют отношения к CNAME, поскольку example.com перенаправление на sub.example.net так субдомен example.net. Как правило, если есть CNAME, будет следующий запрос на sub.example.net. Сначала было бы для MX запись (и), и если она не существует, будет другой запрос для А или AAAA.
В этом случае электронное письмо будет доставлено по адресу 192.0.2.20 как есть А записи на "целевом" домене, где отсутствует MX запись.
Примечание. Чтобы объяснить полученные ответы, вы должны предоставить более релевантную информацию или правильный домен для проверки. После вашего процесса «анонимизации» и уровня детализации невозможно ответить с подробностями ...
Похоже, что авторитетные серверы имен для этого домена (dns1.p01.nsone.netи т. д.) дают противоречивые ответы в зависимости от 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
$
Это поведение отличается от сценария, изложенного в вопросе.
Дело не в том, что MX что вы видите от другого имени (как было указано в вопросе), MX и CNAME явно бок о бок со своими серверами имен, дающими разные «взгляды» в зависимости от того, что вы просили, даже если эти взгляды явно находятся в прямом конфликте и их невозможно объединить.
Что касается результатов, которые получит клиент, это, вероятно, подбрасывание в зависимости от состояния кеша и особенностей реализации. Если у вас уже есть CNAME в кеше вы уже знаете, что имя является псевдонимом, и это свойство самого этого имени, имя не может быть псевдонимом для некоторых типов записей, но не для других (отсюда почему CNAME записи не могут сосуществовать с другими данными).
Поведение этой реализации сервера имен не соответствует стандартам, и я не ожидал, что то, что он делает, будет работать надежно. Невозможно сказать, получат ли клиенты ответ, который они планировали для данной ситуации, или некоторая путаница на основе уже кэшированного CNAME.