URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 64222
[ Назад ]

Исходное сообщение
"Можно ли не определять обратную зону?"

Отправлено chainik , 16-Фев-06 23:37 
Чем может грозить неопределение обратной зоны?

Ситуация такая. Начальство небольшого подразделения, в котором я работаю, купило какой-то из контрактов в МТУ по которому эта организация выделила нам a.b.c.d/28 - подсетку постоянных адресов. Сейчас на этих машинах стоят некоторые сервисы, которыми мы пользуемся. Ну, естественно, захотелось чтоб снаружи можно было бы набирать не ip а имена машин. Далее, зарегистрировали домен с помощью услуг www.nic.ru (назовем его здесь условно mydomainn.ru). Почитав всякие howto и даже лекцию по настройке dns (http://www.opennet.ru/docs/RUS/dns1/) я пришел к выводу (возможно ошибочному), что в такой ситуации, вроде бы, можно запустить первичный DNS, поддерживающий зону mydomainn.ru (может быть впоследствии - какие-то еще зоны) на нашей машине. При этом вторичный dns-сервер можно заказать в том же www.nic.ru.

Только вот мне не понятно, что делать с обратной зоной, обязательно ли ее определение? В нашем случае ее же должно поддерживать МТУ, чего, кажется у нас нет. По крайней мере, адреса записаны только до уровня подсети a.b.0.0/16.

0.0.b.a.in-addr.arpa name = ppp0-0.pppoe.mtu-net.ru.

т.е., если набрать

# nslookup a.b.0.0

, то ответ будет

Server:         212.188.4.10
Address:        212.188.4.10#53

0.0.b.a.in-addr.arpa name = ppp0-0.pppoe.mtu-net.ru.

а если какую-либо подсеть или узел в этой сетке, то уже ничего не найдется.

Так вот, я собираюсь не определять обратную зону. В связи с этим и интересуюсь, будет ли описанная конструкция работоспособной? Если да, то не опасно ли для окружающих отсутствие на сервере обратной зоны?

Хочется разобраться еще до того как я начну эксперименты с делегированием домена mydomenn.ru, а то может и не стоит начинать ;)

Заранее спасибо.


Содержание

Сообщения в этом обсуждении
"Можно ли не определять обратную зону?"
Отправлено Free , 17-Фев-06 04:09 
Очень здорово, что вы так подробно подходите к проблеме.

1. Да, вы можете поднять у себя первичный NS, указав у регистратора доменного имени, свой IP адрес в качестве такового. И указав второй IP для люого второго NS (есть бесплатные).

2. В вашем случае с выделением адресов из пула провайдера, обратную зону должен поднять провайдер.

3. Если обратная зона не прописана, то по доменному имени все к вам достучаться смогут без проблем. Однако, некоторые проблемы могут быть. Если вы, например, поднимете у себя почтовый сервер на этот домен, что купили, то при отсутствии обратной зоны, некоторые сервера почту от вас принимать не будут. также могут быть проблемы при заходе на некоторые ftp сервера... кажись.


"Можно ли не определять обратную зону?"
Отправлено ra , 17-Фев-06 08:01 
3. да, борцы со спамом перегибают палку - отпинывают письма если не удается разрешить обратную зону. а ее, блин, не всегда есть возможность прописать.
с фтп что-то проблем не наблюдал...

"Можно ли не определять обратную зону?"
Отправлено ram_scan , 17-Фев-06 09:01 
>3. да, борцы со спамом перегибают палку - отпинывают письма если не
>удается разрешить обратную зону

Причем, самое дебильное в этой ситуации, что процентов 90 зомбированых/протрояненых хостов с которых спам и валится эту обратную зону таки имеют. Я долго пытался понять логику админов которые нарушая RFC требуют наличия обратной зоны, но так просветление у меня и не наступило.


"Можно ли не определять обратную зону?"
Отправлено jonatan , 17-Фев-06 09:34 
>которых спам и валится эту обратную зону таки имеют. Я долго
>пытался понять логику админов которые нарушая RFC требуют наличия обратной зоны,
>но так просветление у меня и не наступило.
Дискуссия по этому поводу была. Может Вы проясните ситуацию после перевода следущего?
http://www.faqs.org/rfcs/rfc1912.html
   Make sure your PTR and A records match.  For every IP address, there
   should be a matching PTR record in the in-addr.arpa domain.  If a
   host is multi-homed, (more than one IP address) make sure that all IP
   addresses have a corresponding PTR record (not just the first one).
   Failure to have matching PTR and A records can cause loss of Internet
   services similar to not being registered in the DNS at all.  Also,
   PTR records must point back to a valid A record, not a alias defined
   by a CNAME.

"Можно ли не определять обратную зону?"
Отправлено ipmanyak , 17-Фев-06 09:39 
ничего особо опасного не будет!  для  почтаря очень желательно иметь обратную зону, поскольку этого требует RFC1912 2.1 ! Впрочем по тому же  RFC1912 2.1 записи в обратной зоне должны быть для всех инетовских хостов!
2.1 Inconsistent, Missing, or Bad Data
   Every Internet-reachable host should have a name.  The consequences
   of this are becoming more and more obvious.  Many services available
   on the Internet will not talk to you if you aren't correctly
   registered in the DNS.
   Make sure your PTR and A records match.  For every IP address, there
   should be a matching PTR record in the in-addr.arpa domain.  
Поскольку RFC нужно соблюдать советую попросить прова зарегить обратную зону.



"Можно ли не определять обратную зону?"
Отправлено ram_scan , 17-Фев-06 13:36 
>ничего особо опасного не будет!  для  почтаря очень желательно иметь
>обратную зону, поскольку этого требует RFC1912 2.1 ! Впрочем по тому
>же  RFC1912 2.1 записи в обратной зоне должны быть для
>всех инетовских хостов!

Зато в RFC2821 нигде нет требования наличия PTR записи. Кстати, в RFC1912 2.1 написано, если я правильно его понимаю, что хост должен (но не обязан) иметь A запись, и однозначного требования наличия PTR записи как такового там тоже нет. Есть только настойчивое, но необязательное пожелание, сформулированое как "should be a matching PTR record" (а между should и must я вижу огромную разницу).


"Можно ли не определять обратную зону?"
Отправлено jonatan , 17-Фев-06 14:48 
>Зато в RFC2821 нигде нет требования наличия PTR записи.
Их там и не должно быть. Это RFC на протокол SMTP. MTA такой же хост в Инет как и остальные. Значит на него распространяются требования RFC1912.
>Кстати, в RFC1912 2.1 написано, если я правильно его понимаю, что хост должен (но
>не обязан) иметь A запись, и однозначного требования наличия PTR записи
>как такового там тоже нет. Есть только настойчивое, но необязательное пожелание,
>сформулированое как "should be a matching PTR record" (а между should
>и must я вижу огромную разницу).
Согласен. Но как понимать тогда следующее?
Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.

"Можно ли не определять обратную зону?"
Отправлено pirat274 , 17-Фев-06 16:21 
jonatan АБСОЛЮТНО СОГЛАСЕН!!! Всегда ставил проверку, ставлю и буду ставить. И пусть я буду "ДУРАКОМ И БОРЦОМ СО СПАМЕРАМИ". По фиг.

"Можно ли не определять обратную зону?"
Отправлено vt , 17-Фев-06 16:36 
>>Зато в RFC2821 нигде нет требования наличия PTR записи.
>Их там и не должно быть. Это RFC на протокол SMTP. MTA
>такой же хост в Инет как и остальные. Значит на него
>распространяются требования RFC1912.

В rfc1912 никаких ТРЕБОВАНИЙ нет и не может быть по определению, т.к.
Category: Informational
Status of this Memo
This memo provides information for the Internet community.  This memo
does not specify an Internet standard of any kind.

Вообще, rfc1912 - это просто пособие по настройке bind и только.
Никакими СТАНДАРТАМИ хостам не запрещено иметь или не иметь
прямых или обратных записей в dns

В то же время rfc1123 имеет совершенно другой статус
This RFC is an official specification for the Internet community.  It
incorporates by reference, amends, corrects, and supplements the
primary protocol standards documents relating to hosts.
и прямо запрещает mta отвергать почту из-за отсутствия или
несоответствия обратной записи.


"Можно ли не определять обратную зону?"
Отправлено jonatan , 17-Фев-06 17:09 
>и прямо запрещает mta отвергать почту из-за отсутствия или
>несоответствия обратной записи.
Ткните носом, плиз. Никак найти не могу в тексте.

"Можно ли не определять обратную зону?"
Отправлено vt , 17-Фев-06 17:36 
>Ткните носом, плиз. Никак найти не могу в тексте.
5.2.5  HELO Command

"Можно ли не определять обратную зону?"
Отправлено jonatan , 17-Фев-06 17:52 
>5.2.5  HELO Command
Это совсем не то. Речь не о том, проверять адрес имени, указанного в HELO или нет. Речь даже не конкретно о MTA, а о любом хосте Инета. MTA - просто частный случай. Так что вопрос остается открытым.

"Можно ли не определять обратную зону?"
Отправлено йэз , 18-Фев-06 20:19 
делай обязательно. потом не раз натраблишься без неё. опыт.

"Можно ли не определять обратную зону?"
Отправлено jonatan , 18-Фев-06 21:36 
>делай обязательно. потом не раз натраблишься без неё. опыт.
Согласен. Но меня (как и многих других) интересуют существующие стандарты.

"Можно ли не определять обратную зону?"
Отправлено ram_scan , 19-Фев-06 07:24 
>>делай обязательно. потом не раз натраблишься без неё. опыт.
>Согласен. Но меня (как и многих других) интересуют существующие стандарты.

Не обязан ты по стандарту обратную зону иметь. Просто некоторые маньяки настраивают свой софт не по корану, и из-за них приходится геморроиться с обратными зонами.


"Можно ли не определять обратную зону?"
Отправлено PJ , 19-Фев-06 11:57 
http://www.opennet.ru/openforum/vsluhforumID1/63472.html - вроде уже обсуждалось это.

"Можно ли не определять обратную зону?"
Отправлено jonatan , 20-Фев-06 08:58 
>Не обязан ты по стандарту обратную зону иметь. Просто некоторые маньяки настраивают
>свой софт не по корану, и из-за них приходится геморроиться с
>обратными зонами.
По данному вопросу меня не интересуют частные мнения. Приводите стандарты, тогда будет что обсуждать.

"Можно ли не определять обратную зону?"
Отправлено repairman , 18-Май-11 17:34 
> Не обязан ты по стандарту обратную зону иметь. Просто некоторые маньяки настраивают
> свой софт не по корану, и из-за них приходится геморроиться с
> обратными зонами.

Также никто не обязан принимать Вашу почту... покажите, где написано, что я должен...
На этом и сойдемся, Вы шлете, я отказываю, оба правы, всем хорошо... :-)