The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Крупнейшие DNS-сервисы и серверы прекратят поддержку проблемных реализаций DNS

21.01.2019 13:07

1 февраля ряд DNS-сервисов и производителей DNS-серверов решили провести день корректной обработки запросов EDNS (DNS flag day). В этот же день организация ISC планирует выпустить новый значительный релиз DNS-сервера BIND 9.14, в который будут внесены изменения, нарушающие совместимость резолвера с некоторыми DNS-серверами, на которых используется старое ПО с некорректно реализованной обработкой запросов EDNS.

EDNS определяет механизм расширения размера параметров DNS и позволяет добавлять в протокол новые флаги. Расширенные флаги кодируются в специальных RR-записях, что позволят сохранить обратную совместимость с классическим протоколом DNS (не поддерживающий EDNS сервер может ответить на запрос без учёта дополнительных флагов). EDNS был стандартизирован в 1999 году в форме RFC 2671, а в 2013 году было выпущено обновление спецификации RFC 6891.

Так как в первом варианте спецификации EDNS не были явно описаны некоторые пограничные ситуации, DNS-серверы по разному реагировали на запросы с применением не поддерживаемых на этих серверах расширений EDNS. Утверждённая спецификация предписывает в случае отсутствия поддержки определённых EDNS-флагов отправлять соответствующий DNS-ответ в старом формате, просто отбрасывая флаги EDNS. Некоторые серверы поступали иначе и игнорировали не поддерживаемые запросы, вообще не отправляя ответный пакет.

Около 20 лет назад в DNS-сервере BIND был реализован обходной манёвр ("грязный хак"), позволяющий корректно взаимодействовать с подобными серверами, который впоследствии был воплощён и в других DNS-резолверах. Суть метода в том, что в качестве признака отсутствия поддержки флагов EDNS использовался таймаут - если после отправки запроса с флагами EDNS через определённый промежуток времени не поступал ответ, DNS-сервер считал, что расширенные флаги не поддерживаются и отправлял повторный запрос без флагов EDNS.

Применение обходного манёвра позволяло сохранить взаимодействие с проблемными серверами, но приводило к увеличению задержек из-за повторной отправки пакетов, повышению нагрузки на сеть и неоднозначности при отсутствии ответа из-за сетевых сбоев, а также мешало внедрению основанных на EDNS возможностей, таких как применение DNS Cookies для защиты от DDoS-атак. Добавление обходного манёвра также привело к тому, что некоторые DNS-серверы не уделяли должного внимания соблюдению стандарта и до недавнего времени практиковали игнорирование пакетов с не поддерживаемыми флагами EDNS.

В частности, в резолвере PowerDNS все замечания в области поддержки спецификации будут устранены только в готовящемся выпуске 4.2. При этом в подготовленной в 2017 году версии PowerDNS 4.1 авторитативный сервер уже полностью соответствовал спецификации EDNS, а в ветке 4.0 всплывали лишь отдельные несовместимости, возникающие при определённом стечении обстоятельств и в общем виде не мешающие нормальной работе.

Теперь разработчики DNS-серверов договорились удалить из реализаций DNS-резолверов поддержку упомянутого обходного метода проверки и более не откатываться на старый вариант протокола в случае наступления таймаута. Изменение планируется произвести в выпусках BIND 9.14 (намечен на 1 февраля), Unbound 1.8.4/1.9.0 и PowerDNS Recursor 4.2.0. В Knot Resolver рассматриваемый обходной метод не применялся изначально. К инициативе также подключились компании CloudFlare, Quad 9, Cisco (OpenDNS) и Google, которые планируют удалить поддержку обходного метода проверки на своих публичных DNS-серверах.

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

С практической стороны прекращение поддержки обходной проверки может привести к проблемам при взаимодействии с DNS-серверами, использующими очень старые выпуски PowerDNS. Для тестирования корректности реагирования на запросы с EDNS запущены специальные online-сервисы dnsflagday.net и EDNS Compliance Tester. Так как каждый домен обслуживает как минимум 2 разных DNS-сервера, а переход на новые выпуски Unbound и BIND будет выполняться постепенно, эффект от изменения проявится не сразу, но со временем всё больше и больше DNS-резолверов не сможет взаимодействовать с DNS-серверами, некорректно обрабатывающими EDNS-запросы (игнорирующими без отправки ответного пакета).

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

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Рост атак, связанных с захватом контроля над DNS
  3. OpenNews: Новый этап тестирования DNS поверх HTTPS в Firefox
  4. OpenNews: Анализ перехвата провайдерами транзитного DNS-трафика
  5. OpenNews: Выпуск DNS-сервера KnotDNS 2.7.0
  6. OpenNews: Релиз DNS-сервера Unbound 1.7.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49999-dns
Ключевые слова: dns
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, анон (?), 13:30, 21/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уау, неужели красные шляпы обновят BIND в своих репозиториях.
    Полагаю что опять НЕТ.
    Кстати, кто-нибудь знает откуда пошла эта проблема с необновляемым биндом в RedHat?
     
     
  • 2.2, анонимус (??), 14:00, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > Кстати, кто-нибудь знает откуда пошла эта проблема с необновляемым биндом в RedHat?

    От RedHat, очевидно.

     
  • 2.3, Аноним (3), 14:05, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    просто версия заморожена. все фиксы выпускаются исправно. еще не хватало, чтобы bind после рейза версии не правильно запустился из-за битого конфига. как это уже бывает в самбе и т.д.
     
  • 2.4, Ivan_83 (ok), 14:06, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Его же ISC писали, там куча легаси кода, наверное даже в рэдхате всех тянет блевать при попытке что то бэкпортировать.
     
  • 2.13, нах (?), 15:19, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –10 +/
    > Полагаю что опять НЕТ.

    опять не успел обмазаться свеженьким?

    > Кстати, кто-нибудь знает откуда пошла эта проблема с необновляемым биндом в RedHat?

    оттуда же, откуда вообще понятие стабильного дистрибутива, где не обновляют что не попадя ради любителей свежатинки.

    Если оно тебе не нравится - ты вполне можешь поставить Б-жественную Десяточку - каждую неделю что-нибудь новенькое, и тебя не спрашивает.

     
     
  • 3.26, Anonymously (?), 16:22, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В rhel, или ещё где то, спрашивали хочу ли я обновления получить?
     
     
  • 4.36, нах (?), 17:07, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –6 +/
    конечно.
    хочешь - получаешь, не хочешь - так сидишь. У хомеюзеров б-жественной десяточки такого выбора нет, ну а за юзеров ентер-прайс версий решают ентер-прайс админы.

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

     
  • 2.22, Дмитрий (??), 16:05, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сразу видно чувака не понимающего, как работают такие дистры как редхат. Зачем показывать свою некомпетентность?
     
  • 2.23, Аноним (-), 16:06, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты что-то сказал невнятное, давай еще разок.
     

  • 1.5, Аноним (5), 14:08, 21/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так проблема была в кривых dns серверах или не очень умных фаерволах?
     
     
  • 2.6, Аноним (6), 14:10, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и там и там.
     
  • 2.10, AnonPlus (?), 15:00, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Основная проблема в том, что по стандарту, если серверу приходит запрос с EDNS, сервер должен ответить, мол, ошибка, я такого не умею. Многие серверы в ответ просто молчат, игнорируя такой запрос. Их теперь выкидывают на мороз.
     
     
  • 3.50, h31 (ok), 23:24, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > сервер должен ответить, мол, ошибка, я такого не умею

    <зануда mode="on">Точнее, отправить ответ без учета неподдерживаемых флагов. Это всё-таки разные вещи.</зануда>

     
  • 2.19, КО (?), 16:02, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А так же в проблеме усиления трафика. Забыли ужо, что бывает если DNS сервер непойми кому начинает отвечать всякие глупости.
     
     
  • 3.37, нах (?), 17:09, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    ага, клаудфлерь-то забыла, поверила, ао ммм.

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

     

  • 1.7, Анонимус154 (?), 14:53, 21/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А где-то кроме этого сайта есть пруфы, что Гугл, Cloudflare и прочие вендоры включат на своих рекурсорах принудительную поддержку EDNS?
     
     
  • 2.12, нах (?), 15:16, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –10 +/
    а причем тут - вендоры?

    Принудительно отключать поддержку неправильной обработки ненужно-edns собираются не они (точнее, они собираются это сделать не своими руками), а теплая компашка из разработчиков isc/knot/power/кто там еще - unbound.

    Видимо, кормятся из одной и той же кормушки.

    Иначе совершенно непонятно, зачем им всем и сразу понадобилось ломать то, что работало.

    А так намек понятен - "несите ваши денежки гуглю и клаудфлейр, там ваш днс точно в безопастносте".
    (кстати, напомните мне, прекрасный проект летсдекритп на основании чего подтверждает владение доменом? А, ну да, ну да...)

     
     
  • 3.15, fi (ok), 15:34, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Иначе совершенно непонятно

    ну только такому "спецу" непонятно ))))) - мы уже привыкли.

    А остальные умеют договариватся когда решают общие проблемы.

     
     
  • 4.16, нах (?), 15:35, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    чьи проблемы - гугля и клаудфлери, "проблема", надо понимать, в том что они еще не всех под себя подгребли?

    Ну да, вот договорились и порешали.

     
     
  • 5.27, Аноним (27), 16:43, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, гугль и клаудфлэр же не используют _те_же_самые_днссервера_, что и остальные.
    Заканчивая с грибами
     
     
  • 6.42, Анонимус154 (?), 17:54, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых может и не используют.
    Во-вторых кто сказал, что они завтра выкатят у себя bleeding-edge обновление софта?
     
     
  • 7.43, нах (?), 17:57, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну вообще-то им - пофиг.
    Могут и выкатить, не у них сломается. И, скорее всего таки выкатят, иначе зачем их имена в списке спонсоров dns breaking day?

    Но кто сказал что изменения уже не внесены? Из статьи обратного вовсе не следует.

     
  • 3.25, Ivan_83 (ok), 16:14, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет, в данном случае всё правильно.
    EDNS уже дофига лет, 15 лет назад я его реализовывал у себя в резолвере, а он был ещё до этого.
    То что кто то не осилил правильно написать сервер изначально или поправить его за 15 лет - он ССЗБ.

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

     
     
  • 4.39, нах (?), 17:18, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    проблема в том, что это как раз не их проблема - это проблема их счастливых юзверей, особенно тех, кто поторопится обновляться.

    И кое-кто очень почему-то захотел, чтобы эта проблема у них в одночасье возникла. И, чисто так случайно, эти же кто-то предоставляют прекрасный dns-as-a-service, совпадение, конечно же - совпадение!

    > EDNS нужен был чтобы можно было договорится как заслать большой ответ

    который без dnssec был практически ненужно, для joe average по крайней мере, зато очень пригодился ддосерам.

    Поэтому массхостеры вынуждены были понаставить лимит на размер такого пакета. Для внешнего сервера это выглядит именно как таймаут.
    Пострадают, в частности, недостаточно продвинутые обитатели hetzner'а.

    У продвинутых, конечно, edns-udp-size 1432 давно в options, но их единицы. Остальным дан четкий сигнал - переносите-как свои ns'ы к правильным пацанам, а не то они работать перестанут.

     
     
  • 5.44, Ivan_83 (ok), 18:17, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насчёт одночасья - отчасти соглашусь, а может просто у нас об этом не писали.
    С другой стороны - хз сколько таких корявых днс серверов осталось, если 1-5% - то пусть страдают.

    EDNS было нужно и без DNSSec, большие ответы с кучей записей прилетали уже давно, тот же список корневых серверов.

    Я бы не назвал это чотким сигналом, наверняка уже 100500 перепостов инструкций для копи-пасте макак что и где нужно поправить.
    Сделать такое один раз в жизни - не сильно напряжно, я вообще не видел до того чтобы с DNS что то глобально менялось и требовало внимания=телодвижений.

     
     
  • 6.46, пох (?), 19:36, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > EDNS было нужно и без DNSSec, большие ответы с кучей записей прилетали уже давно, тот же список
    > корневых серверов.

    его же не запрашивают с васян-сервера, а корневые как-нибудь уж отдадут. Подозреваю - по tcp (фаллбэк на который никто не отменял)

    > Я бы не назвал это чотким сигналом, наверняка уже 100500 перепостов инструкций для копи-пасте
    > макак что и где нужно поправить.

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

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

    > я вообще не видел до того чтобы с DNS что то глобально менялось и требовало
    > внимания=телодвижений.

    в том и дело. и вот в один прекрасный момент кое-кого это перестало устраивать.
    При том что все работало, и чинить несломанное совершенно не требовалось.


     
  • 5.57, Ordu (ok), 11:43, 25/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > И кое-кто очень почему-то захотел, чтобы эта проблема у них в одночасье возникла. И, чисто так случайно, эти же кто-то предоставляют прекрасный dns-as-a-service, совпадение, конечно же - совпадение!

    =)

    Ребёнок в три года начинает осознавать свои собственные желания и устремления, но ему не так просто оказывается научится различать свои желания и желания родителя. В ситуации когда родитель чего-то хочет от ребёнка, а он не хочет этого делать всё просто: вопросов не возникает где желание родителя, где желания ребёнка. В ситуации, когда родитель что-то запрещает, а ребёнок хочет сделать, тоже ребёнку удаётся без проблем отличить свои желания от желаний родителя. А вот в ситуации, когда родитель говорит ребёнку сделать что-то, что ребёнок и сам не против сделать, иногда начинаются косяки, ребёнку не всегда удаётся верно атрибутировать желание. Родитель говорит "пойдём гулять", и ребёнку вроде хочется пойти гулять, но это же родитель предложил, а значит это желание родителя? Когда родитель запрещает что-то делать, что и так не хочется делать, тоже оказывается сложно понять: кому именно не хочется, ребёнку или родителю? Родители-манипуляторы этим пользуются запрещая ребёнку делать то, что он не хочет, но надо чтобы он сделал.

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

    Так вот я к тому, что твоя позиция мне напомнила психологический кризис трёх лет. Разработчики DNS серверов договорились выпилить уродливый костыль из прошлого, но за инициативой могли стоять ненавистные корпорации с их античеловеческой мотивацией. И тут выявляется когнитивный дефицит, хорошее вдруг оказывается плохим, потому что за хорошим стоит плохая мотивация.

     
     
  • 6.58, нах (?), 15:17, 25/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Разработчики DNS серверов договорились выпилить уродливый костыль из прошлого,

    еще раз: разработчики договорились сломать то, что работало и вовсе не требовало чесать. Проблемы могло вызвать только с лежачими ns'ами - то есть когда у клиента по любому какая-то проблема.

    Причем ни разу не скрывая (не "могут стоять", а перечислены с гордостью на странице рекламы прожекта) кто за этот ужин платил.

    А теперь расскажи мне, с позиции сетевого инженера а не пи...ра, теряющего волю при звуке барабана, чего _хорошего_ для обычного пользователя, или даже для оператора (а не предоставлятеля dns-as-a-service) в этой затее?

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

     
     
  • 7.59, Ordu (ok), 09:01, 27/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А теперь расскажи мне, с позиции сетевого инженера

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

    > разработчики договорились сломать то, что работало и вовсе не требовало чесать.

    Ой, это админский взгляд на вещи. Плевать на админов, их пока ногой не пнёшь, они не пошевелятся. А здесь, как я понимаю, программисты некоторых dns-серверов приняли ту же позу, и 20 лет не шевелились. Ну вот им прилетел живительный пинок, может в будущем они научатся читать rfc и следовать им.

    > Да, у гугля с клаудфларью освободятся ресурсы.

    Мне до этого нет дела. Мне от этого ни тепло, ни холодно. И я не понимаю, зачем ты это упоминаешь многократно. Почему ты многократно упоминаешь это, а не, допустим, E=mc^2? Мне кажется, что E=mc^2 гораздо интереснее.

    > За счет нас с тобой.

    Это как интересно? Я не вижу каким образом я могу от этого пострадать. Пострадают те, кто держит dns-сервера на софте, не уважающим rfc, но это их личные половые трудности.

     
  • 3.41, Анонимус154 (?), 17:53, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так речь про то, что с 1 февраля все сломается.
    От того, что выйдет новая версия софта ровно ничего не произойдёт. Эта версия софта в прод может поехать через год-два-пять-десять. Если 1 февраля принудительно не обновят 1.1.1.1 и 8.8.8.8, то в общем-то ничего не произойдёт.
     
  • 2.14, Andrey Mitrofanov (?), 15:21, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А где-то кроме этого сайта есть пруфы, что Гугл, Cloudflare и прочие
    > вендоры включат на своих рекурсорах принудительную поддержку EDNS?

    Логотипчики на картинке:

    ""A number of DNS software and service providers have announced [...] ""
    --https://www.isc.org/blogs/dns-flag-day/

     
  • 2.24, Ivan_83 (ok), 16:09, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нету никакой принудительной поддержки EDNS!
    Написано же - есть костыль для тех кто без EDNS: им первый запрос идёт с EDNS флагом, если таймаут то запрос повторяется без флага. (Дальше в кеше наверное такие сервера можно было бы помечать как кривые и всегда сразу слать к ним без флага, хз реализовал ли такое кеширование кто то)
    Самому edns уже куча лет, 15 точно есть - я его у себя давным давно реализовывал.
     

  • 1.8, кек (?), 14:56, 21/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    rkn.gov.ru и nalog.ru не проходят проверку :D
     
     
  • 2.11, cat666 (ok), 15:02, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Брехня....
     
  • 2.18, Аноним (18), 15:46, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Только что проверил. Проходят! All Ok!
     
     
  • 3.28, Аноним (28), 16:44, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Оперативно. Позавчера не проходили.
     

  • 1.20, Vadim Deskov (?), 16:03, 21/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Рocкомнaдзор скажет что это кибepaтaка на Россию и активирует план "Cheburnet" - потянет за рубильничек, и злые западные интернеты нас больше не побеспокоят. Придется снова работать на местных васянов за гроши.
     
     
  • 2.30, Аноним (28), 16:44, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Уже нет. РКН принял информацию к сведению и обновился.
     
  • 2.31, Аноним (27), 16:46, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Местных володь?
     

  • 1.29, Аноним (29), 16:44, 21/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Опять заголовок кликбейтный
    Ничего не сломается!
    Будут просто домены на серверах старых которые делегированы резолвиться чуть-чуть дольше и всего делов
    При этом проблема начнёт появляться только когда в дистрибутивах стоящих у провайдеров интернет на резолвере появится новая версия и то не факт, что в ней будет это не включено обратно патчем
     
     
  • 2.32, Аноним (28), 16:46, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Windows Server 2003 и более ранние ресолвиться перестанут.
     
  • 2.34, Ivan_83 (ok), 17:03, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оно уже сейчас дольше резолвится, а после апдейта перестанет.
    Провайдеры слоупоки но даже у них раз в 5-10 лет софт обновляется.
    Патча им никто не даст, а сами они не осилят в большинстве своём, крупняк точно не осилит - у них нет спецов таких, там сплошь обмазанные сертификатами вендоров закрутчики хвостов кошкам, можевельникам и плохому пути.
     
     
  • 3.35, Аноним (35), 17:07, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И типа 8.8.8.8 / 1.1.1.1 и аналогичные перестанут резолвить первого числа такие домены?
     
     
  • 4.40, нах (?), 17:21, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, разумеется, иначе "довольные" клиенты могли сбежать. Сработают закладки, установленные разработчиками во _все_ сервера, включая твой личный - и все перестанут ресолвить.

    Ну кроме тех  у кого rock stable redhat или rock dead debian, наверное - хз когда именно те закладки были внедрены.

    Причем их удивительно единодушно внедрили, казалось бы, совершенно несвязанные команды разработчиков.

     
  • 4.45, Ivan_83 (ok), 18:19, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я брезгую таким пользоваться, разбирайся в этом самостоятельно.
    Я просто подумаю стоит ли мне обновлять unbound у меня на роутерах или оставить ещё на пол годика :)
    А может он уже обновился и я просто не заметил )
     
     
  • 5.47, пох (?), 22:09, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а зачем его обновлять, если это обновление ничерта не исправляет, только ломает?

    Но я вот теперь переход на knot отложу до лучших времен. Потому что продукция сознательных диверсантов нафиг мне не нужна.

     
     
  • 6.48, Sw00p aka Jerom (?), 22:26, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>переход на knot отложу

    а переход с чего? интересно

     
     
  • 7.49, пох (?), 22:33, 21/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    bind99-9.9.9P5
    (нет, в нем нет dnssec, xml, прочего мусора, поэтому и жив по сей день)

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

     
  • 6.55, Ivan_83 (ok), 13:22, 22/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я всё обновляю по мере появления в портах, ибо обновление на n+1 обычно проходит без проблем, а если обновляться раз в пол года или реже то будет n+x обновление много где, и все накопившиеся грабли которые бы вылезали по одному раз в 3-6 недель придётся разгребать разом, плюс грабли из за того что где то может вылезти взаимная зависимость обновляемых пакетов.
     

  • 1.52, DmA (??), 11:40, 22/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а где они взяли unbound 1.8.4 ?
     
  • 1.53, Аноним (53), 11:47, 22/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Помогите исправить ошибки:
    ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed
    docookie=formerr
    optlist=formerr,subnet

    остальное всё ок

     
     
  • 2.54, DmA (??), 12:34, 22/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    update to bind 9.14 :)
    там же можно по ссылке посмотреть технический отчёт(рапорт) и посмотреть подробности
     
     
  • 3.60, Roba (?), 13:57, 28/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    С какого репозитория брать update bind 9.14
    Не могу найти... Стоит 9.10 при команде yum update bind говорит No packages ...
     

  • 1.61, Andrey Mitrofanov (?), 15:14, 04/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > 1 февраля ряд DNS-сервисов и производителей DNS-серверов решили
    > EDNS определяет механизм расширения размера некоторых параметров DNS и позволяет добавлять
    > Около 20 лет назад в DNS-сервере BIND был реализован обходной манёвр ("грязный
    > Проблемы после отмены обходной проверки также могут возникнуть из-за блокирования расширенных

    Ээээ....   Шатдауна интернетов не случилось, я ничего не пропустил?

    Где "кровавые" #Истории Успеха-то?

    "" Больше трупов, Наталья! ""

    Где эксперт из сискоу.рф, пусть бросает всё (комментрарии про госдуму и фсб) и доложится по результатам.  //ну, или кто тут на хабрабр ходит -- чем там-то "закончилось"?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру