Проект не доступен. Ошибка хостинга или провайдера интернета.

Скорее всего, наоборот.

Проблема в DNS. Покажите уже домен, чтобы не гадать. Можно в ЛС, если здесь светить боитесь.

---------- Добавлено 19.02.2012 в 15:04 ----------

Your SOA EXPIRE number is: 3600000. That is NOT OK

Это означает, что зона обновляется посторонними провайдерами через каждые 3600000 секунд. Это 41 день. нормальное значение - 1 неделя. Сравните вот с этим: http://intodns.com/hostace.ru

Красненькое - означает, что наши DNS публичны, т.е. ими можно пользоваться как гугловыми, поэтому это нормально. Вам стоит обратить внимание на SOA. Т.е. в данном случае вам или менять DNS-серверы (равносильно смене провайдера по затратам), либо просто подождать с месячишко и просидеть на других DNS. Вообще, как бы сам интернет-провайдер действует в рамках RFC. Однако, следует заметить, что данная ситуация означает, что ваш сайт может быть недоступен от многих других интернет-провайдеров по аналогичным причинам, поэтому целесообразно вопрос решить с технической поддержкой хостера.

P.S. Это не значит, что проблема будет постоянно - просто существует вероятность, что ситуация повторится.

SOA EXPIRE отвечает за взаимоотношения со slave серверами.

Если мастер ложится, и/или от него не поступает никакой информации по этой зоне,

то в течение этого срока слейв продолжает обслуживать зону на своих кешах.

К кеширующим ДНС провайдеров имеет отношение в первую очередь TTL и serial.

Огласите домен, и список действий что вы с ним делали (смена НС-ов и.т.д.).

SOA EXPIRE tells servers how long to wait before dumping their cached DNS info, in the case the they can't refresh. This has nothing to do with making DNS changes, and doesn't affect how long changes take to propagate.

---------- Добавлено 19.02.2012 в 23:22 ----------

Вообще говоря, данное жесткое ограничение (наличие 0 в поле ttl) было снято в 1997 году (RFC 2181). Связано это было с тем, что реально требование наличия нуля в поле ttl записи SOA нигде не использовалось и не проверялось. С тех пор записи SOA могут содержать значения в поле ttl.

Поле ttl в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается либо последним аргументом данных записи SOA (версии BIND до 8.2.), либо директивой управления $TTL. Запрет на кэширование SOA определен в RFC 1035.

---------- Добавлено 20.02.2012 в 00:31 ----------

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

Вот и накой брать кусок английского текста без перевода и пояснений?

Негативный ответ не только может, но и будет закеширован.

Есть 3 TTL, давайте это разъясним:

1. $TTL - время кеширования положительных ответов (по умолчанию).

2. SOA.TTL - время кеширования отрицательных ответов.

3. локальный TTL - переназначеный для конкретной записи положительный TTL.

Отрицательный ответ _всегда_ имеет TTL.

Но в любом случае к вопросу ТС это ясности не прибавляет.

Должен признаться, я ничего не понял из вышесказанного, поэтому прошу рассмотреть логичность следующего решения:

- Я прошу хостинг, перенести сайт на другие ДНС сервера.

- Я прошу хостинг сменить выделенный Ай-пи адрес сайта (это лишнее?)

Тоесть сайт(три проекта на разных ДНС) начнут «жизнь с нуля». Возможно это поможет прояснить ситуацию. На этом хостинге, у меня еще несколько проектов, которые работают нормально, что означает возможность исправления ситуации в данном ключе.

Насколько логично данное решение? И где все-таки сбой: хостинг или провайдер интернета? Благодарю!

Не логично ни в коей мере.

Еще больше увеличите себе головную боль от переходных процессов.

Сайт - три проекта на разных DNS ? Как это?

Не взрывайте мозг, дайте имя домена.

Надо проверять сначала. Удалите ту запись из hosts, reboot, потом делаете: tracert example.com . Если все в порядке, то tracert должен разрешить ваш домен в правильный IP. Потом делаете ping example.com , несколько раз, и тоже проверяете, что ресолв в IP проходит нормально. Если ресолв не проходит, то проблема либо в ресолверах провайдера, либо в не совсем верной настройке DNS хостинга. Потом гуглите про команду nslookup, и через нее проверяете ресолверы вашего провайдера, если будут ошибки, то проверяете через публичные ресолверы гугля, если и они дают ошибку, значит проблема у DNS хостинга.

Если через hosts сайт работает не полностью, то надо добавить в hosts: example.com, www.example.com, ftp.example.com, subdomain.example.com, etc.

Я видел этот домен и всё там хорошо, кроме записи SOA. Т.е. закеширован мог быть только негативный ответ. Не могу представить иной ситуации. Причём ТС менял DNS. Если на корневых серверах запись уже сменилась, а хостинг отдал ему отрицательный ответ - он был закеширован и, как следствие, сайт доступен отовсюду, откуда к нему не обращались когда его небыло на DNS хостера. Хостер отдаёт REFUSED, не разрешая рекурсивные запросы, поэтому зона обновляется по SOA EXPIRE. В любом другом случае сработал бы TTL. Другой ситуации я представить так и не могу (Я ознакомился со всеми RFC на этот счет).

Я опираюсь на rfc2308