Домен CNAME на поддомен без повторных запросов MX
Должна ли электронная почта (скрытая) работать?
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.
Рассматриваемый домен - Flights , попытка отправить электронное письмо на адрес в этом домене.
Он бы похоже, что авторитетные серверы имен для этого домена ( 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 .
есть некоторые ссылки, требующие, чтобы 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 , и если она не существует, будет другой запрос для A или AAAA .
В этом вариант использования, электронная почта будет доставлена на 192.0.2.20 , поскольку это A записи в «целевом» домене, где отсутствует запись MX .
] Примечание. Чтобы объяснить полученные ответы, вы должны предоставить более релевантную информацию или правильный домен для проверки. После вашего процесса «анонимизации» и уровня детализации невозможно ответить с подробностями ...