Комментарии 29
> ошибки были актуальны на 7 Мая 2016
Спасибо, что указали дату. А то бывает иногда читаешь статью лохматого года, и там написано: «актуально на текущий момент»… Или «по сегодняшнему курсу доллара»… n/c
А потом ищешь дату в посте… ищешь-ищешь находишь какую-нибудь «03 апреля» или «1 августа», без года. И думаешь — в этом году, или в прошлом, или в каком-то другом?
И единственный ответ получаешь, когда открываешь старую-старую статью хабра, и в ней узнаешь, что если год не написан — то это текущий год. А если год был прошлый — тогда Хабр любезно тебе его выдает…
Кстати, а не должен ли vk.com адресоваться к каким-нибудь
ns1.vk.com?
Ведь они как-раз ушли от .RU домена, чтобы обезопаситься от гос.регулирования. А тут вдруг домен vkontakte.ru разделегируют, тогда и vk.com достанется…
Спасибо, что указали дату. А то бывает иногда читаешь статью лохматого года, и там написано: «актуально на текущий момент»… Или «по сегодняшнему курсу доллара»… n/c
А потом ищешь дату в посте… ищешь-ищешь находишь какую-нибудь «03 апреля» или «1 августа», без года. И думаешь — в этом году, или в прошлом, или в каком-то другом?
И единственный ответ получаешь, когда открываешь старую-старую статью хабра, и в ней узнаешь, что если год не написан — то это текущий год. А если год был прошлый — тогда Хабр любезно тебе его выдает…
Кстати, а не должен ли vk.com адресоваться к каким-нибудь
ns1.vk.com?
Ведь они как-раз ушли от .RU домена, чтобы обезопаситься от гос.регулирования. А тут вдруг домен vkontakte.ru разделегируют, тогда и vk.com достанется…
Кстати, а не должен ли vk.com адресоваться к каким-нибудь
ns1.vk.com?
Ведь они как-раз ушли от .RU домена, чтобы обезопаситься от гос.регулирования. А тут вдруг домен vkontakte.ru разделегируют, тогда и vk.com достанется…
Это зависит исключительно от соответствующих технических решений в самой компании. Может быть этот вопрос перестал быть важным, а может быть никто об этом не подумал в ключе зависимости от гос.регулирования.
Всё равно же Mail.Ru уже владеет ВКонтакте.
Причём тут госрегулирование? Домен vk.com используется в интересах маркетинга среди зарубежных пользователей, как менее визуально чужой. Никакой связи между доменным именем и регулированием содержания сайта нет.
Работа серверов Вконтакте регулируется российским законодательством, так как они физически расположены на территории России.
Я всегда ее определял по комментариям, по их датам =)
Про дату — очень верно подмечено! Особенно про отсутствие года в датах!
Сам всегда указываю дату с годом и другим советую.
Очень часто при поиске актуальной информации (например, о различных мероприятиях) попадаются статьи без дат. Вот и думаешь — это о новость о предстоящем или о прошедшем 5 лет назад.
Сам всегда указываю дату с годом и другим советую.
Очень часто при поиске актуальной информации (например, о различных мероприятиях) попадаются статьи без дат. Вот и думаешь — это о новость о предстоящем или о прошедшем 5 лет назад.
Спасибо за репорт. Исправили ns2.vkontakte.ru.
Пользуясь случаем хочу спросить, в чем логика отличия списка NS серверов, которые прописаны у регистратора и опубликованы в зоне com для домена vk.com, от списка NS серверов в зоне vk.com?
Та же история, с вариациями на тему отсутствующих в списке NS записей, прослеживается для доменов vkontakte.ru и vkadre.ru.
Во всех перечисленных доменов у регистраторов присутствует 4 записи, а на авторитативных серверах Вконтакте присутствуют только три записи.
Та же история, с вариациями на тему отсутствующих в списке NS записей, прослеживается для доменов vkontakte.ru и vkadre.ru.
Во всех перечисленных доменов у регистраторов присутствует 4 записи, а на авторитативных серверах Вконтакте присутствуют только три записи.
Может быть какой-то вариант защиты от DDOS атак?
НЛО прилетело и опубликовало эту надпись здесь
«из за нежелания перегружать статью я позволил себе их не публиковать»
Ну, можно было бы немного и перегрузить :) Статья на один экран всего.
Ну, можно было бы немного и перегрузить :) Статья на один экран всего.
Ну, можно было бы немного и перегрузить :) Статья на один экран всего.
Морально готовлюсь опубликовать в этом году статью про
Недавно обнаружил, что public google dns, который 8.8.8.8, ведет себя не так, как общепринято.
Например, если я добавил новую зону в свой домен, и впервые пытаюсь ее пингануть, то любой провайдер немедленно обращается к NS и получает ответ с айпишником, который мне и возвращает. Google же этого не делает, в результате приходится ждать сутки.
Причем несколько лет назад, все было в порядке.
Например, если я добавил новую зону в свой домен, и впервые пытаюсь ее пингануть, то любой провайдер немедленно обращается к NS и получает ответ с айпишником, который мне и возвращает. Google же этого не делает, в результате приходится ждать сутки.
Причем несколько лет назад, все было в порядке.
Боюсь дело тут не в Google Public DNS.
Могу порекомендовать проверить по списку:
1) Убедится в том, что новая запись действительно публикуется на всех авторитативных серверах домена, после того как ее внесли. Возможно, что сервера остаются рассинхронизированы по какой то причине. Проверить можно просто, указав команде nslookup или dig (в зависимости от OS) тип запроса soa, проверяемый домен и сервер и убедится в том, что серийный номер зоны одинаков. После этого проверить конкретную запись таким же способом;
2) Убедится, что нет
Могу порекомендовать проверить по списку:
1) Убедится в том, что новая запись действительно публикуется на всех авторитативных серверах домена, после того как ее внесли. Возможно, что сервера остаются рассинхронизированы по какой то причине. Проверить можно просто, указав команде nslookup или dig (в зависимости от OS) тип запроса soa, проверяемый домен и сервер и убедится в том, что серийный номер зоны одинаков. После этого проверить конкретную запись таким же способом;
2) Убедится, что нет
CNAME записи с большим временем жизни TTL, которая «перекрывает» новую запись.И еще одна проверка-вопрос: а серийный номер зоны Вы не забываете увеличивать?
1. Конечно проверяю, nslookup с непосредственно обслуживающего NS-а, и DNS моего домашнего провайдера, реагирует мгновенно.
2. Нет конечно. Обнаружив такую проблему, я специально поигрался, создавая новые A записи и проверяя как реагирует на это регистратор, домашний провайдер и гугл.
3. Серийный номер автоматически увеличивает панель управления при любом изменении.
2. Нет конечно. Обнаружив такую проблему, я специально поигрался, создавая новые A записи и проверяя как реагирует на это регистратор, домашний провайдер и гугл.
3. Серийный номер автоматически увеличивает панель управления при любом изменении.
Ok, Google :) Я думаю, что дело все же здесь нечисто и руки чешутся посмотреть в чем же дело.
И поэтому предлагаю аттракцион невиданной щедрости: сделайте новую запись и опубликуйте здесь полное имя, fqdn. А я скажу в чем точно дело, что именно происходит с точки зрения внешнего наблюдателя.
И поэтому предлагаю аттракцион невиданной щедрости: сделайте новую запись и опубликуйте здесь полное имя, fqdn. А я скажу в чем точно дело, что именно происходит с точки зрения внешнего наблюдателя.
Я не так часто читаю Хабр, чтобы прямо тут делать интерактивный тест… У вас нет своего домена под рукой на поиграться? Бываю онлайн поздно вечером, скайп — как хабраник.
По Вашим словам проблема с Вашим единичным доменом и ждете Вы сутки, чтобы Google Public DNS увидел новые записи в Вашем домене.
Для меня очень странно выступать их адвокатом, но с другими доменами массовых проблем не наблюдается, в том числе и с теми, которыми я управляю.
Соотвественно раз на произвольных доменах проверка Вашего утверждения дает другие результаты, а опубликовать название домена и сделать в нем запись Вы не можете, то будем считать, что Google Public DNS ведет себя корректно, пока не доказано обратное. Ну или что это сильно специальный случай.
Для меня очень странно выступать их адвокатом, но с другими доменами массовых проблем не наблюдается, в том числе и с теми, которыми я управляю.
Соотвественно раз на произвольных доменах проверка Вашего утверждения дает другие результаты, а опубликовать название домена и сделать в нем запись Вы не можете, то будем считать, что Google Public DNS ведет себя корректно, пока не доказано обратное. Ну или что это сильно специальный случай.
google public dns последние 2 года совершенно неадекватно себя ведет с новыми записями или апдейтами.
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…
google public dns последние 2 года совершенно неадекватно себя ведет с новыми записями или апдейтами.
Было бы интересно получить более подробную информацию. По моим тестам, с внесением новых записей на нескольких доменах — их опрос через 8.8.8.8 отрабатывает вполне себе благополучно.
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
В смысле Google Public DNS не видел в этих AS'ках авторитативных серверов или не обслуживал запросы пользователей из них? В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…
Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
> В смысле Google Public DNS не видел в этих AS'ках авторитативных серверов или не обслуживал запросы пользователей из них?
Не обслуживал запросы. Отваливалось по таймауту.
> В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Это было нарушения со стороны монтерев процесса настройки сети. Были поймание на горячем и наказаные. Потом бегали и исправляли…
«Корпорация Добра» совершенно не отвечает на noc@… и другие… Единственный вариант добиться контакта — отправить в блекхол их важные адреса и передача их аплинкам…
> Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
Возможно… Но другие сервера работают без таких приколов…
Не обслуживал запросы. Отваливалось по таймауту.
> В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Это было нарушения со стороны монтерев процесса настройки сети. Были поймание на горячем и наказаные. Потом бегали и исправляли…
«Корпорация Добра» совершенно не отвечает на noc@… и другие… Единственный вариант добиться контакта — отправить в блекхол их важные адреса и передача их аплинкам…
> Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
Возможно… Но другие сервера работают без таких приколов…
Я любил использовать сервера времени от Google — time1.google.com, time2-4
Перейдя на IPv6 резко разлюбил.
IPv6 адреса серверов времени Google не отвечают, ни пинг ни служба времени.
Уже два года.
https://mebsd.com/ipv6-ping-and-traceroute
Перейдя на IPv6 резко разлюбил.
IPv6 адреса серверов времени Google не отвечают, ни пинг ни служба времени.
Уже два года.
https://mebsd.com/ipv6-ping-and-traceroute
Ping
$ ping6 -c 10 -s 56 time1.google.com
PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:32::f
--- time1.google.com ping6 statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
$ ping6 -c 10 -s 56 time2.google.com
PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:34::f
--- time2.google.com ping6 statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
$ ping6 -c 10 -s 56 time3.google.com
PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:36::f
--- time3.google.com ping6 statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
$ ping6 -c 10 -s 56 time4.google.com
PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:38::f
--- time4.google.com ping6 statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
DNS безалаберность Вконтакте и других компаний