Я хочу результаты
nslookup MyIP
дать мое полное доменное имя вместо имени u123123123.online-servers.com, которое по умолчанию настроено моим хост-провайдером, как мне это сделать?
3 ответа
5
Человек, которому необходимо обновить запись, - это человек, который контролирует in-addr.arpa. Зона DNS связана с вашим IP-адресом.
Интернет-провайдер, предоставивший ваш IP-адрес, контролирует эту зону.
Эти зоны in-addr.arpa делегируются интернет-провайдеру, когда они получают распределение IP из своего регионального реестра.
Если вы заботитесь только о том, чтобы все выглядело правильно, вы можете настроить зону in-arpa.addr для своего IP/ сети на своем собственном сервере. Люди часто делают это для адресного пространства RFC1918.
Смотрите также: http://en.wikipedia.org/wiki/Reverse_DNS_lookup
2
Как упомянул Деннис, Ваш провайдер будет поддерживать обратные записи DNS. Некоторые провайдеры будут изменять записи для вас по вашему запросу, но некоторые не будут.
Обратитесь к своему провайдеру и задайте вопрос, больше ничего не поделаешь.
0
Я хочу результаты
nslookup MyIP, чтобы дать мое полное доменное имя вместо имени u123123123.online-servers.com, которое по умолчанию настроено моим хост-провайдером, как мне это сделать?
Итак, проблема здесь в том, хотите ли вы, чтобы ваши хосты видели имена, которые вы установили, или вы хотите, чтобы остальные хосты тоже видели их.
Вы можете настроить локально официальные обратные зоны для своих доменов in-addr.arpa, и ваш сервер имен ответит клиентам, которые запрашивают у него ответы, которые вы хотите, чтобы он дал.
Проблема и причина, по которой другие люди говорят вам, что вам нужно, чтобы ваш интернет-провайдер внес изменения, заключается в том, что, хотя вы можете настроить своих собственных клиентов, чтобы запрашивать у сервера имен записи PTR для обратных зон, вы не можете получить клиентов других людей. попросить вашего сервера имен, не имея полномочий для тех зон, делегированных вам.
Сделайте шаг назад и подумайте, как DNS-клиент получает ответ на DNS-запрос. У клиента очень мало априорных знаний о системе доменных имен. Как правило, DNS-библиотека на клиенте знает только достаточно, чтобы попросить локальный сервер имен обработать запрос для него (очень ограниченный распознаватель, работающий на клиенте, называется обработчиком-заглушкой). Средство распознавания заглушек запрашивает свой запрос сервера имен, для которого он настроен, и устанавливает флаг в заголовке DNS (флаг "Требуется рекурсия" или "RD"), говоря «если вы не знаете ответ, найдите его для мне."
Рекурсивный распознаватель, отвечающий за выполнение запроса, обычно также не имеет достаточных начальных знаний о дереве DNS. Обычно это только список серверов, отвечающих на запросы для самого верхнего (корневого) уровня DNS. Когда он получает запрос, он проверяет свои локальные авторитетные данные (если они есть) и данные, которые он создал в своем кеше, чтобы увидеть, знает ли он уже ответ, и, предположив, что нет, он начинает свой путь вниз с корень.
Делегация
Допустим, вы хотите задать DNS-запрос (любого типа) для wxyz Кто отвечает за это, и как ваш распознаватель узнает, как их найти? Ваш клиент обычно собирается попросить вашего локального распознавателя разрешить запрос для "wxyz". Предположим, что ваш распознаватель уже ничего не имеет в своем кэше и должен пройти через все это ... Он начнется на верхнем уровне DNS (трейлинг ".") И скажет "эй, корневой сервер, расскажи мне, что я хочу знать о" wxyz "
И корневой сервер скажет: «Черт, чувак, я не знаю ответа на этот вопрос. Поговорите с этим чуваком там». У меня есть запись NS (делегация), в которой говорится, что он знает все о .z. "Это называется рефералом. Итак, ваш распознаватель возвращается, не совсем на первое место, и говорит «эй, распознаватель, который знает все о« .z. », Скажите мне, что я хочу знать о« wxyz », и распознаватель, который знает все о .z. говорит "черт возьми, чувак, я не знаю ответа на это. иди поговори с так и так, у меня есть запись NS, говорящая, что она знает все о ".yz"
И поэтому клиент продвигается вниз по цепочке делегирования от корня, следуя записям NS, которые делегируют ответственность за ответы на записи для делегированных зон. Это работает одинаково для всех типов записей, независимо от того, спрашиваете ли вы о записях A, CNAMES, MX или что у вас есть. Поскольку он работает для всех типов записей, он, очевидно, также работает и для PTR.
Обратные зоны
Зоны, которые являются частью .in-addr.arpa. Иерархия использует те же записи NS для делегирования, что и все другие зоны, но делегирования в этой иерархии назначаются объектам, которые владеют (путем назначения) блоком пространства IP-адресов. В какой-то момент в прошлом ваш провайдер заходил в региональный интернет-реестр и запрашивал блок IP-адресов, которые были назначены ему как его собственное адресное пространство. В рамках этого назначения они получили делегирование в Системе доменных имен для той части in-addr.arpa, которая соответствует их назначению.
Дело в том, что любой, кто следует за цепочкой делегирования от корня DNS, попадет к вашему интернет-провайдеру, а не к вам, если только вы не сможете убедить своего интернет-провайдера в дальнейшем передать вам ответственность только за ваш IP-адрес (а). , Вот почему вышеупомянутые респонденты говорят вам, что вы должны иметь дело с вашим интернет-провайдером: если вы хотите, чтобы ваши обратные сопоставления IP-адресов были видны кому-либо, кроме клиентов, которые настроены сначала запрашивать у ваших серверов имен ответ, вы должны либо (а) попросите интернет-провайдера внести необходимые изменения или (b) делегировать вам полномочия. В противном случае никто больше не увидит ответы, которые вы настроили на своем сервере.