Ставил локально Unbound и столкнулся с ошибкой валидации DNSSEC.
Кто сталкивался с подобным? И какие варианты решения имеются? Очень хочется не сливать инфу различным DoH, DoT серверам корпорациям и при этом получать достоверные DNS записи.
Как давно РКН/провайдер занимается подобного рода пакостью? Мотивацию блокировать ресурсы, пользующиеся популярностью у простых смертных мне ясна, но в данном случае это уже вопиющая наглость.
У меня стоит adguard home который selfhosted в Нидерландах, и там проверка dnssec, все ок
Корневые затея излишняя, они самые палённые, ищите DoH или DoT на любителя, выбирайте того кому доверяете, приоритет без цензуры и логирования и вот и ищите таких.
DNSSEC вроде работает на udp 853 порту, по факту его легко заблокировать и прочитать или подменить это DoT и он быстрее чем DoH, но DoH работает на 443 порту, он смешивается в общем трафике и его сложно проследить или подменить, заблокировать конечно могут, но это максимум что они смогут сделать
Вы по сути пересказали тоже самое.
Почему сам факт модификации трафика интернетообразующей инфраструктуры легитимен? Если корневые сервера - это НКО и они так же располагаются на территории РФ.
Как и я указал ранее, иные блокировки мотивированы захватом рынка и госцензурой. Но тут уже прямое вредительство, таким же макаром осталось модифицировать любой TLS.
С каких корневых серверов и что не резволилось?
Каким образом эта ошибка связана с темой топика?
Продиагностировать ошибку.
В DNSCrypt есть проксирующие релеи.
В целом это невозможно, если администратор NS не подписал свои записи. Протокол не предусматривает метод доверия к записям без RRSIG.
Возможность есть давно. DNS спуфинг замечен только у домру (не могу найти ссылку на сообщение валдика).
Нет ответа с DNSSEC со всех серверов перечисленных здесь https://www.internic.net/domain/named.root.
Каким образом эта ошибка связана с темой топика?
Напрямую. Спуфится ответ от корневого, возникает ошибка связанная с DNSSEC.
Пример ошибки в Unbound:
reply from <.> 192.33.4.12#53
info: query response REC_LAME: recursive but not authoritative server
В DNSCrypt есть проксирующие релеи.
Можно про это поподробнее?
Возможность есть давно. DNS спуфинг замечен только у домру (не могу найти ссылку на сообщение валдика).
На Ростелекоме тоже наблюдаю.
А если поднять впн и зайти с “другой стороны”, без использования провайдера, все будет ок?
Не знаток unbound, но для убедительности можно было бы сравнить два ответа в снифере на один запрос: напрямую и через тунель.
Понятно. Поэтому более десяти лет назад настроил себе DNSCrypt на всякий случай.
Да. Вне РФ работает, с такими же настройками.
Что таке спуфинг? Если подмена ответа, скажем, вместо 173.194.1.2 на запрос “google.com” выдает 127.0.0.1 или IP-провайдера со страничкой описания запрета, то у нас такое с 2014г, когда провайдерам приказали заблокировать украинские сайты.
В данном случае подмена не сработает и вернется ошибка из-за DNSSEC.