Обратная зона DNS

[ttttt 195]

На 76.2 все еще старая зона у вас, со старым серийным номером. Не синхронизируется, читайте логи сервера (они по-моему в syslog)

[ttttt 195]

TTL в 60 секунд приведет к увеличению бесполезной нагрузки на ваш сервер

Это было в дремучие времена так, оно так по дефолту и осталось. А сейчас такие огромные ттл считаются неадекватными, только время людей тратят на борьбу с кэшами.

[lemosh 59]

На 76.2 все еще старая зона у вас, со старым серийным номером. Не синхронизируется, читайте логи сервера (они по-моему в syslog)

да, я видел. уже все нормально.... TTL пока увеличил. 

 

Я так думаю что скорее всего от райпа приходил ответ что не прописаны неймсервера в зоне 76.46.95.in-addr.arpa и поэтому изменения не вносятся изменения в базу. Других причин не вижу. Подал заявку на внесение изменений. Жду ответ

 

 

PS спасибо что носом ткнули в ошибку

Відредаговано 2017-11-01 22:13:11 lemosh

[muff 114]

 

Слейвы перечисляем в allow-transfer.

это понятно

на сервере в котором тип зоны указан слейв также нужно указать  allow-query { any;}; в параметрах зоны?

 

Да, все верно.

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

[muff 114]

Не владея полностью всей информацией, сложно дать точный ответ для решения проблемы.

Но... Если сети арендованые, и звучало

К сожалению, согласно внутренней политике нашей организации мы не передаем управление DNS. 
В том числе, для того, чтобы избежать злоупотребления со стороны клиента из-за отсутсвия опыта или какой-либо другой причины.

Для того, чтобы делегировать управление обратными зонами на ваш ДНС мне необходимо, чтобы вы прислали минимум 2 ДНС сервера в 
формате FQDN, настроенных на прием обратных зон. Оба DNS сервера должны отвечать на запросы из-вне по TCP.

Может стоит связаться с арендодателем и отправить ему данные серверов? Если у Вас все еще остается какая-то ошибка, думаю они Вам подскажут, как ее исправить.

[ig0r 25]

А сейчас такие огромные ттл считаются неадекватными, только время людей тратят на борьбу с кэшами.

 

Кем считаются неадекватными и в чем преимущества низких TTL, кроме быстроты обновления кешей?

Одно дело, когда низкий TTL используется для failover, а другое - когда он ставится просто так. Это же обратная зона DNS, она с большой вероятностью не будет часто меняться.

Низкий TTL кроме нагрузки повышает шансы на отравление кешей. Некоторые считают низкий TTL одной из новых угроз стабильности Сети, а низкий TTL для MX-записей может привести к печальным последствиям.

Відредаговано 2017-11-01 22:26:05 ig0r

[ttttt 195]

Всеми считается, кто днс инфраструктурой занимается

 

А статейки плохие, это разве нормально, что для кого-то отравление днс кэша проблема безопасности, а "ттл в неделю мог бы спасти от угона ника"? Это ж ламерство какое-то. Днс же вообще в клиртексте, ну о какой безопасности может идти речь. И угроза стабильности там тоже не в ттл, я читал и даже обсуждал это на hn еще когда дин ддосили. Там проблема в централизации и ламерстве, люди не поднимают свои днс серверы, как было изначально задумано в распределенной системе днс, а юзают дин или клаудфлейр и если они ложатся, то тянут за собой все сайты клиентов. Никакой ттл от такого в принципе не может спасти.

[lemosh 59]

Теперь все получилось

Modify SUCCEEDED: [domain] 76.46.95.in-addr.arpa

Спасибо ttttt что ткнул носом в ошибку . Проблема была действительно в том что в обратной зоне были прописаны неправильные NS

 

 

 

 

А теперь немного не по теме вопрос. Насколько я понимаю неймсервер отдает IP в ответ на запрос по имени домена. Например для своего домена (nasha.net.ua) хочу прописать только свои неймсервера (nss1.nasha.net.ua и nss2.nasha.net.ua). Насколько это вообще правильно? Ведь для того чтобы получить IP-адрес неймсервера например nss1.nasha.net.ua нужно обратиться к неймсерверу этого же домена, т.е. по логике замкнутый круг получается... Может все-таки так нельзя делать?

[ttttt 195]

Замкнутый круг никуда не денется Если нсы на другом домене, то другой домен тоже на каких-то нсах хостится, а его нсы тогда где? На нсах от третьего домена? А третий тогда на каких? Где-то в цепочке нсы верхнего уровня должны отдать IP адреса нсов нижнего уровня, никуда от этого не деться. Называются записи с этими IP адресами - glue records.

[foreverok 95]

Всеми считается, кто днс инфраструктурой занимается

 

А статейки плохие, это разве нормально, что для кого-то отравление днс кэша проблема безопасности, а "ттл в неделю мог бы спасти от угона ника"? Это ж ламерство какое-то. Днс же вообще в клиртексте, ну о какой безопасности может идти речь. И угроза стабильности там тоже не в ттл, я читал и даже обсуждал это на hn еще когда дин ддосили. Там проблема в централизации и ламерстве, люди не поднимают свои днс серверы, как было изначально задумано в распределенной системе днс, а юзают дин или клаудфлейр и если они ложатся, то тянут за собой все сайты клиентов. Никакой ттл от такого в принципе не может спасти.

Как знать. 60 секунд по моему не адекватное значение. 600 вполне нормально для часто обновляемых зон.

 

Посмотрите на корневые серверы )

        primary name server = a.root-servers.net
        responsible mail addr = nstld.verisign-grs.com
        serial  = 2017110101
        refresh = 1800 (30 mins)
        retry   = 900 (15 mins)
        expire  = 604800 (7 days)
        default TTL = 86400 (1 day)

Ну или ua.

        primary name server = he1.ns.ua
        responsible mail addr = domain-master.cctld.ua
        serial  = 2017110212
        refresh = 7205 (2 hours 5 secs)
        retry   = 3602 (1 hour 2 secs)
        expire  = 3024000 (35 days)
        default TTL = 11111 (3 hours 5 mins 11 secs)

Відредаговано 2017-11-02 21:53:17 foreverok

[ttttt 195]

Только тут ни у кого не корневые серверы, а рядовые домены и 600 это в принципе современный максимум для рядовых доменов. Есть причины ставить 600, но начинать стоит с минимального, если не знаете зачем 600.

[foreverok 95]

От количества запросов зависит. Чем меньше время TTL, тем больше будет запросов к DNS - соответственно нагрузка больше.