Перейти к содержанию

Выбираем DNS


Константин Артурыч

Рекомендуемые сообщения

Завалят спам запросами или не шлют их в таком количестве?

Что есть спам? Спам это ненужные сообщения или запросы.

То есть:

- Cihihen, сколько тебе лет.

- 14.

Через пять минут:

- Cihihen, сколько тебе лет.

- 14.

Еще через пять минут:

- Cihihen, сколько тебе лет.

- 14.

Еще через пять минут:

- Cihihen, сколько тебе лет.

- 14.

 

А чо в этом такого? Может за прошедшие пять минут Cihihen успел повзрослеть...

 

Если в итоге:

, то в чем неправильность?

У каждой DNS записи есть TTL. Неправильность в том, что переспрашивать раньше, чем истек TTL - не по правилам.

  • Согласен 1
Ссылка на комментарий
Поделиться на другие сайты

Линк на правила в студию.

 

Мне как конечному пользователю совершеннейшим образом плевать какие там правила и каким образом днс резолвит адреса. Если он это делает правильно и оперативно - это хорошо.

Изменено пользователем SLASH_id
Ссылка на комментарий
Поделиться на другие сайты

Линк на правила в студию.

http://tools.ietf.org/html/rfc1034

 

Мне как конечному пользователю совершеннейшим образом плевать

Тогда не лезь в обсуждение.

Ссылка на комментарий
Поделиться на другие сайты

Приведите место где указывается что "переспрашивать раньше, чем истек TTL - нельзя".

 

Тогда не лезь в обсуждение.

А что еще мне не делать, господин хороший?

Изменено пользователем SLASH_id
Ссылка на комментарий
Поделиться на другие сайты

Что есть спам?
Спасибо, Кэп!

Но вопрос был не про спам.

У каждой DNS записи есть TTL. Неправильность в том, что переспрашивать раньше, чем истек TTL - не по правилам.

Где можно увидеть правила и кто их установил?

 

 

Смысл поля TTL является ограничение по времени, как долго запись может храниться в кэше.

После этого запись удаляется.

 

Теперь мы имеем Google DNS, который кеширует очень много информации, и даже сам обновляет кеши, когда TTL истекает, а не вытирает запись из кеша, как это делают все другие DNS серверы. Он не делает отсылок, он сразу возвращает ответ. habrahabr.

 

А чо

М-да

Изменено пользователем Cihihen
Ссылка на комментарий
Поделиться на другие сайты

Приведите место где указывается что "переспрашивать раньше, чем истек TTL - нельзя".

Вы статью прочли и ничего в ней не поняли, да? ;)

 

А что еще мне не делать, господин хороший?

Можете даже прекратить жить - "мне совершеннейшим образом плевать" :D

 

Но вопрос был не про спам.

А про что?

 

Где можно увидеть правила и кто их установил?

А для кого была дана эта ссылка?

 

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

Не заслуживающий доверия ответ:)

 

М-да

Чо "м-да"?

Ссылка на комментарий
Поделиться на другие сайты

Вы статью прочли и ничего в ней не поняли, да?

Уточните где написано, что что переспрашивать раньше, чем истек TTL - не по правилам.

А про что?

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

Будут ли такие запросы спамом? За спам в США есть ответственность, и вроде даже уголовная.

А для кого была дана эта ссылка?

Не нахожу там запрета переспрашивать раньше, чем истек TTL.

Ссылка на комментарий
Поделиться на другие сайты

Уточните где написано, что что переспрашивать раньше, чем истек TTL - не по правилам.

Прямого запрета - нет и если бы не было TTL, то такое поведение было бы вполне нормальным.

Но TTL как раз для того и придуман, чтобы не было ЛИШНИХ запросов. Спросил, и на время указанное в TTL закэшировал. То есть, пока TTL не истек - не переспрашиваем.

 

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

Будут ли такие запросы спамом? За спам в США есть ответственность, и вроде даже уголовная.

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

 

Не нахожу там запрета переспрашивать раньше, чем истек TTL.

Умному было бы достаточно того, что вообще есть такая настройка как TTL, за которую отвечает администратор посещаемого вами сайта. А кому, как не администратору этого сайта, лучше знать, какая настройка правильная? Может гуглу?

 

PS. Учитывая наличие в статье недвусмысленных рекомендаций по настройке TTL ("While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host" + "If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change") - я в растерянности... С умным ли я разговариваю?

 

PPS. Cihihen, сколько вам лет?

Ссылка на комментарий
Поделиться на другие сайты

Прямого запрета - нет

Вас только про это и спросили. В статье, на которую вы дали ссылку, никакого запрета нет, ни прямого, ни косвенного.

Умному было бы достаточно того, что вообще есть такая настройка как TTL, за которую отвечает администратор посещаемого вами сайта. А кому, как не администратору этого сайта, лучше знать, какая настройка правильная? Может гуглу?

К чему это? Вопрос был нарушают правила или нет. Остальное лишь ваше желание показать свои познания про TTL.

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

Prefetching name resolutions

As the Internet grows, there is a limit to the cache hit rate a resolver can reach with regular, passive caching: there are relatively few very popular names, and caching the unpopular ones doesn't help much, since they expire before they are requested again. However, we'd like to be able to serve less popular, less frequently requested names as quickly as we can serve popular names like www.gmail.com. Since it's not acceptable to serve stale or extrapolated results for those names, we also need to ensure that the resolutions are always valid (i.e. have not passed the TTL expiry time).

To accomplish these goals, we are experimenting with aggressively prefetching and refreshing names independently of whether and when users ask for them. There are two major challenges to implementing prefetching properly:

Respecting other nameservers' capacity limits. To ensure that we don't overload other nameservers with prefetch queries, we impose rate limits on our outgoing requests. To ensure that that self-imposed cap on outgoing capacity is not exhausted by rogue traffic, we divide up the QPS-based quota for each of the nameservers into multiple traffic queues and strictly prioritize prefetch traffic over user traffic.

. Учитывая наличие в статье недвусмысленных рекомендаций по настройке TTL
С умным ли я разговариваю?

Разве знание рекомендаций говорит об уме?

PPS. Cihihen, сколько вам лет?

После "чо?" ожидался вопрос про "семки".

Изменено пользователем Cihihen
Ссылка на комментарий
Поделиться на другие сайты

Прямого запрета - нет

Тогда нечего нести чушь что "это не по правилам", ок?

 

Но TTL как раз для того и придуман, чтобы не было ЛИШНИХ запросов.

Придуман? Да. Но можно ли это игнорировать? Можно. Ибо не запрещено.

неправильные настройки DNS серверов, которые без необходимости генерируют ЛИШНИЕ запросы

Как же без необходимости? Сменили А-запись - у народа сайт не открывается. Разве не необходимо как можно быстрее начать резолвить ресурс по новому адресу?

при уже ведущейся атаке на корневые сервера, подобное поведение может усугубить ситуацию

У вас есть данные что на корневые ДНС ведется атака? Последние крупные атаки были кажется в 2002м и 2007м.

Умному было бы достаточно того, что вообще есть такая настройка как TTL

Но эту настройку можно игнорировать. А нужно ли - решать уже тому кто настраивает ДНС.

Учитывая наличие в статье недвусмысленных рекомендаций

рекомендаций. Но не правил.

С умным ли я разговариваю?

Попрошу без перехода на личности.

Ссылка на комментарий
Поделиться на другие сайты

Вас только про это и спросили. В статье, на которую вы дали ссылку, никакого запрета нет, ни прямого, ни косвенного.

К чему это? Вопрос был нарушают правила или нет. Остальное лишь ваше желание показать свои познания про TTL.

А что делать? Если Cihihen в начале топика спрашивает "а как это работает", а к концу топика уже имеет свое абсолютно правильное мнение и еще что-то доказывает:)

 

Prefetching name resolutions

As the Internet grows, there is a limit to the cache hit rate a resolver can reach with regular, passive caching: there are relatively few very popular names, and caching the unpopular ones doesn't help much, since they expire before they are requested again. However, we'd like to be able to serve less popular, less frequently requested names as quickly as we can serve popular names like www.gmail.com. Since it's not acceptable to serve stale or extrapolated results for those names, we also need to ensure that the resolutions are always valid (i.e. have not passed the TTL expiry time).

To accomplish these goals, we are experimenting with aggressively prefetching and refreshing names independently of whether and when users ask for them. There are two major challenges to implementing prefetching properly:

Respecting other nameservers' capacity limits. To ensure that we don't overload other nameservers with prefetch queries, we impose rate limits on our outgoing requests. To ensure that that self-imposed cap on outgoing capacity is not exhausted by rogue traffic, we divide up the QPS-based quota for each of the nameservers into multiple traffic queues and strictly prioritize prefetch traffic over user traffic.

1. Поржал, над приведенным примером:) Это же надо такое придумать - кэширование имен гугла гуглом. Это просто улет - иметь свои собственные DNS сервера, но не настроить между ними обмен данными, так что приходится одними серверами кэшировать информацию с других ;)

2. Поржал над выделенной частью - мы будем генерить больше запросов, чем нужно, но мы будем стараться, чтобы вы не грюкнулись от нашей чрезмерной активности. А так как вы ничего не можете сделать - расслабьтесь и получайте удовольствие...

 

Разве знание рекомендаций говорит об уме?

Нет, не говорит, а вот правильное понимание рекомендаций и следование им - как раз наоборот. Только недалекий человек будет читать рекомендации и при этом делать по своему без очень веской необходимости:) ИМХО, прикрывать горе-админов, которые не уменьшили заранее TTL - это не веская необходимось, да и медвежьи услуги с кэшированием как бы тоже...

 

После "чо?" ожидался вопрос про "семки".

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

 

Тогда нечего нести чушь что "это не по правилам", ок?

Прекращайте нести чушь, что это правильно.

 

Придуман? Да. Но можно ли это игнорировать? Можно. Ибо не запрещено.

Никем не запрещено есть глистов, но будет ли кто-нибудь в своем уме добровольно это делать?

 

Как же без необходимости? Сменили А-запись - у народа сайт не открывается. Разве не необходимо как можно быстрее начать резолвить ресурс по новому адресу?

Я отлично помню описаный вами случай:)

В общем, виноват не DNS провайдера, а кое-кто, кто в своей гениальности не обращает внимание на скучные рекомендации rfc. В частности:

 

У вас есть данные что на корневые ДНС ведется атака? Последние крупные атаки были кажется в 2002м и 2007м.

У меня таких данных нет, а у вас, как я понимаю, есть данные, что таких атак в будущем никогда не будет? :D

Можно ли узнать причину для такой удивительной уверенности?

 

Но эту настройку можно игнорировать. А нужно ли - решать уже тому кто настраивает ДНС.

Да, согласен, можно игнорировать здравый смысл, что вы успешно и делаете...

Сообщение от модератора Mark D. Pearlstone
Прошу без оскорблений жителей иностранных государств.
Изменено пользователем Mark D. Pearlstone
Ссылка на комментарий
Поделиться на другие сайты

А что делать? Если Cihihen в начале топика спрашивает "а как это работает", а к концу топика уже имеет свое абсолютно правильное мнение и еще что-то доказывает:)
Ознакомление с окружающим миром ;) :D :)
Ссылка на комментарий
Поделиться на другие сайты

Гость
Эта тема закрыта для публикации ответов.
  • Похожий контент

    • ska79
      От ska79
      Хочу попробовать сделать на базе старого смартфона свой dns сервер (в локальной сети) как это организовать? В сети ничего не нашёл 
    • TheDart
      От TheDart
      При запуске диспетчера задач вижу такую картину

      Служба узла Dns-клиента грузит 29% CPU
      CollectionLog-2021.04.11-17.02.zip
      Вот логи работы AutoLogger'a
      Чаще всего такая картина связана с программами работающих через интернет (Браузер,онлайн игры)
    • ViM
      От ViM
      Нашел много постов с аналогичной проблемой, прощу помощи 
      Готов предоставить все нужные логи 

      https://forum.kasperskyclub.ru/topic/338960-resheno-dns-servera-vystavljajutsja-sami-127022-iz-za-jetogo-kak-ja-podozrevaju-ne-rabotajut-nekotorye-igry-i-ploho-rabotajut-nekotorye-sajty/
    • ska79
      От ska79
      Правильно ли я понимаю что автоматическое получение dns возможно только если ip адрес тоже выставлен назначатться автоматически?

    • KL FC Bot
      От KL FC Bot
      Группа исследователей из нескольких немецких университетов и институтов обнаружила уязвимость в DNSSEC — наборе расширений протокола DNS, которые предназначены для повышения его безопасности, в первую очередь для противодействия DNS-спуфингу.
      Атака, эксплуатирующая эту уязвимость, которую они назвали KeyTrap, позволяет вывести из строя DNS-сервер, отправив ему единственный вредоносный пакет данных. Рассказываем подробнее об этой атаке.
      Как работает атака KeyTrap и чем она опасна
      Публично об уязвимости в DNSSEC стало известно только сейчас, однако она была обнаружена еще в декабре 2023 года и зарегистрирована как CVE-2023-50387. Ей присвоена оценка 7,5 по шкале CVSS 3.1 и уровень опасности «высокий». Полностью информация об уязвимости и соответствующей атаке пока не обнародована.
      Суть KeyTrap состоит в следующем. Атакующий создает собственный DNS-сервер, отвечающий на запросы кэширующих DNS-серверов (то есть серверов, которые непосредственно обслуживают запросы клиентов) вредоносным пакетом. Далее злоумышленник заставляет кэширующий сервер запросить DNS-запись у вредоносного DNS-сервера, который в ответ отправляет криптографически подписанную вредоносную DNS-запись. При этом подпись выполнена таким образом, что в процессе ее проверки атакуемый DNS-сервер зависает на продолжительное время с загрузкой процессора 100%.
      По словам исследователей, в зависимости от используемого на DNS-сервере ПО, эта атака может с помощью единственного вредоносного пакета заставить сервер зависнуть на срок от 170 секунд до 16 часов. В результате атаки KeyTrap можно не только лишить доступа к веб-контенту всех клиентов, которые пользуются выведенным из строя DNS-сервером, но и помешать работе различных инфраструктурных сервисов, таких как защита от спама, обработка цифровых сертификатов (PKI) и безопасная междоменная маршрутизация (RPKI).
      Сами исследователи называют KeyTrap «самой серьезной из когда-либо обнаруженных атак на DNS-серверы». Интересно, что изъяны в логике проверки подписи, которые делают эту атаку возможной, обнаружены еще в одной из самых ранних версий спецификации DNSSEC, опубликованной в 1999 году. То есть данной уязвимости без малого четверть века.
      Предпосылки для KeyTrap содержатся еще в RFC-2035 — спецификации DNSSEC, опубликованной в 1999 году
       
      Посмотреть статью полностью
×
×
  • Создать...