Не добрый день, коллеги по цеху. В текущий момент наблюдается недоступность DNS-серверов, отвечающих за зону ntp.org. С серверами pool.ntp.org синхронизируются миллиарды устройств по всему миру и теперь они испытывают проблему в получении точного времени.

UPD. В связи с тем, что многие комментаторы не читают полностью, напишу здесь краткую суть проблемы: для .RU не очищаются Glue Records при изменении делегирования домена. Как минимум, для доменов, управляемых через Ru-Center и Reg.ru. Сама статья — это «история из жизни» о том, какие проблемы может вызвать такая «особенность» зоны .RU, как они были диагностированы и решены.

---

«Один мой друг» (с) рассказал историю про свои приключения с DNS.

Предыстория

Представьте, что заканчивается 2016 год, на ваших DNS серверах есть несколько сотен доменов, давным давно запущено штук 5 мощных DNS серверов в разных датацентрах, вы хотите наконец-таки избавиться от старых DNS серверов, которые последнее время просто тянут деньги на аренду и занимают место в стойке. Однако, сразу после попытки их отключения, телефоны поддержки раскаляются докрасна, поэтому старые сервера приходится быстро включить и вдумчиво разбираться в ситуации.

Глава 1

Еще раз проверяем DNS зоны, убеждаемся, что нигде нет старых адресов и очень давно. Проверяем из разных регионов запросами на каждый из своих NS. Везде всё отдаётся правильно. Берем tcpdump и смотрим запросы на 53 порт на старыx DNS. Оказывается, что запросов к ним удивительно много. И это при том, что IP адреса этих серверов уже много месяцев нигде не фигурируют!

A Thief on the Run by Manweri

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств (подробнее в нашей статье DMARC: защитите вашу рассылку от подделок). На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.

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

Итак, задача: необходимо поднять окружение разработчика для одновременной работы с несколькими веб-проектами висящими на доменах вида example.app. При этом данные домены должны быть доступны из контейнеров, с хоста, а также, например, из эмулятора Genymotion. Кроме того, из контейнеров должен быть доступен и внешний интернет. Все это усугубляется корпоративным Intranet со своим внутренним DNS сервером.

Данные о новой атаке появились из блога пользователя с ником Unixfreakjp. В его публикации идет речь о новом, более мощном, чем Mirai, ботнете интернета вещей. Ему удалось заразить около 3500 устройств в срок за пять дней. На сегодня эта атака стала самой «удачной» из подобных за последнее время. Благодаря высокой скорости атаки, количество затронутых бот-клиентов достигло такого уровня с момента обнаружения загрузочного файла. После атаки на Dyn это происшествие, вероятно, станет только началом грядущих более неприятных событий для всего интернета.

В этой заметке мы раскрываем подробности того, как работает червь и рассказываем, кого подозревают в организации атаки.

Предыстория

Прожорливый Bind9

Пришлось мне пару лет назад покинуть свой родной дом и переехать в другой город. В результате свой самосборный медиа-центр пришлось оставить, а на новом месте купить телеприставку AuraHD Plus. Весьма не плохой девайс за свои деньги, особенно если учесть, что в нем встроены приложения для доступа к сервисам с фильмами и т.п.

Все бы ничего, но реклама там крутится на каждый чих. Пришлось изобретать, как же ее "порезать". Первая мысль была — поднять свой DNS сервер и отправлять все неугодные домены в /dev/null на 127.0.0.1. К этому моменту мой домашний серверок вернулся ко мне и занял свое почетное место на шкафу в качестве NAS сервера.

Сказано — сделано. Поднят Bind9, прописаны конфиги для нескольких доменов, все отлично. Летим.

Что с нами не так

_{Месторасположение найденных заражённых устройств, участвовавших в Mirai. Иллюстрация Imperva Incapsula.}

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

Создание угроз и опасности для информации, против безопасности данных и нормального функционирования сети. Последний пример — произошедшая атака на сайт Dyn, которая задела не только саму компанию-провайдера, но и всех её клиентов. Среди них самые популярные во всей сети платформы и сервисы: Amazon, Twitter, GitHub, Heroku, Netflix, Spotify, Airbnb, Reddit, Etsy, SoundCloud, The New York Times, Starbucks, HBO, CNN, Basecamp, PayPal, Etsy. Этот список далеко не полный. В него попало более чем 75 участников: интернет-платформы новостных ресурсов, финансовых организаций, продавцов услуг, социальных сетей, сайты компаний-разработчиков. Примерные потери приравниваются к $110 000 000 — за одни сутки. Причины атаки никто, пока, достоверно назвать не может, а к расследованию уже присоединились представители ФБР (США). Событие вышло за рамки администрирования, на «федеральный» уровень. Все, кто пострадал, будут восстанавливать репутацию. Стало понятно, что никто не надежен настолько, насколько это казалось ещё недавно.

У меня (как и у многих web-разработчиков) имеется с десяток сайтов которые необходимо где-то размещать (хостить).

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

В то-же время в наличии имеется:

• Домашний сервер на Ubuntu
• Быстрый ethernet-интернет от МТС

Но не имеется ключевого — статического IP. Если бы он был, то все было-бы намного проще и данную статью я бы точно не писал. А выдавать статический IP мой МТС абсолютно не желает (если только я не подключусь как бизнес-клиент).

Разумеется есть всем известные Dynamic DNS сервисы вроде noip.com, но они успешно решают лишь задачу удаленного доступа к нашему серверу (по SSH или FTP), но для хостинга совершенно нам не подходят, поскольку в настройках домена на DNS-сервере нам нужно обязательно прописать A-запись с реальным IP-адресом (а не ссылку на наш виртуальный домен).

Массовая DDoS атака на инфраструктуру крупного провайдера сетевых сервисов Dyn, происходящая в настоящий момент, привела к недоступности множества популярных ресурсов, использующих DNS-сервисы компании. В число пострадавших входят такие известные организации как Github, Twitter, eBay, New York Times, Etsy, SoundCloud, Spotify, Heroku, Shopify, PayPal и множество других.

Согласно заявлению компании Dyn, атака на DNS-инфраструктуру началась 21 октября 2016 года в 11:10 UTC (14:10 по московскому времени). В 13:20 UTC работоспособность была восстановлена. Однако уже в 15:52 UTC началась вторая волна, отразить которую их инженеры не могут до сих пор.

Последняя информация от 21:43 UTC

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

Незащищенные поддомены подвергают вашу деятельность серьезной опасности, а в последнее время произошел целый ряд инцидентов, при которых взломщики воспользовались поддоменами для обхода защиты.

В случае последнего из череды инцидентов весь код сайта Vine можно было загрузить с незащищенного поддомена.

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

По мере того, как наши дети погружаются в современные технологии, им приходится сталкиваться с новыми угрозами, с которыми не всегда способны справиться даже их родители. Запрещать использование интернета ради детской безопасности в нашем мире уже бессмысленно — это неотъемлемая часть нашей реальности. Для примерно 15% подростков в возрасте от 12 до 17 лет интернет стал местом, где они проводят треть жизни. Надо отметить, что подростки не стремятся разделить этот новый опыт с родителями: более половины детей скрывают от родителей свои нежелательные действия в интернете. А раз мы не можем постоянно сопровождать детей в новом для них мире, остается положиться на автоматизированные средства защиты.

Проблема защиты детей от нежелательного контента (речь идет о строгой защите, т.е. не отключаемой в два клика пятилетним ребенком) формирует целый рынок программных решений. В их основе лежат два принципа блокировки ресурсов: фильтр по IP-адресу, исключающий возможность открытия ресурсов с заранее заданными в неком “черном списке” IP или разрешающий доступ только к IP из “белого списка”, а также контентный анализ, позволяющий принимать решение о блокировке доступа на лету в соответствии с содержимым страницы.

В сети любого Интернет-провайдера можно встретить такой обязательный элемент, как кэширующий DNS сервис. А поскольку работа сети Интернет без службы DNS невозможно, серверов таких будет минимум два, с обязательным резервированием и балансировкой. В заметке я постараюсь описать один из вариантов балансировки нагрузки между несколькими кэширующими серверами на основе Cisco IP SLA.

В августе 2015 года компания Cisco Systems закончила покупку компании OpenDNS.

Безусловно, это одна из самых громких и удачных покупок в области информационной безопасности. Для клиентов Cisco – это беспрецедентная возможность очень просто и быстро повысить уровень безопасности всей организации. Добавляем в качестве внешних серверов разрешения доменных имён (DNS) пару айпишников OpenDNS – вот и всё, что надо для начала использования высоконадёжной и, главное, безопасной инфраструктуры фильтрации угроз на базе DNS-запросов.

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com, и получает в ответ 1.2.3.4.

Как известно, система DNS в сети Интернет является одной из ключевых. Без неё невозможно представить современное состояние сети.

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

Например, список DNS ошибок у не требующей представления компании Вконтакте:

Сегодня около 12:50 мск упали все сервисы reg.ru, в том числе dns-серверы. Все сайт, домены которых делегированны reg.ru так же перестали работать.

Новость на roem: roem.ru/21-03-2016/221280/regru-fall

upd: по состоянию на 13:45 мск работа ns-серверов восстановлена. Сайт reg.ru все еще не доступен.

upd2: 13:57 мск сайт reg.ru заработал.

upd3: reg.ru сообщает, что падение было вызвано DDoS-атакой, ссылка на официальную страницу в vk: vk.com/wall-16725543_16800

Добрый день!

В этой статье я опишу настройку авторитетного DNS сервера, на основе решения PowerDNS. PowerDNS — высокопроизводительный, бесплатный DNS сервер с открытым исходным кодом.

PowerDNS — представляет собой высокопроизводительный DNS-сервер, написанный на C++ и лицензируемый под лицензией GPL. Разработка ведётся в рамках поддержки Unix-систем; Windows-системы более не поддерживаются.
Сервер разработан в голландской компании PowerDNS.com Бертом Хубертом и поддерживается сообществом свободного программного обеспечения.
PowerDNS использует гибкую архитектуру хранения/доступа к данным, которая может получать DNS информацию с любого источника данных. Это включает в себя файлы, файлы зон (англ.) BIND, реляционные базы данных или директории LDAP.
PowerDNS по умолчанию настроен на обслуживание запросов из БД.
После выхода версии 2.9.20 программное обеспечение распространяется в виде двух компонентов — (Authoritative) Server (авторитетный DNS) и Recursor (рекурсивный DNS). Официальный сайт: www.powerdns.com

На этой неделе вся доменная индустрия шумела по поводу покупки доменного портфеля MostWantedDomains, который приобрёл ведущий регистратор GoDaddy за неизвестную сумму. В пакет вошли около 70,000 имён старого разлива (без взрослой тематики и без новых зон) с жемчужинами класса 373.com, faculty.com, carauctions.com, ibill.com, bikerentals.com, kitchenchef.com и т.п.



Обе стороны договорились не разглашать условия контракта. Возможно, в будущем, кто-то с соколиным глазом сможет вычислить сумму на чеке с финансовых отчётов. Но кому интересно сегодня, по катом представлено руководство по оценке подобных виртуальных активов с возможными аргументами, которые можно использовать при торгах.

Несмотря на то, что почти повсеместно мы используем доменные имена вместо IP-адресов, инструменты для мониторинга и контроля за сетевым трафиком как правило оперируют IP-адресами. Разрешение имен вообще (и DNS в частности) используется довольно условно.

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

Можно ли иметь актуальную таблицу соответствия имен и адресов для небольших сетей? Какие именно домены запрашивали пользователи и какие получили IP-адреса? С некоторыми оговорками — да.

Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).