По Вашим словам проблема с Вашим единичным доменом и ждете Вы сутки, чтобы Google Public DNS увидел новые записи в Вашем домене.
Для меня очень странно выступать их адвокатом, но с другими доменами массовых проблем не наблюдается, в том числе и с теми, которыми я управляю.
Соотвественно раз на произвольных доменах проверка Вашего утверждения дает другие результаты, а опубликовать название домена и сделать в нем запись Вы не можете, то будем считать, что Google Public DNS ведет себя корректно, пока не доказано обратное. Ну или что это сильно специальный случай.
Ok, Google :) Я думаю, что дело все же здесь нечисто и руки чешутся посмотреть в чем же дело.
И поэтому предлагаю аттракцион невиданной щедрости: сделайте новую запись и опубликуйте здесь полное имя, fqdn. А я скажу в чем точно дело, что именно происходит с точки зрения внешнего наблюдателя.
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.
Могу порекомендовать проверить по списку:
1) Убедится в том, что новая запись действительно публикуется на всех авторитативных серверах домена, после того как ее внесли. Возможно, что сервера остаются рассинхронизированы по какой то причине. Проверить можно просто, указав команде nslookup или dig (в зависимости от OS) тип запроса soa, проверяемый домен и сервер и убедится в том, что серийный номер зоны одинаков. После этого проверить конкретную запись таким же способом;
2) Убедится, что нет CNAME записи с большим временем жизни TTL, которая «перекрывает» новую запись.
Ну, можно было бы немного и перегрузить :) Статья на один экран всего.
Морально готовлюсь опубликовать в этом году статью про то как работают кеширующие DNS сервисы у нескольких российских классических телекомов, ISP и/или сотовых компаний. Вот там будет больше одной страницы :)
Пользуясь случаем хочу спросить, в чем логика отличия списка NS серверов, которые прописаны у регистратора и опубликованы в зоне com для домена vk.com, от списка NS серверов в зоне vk.com?
Та же история, с вариациями на тему отсутствующих в списке NS записей, прослеживается для доменов vkontakte.ru и vkadre.ru.
Во всех перечисленных доменов у регистраторов присутствует 4 записи, а на авторитативных серверах Вконтакте присутствуют только три записи.
Кстати, а не должен ли vk.com адресоваться к каким-нибудь
ns1.vk.com?
Ведь они как-раз ушли от .RU домена, чтобы обезопаситься от гос.регулирования. А тут вдруг домен vkontakte.ru разделегируют, тогда и vk.com достанется…
Это зависит исключительно от соответствующих технических решений в самой компании. Может быть этот вопрос перестал быть важным, а может быть никто об этом не подумал в ключе зависимости от гос.регулирования.
В этой атаке как правило используются клиенты разных ISP с открытой на весь мир рекурсией, которые в свою очередь как правило (но не обязательно) смотрят в DNS кеши своего оператора связи. Агрегатно генерируется много запросов с рандомными поддоменами атакуемого домена. От каждого единичного клиента при этом полоса всего около 10 qps, В результате эти запросы не могут быть обслужены из локального кеша сервера провайдера и доходят до авторитативных серверов домена. Авторитативные сервера так же не могут служить их из собственного локального кеша и запрашивают свои бэкенды. Нагрузка ложится на SQL бэкенды со всеми вытекающими. А именно: большое количество рекурсивных контекстов у кеширующих серверов на стороне правайдеров, с ухудшением обслуживания своих клиентов и умирающий SQL бэкекнды на стороне авторитативных серверов, обслуживающих домен.
RRL никак не спасает. Атака на вымывание кешей и на перегрузку бэкенда.
Про то, что PowerDNS не лучший DNS, даже его автор понимает. Он обрабатывал до четвертой версии (пока альфа) DNS имена как ASCII строки, что безусловно не является хорошим решением. Как и некоторые другие особенности. Сейчас переписывает.
NSD компилирует, если мне не изменяет память, все данные зон непосредственно в RAM, что перестает работать в некоторых специальных случаях, когда зоны слишком большие и не помещаются в RAM.
Knot — да, перспективный, но пока почти не представлен в серьезных инсталляциях, хотя тут я могу и ошибаться.
Неустар именно выстукает как DNS хостер, в частности занимаясь хостингом клиентских доменов.
По поводу CloudFlare могу сказать, что по внешним признакам решение тоже далеко не идеальное и что они также плохо переваривают Water Chinese Turtle. Недавно наблюдал как там был размещен китайский домен блога по высоким технологиям и другие трудящиеся из Поднебесной его вывели из обслуживания такой атакой, которая пролилась на CloudFlare. Но к их чести (CloudFlare) это коснулось только этого конкретного домена.
Если рассматривать детали — тогда стоит упомянуть о том, что AXFR в нормально реализованных авторитативных DNS серверах это только первичный трансфер зоны. Дальше как правило используется IXFR. Косяков хватает везде и том же в PowerDNS сейчас открыто 309 тикетов, конечно не все явные ошибки, но все же.
По поводу сложностей репликации СУБД — каждая команда разработчиков ищет свое решение, подходящее именно им. Тот же Neustar, одна и самых известных компаний в области DNS хостинга, обслуживающая в том числе домены .biz, .us и .co, использует БД Oracle с репликацией. И они не одни такие.
Сложность реализации и возможное большее теоретическое наличие косяков в алгоритмах или конкретном ПО является лишь одним из факторов, которые принимаются во внимание при разработке. Иногда функциональные преимущества, скорость разработки или др. факторы оцениваются как более важные.
Спасибо за ответ. Если можно, еще спрошу:
1) Реализована ли у вас версионность данных в зоне?
2) Журналируете ли вы запросы?
3) Будет ли доступна клиентам статистика по обращению к их зонам, в виде кол-ва запросов за отчетный период и/или графики и пр.?
Подозреваю, что это тянет еще на несколько статей…
Подозреваю, что речь идет про то, что обновление появится в БД через несколько секунд (сейчас пока зон и данных в них мало, как и количество реплик базы). А через какое время их увидит PowerDNS? Вы после обновления БД принудительно сбрасываете кеш PowerDNS?
Дьявол, как известно, прячется в деталях. Несомненно, схема с бэкэндом в виде реляционной базы удобна в реализации. Но именно реляционная база может стать (и станет, если кому то захочется завалить ваш сервис) узким местом в эксплуатации, в силу того, что она не способна предложить высокий уровень производительности, достаточный для абсорбирования атак типа Water Chinese Turtle, когда запросы не укладываются в кеш и доходят до БД. Вы наверняка найдете решение, но вот будет ли оно оптимальным или потянет за собой много оборудования в виде бесчисленных реплик БД? Как большая компания вы наверняка сможете это себе позволить (много оборудования) с точки зрения расходов. Но правильно ли архитектурное решение?
Коллеги, было бы интересно, если бы вы рассказали как у вас реализована защита от атак:
1) DNS Amplification;
2) Water Chinese Turtle.
Первая — когда ваш сервис используют в качестве усилителя, когда недобросовестный пользователь например делает много «A» записей на одно имя или большие, до 4к, «TXT» записи. А потом запрашивает от имени IP адреса атакуемой жертвы эти имена.
Вторая когда идет атака на ваш бэкенд (базу), с помощью большого потока запросов с рандомными поддоменами, исключая таким образом внутренний кеш PowerDNS из обработки, так как данные запросы им обслужить не могут.
О да, трудно не согласится.
На этому тему тоже есть специальное ПО, которое этот головняк практически снимает. Но, к несчастью, с очень внушительной ценой.
Мне приходилось TE делать на оборудовании, которое не может заглянуть в IP заголовки внутри EoMPLS, чтобы сделать hash на основе src-dst ip и распределить трафик между равнозначными линками. А раз TE появился, несмотря на то, что был ненужен — с ним появились и прочие его прелести, чтобы зря не пропадал.
Для меня очень странно выступать их адвокатом, но с другими доменами массовых проблем не наблюдается, в том числе и с теми, которыми я управляю.
Соотвественно раз на произвольных доменах проверка Вашего утверждения дает другие результаты, а опубликовать название домена и сделать в нем запись Вы не можете, то будем считать, что Google Public DNS ведет себя корректно, пока не доказано обратное. Ну или что это сильно специальный случай.
И поэтому предлагаю аттракцион невиданной щедрости: сделайте новую запись и опубликуйте здесь полное имя, fqdn. А я скажу в чем точно дело, что именно происходит с точки зрения внешнего наблюдателя.
Было бы интересно получить более подробную информацию. По моим тестам, с внесением новых записей на нескольких доменах — их опрос через 8.8.8.8 отрабатывает вполне себе благополучно.
В смысле Google Public DNS не видел в этих AS'ках авторитативных серверов или не обслуживал запросы пользователей из них? В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
Могу порекомендовать проверить по списку:
1) Убедится в том, что новая запись действительно публикуется на всех авторитативных серверах домена, после того как ее внесли. Возможно, что сервера остаются рассинхронизированы по какой то причине. Проверить можно просто, указав команде nslookup или dig (в зависимости от OS) тип запроса soa, проверяемый домен и сервер и убедится в том, что серийный номер зоны одинаков. После этого проверить конкретную запись таким же способом;
2) Убедится, что нет
CNAMEзаписи с большим временем жизни TTL, которая «перекрывает» новую запись.Морально готовлюсь опубликовать в этом году статью про
то как работаюткеширующие DNS сервисы у нескольких российских классических телекомов, ISP и/или сотовых компаний. Вот там будет больше одной страницы :)Возможно в этом и есть какая то логика — но я ее не вижу.
Та же история, с вариациями на тему отсутствующих в списке NS записей, прослеживается для доменов vkontakte.ru и vkadre.ru.
Во всех перечисленных доменов у регистраторов присутствует 4 записи, а на авторитативных серверах Вконтакте присутствуют только три записи.
Это зависит исключительно от соответствующих технических решений в самой компании. Может быть этот вопрос перестал быть важным, а может быть никто об этом не подумал в ключе зависимости от гос.регулирования.
RRL никак не спасает. Атака на вымывание кешей и на перегрузку бэкенда.
NSD компилирует, если мне не изменяет память, все данные зон непосредственно в RAM, что перестает работать в некоторых специальных случаях, когда зоны слишком большие и не помещаются в RAM.
Knot — да, перспективный, но пока почти не представлен в серьезных инсталляциях, хотя тут я могу и ошибаться.
Неустар именно выстукает как DNS хостер, в частности занимаясь хостингом клиентских доменов.
По поводу CloudFlare могу сказать, что по внешним признакам решение тоже далеко не идеальное и что они также плохо переваривают Water Chinese Turtle. Недавно наблюдал как там был размещен китайский домен блога по высоким технологиям и другие трудящиеся из Поднебесной его вывели из обслуживания такой атакой, которая пролилась на CloudFlare. Но к их чести (CloudFlare) это коснулось только этого конкретного домена.
По поводу сложностей репликации СУБД — каждая команда разработчиков ищет свое решение, подходящее именно им. Тот же Neustar, одна и самых известных компаний в области DNS хостинга, обслуживающая в том числе домены .biz, .us и .co, использует БД Oracle с репликацией. И они не одни такие.
Сложность реализации и возможное большее теоретическое наличие косяков в алгоритмах или конкретном ПО является лишь одним из факторов, которые принимаются во внимание при разработке. Иногда функциональные преимущества, скорость разработки или др. факторы оцениваются как более важные.
1) Реализована ли у вас версионность данных в зоне?
2) Журналируете ли вы запросы?
3) Будет ли доступна клиентам статистика по обращению к их зонам, в виде кол-ва запросов за отчетный период и/или графики и пр.?
Подозреваю, что это тянет еще на несколько статей…
1) DNS Amplification;
2) Water Chinese Turtle.
Первая — когда ваш сервис используют в качестве усилителя, когда недобросовестный пользователь например делает много «A» записей на одно имя или большие, до 4к, «TXT» записи. А потом запрашивает от имени IP адреса атакуемой жертвы эти имена.
Вторая когда идет атака на ваш бэкенд (базу), с помощью большого потока запросов с рандомными поддоменами, исключая таким образом внутренний кеш PowerDNS из обработки, так как данные запросы им обслужить не могут.
О да, трудно не согласится.
На этому тему тоже есть специальное ПО, которое этот головняк практически снимает. Но, к несчастью, с очень внушительной ценой.