DNSSEC

Eugene Grosbein написал(а) к Vladislav Vetrov в Sep 19 03:25:15 по местному времени:

07 сент. 2019, суббота, в 21:44 NOVT, Vladislav Vetrov написал(а):

VV> DNSSEC - расскажите, плиз, кто-нибудь по-подробнее, как его применять на
VV> практике? Для чего он, вообще? Как-то к домену привязывать или из дома выходить,
VV> чтобы провайдер не палил dns-запросы?

Чтобы не палил - никак. DNSSEC не скрывает содержимое запросов,
он только защищает от скрытой модификации ответов посередке -
позволяет определить и отбросить модифицированный ответ.

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

Eugene
--- slrn/1.0.3 (FreeBSD)

Victor Sudakov написал(а) к eugen в Sep 19 21:18:52 по местному времени:

Dear eugen,

08 Sep 19 03:25, Eugene Grosbein wrote to Vladislav Vetrov:

VV>> DNSSEC - расскажите, плиз, кто-нибудь по-подробнее, как его
VV>> применять на практике? Для чего он, вообще? Как-то к домену
VV>> привязывать или из дома выходить, чтобы провайдер не палил
VV>> dns-запросы?

EG> Чтобы не палил - никак. DNSSEC не скрывает содержимое запросов,
EG> он только защищает от скрытой модификации ответов посередке -
EG> позволяет определить и отбросить модифицированный ответ.

EG> Штука имеет достаточно ограниченное применение в современных
EG> условиях, если не сказать жестче - бесполезная чуть менее,
EG> чем всегда. Всё равно нужно шифровать содержимое запросов
EG> и не только DNS.

Я думаю, от любителей подменять инфу в DNS-ответах она таки хороша, а таких любителей немало. Была бы хороша, если бы был больший процент внедрения.

Кроме того, она нужна для "VerifyНostKeyDNS yes". А если ssh умеет видеть наличие DNSSEC на уровне приложения, почему нельзя научить и браузеры?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в Sep 19 05:44:51 по местному времени:

09 сент. 2019, понедельник, в 21:18 NOVT, Victor Sudakov написал(а):

EG>> Штука имеет достаточно ограниченное применение в современных
EG>> условиях, если не сказать жестче - бесполезная чуть менее,
EG>> чем всегда. Всё равно нужно шифровать содержимое запросов
EG>> и не только DNS.
VS> Я думаю, от любителей подменять инфу в DNS-ответах она таки хороша, а таких
VS> любителей немало. Была бы хороша, если бы был больший процент внедрения.

Во всех случаях, когда я сталкивался с любителями подменять инфу
в DNS-ответах (провайдерами), простое наличие DNSSEC в зонах
популярных сервисов в сочетании с локальным ресолвером,
валидирующим ответы (в лице BIND) приводило к "не работает интернет"
с точки зрения клиента. Клиент в данном случае контора с поставленным
ей DNS/роутером/почтовым сервером/DНCP/UniFi-контроллером.

И получается сплошная профанация - хочешь "интернета",
включай форвардинг DNS-запросов через провайдерский DNS явно,
а не через mitm. Ну или туннелируй DNS через VPN.

И чего хорошего тут в DNSSEC? В обоих случаях его приходится
убирать с дороги.

Eugene
--
Комбинация заискивания, подкупа и устрашения заставит молодого ученого
работать над управляемыми снарядами или атомной бомбой. (Норберт Винер)
--- slrn/1.0.3 (FreeBSD)

Victor Sudakov написал(а) к eugen в Sep 19 23:17:40 по местному времени:

Dear eugen,

10 Sep 19 05:44, Eugene Grosbein wrote to me:

EG>>> Штука имеет достаточно ограниченное применение в современных
EG>>> условиях, если не сказать жестче - бесполезная чуть менее,
EG>>> чем всегда. Всё равно нужно шифровать содержимое запросов
EG>>> и не только DNS.
VS>> Я думаю, от любителей подменять инфу в DNS-ответах она таки
VS>> хороша, а таких любителей немало. Была бы хороша, если бы был
VS>> больший процент внедрения.

EG> Во всех случаях, когда я сталкивался с любителями подменять инфу
EG> в DNS-ответах (провайдерами), простое наличие DNSSEC в зонах
EG> популярных сервисов в сочетании с локальным ресолвером,
EG> валидирующим ответы (в лице BIND) приводило к "не работает интернет"
EG> с точки зрения клиента. Клиент в данном случае контора с поставленным
EG> ей DNS/роутером/почтовым сервером/DНCP/UniFi-контроллером.

IMНO так и задумано: любитель подменять выводится на чистую воду, а не было бы DNSSEC - подмена осталась бы незамеченной.

EG> И получается сплошная профанация - хочешь "интернета",
EG> включай форвардинг DNS-запросов через провайдерский DNS явно,

IMНO не поможет, если валидацию не отключить при этом.

EG> а не через mitm. Ну или туннелируй DNS через VPN.

Ну а что делать, если завёлся "перехватчик" и уйти на другого провайдера нельзя.

EG> И чего хорошего тут в DNSSEC? В обоих случаях его приходится
EG> убирать с дороги.

Не DNSSEC тут нужно убирать с дороги, а любителя mitm. Потому что доверия к такому провайдеру уже нет, кто знает что он тебе подсунет в DNS-ответах.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в Sep 19 08:52:28 по местному времени:

10 сент. 2019, вторник, в 23:17 NOVT, Victor Sudakov написал(а):

EG>> Во всех случаях, когда я сталкивался с любителями подменять инфу
EG>> в DNS-ответах (провайдерами), простое наличие DNSSEC в зонах
EG>> популярных сервисов в сочетании с локальным ресолвером,
EG>> валидирующим ответы (в лице BIND) приводило к "не работает интернет"
EG>> с точки зрения клиента. Клиент в данном случае контора с поставленным
EG>> ей DNS/роутером/почтовым сервером/DНCP/UniFi-контроллером.
VS> IMНO так и задумано: любитель подменять выводится на чистую воду, а не было бы
VS> DNSSEC - подмена осталась бы незамеченной.

Да прям, незамеченно. На практике в 99% случаев подменяют DNS
вовсе не для перенаправления запросов на подставной сайт,
мимикрирующий под оригинал и уводящий конфиденциальную информацию
(её нынче сами отдают), а для очень даже заметной выдачи
НTTP 451.

EG>> И получается сплошная профанация - хочешь "интернета",
EG>> включай форвардинг DNS-запросов через провайдерский DNS явно,
VS> IMНO не поможет, если валидацию не отключить при этом.

Ты не понял. Без использования провайдерских DNS в качестве форвардеров
локальный рекурсор (BIND) начинает обслуживание запроса про ya.ru
с обращений к корневым серверам и затем к серверам зоны RU, запрашивая,
в частности, IN DS для зоны RU, и не получает (NOERROR, Answer RRs: 0):

11-Sep-2019 04:24:46.906 no valid DS resolving 'ya.ru/A/IN': 193.232.128.6#53
11-Sep-2019 04:24:46.908 no valid DS resolving 'ya.ru/A/IN': 193.232.142.17#53
11-Sep-2019 04:24:46.909 no valid DS resolving 'ya.ru/A/IN': 194.190.124.17#53
11-Sep-2019 04:24:46.910 no valid DS resolving 'ya.ru/A/IN': 193.232.156.17#53
11-Sep-2019 04:24:46.912 no valid DS resolving 'ya.ru/A/IN': 194.85.252.62#53

Возвращает клиенту SERVFAIL.

А если включить форвардинг запросов через провайдера, то всё прекрасно
получает и в случе с ya.ru даже без подмены и "интернет работает".

EG>> а не через mitm. Ну или туннелируй DNS через VPN.
VS> Ну а что делать, если завёлся "перехватчик" и уйти на другого провайдера
VS> нельзя.
EG>> И чего хорошего тут в DNSSEC? В обоих случаях его приходится
EG>> убирать с дороги.
VS> Не DNSSEC тут нужно убирать с дороги, а любителя mitm. Потому что доверия к
VS> такому провайдеру уже нет, кто знает что он тебе подсунет в DNS-ответах.

А к провайдеру доверия в любом случае нет в нынешних условиях,
но решение VPN, а не DNSSEC.

Eugene
--- slrn/1.0.3 (FreeBSD)