Организация ICANN, регулирующая вопросы, связанные с IP-адресами и доменными именами и интернете, выступила с инициативой (https://www.icann.org/news/announcement-2019-02-22-en) повсеместного перехода на использование DNSSEC (https://ru.wikipedia.org/wiki/DNSSEC) для всех доменных имён. ICANN отмечает наличие значительного риска для ключевых частей инфраструктуры DNS, вызванного увеличением числа атак (https://www.opennet.me/opennews/art.shtml?num=49937) на DNS-серверы и ростом связанной с DNS вредоносной активностью (https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recen....
Последнее время фиксируется множество различных типов атак на DNS, от захвата доменов (https://www.opennet.me/opennews/art.shtml?num=49744) через перехват параметров учётной записи к интерфейсу регистратора или DNS-сервиса, проводимых с целью изменения списка DNS-серверов или содержимого отдельных записей, до применения (https://www.opennet.me/opennews/art.shtml?num=48494) BGP (https://www.opennet.me/opennews/art.shtml?num=48679) для подмены DNS-серверов.
Большую часть из атак, связанных с заменой привязки имени к IP, отравлением DNS-кэша или MITM-подменой, можно было блокировать в случае использования DNSSEC, так как атакующие не могли бы сформировать корректную цифровую подпись без получения закрытого ключа, который хранится отдельно у владельца домена.
Для борьбы с участившимися атаками по перенаправлению трафика на уровне изменения параметров DNS организация ICANN выработала (https://www.icann.org/news/announcement-2019-02-15-en) список рекомендаций по усилению защиты для регистраторов, владельцев доменов и всех связанных с DNS представителей индустрии. Одной из ключевых рекомендаций является применение DNSSEC для защиты целостности содержимого DNS зон и включение валидации DNSSEC на стороне резолверов. При этом DNSSEC не выполняет шифрование трафика - для обеспечения конфиденциальности и защиты трафика от перехвата следует использовать DoH (https://www.opennet.me/opennews/art.shtml?num=49673) ("DNS over HTTPS") или DoT ("DNS over TLS (https://www.opennet.me/opennews/art.shtml?num=48443)").Также упомянуты такие общие рекомендации, как применение двухфакторой аутентификации для доступа к интерфейсам управления доменами, регулярная и оперативная установка обновлений с устранением уязвимостей, анализ логов на предмет неавторизированного доступа, рецензирование обоснованности предоставления сотрудникам повышенных полномочий (root-доступа), отслеживание истории всех изменений DNS-записей, использование надёжных паролей, исключение передачи паролей в открытом виде и регулярная смена паролей. Для защиты почтовых отправлений рекомендовано использовать DMARC с SPF или DKIM записями.
Дополнительно можно отметитьпубликацию (https://www.mail-archive.com/bind-announce@lists.isc.or... корректирующих выпусков DNS-сервера BIND 9.11.5-P4 и 9.12.3-P4 c устранением трёх уязвимостей:- CVE-2018-5744 (https://lists.isc.org/pipermail/bind-announce/2019-February/... может использоваться для вызова отказа в обслуживании через создание условий для исчерпания доступной для процесса named памяти. Проблема вызвана некорректным освобождением памяти при обработке пакетов с определённым сочетанием опций EDNS. В случае если на уровне операционной системы размер выделяемой процессу named памяти не лимитирован, атака может использоваться для исчерпания всей доступной в системе свободной памяти.
- CVE-2019-6465 (https://lists.isc.org/pipermail/bind-announce/2019-February/... - пользователь может запросить и получить содержимое DNS-зоны не имея на это полномочий (без явного разрешения allow-transfer в ACL). Проблема проявляется только для зон DLZ (Dynamically Loadable Zones), доступных на запись.
- CVE-2018-5745 (https://lists.isc.org/pipermail/bind-announce/2019-February/... - возможность инициирование краха (assertion failure) процесса named при указании неподдерживаемого в BIND алгоритма ключей DNSSEC при использовании режима "managed-keys". Уязвимость может быть эксплуатировано только сто стороны доверенного DNS-сервера, указанного администраторм в настройках в качестве сервера для валидации DNSSEC. Проблема опасна не столько атаками, сколько возможностью непреднамеренного проявления, например, когда BIND на стороне резолвера собран без поддержки устаревших алгоритмов и настроен на использование для валидации DNSSEC сервера, который может использовать один из этих алгоритмов.
URL: https://www.mail-archive.com/bind-announce@lists.isc.or...
Новость: https://www.opennet.me/opennews/art.shtml?num=50199
DNS over HTTPS — шляпа. Если нужно шифрование, то только over TLS.
Наоборот, если весь трафик будет HTTPS, фильтрануть будет намного сложнее.
Загугли "DNS over HTTPS criticism".
Загугли "DNS over HTTPS criticism debunked".
Хорошая попытка, но нет.
ты гуглишь только то, что вписывается в манямирок?
Он просит гуглить других.
А что по поводу DNS over TLS criticism? Daniel Stenberg говорит, что все имплементации DoT делают новое TLS соединение на каждый резолв. Это полная дичь.
35:20 https://fosdem.org/2019/schedule/event/dns_over_http/
DoH соединение живет часами, а еще имеет мультиплексирование и другие плюшки http/2, и потом быстро перейдет на http/3 over quic с очередными плюшками отказа от tcp-костылей.
А про DoT еще автор DNSCrypt давно говорил: https://dnscrypt.info/faq/
> Will be difficult to improve without introducing more hacks. Unlikely to benefit from any improvements besides new TLS versions or homegrown reinventions.
> Difficult to implement securely. Validating TLS certificates in non-browser software is the most dangerous code in the world https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...
> Not well understood even by its proponents. It is a truck, as it is heavy and slow to load, but most if not all implementations perform a full round trip for every packet
> Questionable practical benefits over DoH
Ты не мог бы отвечать по теме? Вопрос про шифрование, а не фильтрацию.
Он отвечает по теме. Знаешь какой главный аргумент критики DoH и одобрения DoT у одного из разработчиков DNS Пола Викси? То что он хочет в своей домашней и корпоративной сети иметь возможность блокировать шифрование днс и откатывать юзеров к обычному, потому что он хороший и ему надо верить, он лучше знает и о юзерах заботится. А DoH мешает и вызывает ненависть.
https://www.theregister.co.uk/2018/10/23/paul_vixie_slaps_do.../
https://www.theregister.co.uk/2018/10/30/dns_over_https_cont.../
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.
да! А мы хотим чтобы эта возможность была только у нас!
Верьте нам, мы правильные ребята, ведь мы не живем на деньги, которые платите нам вы, в отличие от вашего опсоса, который спит и видит кому бы еще вас запродать. Верьте, мы - корпорации добра!
Думаешь ты хоть капельку убедителен?
1. Юзеры и так сидели на гуглоднс десятилетия. 8.8.8.8 стандарт многих эникеев, хомяков и даже некоторых админов. С CF аналогично становится. Т.е. они и так имели доступ. Но помимо них все остальные по пути, от оператора и соседа-хацкера до неизвестных людей. Нет ничего плохого в том, чтобы запретить всем, кроме конечных гуглефляр, смотреть и фильтровать днс-трафик. Это полностью правильно.
2. Те, кто брезговал гуглефлярой в прошлые годы, могут делать это и с протоколами шифрования. Это стандарты, есть много открытых реализаций. DoH на своём сервере поднять особенно просто, в этом одно из основных преимуществ. Это тоже полностью правильно, запретить оператору и другим смотреть на днс-трафик между тобой и твоим сервером.
Где ты видишь усиление централизации? Она и так была с открытым днс десятилетия, не надо отрицать факты. И ситуация не меняется от шифрованных протоколов никак, кроме запрета третьим сторонам по пути трафика.
Далеко не во всех странах фильтрация сколько нибудь существенная проблема. А шпиенить любят везде.
dnscrypt же
> закрытого ключа, который хранится отдельно у владельца доменаУзкое место. Хранится не только у владельца. Потому технология ущербна.
Там разные ключи: KSK, ZSK, DSKEY. Светишь только DSKEY, а данные подписываешь ZSK.
угу-угу, бесконечные дыры в кривой и написанной хвостом макаки "поддержке" оверинжиниренного и совершенно бестолкового dnssec - icann не то чтобы не колебут, а, скорее, хорошо оплачены хорошими ребятами.
Как только менеджмент ключей DNSSEC перестанет быть адовыми граблями, приводящими к "потере" зоны на часы и сутки, так и сразу. Механизм публикации ключей настолько угрёбищен, что его проще избегать, чем им пользоваться. API для автоматизированной републикации ключей у большинства регистраров также отсутствует, а его наличие создаст дополнительные дыры.
> приводящими к "потере" зоны на часы и сутки, так и сразуВам для этого RFC6781 и RFC7583 написали как, когда и что делать. Но чукча, видимо, не читатель...
Вам сюда:
https://ianix.com/pub/dnssec-outages.htmlВсе здесь перечисленные, видимо, тоже не читатели.
Я сам могу вам давать двухдневные курсы на эту тему, только это всё не меняет того факта, что "потери зоны на сутки" описанные в ссылке к DNSSEC отношения не имеют, прочие же проблемы это от кривизны рук.
Конечно же не имеют. Впрочем, говорить с вами больше не о чем, всё ясно.
Ага, сейчас победали сразу. Ни в коем случае нельзя этого делать. Это же очередной зонд от АНБ. Если покопаться кто рулит ICANN через подставные фирмы то там 100% будут торчат уши АНБ.
>Если покопаться
>ЕслиЧто же не покопался?
зачем нам впрямую рулить полезными идиотами, если они и так все за нас и для нас делают, при минимальных управляющих воздействиях?
Зачем же вы так палитесь, тащ майор?
А что мешает атакующим полчив контроль за доменом на уровне регистратора или перенаправив домен на свой DNS-сервер вообще отключить DNSSEC?Мне кажется, что DNSSEC будет эффективным только если он обязательно будет включен на всех серверах и resolver-ах.
в том то и проблема, щас призывают всех поголовно включать, а потом будут поголовно призывать, чтобы днс сервера не отвечали не подписанными ответами. и так еще лет 20 это внедряться будет, и за этот период выскочит какой-то другой протокол, который будут активно продвигать.
Эт точно. Когда я более 15 лет назад пришел в айти все кругом дружно кричали "нужна срочна ipv6" ...
Так точно. Я всегда с этих ребят ржал, потому что очевидно было, что это поделие нормально не взлетит. И ведь спорили, с пеной у рта. До сих пор ржу и напоминаю.
https://www.google.com/intl/en/ipv6/statistics.html - вроде взлетает потихоньку. Больше четверти интернета уже на нём...
> https://www.google.com/intl/en/ipv6/statistics.html - вроде взлетает потихоньку.
> Больше четверти интернета уже на нём...Еще лез 30 - глядишь 50-60% будет.
Всегда убираю DNSSEC при сборке, так половина дыр в BIND так или иначе связаны с кодом DNSSEC.
В рекурсивных резолверах тоже выключены проверки DNSSEC, потому что жалобы юзеров вида "аааа, у меня домен xyzzy.com через вас не резолвится" - задолбали.
Юзер ведь не бежит к админам xyzzy.com, которые продолбали очередной ручной апдейт DS/KSK или у которых регистрар тупо закешировал DS на сутки... юзер сразу бежит к своему ISP и ноет что ISP плохой. Так что пока это счастье не перестанет на 99.9% зависеть от человеческого фактора - оно будет выключено.
Чушь.
Наличие / отсутствие DNSSEС не влияет на само разрешение домена. Оно либо проходит, либо нет.
DNSSEC лишь подтверждает достоверность полученных данных.
> Чушь.типичное мнение комнатного теоретика, ага.
> Наличие / отсутствие DNSSEС не влияет на само разрешение домена. Оно либо
ни одного слова он не понял, но зато он "читал rfc", и лезет с ценными сведениями.
Тот мусье просто не в курсе, что рекурсивный резолвер с включенным чеком сдропнет ответ, если чек не пройдёт.
тот мусье, я ж говорю, вообще ни слова не понял, но полез с ценным мнением - он же читал rfc, а остальные видать лохи!
То есть до него в принципе не дошло, о чем речь, и понёс он чепуху совершенно не про это.
> типичное мнение комнатного теоретика, ага.Да-да, десятки доменов с DNSSEC и авто KSK rollover третий год без единой поблемы это, видимо, не у меня работают. Но балаболам с Опеннет виднее.
десятки? Проходи мимо мальчик-с-локалхостингом, проходи...никому твои десятки даром не сдались. Кстати, ломать их такими сложными методами тоже нафиг никому не надо.
P.S. а что твои клиенты сообразят куда пожаловаться, если ты все у себя поломаешь - это тоже навряд ли. К тому же жаловаться должны будут клиенты их клиентов - а у них все работает - трудами инженера оператора, отключившего на своем ресолвере нафиг вредную и опасную псевдосекьюрить. Ну или не работает, но они гонят на оператора. В принципе, правильно, ибо нех.
Десятки доменов.
По ходу хостер уровня "прихожая".
Што, простите?
Напрягитесь, подумайте, поэкспериментируйте... Я в вас верю.
обезьянки неистово кинулись минусить - они не понимают, как это, не хотеть обмазаться свеженьким, да еще под соусом "безопастносте" ;)причем дыры никак не могут залатать уже лет пять, с момента появления прототипа технологии. И это не считая еще отдельно дыр в openssl (изобретатели криптотрэша ведь не могут на самом деле в криптографию - поэтому используют насквозь гнилую и принципиально неизлечимую раздутую помойку вместо собственного кода или хотя бы отдельных примитивов, написанных кем-то более аккуратным и не ставящим неодолимо-глобальных задач)
на самом деле понятно, дыры не только там, поделка isc с какой стороны не глянь - шерето, просто последние лет пять никто даже не ищет дальше поверхности.
Да не, ну с биндом-то всё терпимо. А вот DNSSEC - мертворождённое угрёбище.
> Да не, ну с биндом-то всё терпимо.это ты на радостях от dnssec просто забыл, например, про libxml2 ;-)
ну и про новый пихоновский bind, который грядет тоже совершенно неотвратимо. То ли на клятую винду от него бежать, то ли на knot (который тоже делают странные ребята)...
10 бинд, не, чур, чур. Но вроде поддержка 9 не прекращается, потому что понимают, что это труба
> вместо собственного кодаЖги дальше.
Смотришь на весь этот стек технологий (smtp, dns, ip4/6...) и как-то грустно становится, слеплено из г-на и веток...
Проблема легаси... QUIC тоже её дитя
Попробуй принять во внимание возраст этих технологий и какие ограничения/задачи стояли перед их создателями на момент проектирования.
предложите лучше вариант?
ах да, его же нет
[sarcasm]IPX/SPX[/sarcasm]
> [sarcasm]IPX/SPX[/sarcasm]"основным недостатком протокола ipx является то, что он разработан фирмой novell" (c)какое-то раннее издание книжки для MCSE. Ни разу между прочим не соврали - будь spx (с голым ipx далеко не уедешь) меньше обложен недосказанностью и копирайтами - вполне возможно, жил бы и по сей день, как минимум, в локальных сетях. Ну или какой-нибудь условно-совместимый ipxv2, там, помнится, номер сети был немного ограничен.
И ни торговлишки цифирками новел не догадалась предусмотреть, ни буковками - а когда у общества нет цветовой дифференциации штанов, оно лишено цели...
Не нравится, что инженерами сделаны, а не на коленке? Разве что кроме smtp, тот своеобразный и ещё и текстовый. А DoH прям такой не костыль вообще... Вообще не относится к everything-over-http.
Я таки поддержу коммент рядом: посмотрите когда всё это сделано и какие задачи решало (и ведь решало).
вообще-то из помянутого списка инженерами сделан только smtp и v4. Ну да, обезьяны ж не умеют в текстовые строки, но инженерам на твои страданья было начхать, а вот отлаживать им было удобнее человекочитаемый протокол.Все остальное выдумано кабинетными теоретиками, к сожалению, быстренько прорвавшимися к рулю, когда в arpanet запахло деньгами, и по сей день их пилящими по мелочам (бюджетец icann желающие да обрящут).
начиная вот прямо с dns, отвратительней которого еще поискать (все что пятнадцать лет назад писал про него djb - осталось верно, только добавлены совсем уродливые и гнилые криптокостыли, которые трусы и саботажники никак не хотят, гады, внедрять). Ну да, ну да - зато торговлишку воздухом прибрали к жадным лапам на самом раннем этапе.
>[оверквотинг удален]
> твои страданья было начхать, а вот отлаживать им было удобнее человекочитаемый
> протокол.
> Все остальное выдумано кабинетными теоретиками, к сожалению, быстренько прорвавшимися
> к рулю, когда в arpanet запахло деньгами, и по сей день
> их пилящими по мелочам (бюджетец icann желающие да обрящут).
> начиная вот прямо с dns, отвратительней которого еще поискать (все что пятнадцать
> лет назад писал про него djb - осталось верно, только добавлены
> совсем уродливые и гнилые криптокостыли, которые трусы и саботажники никак не
> хотят, гады, внедрять). Ну да, ну да - зато торговлишку воздухом
> прибрали к жадным лапам на самом раннем этапе.а как должен выглядеть DNS - нe кypильщикa (в смысле архитектypнo), можно тoчкy зpeния изложить ?
э.. ну где-то в районе обитания djbdns, полагаю, по сей день лежит статья его же автора, подробно описывающая _нерешаемые_ проблемы в этом протоколе (требует понимания протокола, а не только общего представления).
Большинство претензий достаточно серьезны и оправданы, и лишь часть из этого закостылена подпорочками (которые местами сами ведут к проблемам) в современных версиях. Соответственно, выглядеть должно как несовместимый протокол, а возможность такого с сохранением фаллбэка на старую версию, если другой не поддерживается, авторами исходного ни разу не предусмотрена. Поэтому и мучаемся с тем что есть, не считая всяких уродцев типа сdoh.
хм, доки и мануалы от этого пациента проглядываем эдак с 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 не было)
- потом слегка подкостылили - на предмет возни с гражданской авиа-темой
- потом еще костылей подбросили, бронь гостциниц и прочий буккинг...в итоге ну иво нафиг
> dns
> все что пятнадцать лет назад писал про него djb -Двадцать лет. А bind живее всех живых.
>> dns
>> все что пятнадцать лет назад писал про него djb -
> Двадцать лет. А bind живее всех живых.так его ж каждые пять лет новые студенты с нуля переписывают, ниасиливая разобраться в коде предыдущего потока. А переписать с нуля сам протокол - так это не студенты нужны, и нужна дурья сила кого-нибудь вроде тандема циски с ебеме чтобы потом его продавить хотя бы в качестве параллельно-поддерживаемого стандарта. Не надейтесь, просто ищите работу, не связанную с современным it :-(
DNS да, тоже то ещё угрёбище, неужели нельзя было текстовым сделать... Можно бы было плодить экстеншны по самое не хочу.
>DNS да, тоже то ещё угрёбище, неужели нельзя было текстовым сделать... Можно бы было плодить экстеншны по самое не хочу.упаси всевышний, про скорость можно забыть, только TLV - только hardcore
...http им мало
> DNS да, тоже то ещё угрёбище, неужели нельзя было текстовым сделать...скажи спасибо что не сделали - я как представляю себе поддержку текстового протокола с жесткими требованиями к response time силами студентов на подработке в ISC - так дрожь пробирает... к тому же я отлично помню их pop3 ;-)
Но самая мякотка - это ASN.1 и ASN.1-based, типа SNMP. С них меня вообще тошнит фонтаном.
> Но самая мякотка - это ASN.1 и ASN.1-based, типа SNMP. С них меня вообще тошнит фонтаном.угу, типичный пример over-engenigring
>> Но самая мякотка - это ASN.1 и ASN.1-based, типа SNMP. С них меня вообще тошнит фонтаном.
> угу, типичный пример over-engenigringдык, itu жеж. от людей, которые изобрели x.400...
Ломай совместимость?
> Ломай совместимость?не ,с совместимостью как раз все хорошо - поэтому и пытаются внедрять административным методом, что оно нахрен не надо пользователю.
Как же навязывают DNSSEC..
Читал я читал про это DNSSEC так и не понял как это может помочь :(
Может кто объяснит на пальцах ?
Точки(сервера) что ли подменяют ? Или провайдеры целят на ДНС-сервера какие им в голову взбредет ?
DNSSEC это цифровые подписи удостоверяющие записи. Это уже хорошо само по себе.
Больше практической пользы лежит в базирующемся на нём DANE. К примеру, потенциально можно вообще отказаться от CA.
Так же, как и IPv6, будь он не ладен. Не переживайте, пройдёт ещё 30 лет, а воз будет и ныне там.
Всегда отключаю при сборке unbound и никогда не настраиваю и не разрешаю проверки DNSSec, ибо с одной стороны это может привести к тому что какие то сайты не откроются, с другой мне нечего терять в случае полного слома днс.ICANN я тоже доверять не собираюсь, как и центрам сертификации - я их не знаю, у них нет обязанностей предо мной.
Итак уже слишком много всяких ключей от интернета развелось с этим повсеместным TLS, лезущим из всех щелей, теперь вот решили ещё и тут гайки закрутить.
> ICANN я тоже доверять не собираюсь, как и центрам сертификации - я их не знаю, у них нет обязанностей предо мной.И как это выглядит в исполнении Вани? Alternate roots?
Это выглядит как: мне похер на ваши потуги, я ничего делать для перехода на TLS, DNSSec не буду.
Одно Кольцо покорит их, одно соберет их,
Одно их притянет и в черную цепь скует их.
> Одно Кольцо покорит их, одно соберет их,
> Одно их притянет и в черную цепь скует их.чаво это только одно?! Мы тоже хотим свою долю!
Но если они додумаются до этого, повторяю, ущерб для них будет очень большой, если не сказать, колоссальный.
На текущий момент DNS-сервера с DNSSEC резолвят не все домены. Видимо поэтому:> "Организация ICANN, регулирующая вопросы, связанные с IP-адресами и доменными именами и интернете, выступила с инициативой повсеместного перехода на использование DNSSEC для всех доменных имён."
Как на win7 то doh или dot настроить? Все сводится к замене dns сервера, но от этого секурности не появится
DNSCrypt 2 поддерживает DoH.
к вопросу о полезности dnssec - если бы он был полноценно внедрен то ситуация вроде той что в презе ниже была бы невозможнаhttps://pc.nanog.org/static/published/meetings/NANOG75/1892/...
Opennet, включай DNSSEC.