Re: Проблема с проверкой домена отправителя, IPv6.

На Tue, 27 Jan 2009 10:47:38 +0300
"Dmitry Akindinov" <CGatePro@mx.ru> записано:

> Здравствуйте,
>
> Sergey Chumakov wrote:
> > Добрый день.
> >
> > FreeBSD 6.2/7.1, CGP 5.2.9/5.2.10.
> >
> > Иногда не удается отправить письмо с адреса в почтовом домене, MX-ы
> > которого содержат IPv6 адреса.
> >
> > 23:10:33.246 4 SMTPI-495989([1.1.1.1]) checking MX-record for freebsd.org
> > 23:10:33.246 5 SMTPI-495989([1.1.1.1]) reverse-connecting to [2001:4f8:fff6::34]:25
> > 23:10:33.246 1 SMTPI-495989([1.1.1.1]) Return-Path 'mav@FreeBSD.org' rejected: no relay available
> >
> > Похожая проблема (номер 2) была описана в этом письме:
> > http://mx.ru/Lists/CGatePro/Message/17240.html?Skin=Russian
> >
> > Дело вот в чем:
> >
> > $ host mx1.freebsd.org
> > mx1.freebsd.org has address 69.147.83.52
> > mx1.freebsd.org has IPv6 address 2001:4f8:fff6::34
> >
> > CGP делает запрос MX, и если в дополнительной секции ответа содержатся
> > записи, то запрос А-записи уже не производится:
> >
> > 22:29:39.812 5 DNR-029241(freebsd.org) MX-request
> > 22:29:39.812 4 DNR-029241(freebsd.org) MX-request -> udp:[195.248.191.67]:53
> > 22:29:39.812 5 DNR-029241(freebsd.org) got 195 bytes from [195.248.191.67]:53: 72 39 81 80 00 01 00 01 00 02 00 04 07 66 72 65 65 62 73 64 03 6F 72 67 00 00 0F 00 01 C0 0C 00 0F 00 01 00 00 00 D1 00 08 00 0A 03 6D 78 31 C0 0C C0 0C 00 02 00 01 00 00 09 F2 00 11 03 6E 73 32 07 69 73 63 2D 73 6E 73
> > 22:29:39.812 5 DNR-029241(freebsd.org) MX:OK 22:29:39.812 4 DNR-029241(freebsd.org) MX[0]: freebsd.org(pty 10) = mx1.freebsd.org
> > 22:29:39.812 4 DNR-029241(freebsd.org) suppl[0]: mx1.freebsd.org=[2001:4f8:fff6::34]
> >
> > Такая ситуация получается, когда в кэше сервера имен А-записи
> > mx1.freebsd.org уже нет (TTL закончился), а АААА-запись еще есть,
> > соответственно он и выдает только ее в дополнительной секции.
>
> Сщмнительно, что такое поведение DNS сервера можносчитать нормальным.
> Если уж выдавать записи, то все?

Это дефолтное поведение серверов имен. Рекурсивным в данном случае является только запрос MX-записи, сервер ее честно выдает. Все, что отдается в additional section запроса - отдается из кэша, если оно там есть. Если его там нет - не отдается, и CGP не считает это странным, не так ли?

>
> > Если вычистить все записи из кэша DNS, CGP делает все честно, т.е.
> > запрашивает А-запись тоже, и все работает как надо:
> >
> > 23:17:28.740 5 DNR-019703(freebsd.org) MX-request
> > 23:17:28.740 4 DNR-019703(freebsd.org) MX-request -> udp:[195.248.191.67]:53
> > 23:17:28.740 5 DNR-019703(freebsd.org) got 167 bytes from [195.248.191.67]:53: 4C F7 81 80 00 01 00 01 00 02 00 03 07 66 72 65 65 62 73 64 03 6F 72 67 00 00 0F 00 01 C0 0C 00 0F 00 01 00 00 00 A5 00 08 00 0A 03 6D 78 31 C0 0C C0 0C 00 02 00 01 00 00 0C 5D 00 11 03 6E 73 32 07 69 73 63 2D 73 6E 73
> > 23:17:28.740 5 DNR-019703(freebsd.org) MX:OK
> > 23:17:28.740 4 DNR-019703(freebsd.org) MX[0]: freebsd.org(pty 10) = mx1.freebsd.org
> > 23:17:28.740 5 DNR-019704(mx1.freebsd.org) A-request
> > 23:17:28.740 4 DNR-019704(mx1.freebsd.org) A-request -> udp:[195.248.191.67]:53
> > 23:17:28.800 5 DNR-019704(mx1.freebsd.org) got 167 bytes from [195.248.191.67]:53: 4C F8 81 80 00 01 00 01 00 02 00 03 03 6D 78 31 07 66 72 65 65 62 73 64 03 6F 72 67 00 00 01 00 01 C0 0C 00 01 00 01 00 00 0E 10 00 04 45 93 53 34 C0 10 00 02 00 01 00 00 0C 5D 00 11 03 6E 73 32 07 69 73 63 2D 73 6E
> > 23:17:28.800 5 DNR-019704(mx1.freebsd.org) A:OK
> > 23:17:28.800 4 DNR-019704(mx1.freebsd.org) A[0]: mx1.freebsd.org=[69.147.83.52]
> >
> > Ключик --IPv6 NO проблему не решает, а должен бы, по логике.
>
> Там попытки соединения по IPv6 в этом случае не происходит. Но проблемы
> это не решает: от DNS была получена одна MX запись, да и та - нерабочая.
>

MX-запись была получена рабочая. Если бы CGP запрашивал А-запись этого MX-а, он получил бы ее. Но он _не запрашивает_ А-запись.

Отсюда FR: если указан ключ --IPv6 NO - игнорировать АААА-записи DNS. Это будет логичным.

-- 
С уважением, 

Сергей Чумаков,
системный администратор.
Группа телекоммуникационных компаний Vega.