Провайдерские, публичные? Вы путаете причину и следствие. Какое дело Гуглу до нагрузки на корни? Они решают свои задачи.
Мы просто катимся по инерции. Инерции устаревшей архитектуры интернета и местами пересечения с потребностями Энтерпрайза где нужен был шлюз который бы обслуживал как внутренние зоны так и пересылал запросы на улицу. Производительность здесь вообще не причём. Её успешно может решить хотя бы тот же 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.
Кажется я Вас понял)
Вы имели ввиду, что в корневой зоне содержится информация о NS-серверах "." и о NS-серверах отвечающих за зоны TLD.
Я же говорил про то, что сами зоны TLD не обслуживаются корнями.
К сожалению, не всё так радужно с децентрализацией. В большинстве случаев такие системы для первичной инициализации всё равно используют DNS, а если и не используют, то набор вшитых в софт первичных ip ограничен и вычисляем.
Вот здесь и кроется проблема. Невозможно откатить только ru и рф без переподписания dnssec всего корня. Если сделать такие изменения, то однозначно придётся отказаться от dnssec. Ну либо уже сейчас нужно обязывать внедрять в рекурсеры якоря доверия нового ключа dnssec. И опять же, эта мера поможет только для подконтрольных нам доменах 1го уровня, остальные, по dnssec работать не будут.
Если кабель рубанут, то ничего не произойдёт. Корни в стране имеются. Здесь вопрос именно в том, что если намеренно уничтожат или заменять информацию о ns серверах зоны ru и подобных.
Провайдерские, публичные? Вы путаете причину и следствие. Какое дело Гуглу до нагрузки на корни? Они решают свои задачи.
Мы просто катимся по инерции. Инерции устаревшей архитектуры интернета и местами пересечения с потребностями Энтерпрайза где нужен был шлюз который бы обслуживал как внутренние зоны так и пересылал запросы на улицу. Производительность здесь вообще не причём. Её успешно может решить хотя бы тот же 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 у вас на роутере, но в таком случае у вас роутер, скорее всего, сам занимается резовингом и нсди ему не указ.
Вы имели ввиду, что в корневой зоне содержится информация о NS-серверах "." и о NS-серверах отвечающих за зоны TLD.
Я же говорил про то, что сами зоны TLD не обслуживаются корнями.
Продолжу за вас: «ru это TLD»