Private and authenticated DNS

Например, скажем, у меня есть домен example.com, я хотел бы создать поддомен mypc.example.com (хотя и не только один) это разрешается только для тех телефонов (Android / iOS) и ПК (Windows, Linux), у которых есть определенный ключ, те машины, у которых нет этого ключа, не должны иметь возможность разрешать IP. По сути, это частная замена службам динамического DNS.

Особое внимание я уделяю. Этим предложением ваш вопрос отличается от вопроса о DNS. Вы ищете нечто похожее на DNS, но не DNS.

Механизмы безопасности в DNS сосредоточены в следующих областях:

• Проверка подлинности изменений в авторитетных данных и предотвращение создания ложных сообщений между внутренними системами с помощью поддельных IP-адресов. (динамические обновления и передачи зон)
• Аутентификация авторитетных ответов, видимых рекурсивными серверами, для предотвращения атак с отравлением DNS. (DNSSEC)
• Защита связи между преобразователями заглушек и рекурсивными серверами для улучшения конфиденциальности конечного пользователя и предотвращения взлома на этом пути. (DNS через HTTPS, DNSCrypt и т. Д.)
• Уменьшение количества сетевых ресурсов, которые могут быть использованы поддельными DNS-запросами. (DNS-файлы cookie)

Следует отметить, что конфиденциальность отдельных записей не входит в число этих инициатив. DNS через HTTPS и DNSCrypt действительно предназначены для обеспечения некоторой степени конфиденциальности, но только для преобразователей заглушек, трафик которых может отслеживаться по сети. Защита индивидуальных записей не является целью, которую я преследую, насколько мне известно.

Если бы мне пришлось сделать предположение, причина, по которой конфиденциальность индивидуальных записей не является чьим-либо приоритетом, заключается в том, что она полностью противоречит сути текущей модели проектирования. Считается, что это не имеет большого значения для уровня усилий, необходимых для реализации. (или, если говорить более прямо, это по своей сути плохо подходит для оригинального дизайна). Учетные данные клиента должны быть переданы через рекурсивные системы в авторитетные системы, а для обеспечения конфиденциальности транспорт должен быть безопасным между всеми участниками. Он предъявляет множество требований ко всем участвующим сторонам из-за небольшой воспринимаемой выгоды.

Короче говоря, DNS похож на решение, которое вы ищете, но оно не было построено с учетом модели, которую вы имеете в виду. Комментарий Майкла верен: ваши модели безопасности должны предполагать, что кто-то собирается узнать IP-адрес в какой-то момент с помощью автоматического сканирования или социальной инженерии. В центре внимания безопасности должно быть то, что происходит, когда кто-то отправляет трафик на ваш IP-адрес.

Итак, на самом деле ничего не существует, что это как один продукт. Вы можете , может быть, сколотить несколько вещей, чтобы сделать что-то силимарное, но вряд ли с такими вещами, как iOS / Android, поскольку вы ограничены тем, что вы можете изменить (без взлома / рутирования и т. Д.).

Если если вы хотите защитить запрос от любопытных глаз между клиентом и сервером, вы можете использовать такие вещи, как DNSCrypt или DNS через TLS, но это не решает проблемы, связанной с тем, что кто-либо может запросить ваш домен.

DNSSEC позволяет только проверять что запись фактически соответствует ожидаемому, но, насколько мне известно, не обеспечивает механизма аутентификации. Его цель - подписать ответы DNS, чтобы указать, что запрос не был изменен каким-либо другим объектом после его запроса.

Проблема с тем, что вы хотите выполнить, состоит в том, что DNS работает не так. На фундаментальном уровне DNS - это форма распределенной службы. Когда вы настраиваете DNS-сервер на своем устройстве (телефон, планшет, ПК, ж / д), он будет отправлять все DNS-запросы в это поле и ожидать ответа. Если это поле знает, что это за значение, оно вернет его, если нет, то ему нужно перейти к следующему полю в своей конфигурации и попросить это поле указать значение; этот процесс повторяется до тех пор, пока не будет найден ответ.

Если вы хотите ограничить круг лиц, которые могут запрашивать ваш ящик, лучше всего использовать правила брандмауэра, которые в первую очередь контролируют, кто может отправлять запросы в систему. Очевидно, это не то, что будет работать для мобильных и динамических клиентов.

То, что вы просите, должно быть индивидуальным решением или расширением чего-то вроде DNS через TLS, где может быть добавлена ​​аутентификация. Возможно, что-то вроде сертификата клиента с подключением DNS через TLS можно использовать, чтобы доказать, что клиент - это то, что вы ожидаете, а затем, если это правильно, предоставьте ответ DNS. Я не думаю, что сейчас это доступно с DNS через TLS, но кажется возможным добавить это.

Какова ваша настоящая цель здесь? Когда люди задают такие чрезвычайно конкретные вопросы, как этот, это потому, что они имеют в виду цель и думают, что нашли путь к ее решению ... часто они ищут ответ не в том направлении.

ОБНОВЛЕНИЕ :

ssh'ing в мой ноутбук на основе только доменного имени было бы неплохо

Итак, мы уже выяснили, почему это не будет работать только с DNS. Если вам действительно нужен аутентифицированный DNS, вам придется создать собственное решение, поскольку я не знаю ничего, что делает это сегодня.

Что касается выполнения того, что вы хотите (подключение к вашей машине, несмотря на динамический IP-адрес), я бы посмотрите на такие службы, как TeamViewer, где есть удаленный сервер, который настроен на прием постоянного соединения с вашей клиентской машины. Это позволит вам подключиться к службе, после чего служба сможет настроить «туннель» к удаленному клиенту. Другой такой сервис - это LogMeIn.

Эти инструменты устанавливают постоянное соединение от клиента к серверам поставщиков услуг.Это означает, что вы можете устанавливать соединения через большинство NAT / брандмауэров, поскольку большинство сетей не блокируют исходящий трафик. Отсюда не имеет значения, находится ли ваш ноутбук дома или в местной кофейне, вы все равно сможете добраться до него.