Как лучше всего создавать записи A, указывающие на localhost? Считается ли это табу или существуют допустимые случаи, когда это допустимо?
У меня есть дюжина доменов, где я настраиваю «локальные». поддомены, которые указывают на 127.0.0.1, чтобы помочь при локальной разработке веб-приложений, связанных с этими доменами. Мне и другим разработчикам в моей команде часто приходится работать с несколькими сайтами на наших локальных хостах, и ссылка на IP-адреса в URL-адресе или сохранение локальной карты доменов в вашем файле hosts имеет тенденцию вызывать путаницу и становится трудно поддерживать с течением времени.
Поэтому я подумал, что регистрация их как поддоменов будет быстрым и простым способом предоставить ярлыки для всех. Так оно и было. Он работал несколько недель, потом вдруг перестал работать. Итак, я вошел в систему управления DNS моего провайдера, и, конечно же, во все «локальные». Записи были удалены.
Мой хозяин - Godaddy.
Прежде чем я пойду на Godaddy за изменение моих записей DNS без моего разрешения, есть ли законная причина, по которой они бы удалили их? Могли ли они подумать, что это какая-то проблема с безопасностью или нарушение? Godaddy - просто ужасная компания в целом, но смена DNS-провайдера - не моя задача. Это то, на что я должен злиться?
Хотя это может быть немного странно, я не знаю ни одного конкретного стандарта или спецификации, которые запрещали бы делать такие вещи в общедоступном DNS в целом. Возможно, существует какая-то причуда платформы GoDaddy, которая вызывает какие-то проблемы при использовании адресов обратной связи, или, возможно, она была удалена только потому, что она «нестандартная» или «странная».
Если все машины находятся в одной сети и не покидают ее, возможно, вы создадите эти записи на своем внутреннем DNS?
Если бы мне пришлось угадывать, это, вероятно, ошибочная попытка предотвратить отражение трафика. Возьмем следующий пример:
$ORIGIN example.com.
stophittingyourself IN NS ns1.stophittingyourself
ns1.stophittingyourself IN A 127.0.0.1
Если бы я отправил запрос на noreally.stophittingyourself.example.com. к рекурсивному DNS-серверу, он будет следовать по цепочке ссылок и пытаться запросить 127.0.0.1:53. Скорее всего, существует прослушиватель localhost, и в большинстве случаев конечный результат - это сервер, говорящий сам с собой. Это неизбежно приведет к кешируемому сбою ... но каждый раз, когда вы меняете noreally к somethingelse, этот сбой должен кэшироваться отдельно согласно RFC.
В конечном итоге реферал 127.0.0.1 может использоваться для более эффективного использования ресурсов, чем указание на случайный IP-адрес, который либо не отвечает, либо не является авторитетным. Попытка предотвратить это на этом уровне - это странный, особенно потому, что для жертвы имеет смысл объявить список сетей, с которыми она не должна связываться для получения достоверных данных (включая 127.0.0.0/8), но это никогда не мешает бизнесу делать глупости во имя «безопасности» "цитатами из пальцев.
Наполовину связанный касательный: если вы запускаете рекурсивный DNS-сервер и никогда не задумывались об использовании рефералов для направления трафика таким образом, вы можете захотеть узнать, как можно настроить ваше программное обеспечение DNS, чтобы игнорировать эти рефералы. Хотя межсетевой экран также может здесь помочь, я обещаю, что счетчики пакетов на вашем интерфейсе обратной связи будут намного тише, если вы будете обрабатывать клиентский трафик.
Пример на основе BIND:
# refuse to loop back on ourself
server 203.0.113.0/24 { bogus yes; };
server 127.0.0.0/8 { bogus yes; };
server 0000::/3 { bogus yes; };
server fe80::/16 { bogus yes; };
server 169.254.0.0/16 { bogus yes; };
# refuse attempts to funnel requests into private/backbone space
server 172.18.53.1/32 { bogus no; }; # whitelisting example
server 172.18.53.2/32 { bogus no; }; # whitelisting example
server 192.168.0.0/16 { bogus yes; };
server 10.0.0.0/8 { bogus yes; };
server 172.16.0.0/12 { bogus yes; };
server 100.64.0.0/10 { bogus yes; };
A-запись, указывающая на 127.0.0.1, представляет собой угрозу безопасности, поскольку делает возможными XSS-атаки. Больше информации: http://www.securityfocus.com/archive/1/486606/30/0/threaded