У меня проблемы с пониманием очень конкретной части службы DNS и ее базовой структуры. Лучше всего это описать, указав конкретную проблему, которая может возникнуть у злонамеренного интернет-провайдера.
Предполагая, что мой интернет-провайдер изменяет SOA записей DNS, которые он доставляет своим пользователям. Как я могу проверить правильность SOA, если я не могу получить доступ к другим DNS-серверам.
Мои знания о процессах на данный момент:
Надеюсь, что сделал свой вопрос максимально понятным. Если возможно, обратитесь к RFC, посвященному этой теме, но также кратко опишите логику, лежащую в основе этого.
Спасибо
Когда я регистрирую DNS у регистратора, я ввожу ответственный DNS-сервер для доменного имени, которое определяет авторитетный DNS-сервер. Это определяет запись SOA для поиска доменного имени. Вот где мне не хватает информации. Как информация регистратора (soa, IP-адрес авторитетного DNS-сервера и т. Д.) Передается в систему службы DNS. Или как клиент проверяет подлинность SOA домена?
Это не совсем то, как это работает, или, возможно, просто проблема с терминологией. (вы можете посмотреть на RFC 8499 «Терминология DNS» для полной информации)
Для разрешения любого доменного имени необходимо, чтобы для него были уполномоченные серверы имен, и эти серверы имен должны быть перечислены в родительской зоне в записях NS.
Итак, если у вас есть example.com ты можешь решить это ns1.example.net и ns2.example.net будут для него авторитетными серверами имен, и вы их настраиваете. Этого недостаточно. Чтобы разрешение работало, оба сервера имен должны быть указаны в родительской зоне, то есть .COM Вот.
Все это является основным механизмом делегирования DNS, поэтому он охвачен каноническими RFC для DNS, а именно RFC 1034 и 1035. Обратите внимание, однако, что они старые, многие из них больше не применяются (и, конечно, много нового не описанные в них теперь применяются), и некоторые термины там, такие как доменное имя, используются с другим значением, чем то, которое мы имеем сегодня.
Как происходит смена родительской зоны? Вы идете к регистратору example.com и предоставить ему серверы имен. Затем регистратор отправит их в реестр через специальный закрытый протокол, обычно EPP, и через «некоторое время» официальные серверы имен реестра в зоне будут иметь записи NS для вашего домена, в которых перечислены ваши серверы имен.
EPP - это STD 69однако вы не получите никакого полезного понимания на высоком уровне, прочитав эти RFC, поскольку они подробно объясняют протокол, чего вы никогда не увидите, потому что это только между реестрами и регистраторами.
Как видите, нигде нет упоминания о SOA в приведенном выше. Запись SOA находится в вашей зоне, а не за ее пределами, и будет возвращена по запросу или по соответствующим запросам любым из ваших официальных серверов имен в вашей зоне.
Также обратите внимание, что регистратор доменного имени и поставщик DNS - это две совершенно разные задачи. Вы выбираете поставщика DNS для управления вашими официальными серверами имен, вы выбираете регистратора для регистрации доменного имени, а затем время от времени обновляете подключенные к нему серверы имен. Конечно, данная компания может выполнять обе задачи одновременно, но технически каждая из них выполняет определенные задачи, не связанные с другой.
Что касается аутентификации записей, чтобы убедиться, что они не подделаны во время передачи, как уже ответил Никита Киприянов, это задача DNSSEC. Существует несколько RFC, охватывающих DNSSEC, и освоить эту технологию нетривиально, вам нужно сначала твердое понимание DNS, включая темные углы, такие как подстановочные знаки и CNAME, а затем базовое понимание криптографии. Вместо RFC для этого я предлагаю сначала ознакомиться с введением из Википедии, которое достаточно хорошо, чтобы подогреть аппетит: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
Подводя итог ОЧЕНЬ широко, с DNSSEC все записи (не только SOA абсолютно все записи в зоне) также будут иметь новые связанные RRSIG записи, содержащие подпись, вычисленную с некоторым ключом над содержимым (запись DNS); если кто-то на пути изменит часть содержимого, подпись больше не будет совпадать (и нет, очевидно, он не может пересчитать подпись на лету, чтобы она снова совпала).
Для вашего конкретного случая использования, о котором вы говорите (злонамеренный интернет-провайдер, который может прослушивать все ваши DNS-запросы - для аналитики -, фильтровать ваши запросы, изменять ответы), некоторые люди (включая некоторых поставщиков браузеров) попытаются убедить вас, что DNS over HTTPS (также существует DNS поверх TLS) решает все проблемы, что неверно, и, по крайней мере, не предоставляет те же услуги, что и DNSSEC. Но идея использования DNS поверх HTTPS (где обычно DNS проходит через порт 53 в TCP и UDP, поэтому весь трафик идет в виде обычного текста; DNSSEC добавляет целостность и аутентификацию, но не конфиденциальность, весь трафик все еще остается открытым) заключается в том, что используя HTTPS, который сам находится поверх TLS, вы получаете конфиденциальность, поскольку TLS будет шифровать все обмены, то есть как ваши запросы DNS, так и ответы DNS.
Сторонники этого мифа не могут адекватно оценить проблему, так это то, что вы получаете конфиденциальность для всех своих DNS-обменов (и связанный с этим факт, что ответы не могут быть изменены; их все еще можно фильтровать), но ТОЛЬКО между вами и рекурсивным DNS. сервер, который вы запрашиваете через DoH (псевдоним DNS через HTTPS). Этот конкретный преобразователь DNS, очевидно, видит и ваши запросы, и ответы, поскольку он работает над ними для вас, и, следовательно, он может дать вам абсолютно то, что он хочет, без каких-либо доказательств подлинности ... если DNSSEC не используется.
SOA - это просто еще одна запись ресурса DNS. Конечно, у него есть особая функция, но то, что относится к DNS RR в целом, применимо и к SOA. Его можно запросить как обычно (например: host -vt soa example.com).
Эта запись состоит из имени авторитетного DNS-сервера, административного адреса электронной почты (в форме «доменного имени», где @ заменяется точкой) и набора чисел, которые определяют порядковый номер зоны (предназначен только для увеличения и никогда go down) и таймеры, для которых очень важно время существования отрицательного ответа, поскольку оно определяет, как долго удаленные кеши могут хранить ответы "NXDOMAIN".
В необработанном "старом добром" DNS нет механизма проверки на подделку DNS RR на лету. Действительно, интернет-провайдер может это сделать и останется незамеченным.
В современном DNS ЕСТЬ средство борьбы с этим. Это называется DNSSEC. По сути, это набор специальных DNS RR с цифровыми ключами и цифровыми подписями, которые аутентифицируют соответствующие RR данных, и всю цепочку доверия, начинающуюся с корня DNS (.), Ключи которого хранятся в любом преобразователе с поддержкой DNSSEC. Эти ключи аутентифицируют серверы, ответственные за TLD, каждый TLD аутентифицирует сервер доменов 2-го уровня и так далее, вплоть до конечного сервера, который аутентифицирует конкретную запись. Следуя этой цепочке доверия, этот преобразователь может обнаружить любое злонамеренное вмешательство. Это включает в себя возможность подтвердить отсутствие какой-либо записи. Также никто не может отрицать тот факт, что домен использует DNSSEC, потому что эта информация подписана их родительским уровнем DNS. Например, зона .com подписана, и, таким образом, если вы предоставите необходимые данные DNSSEC своему регистратору, и они опубликовали их в зоне .com, никто не сможет ложно заявить, что вы не используете DNSSEC для своего домена, потому что это утверждение не будет t проверять по подписям зоны .com, и если они попытаются заявить, что .com не подписан, это не будет проверяться по ключам, хранящимся в самом преобразователе.
В общем, эти подписи остаются действительными даже при обслуживании кэширующим сервером DNS, поэтому это не препятствует кэшированию. Они только подтверждают подлинность представленной записи, созданной официальным сервером, и она представлена без изменений.
Однако злонамеренный интернет-провайдер все еще может отказать в обслуживании такому «слишком умному» преобразователю. Единственное, что преобразователь может сделать, если обнаружит подделку, - это вернуть ошибку, которая приводит к отказу в обслуживании. Затем интернет-провайдер может подделать каждый пакет DNS, чтобы DNS эффективно не работал с включенной проверкой DNSSEC, мотивируя пользователей отключить это, вернувшись к обычному старому небезопасному DNS. Они могут изобрести всевозможные веские причины, чтобы оправдать такое поведение. Затем, убедив пользователей в том, что DNSSEC - это плохо, этот провайдер может сделать что угодно.