Comments 235
Главный вопрос: это баг или фича?...
Как минимум, это хорошая головная боль под конец рабочего дня :)
Нет хорошей головной боли ;)
12 ночи. Спасибо
Я как раз в это время поменял записи в днс. Запускаю certbot а он не видит сервак, я давай метаться, что не так сделал. Да нет, все норм, потом смотрю перестали резольвится сайты.У меня аж внутри похолодело. В голову куча разных поисков решений полезло че где сломалось и ваще. "Да чё происходит!" давай метаться, что не так сделал, хотя ничего такого не делал. А по итогу оно вон оно чё >8(
- Я поправил DNS и теперь сайт не открывается...
- Не волнуйся, сейчас все сайты не открываются.
- Все сайты не открываются? Боже, что я наделал!?
"Глаза лопнули" (с)
меня как-то позвали настроить dvb-t2 тк почему-то перестала работать когда стены выравнили гипсокартоном хотя антенна снаружи - крутил-вертел и в окно вылазили да всё нет сигнала и пришлось идти к соседям проверять где также не работало: понедельник иногда день профилактик
Если бы проснувшись не обнаружил кучи новостей то подумал бы что началось)
Да и после рабочего дня, наверное, тоже) Если дома инет нестабилен
А это смотря кому вопрос будет адресован 8(
это кто-то, кто отвечает за всю .ru зону, внес неправильные настройки? интересно, что можно сломать всей стране часть сайтов.
Многие (кто не знал) теперь будут знать, что такое DNS
P.S. С телефона не заходит на эту страницу, так как не было в кеша dns
Жесть, а я тут полчаса пытаюсь понять почему у девушки на ифоне не работают .ru, а у меня работают. Причем смена dns не помогла)
Не мог зайти в озон и ТД, оказалось из-за того что стоял днс от адгуард, убирающий рекламу. Возможно проблема с доступом лишь на иностранных днс. Ибо сейчас у меня все работает на автоматических днс
DNS яндекса чаще возвращают записи без проблем. Зарубежные DNS - возвращают записи через раз или не возвращают вовсе. Также могут быть иные ресолверы, которые возвращают тоже без ошибок или с незначительными перебоями.
Скажите ip днс яндекса
https://dns.yandex.ru/
77.88.8.8 77.88.8.1
77.88.8.8
77.88.8.8
77.88.8.1
Базовый
IPv4 Основной DNS 77.88.8.8
IPv4 Альтернативный DNS 77.88.8.1
Безопасный
IPv4 Основной DNS 77.88.8.88
IPv4 Альтернативный DNS 77.88.8.7
Семейный
IPv4 Основной DNS 77.88.8.2
IPv4 Альтернативный DNS 77.88.8.3
а у Вас гугл не резолвится?)
77.88.8.8 77.88.8.1
больше не возвращают)
Днс и мнгамаркет не открывались, проверял. Щас не знаю. Все Инструменты тоже вверх лапками
Интернет починили) Можно опять смотреть на котиков
Был немало удивлен, что эта авария случилась без участия РКН.
Они уже отчитались, что это происки врагов?
Не они, но минцифры примерно так в телеграме и написали, мол, это все глобальная инфраструктура виновата.
Цитата с сайта Центра:
Специалисты Технического центра Интернет и МСК-IX работают над её устранением. В настоящее время для абонентов НСДИ проблема решена. Идут восстановительные работы.
Мы будем держать вас в курсе ситуации.
Выделенный тест это, наверное, намёк? Типа - своим сделали...
Коммент с просторов интернетов, которые устояли ))
Роскомнадзор не смог отчитаться об успешной блокировке Рунета из-за отсутствия интернета
Они сами у себя наверно ищут ошибки, не могут поверить, что не у них )
Проксики врагов
Сервера *.dns.ripn.net - частично не отвечают
kdig ya.ru @b.dns.ripn.net
;; WARNING: response timeout for 2001:678:16:0:194:85:252:62@53(UDP)
;; WARNING: response timeout for 194.85.252.62@53(UDP)
;; WARNING: response timeout for 2001:678:16:0:194:85:252:62@53(UDP)
;; WARNING: response timeout for 194.85.252.62@53(UDP)
;; WARNING: response timeout for 2001:678:16:0:194:85:252:62@53(UDP)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43363
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 2; ADDITIONAL: 4
;; QUESTION SECTION:
;; ya.ru. IN A
;; AUTHORITY SECTION:
YA.RU. 345600 IN NS ns1.yandex.RU.
YA.RU. 345600 IN NS ns2.yandex.RU.
;; ADDITIONAL SECTION:
ns1.yandex.RU. 345600 IN A 213.180.193.1
ns2.yandex.RU. 345600 IN A 93.158.134.1
ns1.yandex.RU. 345600 IN AAAA 2a02:6b8::1
ns2.yandex.RU. 345600 IN AAAA 2a02:6b8:0:1::1
Именно в этот момент я как раз решил обменять истёкшие сертификаты, и тоже ломал голову, почему для домента на .com сертбот выписал всё без проблем, а для .ru - отказался получить DNS TXT запись.
Тестирование отключения доступа к ru-сайтам из-за рубежа, полагаю, прошло успешно
Я думал dns более отказоустойчив по репликам у провайдеров, а получается его можно просто положить по всей стране. Неужели реплики мгновенно обновляются без верификации?
Потому лучше не пользоваться "национальными" доменами, при возможности.
Почему?
Мое мнение: зонах org\net\com гораздо больше "денег" крутится и к ним относятся существенно более ответственно.
В .ru сегменте же не гнушаются половину интернета зарубить во исполнение предписаний - налицо отношение "на отвали".
@BarsMonsterВам тот же ответ.
Нам жабнули домен в зоне .net за то что поставщик пожаловался что мы взяли его картинки чтобы продавать его товар.
У поставщика наверно были права на торговую марку? В ру точно также отжимают домены через суд.
Подтверждаю, у нас похожее было, тоже жалоба на одну картинку всего и просто сняли с делегирования (им пофиг на правила, видимо боялись штрафов или чего-то). И.. после этого ушли на выходные и 2 дня праздников.
И это был Network Solutions, который к тому времени кому-то перепродали. Благо на твиттере поддержка была активна в выходные и, слава богу, они кого-то нашли и те из дома нас включили назад. Но сама система шокировала.
Network Solutions один из худших регистраторов в этом плане. Один мой друг потерял там купленный за хорошую сумму домен, его просто разделегировали и все.
Evonames, Internet.BS, Porkbun нормальные регистраторы без такого вот.
по крайней мере я стал понимать почему есть регистраторы, у которых домен стоит в несколько раз больше и можно спокойно с кем-то поговорить нормально по телефону и решить вопросы.
Network Solutions далеко не дешевый регистратор и поговорить с ними можно, только из-за их абсолютно тугих правил, которые писались чисто под США толку в этом нет. А вот какой-нить Porkbun имеет весьма приятную поддержку, пусть и не по телефону, но скорее всего с ней не придется сталкиваться вообще. А цены у них одни из самых низких по рынку.
В общем, не от цен зависит.
В нашем случае поддержка работала, но abuse department ушел на 4 дня и ничего официальными путями нельзя было сделать совсем. Я не помню сколько у них стоило, да, по-моему не дешево.
Но я звонил в другое место, где еще дороже, пока мы были в запарках этих. И там с другой стороны человек не спешил и вошел в наши проблемы даже, хотя ничего им не заплатили и даже не обещали.
За такие "советы" по рукам бить мало.
1. Первый - регистратор из Киева, который уже блокировал РФ, а какие великолепные слова писал его владелец на одном из порнушных форумов в адрес всех русских... Потом правда смягчили позицию, и до блокировок старых российских клиентов дело так и не дошло, лишь отключили у себя домены .ru и заблокировали регистрацию из РФ.
2. Второй - регистратор из США (это само по себе риски санкций и пр.), который когда-то был хорошим, но после продажи компании старыми владельцами крупному игроку доменного рынка, стал ничем не лучше других.
3. Третий - тоже из США, но еще и полные неадекваты. Мало того что блокируют домены и даже целые аккаунты по фейковым жалобам от конкурентов, так еще и исполняют все запросы от любого органа любой страны, и из Гондураса и из РФ.
От таких надо держаться подальше.
1, 2 - я не живу в РФ, поэтому не знаю.
Формально Evonames имеет регистрацию на Кипре и они до сих пор реселлят домены через российского ИП. Думаю если бы все было как вы говорите, то этого бы не было.
Internet.bs формально зарегистрирован на Багамах, когда-то считался абузостойким, например, там рутрекер держал домен.
3 - да, из США, держу там много доменов, с блокировками не сталкивался. Правда ничего серого. А вот про запросы интересно, можете привести подробности?
Также хотелось бы услышать ваши рекомендации.
Информация в открытом доступе. Можете сами загуглить, обсуждалось в начале 22-го, там давали ссылку на какой-то форум порнушников, где их CEO или оунер писал.
Я тоже когда то тоже думал что они на Багамах. А потом случайно прочитал как кто то из руководства РКН (в контексте что они послали запрос на блокировку) называл их регистратором из Майами. А это как бы не на Багамах. Думал перепутали. Оказалось им там виднее. Домен тот кстати заблокировали.
Стало любопытно, т.к. сам держал там пару доменов, и вот что нашел.
По Whois отображается как США: https://reports.internic.net/cgi/whois?whois_nic=internet.bs+corp.&type=registrar
В YP адрес компании бьется тоже в США: https://www.yellowpages.com/miami-fl/mip/internet-bs-corp-21291987
Т.е. физически они в US, компания их зарегистрирована тоже в US. И в случае санкций US они точно будут подчиняться законодательству US.
А эту всю конструкцию продали холдингу из UK. С точки зрения санкционных рисков вдвойне более опасно.
Но эти все риски актуальны только для граждан РФ. Если у вас другое гражданство то можно так сильно не заморачиваться.
Наверно не очень корректно такое советовать. Но если очень интересно, можете проверить и сами на себя отправить такую жалобу. Чтобы не нарушать закон, например от имени несуществующего ГондурасКомНадзора или лучше Министерства Правды какой-то несуществуещей страны. И они выполнят его требования.
Универсальных рекомендаций быть не может. Тут каждый сам себе выбирает хостинги и регистраторы под свои модели рисков и под свою ответственность.
Пару лет назад советовал советовал знакомым НеймЧип, а оно вот как все обернулось в марте 22-го.
Для владельцев доменов с паспортом РФ можно советовать выбирать тех, кто из нейтральных стран. Иначе есть риск что либо с одной стороны заблокируют, либо с другой выгонят, либо на уровне санкций отключат.
великолепные слова писал его владелец на одном из порнушных форумов
Весомая характеристика качества хостинга...
А есть такие компании, где вам везде отвечают роботы. И с ними вопрос вообще может быть не реально решить.
(конечно, если это Amazon, то наоборот, можно робота уговорить на хорошие условия)
Нам заблокировали доступ к купленному домену .pro
Просто на сайте увидели упоминание про работу в крыму и решили наложить персональные санкции.
Поддержка Яндекса (днс был у него) подсказала что мы не одни в этот день с такой проблемой и что это связано упоминанием запрещенного слова на сайте.
Nic ру (покупали через него) предложил в замен любой другой домен и бонусы.
Владелец зоны .pro отморозился в поддержке вообще.
Почему?
гугль : 9.5 правил
От косяков не застрахован никто. Ошибки с глобальным импактом могут быть везде, раз в десятилетие: https://socprime.com/blog/what-is-bgp-and-how-its-failure-took-facebook-down/
Абсолютно согласен, но этот вот косяк кажется достаточно большим. Ведь, в теории, после одновления должен был быть тест и он не должен был пройти. Или если бы был peer review.
Ну, скажем для KSK есть офигенно скучные многочасовые церемонии с небольшой кучкой народу, где уже, видимо, не одно поколение мух сдохло от скуки. (Не забываем скачать все Script pdf-ки, чтобы оценить степень занудства)
Для зон чуточку пониже, по идее, что-то очень похожее должно происходить... наверное.
Смотрел на одном дыхании. С экшеном конечно такое себе, но жизненный опыт заставляет ждать подвоха в развитии сюжетной линии. "шаг 10 - дождитесь выполнения шага 9", "шаг 7 - попробуйте открыть ноутбук, шаг 8 - снова попробуте открыть ноутбук, но теперь - потянув за пимпочку слева". А каков бунтарь и вольнодумец в сером джемпере, выкинувший тестовый лист из принтера без соответствующих указаний. Мой вердикт - однозначно, смотреть всем отделом. PS Надеюсь зачтут как просмотр обучающего видео
Эти видео меня всегда забовляют.
Там время от времени один из HSM из эксплуатации выводят. Очень весело смотреть, как дорогущую (и исправную) железку строго по инструкции ломают.
Я в последнее время часто вспоминаю, что одна из базовых национальностей белых американцев — это немцы, по историческим причинам принявшие англ. язык (бритиши тупо раньше приехали). Вот такие вот вещи это прям одна из иллюстраций к этому (: Замечательное видео.
Все церемонии не смотрел. Но приколы случаются
Домены на letsencrypt тоже затронуло.
Я думал dns более отказоустойчив по репликам у провайдеров, а получается его можно просто положить по всей стране. Неужели реплики мгновенно обновляются без верификации?
Гугль : TTL \ кеши DNS
Выглядело как ядерная война :-) В краткосрочной перспективе спас Тор-браузер. И Телеграм.
Во-во. Подумал что неплохо бы прикупить радиоприемник на всякий случай ;)
Подумал что неплохо бы прикупить радиоприемник на всякий случай ;)
Так не поможет. УКВ разве что чего-то скажет, а СВ\ДВ не смогут отражаться , да и они живы ли, маяк тот же на ДВ ?
Вот, радиоприемник нужен вседиапазонный, чтобы СВ/КВ обязательно брал. Вроде Tecsun PL-330 и выше.
Вот, радиоприемник нужен вседиапазонный, чтобы СВ/КВ обязательно брал. Вроде Tecsun PL-330 и выше.
и держать его 24\7 в клетке Фарадея, не забывая раз в год менять рядом лежащий комплект батарей ?
Угроза электромагнитного импульса воздушного ядерного взрыва для современной электроники сильно приувеличина. Сильно!
1) Достаточно радиоприёмник на лампах
2) если ваш карманный транзисторный радиоприёмник сумеет сгореть от электромагнитного импульса, вашему организму достанутся другие эффекты ядерного взрыва, и вам будет не до радиопередач.
Совершенно ничего сложного. Срок хранения качественных батареек - около 5 лет. Клетка Фарадея в данном случае - замотать приёмник в стретч-плёнку, далее чередующиеся слои фольги и плёнки, чем больше слоёв и они толще - тем эффективнее экран. Сам приёмник на хранении должен быть обесточен, т.е. батарейки хранить не в нём, а рядом - потому что обесточенная и запитанная схемы по стойкости к ЭМИ различаются на много порядков. Чтобы испортить обесточенную схему, в ней надо напрямую навести повреждающие токи, а если схема запитана - импульсу достаточно невпопад пооткрывать в ней транзисторы и ее убьёт собственная батарея.
так вот и поможет: если эфир молчит, значит, это ОНО
А я сразу приценилась к рациям на Озоне (он работал у меня).
"Да нету этой вашей .RU-зоны..."
Два американца в русской подводной ядерной лодке. Входит командир:
-Кто положил ботинки на пульт управления?
Все молчат...
-Кто положил ботинки на пульт управления?!
Тишина....
-Кто положил ботинки на пульт управления?!!
Опять все молчат...
Американец говорит: "Какой у вас тут беспорядок!!! вот у нас в Америке...."
-Да нету вашей Америки... Кто положил ботинки на пульт управления?!!!!!
Объясните, как проверить, починили или нет?
Например так
ya.ru открыть. Или тут посмотреть: https://dnssec-analyzer.verisignlabs.com/ya.ru
UPD: Да. Подождать, 0.5-1мин для прогрузки теста
Способов, кроме как сидеть и резольвить до посинения я не знаю..
> dig @1.1.1.1 ya.ru
Можно добавить в hosts-файл: 212.193.111.1 whois.tcinet.ru
И затем при помощи whois-запросов к доменам *.ru получать IP их авторитетных NS-ок и, при условии, что там есть клеевые записи, отправлять запросы адресных записей искомого домена напрямую к его авторитетным NS. Несколько сайтов так себе «поднял».
К примеру, очень хотелось глянуть, насколько просел трафик MSK-IX
195.208.22.33 msk-ix.ru www.msk-ix.ru
Однако, там график в момент аварии перестал рисоваться, видимо, тоже в бэкенде использует DNS-запросы к зоне ru.
Вот прям хорошее время задуматься об альтернативных ДНС ;)
Вот прям хорошее время задуматься об альтернативных ДНС ;)
Какая разница то, если умерла зона ?
google 8888 и Cloudflare 1111 - не отдают ничего в зоне ру
Тоже полез отвечать не читая ссылку, но пересилил себя. Там про децентрализацию ответственности за альтернативные зоны - то есть альтернативную DNS инфраструктуру.
Как ваша система отреагирует, если я создам 100 блоков, начиная с какого-то более раннего (скажем, 50-й от головы), только домены в них зарегаю на свой ключ (имена возьму из существующих блоков)? В биткоине форк с бо́льшим объёмом работы всегда побеждает (в этом смысл блокчейна), а у вас цепь не продлевается, пока кому-то не понадобится новый домен. Если человек запускает новую ноду и получает два конфликтующих форка, какой из них он выберет?
Ноды не откатятся больше, чем на 4 блока назад. Независимо намайнить некий длинный форк невозможно. Разве что с самого нуля для себя любимого :)
Даже 4 блока уже неплохо — можно считать, что домены в последних 4 блоках могут быть захвачены кем угодно, кому не лень помайнить. Хорошо, как быть с новыми нодами, которые не знают «истинную» голову цепи (её на самом деле не существует, если блокчейн не игрушечный — всегда есть ненулевая вероятность параллельной более длинной цепи)? Вот я запустил ноду, она подключилась к каким-то участникам. Злоумышленник запустил сто тыщ нод, которые раздают альтернативную цепь, где последние 100 или 50 блоков отличаются. Моя нода получила два варианта истории, один от старых нод, другой от злоумышленника. Какой из них следует выбрать? Почему?
Независимо намайнить некий длинный форк невозможно
Почему? Кто запретит? Центра же нет, каждый волен создавать блоки с любым предком, лишь бы PoW был верный.
Эти 4 блока обычно пустые. Такая ситуация невозможна.
Короче, я понял, что нет понимания как работает этот блокчейн, и надо писать доку/статью :)
Почему они пустые, если у вас одна транзакция в каждом блоке? Понимание как раз есть, тут всё очень банально: ваш блокчейн не работает. В общем смысле — нет. Это игрушечная система, которая будет прекрасно функционировать в отсутствие мотивированного атакующего, располагающего достаточно скромными ресурсами. Вы пишете, что блоки подписывают предыдущие участники, что будет, если они откажутся? Ведь они за это ничего не получают. Или если они попросту забросят систему. Всё остановится или есть запасной вариант на этот случай? Что будет, если атакующий подкупит этих участников, и они подпишут его альтернативную историю? Система абсолютно не децентрализована, впрочем, PoS и его аналоги заведомо этого не допускают. Всё работает, потому что не популярно и не интересно тем, у кого есть ресурсы на атаку. Но как только вы перейдете дорогу кому-то заинтересованному, всё быстро развалится, поэтому я надеюсь, что от этой вашей системы не будет зависеть ничего важного. А поиграть в безопасность, иммутабельность и нецензурность не вредно, если понимать, что это просто игра.
у вас одна транзакция в каждом блоке
Нет
Ну хорошо, какой смысл откатывать 4 пустых блока? Зачем вообще такой откат нужен, если он ничего не меняет? Выглядит как cargo cult (хехе), ведь у биткоина так сделали, значит, нам тоже надо, а понимания нет. К слову, у биткоина глубина реорга не ограничена вообще никак. Если вы предоставите форк с большим объемом работы, он будет принят безоговорочно, даже если он откатывает всё до генезиса. И это абсолютно верный алгоритм. Если система децентрализована на самом деле, у неё не может быть каких-то точно-настоящих-форков, которые фиксируются чекпоинтами от разработчиков. У биткоина есть отметки блоков, которые считаются заведомо верными (это оптимизация), но если нода получит конфликтующий форк, она его честно проверит и примет, если он удовлетворяет правилам.
Лайк за AGPLv3
Докладываю из Казахстана: не работают Ozon, Wildberries, Avito.
В топе Хабра ("читают сейчас") висит статья "DNSSec: Что такое и зачем" от 2011 года XD
А мне в начале показалось, что это следствие отключения LTE в Ленинградской, Псковской и т.д.
из-за границы все работает
из-за границы все работает
Пока у вашего локального провайдера не умрет кеш.
google 8888 и Cloudflare 1111 - не отдают ничего в зоне ру
тогда что, у всех провайдеров рф одновременно протух кэш?
тогда что, у всех провайдеров рф одновременно протух кэш?
Он обычно задается, и обычно 3600 секунд.
Average TTL: 6468
Median TTL: 300
“For registry operators”: Longer TTLs (around 1 hour) to allow public registration of domains.
https://www.varonis.com/blog/dns-ttl#choose
Не одновременно, а в течении 5-20 минут. Это достаточно быстро но не одновременно. А так кеш записей от 10 минут до 2х часлв.
А так кеш записей от 10 минут до 2х часлв.
DNS TTL values may vary from 0 seconds to 248555 days (2^31 -1 seconds
The highest possible DNS TTL value is 604800 (7 days). While technically there is no maximum DNS TTL setting, values over 7 days will be rounded
Recommendation: For most users, a maximum DNS TTL setting of 86400 (24 hours) is a good choice.
Если подумать то это фигня какая-то. Провайдерские(и вообще крупные) DNS, ИМХО, должны бы работать в каком-то особом кэширующем режиме, не удаляя записи по TTL, а только обновляя их при запросе, а коли апстрим сдох - отдавая кэш... Конечно что целая доменная зона накроется никто не предполагал, но всё же...
Он честно держался около часа (типичный TTL) - проблемы у абонентов начались массово как раз около 19:40 (через час).
Только на ХыХу залез работу сменить, а тут все поломалось. Даже с начала испугался, что это я поломал. :)
У меня все открывается, мб из-за dnscrypt-proxy, а мб из-за того что все в кэше.
Опять "заблочили 127.0.0.1"?
Среагировало Минцифры https://t.me/mintsifry/2114
❗В ближайшее время доступ к сайтам в зоне .RU будет восстановлен
Возникла техническая проблема, затронувшая зону .RU, связанная с глобальной инфраструктурой DNSSEC*. Специалисты Технического центра Интернет и МСК-IX работают над её устранением.
В настоящее время для абонентов Национальной системы доменных имен проблема решена. Идут восстановительные работы. Мы будем держать вас в курсе ситуации.
*DNSSEC — это набор расширений протокола DNS, благодаря которому гарантируется целостность и достоверность данных
@mintsifry
Вот видите, "Координационный центр национального домена сети Интернет" не при чем, глобальная инфраструктура DNSSEC сломалась сама по себе ))
s/!
как так? Они же запрещали телеграм, как угрозу хуже бен ладена. теперь сами в нем новости пишут?
запрещали, потом перестали.
Вот такие они "непостоянные".
И довольно давно. Одно другому абсолютно не мешает.
Еще помнится, как-то давно они запрещали LinkedIn а потом сами же там сотрудников искали.
Вот и думай, что такого страшного накопали на Дурова, что он молча пускает их к себе на "почитать".
Меня хрен кто переубедит, что те, кто так яро запрещал телегу, просто так и без причины, следуя трендам спустя время сами стали лезть в телегу, создавать там каналы и аккаунты различных властных структур и отдельных чиновников, вдобавок рекламируя ту же самую телегу в подконтрольных СМИ. "Не можешь победить - возглавь" и тут сработало?
Ещё непонятен момент, почему все айтишники так полагаются на этот инструмент для оповещений и прочего. Никто ничего не гарантирует, обязательств никаких, но работоспособность инфры уже фактически зависит от работоспособности стороннего мессенджера с закрытыми исходниками сервера. Странная какая-то ситуация.
Ещё непонятен момент, почему все айтишники так полагаются на этот инструмент для оповещений и прочего
Потому что он удобный и работает. И тот факт, что товарищ майор узнает, что у меня на сервере дисковое пространство заканчивается, меня никак не напрягает :) Впрочем, в любом случае вряд ли миф о безопасности Телеги решат разрушить на моём скромном примере, так что сплю спокойно. Если вдруг Телеграм перестанет работать так замечательно, как он это делает сейчас, - никто не мешает за пару часов все оповещения перенаправить в эл. почту (с которой все инструменты работают прекрасно) и потом спокойно искать другую альтернативу.
Безотносительно "накопали" - "они" точно прекращали лезть в телегу?
Почему-то у меня в паямяти, как ржали, что многие госведомства публикуют ссылки на свои ТГ каналы в самый разгар борьбы с ним. Не помню я такого, чтобы эти каналы массово закрывались после начала гонений.
nslookup ya.ru 8.8.8.8
Кажется ожил
"Официальный" ответ - https://cctld.ru/media/news/kc/35564/
Который не везде пока открывается.
Тут со скринами как раз на этот случай.
Последние два параграфа наиболее «интересные». Думаем.
Вроде бы подобные косяки можно сгладить, используя собственный сервер Unbound и настроив на нём serve-expired-ttl на несколько часов. Т.е. использовать устаревшее значение из кеша, если авторитативный сервер не отвечает.
Насколько я помню с тех древних времён, когда первый раз настраивал DNS - ходить напрямую к рут-серверам, если я не магистральный провайдер / крупный хостер, - очень невежливо :) Но таки да, в данной ситуации помогло, даже без этой настройки, а просто добавив в конфиг "domain-insecure: ru."
Как я понял, у вас тоже Unbound. Да и здесь на Хабре была статья про правильную настройку резолвера, как-раз через этот продукт. Так вот, на их же сайте есть ответ на “Why would you want Unbound as a resolver for your home network?". Довольно уважаемая контора, не будут же вредное советовать.
У меня аж два unbound'а в разных датацентрах, почти по-взрослому. И всё равно был настроен форвардинг на публичный ресолвер, т.к. в голове отложилось правило "нечего всякой мелюзге дёргать корневые серверы, они загнутся, если каждый будет напрямую ресолвить" :) Но после сегодняшнего дня я, пожалуй, поменяю своё мнение. Тем паче у использования публичных серверов есть ещё несколько недостатков (скажем, некоторые DNSBL, используемые почтовыми серверами, не отвечают на запросы с публичных DNS).
Почему вы считаете, что ваш unbound настроенный на корневые серверы будет отрабатывать ситуацию с поломанной подписью лучше, чем публичный ресолвер, который был до этого в цепочке?
Потому что в моём unbound, который сам рекурсивно запрашивает DNS-серверы от корневых и далее, я добавил строчку "domain-insecure: ru", тем самым временно отключив DNSSEC для конкретной поломавшейся зоны - и всё заработало, причём даже не пришлось отказываться от DNSSEC для остальных зон. А публичный ресолвер, сталкиваясь с невалидным DNSSEC от корневого сервера зоны, мне в любом случае выдаёт ошибку SERVFAIL, даже если я сам при запросе к нему DNSSEC не использую, - и никакими настройками на своей стороне я на это повлиять не могу.
Да, но это "костыль" или "hot-fix", от которого есть польза если вы реагируете на инциденты быстрее, чем владелец публичного ресолвера.
Ни один владелец публичного ресолвера (кроме серверов НСДИ, на которых натурально тупо отключили DNSSEC вообще), на сегодняшний инцидент не прореагировал, насколько мне известно. Я прореагировал тоже поздновато, но это потому, что сначала пришлось разобраться в ситуации и отказаться от форвардинга. В следующий раз в случае возникновения подобных проблем мне будет достаточно 5 минут и я смогу и себе, и остальным своим пользователям пару лишних часов беспроблемного пользования сетью обеспечить. В целом надо бы и мониторинг unbound настроить, чтобы при возникновении аномального количества ошибок ресолвинга реагировать на это проактивно, а не ждать, пока пользователи сообщат о проблемах.
Вполне возможно, что и прореагировал, просто этот герой нам пока не известен (где-то читал комментарий, сейчас не могу найти, что у Йоты все работало). Но, главное, именно такой инцидент вряд ли повторится второй раз, а если и повториться, на него сможет оперативно отреагировать даже роскомнадзор (или кто там отвечает за устойчивость интернета). А вот в новом придется разбираться заново, и снова тратить несколько часов. Правильно было бы делегировать эти проблемы и их решение своему провайдеру.
Как я тут сегодня неожиданно для себя выяснил, именно такие инциденты с DNSSEC по всему миру повторяются с завидной регулярностью ;)
А своему провайдеру, по крайней мере российскому, делегировать DNS уж точно не хочется по совершенно другим причинам.
А почему невежливо?
У меня уже много лет Unbound на корневые сервера ходит.
В Unbound можно отключить DNSSEC. И все заработает. Достаточно закоментить строчку в конфиге.
auto-trust-anchor-file: "/var/lib/unbound/root.key"
Блин, всё равно не понимаю иерархию.
Мне раньше думалось что раз я могу создать локальный DNS сервер и "скачивать" весь "интернет" себе локально и сидеть себе резолвить, то вся эта штука должна быть не так централизована? Почему извне зайти сложно, есть же разные dns сервера тот же гугл 8.8.8.8 и т.д., они же хранят свои записи. Почему это затронуло вход в .ru домен даже извне и с забугорных dns?
Потому что у скэшированных хоть локальным сервером, хоть гуглом, записей есть TTL, по истечении которого они заново запрашивают их по всей цепочке. И в нашем случае - получают ошибку, которую честно транслируют клиенту.
Да, но если от кеша зависит только домашняя сеть, про бизнес не говорим - устаревшая запись лучше чем вообще никакой. Выше уже намекал на это, есть RFC 8767 Serving Stale Data to Improve DNS Resiliency. Сам вот хочу попробовать, раз такой повод подвернулся.
Да, вот тут описано для unbound. С опцией serve-expired-client-timeout выглядит разумно (использовать протухшие записи только если не достучались до сервера), без неё не очень (в любом случае сразу отдавать протухшие записи и только потом в фоне их обновлять).
P.S. Включил у себя эту настройку и только потом подумал, что в сегодняшней проблеме она бы не помогла. Это сработает при недоступности внешнего сервера, а если он доступен, но выдаёт ошибку (как поступали сторонние ресолверы) или неверные данные (если стучаться к корневому серверу RU самому), - то клиент тоже получит ошибку, а не протухшую запись из кэша.
то вся эта штука должна быть не так централизована? Почему извне зайти сложно, есть же разные dns сервера тот же гугл 8.8.8.8 и т.д., они же хранят свои записи. Почему это затронуло вход в .ru домен даже извне и с забугорных dns?
Она и не централизована - есть корневые \ root сервера, есть 1111 и 8888. Система застрахована от выхода из строя сервера. И более того, система оставалась рабочей час, пока не протухли TTL. Можно поставить TTL 24 часа и больше - и система бы работала.
т.е. 1.1.1.1 и 8.8.8.8 когда я у них запрашиваю ip ресурса, сами запрашивают его у ... у кого?
только не говорите что у dns-сервера в россии. всë так плохо? я понимю что они переодически тоже обновляют записи, но не думал что время хранения записей у 1.1.1.1 и 8.8.8.8 (и другие) такое маленькое.
один из главных вопросов который возник с этой ситуации: данная ситуация может ли в перспективе задеть зарубежные сайты? т.е. вот именно по этой схеме (подчëркиваю, по этой схеме, другие варианты блокировки не рассматриваем сейчас) могут накрыть зарубежные сайты или нет? так что нельзя будет у 1.1.1.1 получить ip google.com например? или 1.1.1.1 запрашивает ip условно у dns-сервера в Америке и такое быть не может? интересуюсь этой темой, но тут возникло ряд новых вопросов.
Вы всё перепутали, нарисуйте уже для себя схемку на бумажке :)
Если 1.1.1.1 или любой другой сервер не в России, и серверы зарубежных зон DNS тоже не в России - то, очевидно, что бы там ни блокировали в России, на возможность получить адрес зарубежного сервера у 1.1.1.1 это никак не может отразиться. А вопрос доступности Вам того же 1.1.1.1, 8.8.8.8 и т.п. (да даже и корневых серверов) в случае их блокировки решается так же, как и обход любых других блокировок.
Т.е. теоретически (маловероятно, но уже зарёкся хоть что-то исключать) могут заблокировать вообще все известные публичные DNS и все корневые серверы и обязать всех пользоваться НСДИ и DNS российских провайдеров. Но покуда у Вас есть работающий VPN для доступа к заблокированным ресурсам - Вам это никаких проблем не доставляет.
спасибо. ну т.е эти упыри хотят отпачковаться от остального мира, с которым они якобы хотят дружить (телевизору мы верим). вы описали думаю схему по которой они будут действовать. также как с созданием сертификатов для сайтов. сначала создать свои dns, потом переводить всех на российские dns (они есть, это понятно, я имею ввиду принуждать к использованию именно их), потом заблочить международные dns. примерно план такой. ждëм когда 8.8.8.8 признают экстремистским ресурсом.
Думается мне, на пути к реализации такого плана лежит немало сюрпризов (и слава Богу). Настройки DNS гвоздями приколочены в массе железок, многие из которых просто работают годами и к ним уже не то, что пароль администратора забыт, но и где они стоя́т, никто не вспомнит. И железки эти обеспечивают работу не только граждан и бизнеса, чьи проблемы мало кого волнуют, но и госорганов и прочих стратегических структур. А простой перехват всех запросов на 53 порт с перенаправлением на правильный сервер как раз из-за DNSSEC и не всегда сработает.
Время жизни определяется для каждого домена при настройке самого домена. Можете поставить долгое, но при переезде/обновлении вы, внезапно, будете иметь долгий период неработоспособности, пока кэши не протухнут. Угадайте что выбирают администраторы, у которых изменения в домене случаются всё-таки чаще падения целой зоны?
Есть корневая зона — точка. Её обслуживает ICANN. В ней есть NS-записи, соответствующие доменам первого уровня — ru., net., com., ai. и так далее. Эти зоны обслуживаются NS-ками других организаций, а в корневых есть записи, которые обеспечивают делегирование. И так далее, условный habr.com. — уже домен второго уровня, в нём тоже можно как делегировать поддомены на другие NS-ки, так и просто создать ресурсные записи. Видео и статей на данную тему — масса.
Вопрос знатокам, а мне на своём DNS-сервере обслуживающим один домен надо, что-то делать?
мне в 18:26 сегодня первые ошибки по резолвингу начали приходить
ещë только частично почитал комментарии, ещë почитаю. меня сегодняшняя штука озадачила. то что это российсие службы виноваты - понятно, то что снова что-то ломают - понятно. вопросов нет. интересно что и как.
озадачило меня то что 1.1.1.1 и 8.8.8.8 не возращали ip например mail.ru. надо видиму хорошо почитать про dnssec, так как я не понял как так? я думал оттуда (1.1.1.1 и 8.8.8.8) ответ полюбому придëт если 1) запись на них не удалена 2) dns-трафик не заблокирован по пути.
если кто напишет статейку-разбор ситуации будет круто!
1.1.1.1, после того, как TTL предыдущей записи для mail.ru истекло, заново постучался на корневой сервер зоны .ru, чтобы тот отдал ему адрес авторитативного сервера для mail.ru (а тот уже адрес mail.ru). И получил ответ с неверной подписью. После чего 1.1.1.1 клиентам начал возвращать ошибку. Всё как и задумано.
не думал что у них такой маленький срок хранения, выходит они лишь посредники. я думал они непосредственно хранят записи и лишь переодически их обновляют. а напрямую обратиться к "корневому серверу" "простой смертный" не может? верно прдполагаю?
Может, если свой DNS-сервер поднять. Я вот сегодня на своём DNS (он уже был, но раньше там был форвардинг на публичный ресолвер) так и сделал. Но это считается не очень хорошей практикой. Нечего грузить корневые серверы попусту, да и своему серверу усложнять работу рекурсивными запросами по всей цепочке.
Если бы TTL был больше - процесс переезда на новый IP и вообще любой смены конфигурации в DNS (для той же почты это MX, SPF, DKIM, для получения сертификатов и подтверждения владения доменом - разные записи TXT и т.п.) был бы неприемлемо длительным.
А можно как-то узнать какой TTL у конкретного DNS сервера? Потому что у меня на билайне (провод и lte) всё работало когда у остальных сбоило. И с другой стороны: например изменений A-записи домена у меня не видно дольше, чем у других. DNS провайдерские.
Конечно, можно: dig +ttlunits @nameserver_ip hostname
Но если в сегодняшней ситуации у кого-то работало - скорее всего, дело не в TTL, а в том, что их админы вовремя подсуетились и отключили DNSSEC до устранения проблемы (ну или DNSSEC там вообще не был включен, тогда это им жирный минус, а не плюс).
Почему минус?
Между клиентом и провайдером нет dnssec, и нет шифрования dns трафика. Доверять такому ответу нужно с той же степенью, что и ответу провайдера у которого отключен dnssec.
Единственно правильный вариант - иметь свой рекурсор локально, на каждом компе. В идеале, системная функция ОС должна обеспечивать рекурсивную функцию.
DNSSEC между пользователем и DNS-сервером провайдера - это один вопрос, а между DNS-сервером провайдера и корневыми/авторатитивными серверами - другой. Отключая второе, провайдер передаёт своим пользователям потенциально недостоверные данные.
А насчёт рекурсивного ресолвера на каждом компе... думаю, корневые серверы и серверы TLD от такого решения загнутся сразу, серверы всех более или менее популярных доменов - чуть погодя :) Из-за этого и появились провайдерские, а затем и публичные DNS, чтобы добавить ещё один уровень кэширования, снижающий нагрузку на всю систему DNS.
Провайдерские, публичные? Вы путаете причину и следствие. Какое дело Гуглу до нагрузки на корни? Они решают свои задачи.
Мы просто катимся по инерции. Инерции устаревшей архитектуры интернета и местами пересечения с потребностями Энтерпрайза где нужен был шлюз который бы обслуживал как внутренние зоны так и пересылал запросы на улицу. Производительность здесь вообще не причём. Её успешно может решить хотя бы тот же any cast dns. Сейчас в большей степени это используют Гугл и подобные ему сервисы, но никто не запрещает делать тоже самое и авторитативным серверам.
Гугл-то по-любому справится, а вот тот же накосячивший вчера администратор зоны RU - уже не факт, по крайней мере уж точно не оперативно. А сколько всего таких серверов, обслуживающих TLD и отдельные домены, на которые Вы предлагаете нагрузку увеличить на несколько порядков? Если бы система изначально строилась по-другому, всё возможно. Но если сейчас, скажем, с очередными апдейтами винды, андроида, макоси и иоси заставить их все по умолчанию делать самостоятельный ресолвинг - начнётся такой армагеддон, что вчерашний день на его фоне покажется эталоном стабильной работы интернета :)
может есть ссылка на вменяему инструкцию как это делать? мне даже просто интересно попробовать, посмотреть. сейчас попробовал. полный мрак. инструкции в инете все поверхностные, многие устаревшие и нерабочии.
sudo apt install bind9
man bind9Если это выглядит непонятными заклинаниями, то не нужно оно вам. Начинать развлекаться с сетевой магией лучше с чего-то другого. ВПН вон себе поднимите и настройте личный, например. Прямо обычный OpenVPN по полноценной инструкции без магических скриптов.
Берите официальную документацию unbound и делайте, всё понятно разжёвано и уж точно актуально. Можно ещё bind, но в качестве ресолвера, IMHO, unbound проще.
и. я думал они непосредственно хранят записи и лишь переодически их обновляют.
Они их и хранят. В соответствие с TTL. 1 час. И периодически их обновляют - по мере прихода запроса по истечению TTL
Могли бы пояснить почему DNSKEY раздваивается?
Любопытно, что сервера гугла, отвечающие за изображения аватарок на Youtube стали доступны временно. Началось это после предыдущей "попытки блокировки", пару дней назад, кажется.
Роском тестирует что-то новое?
что вообще эти упыри делали? что они делали что сломали именно ru зону?
В связи с этим, обращение к сайтам, размещенным в зоне .ru, может быть затруднено.
За такие формулировки хочется в лицо плюнуть
Реакция ЦМУ ССОП: "подключайтесь к скрепным DNS и отключайте DNSSEC".
Работаю в техподе провайдера. Завтра первый рабочий день спустя 2 выходных. Надо закупаться сигаретами.
Отец знакомого работает в Интернете.
Сегодня срочно вызвали на совещание. Вернулся поздно и ничего не объяснил. Сказал лишь сохранять мемы и бежать в магазин за флешками для скачанных сайтов.
Сейчас дозваниваемся куда-то далеко за город по диалап-модему. Не знаю что происходит, но мне кажется началось..
пятница после четырнадцати - пора начинать улучшать сеть
.RU домены ресолвятся с ошибками — имеются проблемы с DNSSEC