The OpenNET Project / Index page

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

ICANN призывает к повсеместному внедрению DNSSEC. Обновление BIND с устранением уязвимостей

24.02.2019 11:14

Организация ICANN, регулирующая вопросы, связанные с IP-адресами и доменными именами в интернете, выступила с инициативой повсеместного перехода на использование DNSSEC для всех доменных имён. ICANN отмечает наличие значительного риска для ключевых частей инфраструктуры DNS, вызванного увеличением числа атак на DNS-серверы и ростом связанной с DNS вредоносной активностью.

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

Для борьбы с участившимися атаками по перенаправлению трафика на уровне изменения параметров DNS организация ICANN выработала список рекомендаций по усилению защиты для регистраторов, владельцев доменов и всех связанных с DNS представителей индустрии. Одной из ключевых рекомендаций является применение DNSSEC для защиты целостности содержимого DNS зон и включение валидации DNSSEC на стороне резолверов. При этом DNSSEC не выполняет шифрование трафика - для обеспечения конфиденциальности и защиты трафика от перехвата следует использовать DoH ("DNS over HTTPS") или DoT ("DNS over TLS").

Также упомянуты такие общие рекомендации, как применение двухфакторой аутентификации для доступа к интерфейсам управления доменами, регулярная и оперативная установка обновлений с устранением уязвимостей, анализ логов на предмет неавторизированного доступа, рецензирование обоснованности предоставления сотрудникам повышенных полномочий (root-доступа), отслеживание истории всех изменений DNS-записей, использование надёжных паролей, исключение передачи паролей в открытом виде и регулярная смена паролей. Для защиты почтовых отправлений рекомендовано использовать DMARC с SPF или DKIM записями.


Дополнительно можно отметить публикацию корректирующих выпусков DNS-сервера BIND 9.11.5-P4 и 9.12.3-P4 c устранением трёх уязвимостей:

  • CVE-2018-5744 может использоваться для вызова отказа в обслуживании через создание условий для исчерпания доступной для процесса named памяти. Проблема вызвана некорректным освобождением памяти при обработке пакетов с определённым сочетанием опций EDNS. В случае если на уровне операционной системы размер выделяемой процессу named памяти не лимитирован, атака может использоваться для исчерпания всей доступной в системе свободной памяти.
  • CVE-2019-6465 - пользователь может запросить и получить содержимое DNS-зоны не имея на это полномочий (без явного разрешения allow-transfer в ACL). Проблема проявляется только для зон DLZ (Dynamically Loadable Zones), доступных на запись.
  • CVE-2018-5745 - возможность инициирования краха (assertion failure) процесса named при указании неподдерживаемого в BIND алгоритма ключей DNSSEC при использовании режима "managed-keys". Уязвимость может быть эксплуатирована только со стороны доверенного DNS-сервера, указанного администратором в настройках в качестве сервера для валидации DNSSEC. Проблема опасна не столько атаками, сколько возможностью непреднамеренного проявления, например, когда BIND на стороне резолвера собран без поддержки устаревших алгоритмов и настроен на использование для валидации DNSSEC сервера, который может использовать один из этих алгоритмов.


  1. Главная ссылка к новости (https://www.mail-archive.com/b...)
  2. OpenNews: Крупнейшие DNS-сервисы и серверы прекратят поддержку проблемных реализаций DNS
  3. OpenNews: Рост атак, связанных с захватом контроля над DNS
  4. OpenNews: Анализ перехвата провайдерами транзитного DNS-трафика
  5. OpenNews: Влияние параметров DNSSEC на производительность DNS серверов
  6. OpenNews: DNSSEC на корневых DNS-серверах будет введён в эксплуатацию 5 мая
Лицензия: CC-BY
Тип: Тема для размышления
Ключевые слова: dnssec, dns, bind
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (84) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, timur.davletshin (ok), 12:01, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    DNS over HTTPS — шляпа. Если нужно шифрование, то только over TLS.
     
     
  • 2.15, Аноним (15), 13:25, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наоборот, если весь трафик будет HTTPS, фильтрануть будет намного сложнее.
     
     
  • 3.17, timur.davletshin (ok), 13:36, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Загугли "DNS over HTTPS criticism".
     
     
  • 4.20, Аноним (20), 14:05, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Загугли "DNS over HTTPS criticism debunked".
     
     
  • 5.23, timur.davletshin (ok), 14:12, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Хорошая попытка, но нет.
     
     
  • 6.53, Аноним (20), 01:36, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ты гуглишь только то, что вписывается в манямирок?
     
     
  • 7.55, Аноним (55), 06:00, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Он просит гуглить других.
     
  • 4.75, Аноним (75), 10:35, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что по поводу DNS over TLS criticism Daniel Stenberg говорит, что все имплеме... текст скрыт, показать
     
  • 3.26, вейланд (?), 15:16, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не мог бы отвечать по теме? Вопрос про шифрование, а не фильтрацию.
     
     
  • 4.56, Аноним (75), 06:11, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Он отвечает по теме. Знаешь какой главный аргумент критики DoH и одобрения DoT у одного из разработчиков DNS Пола Викси? То что он хочет в своей домашней и корпоративной сети иметь возможность блокировать шифрование днс и откатывать юзеров к обычному, потому что он хороший и ему надо верить, он лучше знает и о юзерах заботится. А DoH мешает и вызывает ненависть.
    https://www.theregister.co.uk/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy_f
    https://www.theregister.co.uk/2018/10/30/dns_over_https_controversy/
    https://twitter.com/paulvixie/status/1053765281917661184
    > DoH is an over the top bypass of enterprise and other private networks. But DNS is part of the control plane, and network operators must be able to monitor and filter it. Use DoT, never DoH.
    > DoH will be the default setting for many BYOD, and will mindlessly bypass security policy. Not at all like DoT, which can be filtered by any network operators with ease, to force local resolver use. DoH is a big F.U. to ALL network operators.
    > Not an expert here, but in many/most parts of the planet, the "network operators" ARE the #1 threat.
    > And this matters why exactly? My home and Enterprise networks monitor and control DNS, for the good of the users. I am not the bad guy here.

    А теперь вопрос, вы действительно хотите его слушать и выбирать DoT? Вы считаете что провайдер/оператор/владелец сети должен за вас решать и блокировать DoT по желанию, получая ваши днс-запросы? Обратите внимание: "Not at all like DoT, which can be filtered by any network operators with ease, to force local resolver use".
    Нет. Пускай эти админы и операторы идут в лес со своими хотелками и предпочитаемым протоколом, вдарим по ним DoH.

     
     
  • 5.96, гуглефларя (?), 15:24, 26/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да! А мы хотим чтобы эта возможность была только у нас!
    Верьте нам, мы правильные ребята, ведь мы не живем на деньги, которые платите нам вы, в отличие от вашего опсоса, который спит и видит кому бы еще вас запродать. Верьте, мы - корпорации добра!
     
     
  • 6.97, Аноним (97), 20:59, 27/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Думаешь ты хоть капельку убедителен?
    1. Юзеры и так сидели на гуглоднс десятилетия. 8.8.8.8 стандарт многих эникеев, хомяков и даже некоторых админов. С CF аналогично становится. Т.е. они и так имели доступ. Но помимо них все остальные по пути, от оператора и соседа-хацкера до неизвестных людей. Нет ничего плохого в том, чтобы запретить всем, кроме конечных гуглефляр, смотреть и фильтровать днс-трафик. Это полностью правильно.
    2. Те, кто брезговал гуглефлярой в прошлые годы, могут делать это и с протоколами шифрования. Это стандарты, есть много открытых реализаций. DoH на своём сервере поднять особенно просто, в этом одно из основных преимуществ. Это тоже полностью правильно, запретить оператору и другим смотреть на днс-трафик между тобой и твоим сервером.
    Где ты видишь усиление централизации? Она и так была с открытым днс десятилетия, не надо отрицать факты. И ситуация не меняется от шифрованных протоколов никак, кроме запрета третьим сторонам по пути трафика.
     
  • 3.27, Аноним (27), 15:22, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Далеко не во всех странах фильтрация сколько нибудь существенная проблема. А шпиенить любят везде.
     
  • 2.49, Аноним (49), 22:49, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    dnscrypt же
     
  • 1.3, Аноним (3), 12:05, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > закрытого ключа, который хранится отдельно у владельца домена

    Узкое место. Хранится не только у владельца. Потому технология ущербна.

     
     
  • 2.89, Аноним (89), 16:09, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там разные ключи: KSK, ZSK, DSKEY. Светишь только DSKEY, а данные подписываешь ZSK.
     
  • 1.4, Аноним (4), 12:12, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    угу-угу, бесконечные дыры в кривой и написанной хвостом макаки "поддержке" оверинжиниренного и совершенно бестолкового dnssec - icann не то чтобы не колебут, а, скорее, хорошо оплачены хорошими ребятами.

     
  • 1.5, Онаним (?), 12:13, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как только менеджмент ключей DNSSEC перестанет быть адовыми граблями, приводящими к "потере" зоны на часы и сутки, так и сразу. Механизм публикации ключей настолько угрёбищен, что его проще избегать, чем им пользоваться. API для автоматизированной републикации ключей у большинства регистраров также отсутствует, а его наличие создаст дополнительные дыры.
     
     
  • 2.32, xm (ok), 17:08, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > приводящими к "потере" зоны на часы и сутки, так и сразу

    Вам для этого RFC6781 и RFC7583 написали как, когда и что делать. Но чукча, видимо, не читатель...

     
     
  • 3.60, Онаним (?), 09:28, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вам сюда:
    https://ianix.com/pub/dnssec-outages.html

    Все здесь перечисленные, видимо, тоже не читатели.

     
     
  • 4.76, xm (ok), 11:24, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я сам могу вам давать двухдневные курсы на эту тему, только это всё не меняет того факта, что "потери зоны на сутки" описанные в ссылке к DNSSEC отношения не имеют, прочие же проблемы это от кривизны рук.
     
     
  • 5.77, Аноним (77), 11:25, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Конечно же не имеют. Впрочем, говорить с вами больше не о чем, всё ясно.
     
  • 1.6, Anon_Erohin (?), 12:29, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Ага, сейчас победали сразу. Ни в коем случае нельзя этого делать. Это же очередной зонд от АНБ. Если покопаться кто рулит ICANN через подставные фирмы то там 100% будут торчат уши АНБ.
     
     
  • 2.12, Аноним (12), 13:10, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >Если покопаться
    >Если

    Что же не покопался?

     
  • 2.34, АНБ (?), 17:20, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    зачем нам впрямую рулить полезными идиотами, если они и так все за нас и для нас делают, при минимальных управляющих воздействиях?

     
  • 2.59, Аноним (59), 07:54, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем же вы так палитесь, тащ майор?
     
  • 1.7, Аноним (7), 12:33, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что мешает атакующим полчив контроль за доменом на уровне регистратора или перенаправив домен на свой DNS-сервер вообще отключить DNSSEC?

    Мне кажется, что DNSSEC будет эффективным только если он обязательно будет включен на всех серверах и resolver-ах.

     
     
  • 2.28, Sw00p aka Jerom (?), 15:45, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    в том то и проблема, щас призывают всех поголовно включать, а потом будут поголовно призывать, чтобы днс сервера не отвечали не подписанными ответами. и так еще лет 20 это внедряться будет, и за этот период выскочит какой-то другой протокол, который будут активно продвигать.
     
     
  • 3.52, Pahanivo (ok), 23:13, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Эт точно. Когда я более 15 лет назад пришел в айти все кругом дружно кричали "нужна срочна ipv6" ...
     
     
  • 4.66, Онаним (?), 09:35, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так точно. Я всегда с этих ребят ржал, потому что очевидно было, что это поделие нормально не взлетит. И ведь спорили, с пеной у рта. До сих пор ржу и напоминаю.
     
     
  • 5.92, Аноним (92), 03:28, 26/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.google.com/intl/en/ipv6/statistics.html - вроде взлетает потихоньку. Больше четверти интернета уже на нём...
     
     
  • 6.98, Pahanivo (ok), 14:09, 28/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > https://www.google.com/intl/en/ipv6/statistics.html - вроде взлетает потихоньку.
    > Больше четверти интернета уже на нём...

    Еще лез 30 - глядишь 50-60% будет.

     
  • 1.8, Аноним (7), 12:37, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всегда убираю DNSSEC при сборке, так половина дыр в BIND так или иначе связаны с кодом DNSSEC.
     
     
  • 2.9, Онаним (?), 12:39, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В рекурсивных резолверах тоже выключены проверки DNSSEC, потому что жалобы юзеров вида "аааа, у меня домен xyzzy.com через вас не резолвится" - задолбали.
     
     
  • 3.10, Онаним (?), 12:41, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Юзер ведь не бежит к админам xyzzy.com, которые продолбали очередной ручной апдейт DS/KSK или у которых регистрар тупо закешировал DS на сутки... юзер сразу бежит к своему ISP и ноет что ISP плохой. Так что пока это счастье не перестанет на 99.9% зависеть от человеческого фактора - оно будет выключено.
     
  • 3.45, xm (ok), 21:08, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Чушь.
    Наличие / отсутствие DNSSEС не влияет на само разрешение домена. Оно либо проходит, либо нет.
    DNSSEC лишь подтверждает достоверность полученных данных.
     
     
  • 4.48, пох (?), 22:17, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Чушь.

    типичное мнение комнатного теоретика, ага.

    > Наличие / отсутствие DNSSEС не влияет на само разрешение домена. Оно либо

    ни одного слова он не понял, но зато он "читал rfc", и лезет с ценными сведениями.

     
     
  • 5.67, Онаним (?), 09:37, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тот мусье просто не в курсе, что рекурсивный резолвер с включенным чеком сдропнет ответ, если чек не пройдёт.
     
     
  • 6.68, пох (?), 09:50, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    тот мусье, я ж говорю, вообще ни слова не понял, но полез с ценным мнением - он же читал rfc, а остальные видать лохи!
    То есть до него в принципе не дошло, о чем речь, и понёс он чепуху совершенно не про это.

     
  • 5.78, xm (ok), 11:34, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > типичное мнение комнатного теоретика, ага.

    Да-да, десятки доменов с DNSSEC и авто KSK rollover третий год без единой поблемы это, видимо, не у меня работают. Но балаболам с Опеннет виднее.

     
     
  • 6.80, пох (?), 12:40, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –6 +/
    десятки? Проходи мимо мальчик-с-локалхостингом, проходи...

    никому твои десятки даром не сдались. Кстати, ломать их такими сложными методами тоже нафиг никому не надо.

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

     
  • 6.90, Онаним (?), 20:38, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Десятки доменов.
    По ходу хостер уровня "прихожая".
     
  • 4.61, Онаним (?), 09:29, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Што, простите?
     
     
  • 5.79, xm (ok), 11:35, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Напрягитесь, подумайте, поэкспериментируйте... Я в вас верю.
     
  • 2.30, пох (?), 16:44, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    обезьянки неистово кинулись минусить - они не понимают, как это, не хотеть обмазаться свеженьким, да еще под соусом "безопастносте" ;)

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

    на самом деле понятно, дыры не только там, поделка isc с какой стороны не глянь - шерето, просто последние лет пять никто даже не ищет дальше поверхности.

     
     
  • 3.62, Онаним (?), 09:30, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да не, ну с биндом-то всё терпимо. А вот DNSSEC - мертворождённое угрёбище.
     
     
  • 4.69, пох (?), 09:52, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Да не, ну с биндом-то всё терпимо.

    это ты на радостях от dnssec просто забыл, например, про libxml2 ;-)

    ну и про новый пихоновский bind, который грядет тоже совершенно неотвратимо. То ли на клятую винду от него бежать, то ли на knot (который тоже делают странные ребята)...

     
     
  • 5.74, Аноним (74), 10:21, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    10 бинд, не, чур, чур. Но вроде поддержка 9 не прекращается, потому что понимают, что это труба
     
  • 3.85, Zulu (?), 13:49, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > вместо собственного кода

    Жги дальше.

     
  • 1.14, koblin (ok), 13:23, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Смотришь на весь этот стек технологий (smtp, dns, ip4/6...) и как-то грустно становится, слеплено из г-на и веток...
     
     
  • 2.16, Аноним (15), 13:29, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Проблема легаси... QUIC тоже её дитя
     
  • 2.19, macfaq (?), 14:04, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Попробуй принять во внимание возраст этих технологий и какие ограничения/задачи стояли перед их создателями на момент проектирования.
     
  • 2.24, Аноним (24), 14:33, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    предложите лучше вариант?
    ах да, его же нет
     
     
  • 3.41, Аноним (41), 19:44, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    [sarcasm]IPX/SPX[/sarcasm]
     
     
  • 4.47, пох (?), 22:15, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > [sarcasm]IPX/SPX[/sarcasm]

    "основным недостатком протокола ipx является то, что он разработан фирмой novell" (c)какое-то раннее издание книжки для MCSE. Ни разу между прочим не соврали - будь spx (с голым ipx далеко не уедешь) меньше обложен недосказанностью и копирайтами - вполне возможно, жил бы и по сей день, как минимум, в локальных сетях. Ну или какой-нибудь условно-совместимый ipxv2, там, помнится, номер сети был немного ограничен.

    И ни торговлишки цифирками новел не догадалась предусмотреть, ни буковками - а когда у общества нет цветовой дифференциации штанов, оно лишено цели...

     
  • 2.25, Аноним (25), 15:00, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не нравится, что инженерами сделаны, а не на коленке? Разве что кроме smtp, тот своеобразный и ещё и текстовый. А DoH прям такой не костыль вообще... Вообще не относится к everything-over-http.
    Я таки поддержу коммент рядом: посмотрите когда всё это сделано и какие задачи решало (и ведь решало).
     
     
  • 3.33, пох (?), 17:18, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вообще-то из помянутого списка инженерами сделан только smtp и v4.  Ну да, обезьяны ж не умеют в текстовые строки, но инженерам на твои страданья было начхать, а вот отлаживать им было удобнее человекочитаемый протокол.

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

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

     
     
  • 4.42, mimokrkodil (?), 20:32, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > твои страданья было начхать, а вот отлаживать им было удобнее человекочитаемый
    > протокол.
    > Все остальное выдумано кабинетными теоретиками, к сожалению, быстренько прорвавшимися
    > к рулю, когда в arpanet запахло деньгами, и по сей день
    > их пилящими по мелочам (бюджетец icann желающие да обрящут).
    > начиная вот прямо с dns, отвратительней которого еще поискать (все что пятнадцать
    > лет назад писал про него djb - осталось верно, только добавлены
    > совсем уродливые и гнилые криптокостыли, которые трусы и саботажники никак не
    > хотят, гады, внедрять). Ну да, ну да - зато торговлишку воздухом
    > прибрали к жадным лапам на самом раннем этапе.

    а как должен выглядеть DNS - нe кypильщикa (в смысле архитектypнo), можно тoчкy зpeния изложить ?

     
     
  • 5.46, пох (?), 22:05, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    э.. ну где-то в районе обитания djbdns, полагаю, по сей день лежит статья его же автора, подробно описывающая _нерешаемые_ проблемы в этом протоколе (требует понимания протокола, а не только общего представления).
    Большинство претензий достаточно серьезны и оправданы, и лишь часть из этого закостылена подпорочками (которые местами сами ведут к проблемам) в современных версиях. Соответственно, выглядеть должно как несовместимый протокол, а возможность такого с сохранением фаллбэка на старую версию, если другой не поддерживается, авторами исходного ни разу не предусмотрена. Поэтому и мучаемся с тем что есть, не считая всяких уродцев типа сdoh.

     
     
  • 6.51, mimokrkodil (?), 23:12, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    хм, доки и мануалы от этого пациента проглядываем эдак с 2001..
    ..просто инетерсено по стеку технологий - кто как видит ?

    >Соответственно, выглядеть должно как несовместимый протокол, а возможность такого с сохранением фаллбэка на старую версию, если другой не поддерживается, авторами исходного ни разу не предусмотрена.

    ну-да, перенeсли из сетевого на доменный(предметку) уровень UDP-like mode - ско-ко такого непотребства насмторелся;

    ...итить их, TLV - не асилили и/или 2-4 uint32 пожлобились,
    ведь все ж перед глазами было: IP-, UDP-, TCP- headers


    если не подводит память, уже нек-рые DNS станд. рекомендуют UDP-payload size > больше дефолтного MTU(1500)

    :(

    P.S.:

    однов время возился с протоколом GALILEO (изначально us. военщина - думается транспорт авиа-грузов):

    - пля, просто видно было ядро проектировал профи (прообраз TLV, если память не подводит тогда еще DARPA не было)
    - потом слегка подкостылили - на предмет возни с гражданской авиа-темой
    - потом еще костылей подбросили, бронь гостциниц и прочий буккинг...

    в итоге ну иво нафиг

     
  • 4.50, Ю.Т. (?), 23:01, 24/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > dns
    > все что пятнадцать лет назад писал про него djb -

    Двадцать лет. А bind живее всех живых.

     
     
  • 5.71, пох (?), 09:55, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> dns
    >> все что пятнадцать лет назад писал про него djb -
    > Двадцать лет. А bind живее всех живых.

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

     
  • 4.63, Онаним (?), 09:31, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    DNS да, тоже то ещё угрёбище, неужели нельзя было текстовым сделать... Можно бы было плодить экстеншны по самое не хочу.
     
     
  • 5.70, litrovi4 (?), 09:55, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >DNS да, тоже то ещё угрёбище, неужели нельзя было текстовым сделать... Можно бы было плодить экстеншны по самое не хочу.

    упаси всевышний, про скорость можно забыть, только TLV - только hardcore
    ...http им мало

     
  • 5.81, пох (?), 12:43, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > DNS да, тоже то ещё угрёбище, неужели нельзя было текстовым сделать...

    скажи спасибо что не сделали - я как представляю себе поддержку текстового протокола с жесткими требованиями к response time силами студентов на подработке в ISC - так дрожь пробирает... к тому же я отлично помню их pop3 ;-)

     
  • 4.64, Онаним (?), 09:32, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Но самая мякотка - это ASN.1 и ASN.1-based, типа SNMP. С них меня вообще тошнит фонтаном.
     
     
  • 5.72, litrovi4 (?), 10:00, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но самая мякотка - это ASN.1 и ASN.1-based, типа SNMP. С них меня вообще тошнит фонтаном.

    угу, типичный пример over-engenigring

     
     
  • 6.82, пох (?), 12:44, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Но самая мякотка - это ASN.1 и ASN.1-based, типа SNMP. С них меня вообще тошнит фонтаном.
    > угу, типичный пример over-engenigring

    дык, itu жеж. от людей, которые изобрели x.400...

     
  • 1.43, Аноним (43), 20:42, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ломай совместимость?
     
     
  • 2.73, пох (?), 10:01, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ломай совместимость?

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

     
  • 1.44, Аноним (44), 20:58, 24/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как же навязывают DNSSEC..
     
     
  • 2.58, Аноним (58), 07:12, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Читал я читал про это DNSSEC так и не понял как это может помочь :(
    Может кто объяснит на пальцах ?
    Точки(сервера) что ли подменяют ? Или провайдеры целят на ДНС-сервера какие им в голову взбредет ?
     
     
  • 3.95, xm (ok), 10:46, 26/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    DNSSEC это цифровые подписи удостоверяющие записи. Это уже хорошо само по себе.
    Больше практической пользы лежит в базирующемся на нём DANE. К примеру, потенциально можно вообще отказаться от CA.
     
  • 2.65, Онаним (?), 09:33, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так же, как и IPv6, будь он не ладен. Не переживайте, пройдёт ещё 30 лет, а воз будет и ныне там.
     
  • 1.54, Ivan_83 (ok), 04:29, 25/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Всегда отключаю при сборке unbound и никогда не настраиваю и не разрешаю проверки DNSSec, ибо с одной стороны это может привести к тому что какие то сайты не откроются, с другой мне нечего терять в случае полного слома днс.

    ICANN я тоже доверять не собираюсь, как и центрам сертификации - я их не знаю, у них нет обязанностей предо мной.

    Итак уже слишком много всяких ключей от интернета развелось с этим повсеместным TLS, лезущим из всех щелей, теперь вот решили ещё и тут гайки закрутить.

     
     
  • 2.86, Zulu (?), 13:54, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ICANN я тоже доверять не собираюсь, как и центрам сертификации - я их не знаю, у них нет обязанностей предо мной.

    И как это выглядит в исполнении Вани? Alternate roots?

     
     
  • 3.87, Ivan_83 (ok), 13:59, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это выглядит как: мне похер на ваши потуги, я ничего делать для перехода на TLS, DNSSec не буду.
     
  • 1.57, Аноним (55), 06:19, 25/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Одно Кольцо покорит их, одно соберет их,
    Одно их притянет и в черную цепь скует их.
     
     
  • 2.83, гугель (?), 12:44, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Одно Кольцо покорит их, одно соберет их,
    > Одно их притянет и в черную цепь скует их.

    чаво это только одно?! Мы тоже хотим свою долю!

     
     
  • 3.88, Аноним (55), 14:09, 25/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Но если они додумаются до этого, повторяю, ущерб для них будет очень большой, если не сказать, колоссальный.
     
  • 1.84, Аноним (84), 13:19, 25/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На текущий момент DNS-сервера с DNSSEC резолвят не все домены. Видимо поэтому:

    > "Организация ICANN, регулирующая вопросы, связанные с IP-адресами и доменными именами и интернете, выступила с инициативой повсеместного перехода на использование DNSSEC для всех доменных имён."

     
  • 1.91, Аноним (91), 22:07, 25/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как на win7 то doh или dot настроить? Все сводится к замене dns сервера, но от этого секурности не появится
     
     
  • 2.93, Аноним (75), 07:28, 26/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    DNSCrypt 2 поддерживает DoH.
     
  • 1.94, samm (ok), 09:13, 26/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    к вопросу о полезности dnssec - если бы он был полноценно внедрен то ситуация вроде той что в презе ниже была бы невозможна

    https://pc.nanog.org/static/published/meetings/NANOG75/1892/20190219_Gavrichen

     

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



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

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