Действительно ли там кто-либо является стандартным для DNS <-> аутентификация IP?
Я надеюсь реализовывать механизм аутентификации, который позволяет осуществлять политики доступа на основе доменного имени клиента. Сервер аутентификации использует информацию, доступную в DNS для проверки клиентской авторизации.
Подробнее:
Политика доступа владелец ресурса ограничивает доступ к ресурсу только к определенному субдомену (например, my-x-service.clientexample.com). Для доступа к ресурсу, клиент должен доказать, что он владеет субдоменом или что это - третья сторона, разрешенная получить доступ к тому ресурсу от имени доменного владельца.
Аутентификации, Чтобы доказать, что она действует от имени доменного владельца клиент, нужно было добавить ее IP-адрес в белый список в записях TXT доменного имени. Подлинный сервер соответствует IP-адресу клиентского запроса со списком, опубликованным на записи TXT требуемого обеспеченного домена. Если оба соответствия это предоставляет доступ к ресурсу.
http://maps.serverexample.com/getLocationByname?params
Content-Type: application/JSON
Claim-Domain: my-x-service.clientexample.com
Уже есть ли какой-либо такой стандарт на месте? Я знаю только о SPF, но поскольку он используется для электронной почты, я думаю, что спецификации потребовали бы некоторой обрезки.
Редактирование -
SPF не является учетными данными безопасности
Я думаю, что большое заблуждение состоит в том, что записи SPF предоставляют надежные учетные данные. На самом деле SPF - это не безопасных учетных данных, по крайней мере, в реальном мире безопасности.
DNS - это изначально небезопасный протокол. Он основан на UDP (без подтверждения на транспортном уровне), сам протокол не реализует рукопожатие, и нет криптографической гарантии того, что полученный «ответный» пакет не был подделан. Если вы проведете небольшое исследование, вы сможете найти это повсюду.
Слон в комнате здесь довольно очевиден: если DNS настолько небезопасен, почему SPF может делать то, что делает? Потому что риск невелик. Худшее, что может случиться с SPF, - это сценарий с нулевым усилением: вы вернетесь туда, где были, если бы у вас не было записи SPF. SPF - уродливый компромисс, на который администраторы электронной почты были вынуждены пойти перед лицом гораздо более серьезной проблемы, и это ее масштабы.
Для дальнейшего исследования я рекомендую вам изучить малоизвестный тип записи DNS, называемый ] SSHFP и проблемы, с которыми он сталкивается, чтобы быть полезным. SSHFP - это стандарт для размещения открытого ключа SSH сервера в DNS. Ваш SSH-клиент никогда не попросит вас изначально доверять ключу. Это было бы фантастически . Но если вы посмотрите на предварительные условия для того, чтобы SSH-клиент доверял записи SSHFP , то это точно такая же проблема, которая описывается здесь. Это должно устранить любые оставшиеся сомнения в том, можно ли использовать DNS для предоставления учетных данных безопасности без какой-либо формы доверия корневого сервера имен. (DNSSEC)
Безопасность DNS - не единственная проблема
Хорошо, теперь вы знаете, почему то, что вы описываете , не было сделано раньше. Однако DNSSEC не за горами, верно? Давайте представим на мгновение, что валидация распознавателей DNSSEC доступна каждому, и что DNSSEC не сталкивается с той же инерцией, что и IPv6.
Этого стандарта, вероятно, не будет.
Я знаю цепочку комментариев. сопровождающий ответ Марка - это не то, что вы хотите услышать, но у них есть гвоздь в голову, когда дело доходит до того, что иметь опубликованный список доверенных IP-адресов - плохая идея. Крупные компании будут очень лишены стимулов для внедрения трехступенчатого доверительного управления, когда вы публикуете список IP-адресов в Интернете, которые можно использовать для доступа к их системе. Для них это абсурдная перспектива, особенно когда криптография с открытым ключом существует и является предпочтительным способом управления системами делегированного доверия.
В этом ответе я упомянул две технологии, которые решают гораздо более серьезные проблемы, влияющие на каждый в ИТ в глобальном масштабе, оба из которых сталкиваются со значительной инерцией. Эта инерция ничто по сравнению с тем, чтобы заставить эту птицу летать. Это проклятая правда.
Подумайте, как это будет работать. SPF работает, потому что позволяет удаленным почтовым серверам проверять свою входящую почту, чтобы убедиться, что почта действительно пришла туда, где она предназначена. Это возлагает ответственность на отправителя за то, чтобы в первую очередь иметь запись SPF.
Как это будет работать с записью DNS для доступа в Интернет? Он публикует список клиентов, которым разрешено подключаться к нему, а затем ... что? Затем клиент просто говорит: «О нет! Меня нет в списке! Мне лучше разорвать соединение!» и никто никогда не пишет клиента, который не подчиняется этим записям. И никто не должен запирать двери на ночь, и нам не нужны банки, потому что мы храним наши деньги в обувной коробке под кроватью, а полиция уходит на пенсию, потому что все только начинают ладить, и мир во всем мире больше не является нереальной мечтой.
Если вы хотите, чтобы владельцы ограничивали ресурсы известными IP-адресами, сделайте это так, как это делалось десятилетиями: с помощью брандмауэра. Или сделайте это так, как это делалось почти столько же: с помощью правил конфигурации веб-сервера.
владелец ресурса, чтобы ограничить доступ к одному или нескольким доменным именам.
Самое близкое к этому, что я могу придумать, это запустить все ваши собственные серверы имен и использовать ACL для ограничения кому разрешено запрашивать данную зону.
Пример отрывка из конфигурации (для привязки):
acl trusted_src_ip {
192.168.2.0/24;
2001:db8::/64;
};
zone "mysecretdomain.com" IN {
type master;
file "zones/mysecretdomain.com";
allow-query { trusted_src_ip; };
};
Но это почти наверняка неправильное решение реальной проблемы, которую вы пытаетесь решить.