Чем же отличается верифицированный ответ с NS записями следующего уровня, от верифицированного конечного ответа конечного сервера? Если исходить из злого умысла, то и "авторитет" можно дать не тому кому надо.
Кто-нибудь видел каким серверам был делигирован домен MasterCard? В скрине, зона с самих серверов MasterCard, а была ли эта ошибка на DNS серверах зоны com?
Облачные провайдеры проверяют?? Да не смешите мои тапочки! Они все как один используют dkim как ещё один признак спама в своей весовой модели. Хотя чего говорить, та же RFC гласит "если подпись не проходит проверку - относитесь к письму как к письму без подписи".
Про icmp: Допустим, как вариант, ваш сервер отправляет ответный пакет на ip и порт вопрошающего клиента. Если у клиента истёк тайм-аут ожидания ответа на запрос, то порт закрывается. Пакет на закрытый порт заставит уст-во клиента отправить "icmp port unreachable" в вашу сторону.
Провайдерские, публичные? Вы путаете причину и следствие. Какое дело Гуглу до нагрузки на корни? Они решают свои задачи.
Мы просто катимся по инерции. Инерции устаревшей архитектуры интернета и местами пересечения с потребностями Энтерпрайза где нужен был шлюз который бы обслуживал как внутренние зоны так и пересылал запросы на улицу. Производительность здесь вообще не причём. Её успешно может решить хотя бы тот же any cast dns. Сейчас в большей степени это используют Гугл и подобные ему сервисы, но никто не запрещает делать тоже самое и авторитативным серверам.
Между клиентом и провайдером нет dnssec, и нет шифрования dns трафика. Доверять такому ответу нужно с той же степенью, что и ответу провайдера у которого отключен dnssec. Единственно правильный вариант - иметь свой рекурсор локально, на каждом компе. В идеале, системная функция ОС должна обеспечивать рекурсивную функцию.
Такое ощущение, что у всех dnssec прям локально проверяется, что можно давать советы по отключению dnssec и предупреждать, что это повлияет на безопасность. Ну ок, провайдер на своём рекурсоре включил dnssec верификацию, ну а дальше что? Конечный клиент всё равно не проверяет ответ провайда. Схема с dnssec изначально мертва! Но мы попытаемся решить её с помощью dot/doq/doh. Единственный способ оживить dnssec это сместить функцию рекурсора к клиенту.
По поводу комментария Cloudflare: Нужно заканчивать использовать архаичный инструмент "промежуточный рекурсор", они нужны были на заре становления интернета, когда были большие проблемы со связностью. Сейчас, по хорошему, нужен нормальный полноценный резолвер прямо на клиенте. Тогда бы и с dnssec проблем бы не было (точка верификация находилась бы у клиента, а не где-то посередине) и вся эта возня с DoH/DoT была бы более логичной (возможно немного сложнее, но точно логичнее нежели тупо доверять какой то промежуточной точке).
Кэшировать где? Тут большой вопрос, так к примеру если говорить о PowerDNS Recursor, то если ему ответ прилетает от авторитативного сервера с заполненным расширением ecs, то кэш формируется конкретно по маске сети указанной в ecs, но надо понимать, что авторитативный сервер должен уметь заполнять это поле при ответе. К примеру Bind заполняет его всегда маской /0, так что никакого "узкого" кэша на рекурсоре не сформируется. PowerDNS Auth же просто копирует маску из запроса в ответ, соответственно, кэш на рекурсоре будет формироваться соответственно ширине маски запроса. И если прилетит подобный запрос источник которого не попадает под маску имеющегося ответа в кэше, то рекурсор должен начать полноценный резолв. А вообще, по логике, если к примеру рассматривать в качестве авторитативного сам PowerDNS, то маску можно было бы не копировать из запроса, а к примеру, брать её из условий функции view (Аналог view bind или split dns и т.п.).
Так ли это? Точно скажу, что гугл днс придёт к авторитативному серверу с ip ближайшей точки присутствия гугла, хотя при этом весь мир на стороне клиента использует один ip 8.8.8.8. Иначе гугл ломал бы geodns.
На моём японском виндоме 2000 года, стоит навигация с GPS и гироскопом, а так же имеет подключение к датчику скорости. Да же если нет сигнала gps она вполне успешно определяет и скорость и направление.
Вообще когда я первый раз увидел карты японской навигации 2000х годов, я не поверил своим глазам! Детализация некоторых современных систем очень далека от той, что была в японской «голове».
dmarc это не подпись.
Патентовать то что уже давно изобретено? Та же Yva.ai уже давно всё это реализовала.
Люди, которые думают
что знают всё,
очень раздражают нас.
Людей которые
действительно всё знают! ©
Есть DANE.
Вот только решим проблему последней мили в dnssec и пошлём нафиг эти централизованные CA. Станем сами себе CA.
Чем же отличается верифицированный ответ с NS записями следующего уровня, от верифицированного конечного ответа конечного сервера? Если исходить из злого умысла, то и "авторитет" можно дать не тому кому надо.
Что вы имеете ввиду под "достоверности их ответов " ?
Кто-нибудь видел каким серверам был делигирован домен MasterCard? В скрине, зона с самих серверов MasterCard, а была ли эта ошибка на DNS серверах зоны com?
Облачные провайдеры проверяют?? Да не смешите мои тапочки! Они все как один используют dkim как ещё один признак спама в своей весовой модели. Хотя чего говорить, та же RFC гласит "если подпись не проходит проверку - относитесь к письму как к письму без подписи".
Про icmp:
Допустим, как вариант, ваш сервер отправляет ответный пакет на ip и порт вопрошающего клиента. Если у клиента истёк тайм-аут ожидания ответа на запрос, то порт закрывается. Пакет на закрытый порт заставит уст-во клиента отправить "icmp port unreachable" в вашу сторону.
Провайдерские, публичные? Вы путаете причину и следствие. Какое дело Гуглу до нагрузки на корни? Они решают свои задачи.
Мы просто катимся по инерции. Инерции устаревшей архитектуры интернета и местами пересечения с потребностями Энтерпрайза где нужен был шлюз который бы обслуживал как внутренние зоны так и пересылал запросы на улицу. Производительность здесь вообще не причём. Её успешно может решить хотя бы тот же any cast dns. Сейчас в большей степени это используют Гугл и подобные ему сервисы, но никто не запрещает делать тоже самое и авторитативным серверам.
Почему минус?
Между клиентом и провайдером нет dnssec, и нет шифрования dns трафика. Доверять такому ответу нужно с той же степенью, что и ответу провайдера у которого отключен dnssec.
Единственно правильный вариант - иметь свой рекурсор локально, на каждом компе. В идеале, системная функция ОС должна обеспечивать рекурсивную функцию.
Аргументируйте про время.
Такое ощущение, что у всех dnssec прям локально проверяется, что можно давать советы по отключению dnssec и предупреждать, что это повлияет на безопасность. Ну ок, провайдер на своём рекурсоре включил dnssec верификацию, ну а дальше что? Конечный клиент всё равно не проверяет ответ провайда. Схема с dnssec изначально мертва! Но мы попытаемся решить её с помощью dot/doq/doh.
Единственный способ оживить dnssec это сместить функцию рекурсора к клиенту.
По поводу комментария Cloudflare:
Нужно заканчивать использовать архаичный инструмент "промежуточный рекурсор", они нужны были на заре становления интернета, когда были большие проблемы со связностью. Сейчас, по хорошему, нужен нормальный полноценный резолвер прямо на клиенте. Тогда бы и с dnssec проблем бы не было (точка верификация находилась бы у клиента, а не где-то посередине) и вся эта возня с DoH/DoT была бы более логичной (возможно немного сложнее, но точно логичнее нежели тупо доверять какой то промежуточной точке).
Кэшировать где? Тут большой вопрос, так к примеру если говорить о PowerDNS Recursor, то если ему ответ прилетает от авторитативного сервера с заполненным расширением ecs, то кэш формируется конкретно по маске сети указанной в ecs, но надо понимать, что авторитативный сервер должен уметь заполнять это поле при ответе. К примеру Bind заполняет его всегда маской /0, так что никакого "узкого" кэша на рекурсоре не сформируется. PowerDNS Auth же просто копирует маску из запроса в ответ, соответственно, кэш на рекурсоре будет формироваться соответственно ширине маски запроса. И если прилетит подобный запрос источник которого не попадает под маску имеющегося ответа в кэше, то рекурсор должен начать полноценный резолв. А вообще, по логике, если к примеру рассматривать в качестве авторитативного сам PowerDNS, то маску можно было бы не копировать из запроса, а к примеру, брать её из условий функции view (Аналог view bind или split dns и т.п.).
Так ли это? Точно скажу, что гугл днс придёт к авторитативному серверу с ip ближайшей точки присутствия гугла, хотя при этом весь мир на стороне клиента использует один ip 8.8.8.8. Иначе гугл ломал бы geodns.
Если только dnssec у вас на роутере, но в таком случае у вас роутер, скорее всего, сам занимается резовингом и нсди ему не указ.
Вообще когда я первый раз увидел карты японской навигации 2000х годов, я не поверил своим глазам! Детализация некоторых современных систем очень далека от той, что была в японской «голове».