Если у меня есть доменное имя с серверами имен, указывающими на Webhost One, но у меня есть запись A, указывающая на Webhost Two, к какому хосту меня приведет доменное имя?
Я почти уверен, что A Record имеет прецедент, не так ли? В настоящее время у меня есть домены с GoDaddy, но я указываю запись A на 000Webhost. Мой домен приводит меня к 000Webhost. Но не означает ли это, что данные WHOIS домена неточны?
Это значит, что серверы имен указывают на GoDaddy, а затем GoDaddy указывает на 000Webhost? Или он идет прямо на 000WebHost?
Причина, по которой я спрашиваю, заключается в том, что у моего друга есть веб-сайт, который указывает на веб-хост, но у этого веб-хоста нет записей о том, что этот сайт размещен там, и тем не менее этот сайт был в сети уже десять лет. Так что мне интересно, имеют ли серверы имен когда-нибудь прецедент, или, действительно, что происходит?
Я думаю, вы сильно не понимаете, как работает DNS. Записи NS используются для поиска авторитетного сервера для домена. Запись ресурса A - это то, что запрашивает клиент (обычно), и это то, что будет искать ответ клиенту.
Быстро-иш:
Допустим, у вас есть example.com. Кто-то входит http://www.example.com в свой веб-браузер. Их компьютер выполняет рекурсивный поиск www.example.com на локальном DNS-сервере. Этот сервер не знает, какой IP-адрес соответствует www.example.com, поэтому он определяет самый низкий уровень домена, для которого ему известны серверы. В данном случае это . корневые серверы. Доменное имя www.example.com на самом деле www.example.com. <- обратите внимание на "." в конце.
Таким образом, DNS-сервер связывается с корневым сервером и спрашивает их, знают ли они, где находится www.example.com. Они этого не делают. Они действительно знают, где "com". Тем не менее, это было из NS-записей для этого домена. Эта NS-запись возвращается на DNS-сервер. Таким образом, DNS-сервер связывается с "com." server и спрашивает их, знают ли они, где находится www.example.com, они тоже не знают. Но они точно знают, где находится «example.com». опять же по NS-записям, которые указывают на a.iana-servers.net. и b.iana-servers.net.. Никто «просто не знает», где находятся эти серверы, поэтому связующие записи для этих доменов регистрируются в «сети». корневые серверы. Больше поисков в "сети". корневые серверы ...
DNS-сервер теперь знает, как связаться с сервером для example.com. домен! Поэтому он спрашивает этот сервер, знает ли он, где находится www.example.com, и знает! У этого сервера есть запись SOA, которая определяет его как авторитетный для example.com. домен, и он знает запись A для 'www.example.com', IP-адрес, на который он указывает. DNS-сервер возвращает этот IP-адрес клиенту, и мир в безопасности еще на одну ночь.
Детали Моара:
Когда клиент запросил www.example.com от DNS-сервера он сообщил DNS-серверу, что ищет запись A (A для IPv4; в наши дни клиенты также обычно ищут записи IPv6 AAAA). Когда другой DNS-сервер получил запросы для записи A, они также искали записи CNAME, но не искали другие типы записей. DNS-сервер знает, что, когда запрос на более длинное доменное имя терпит неудачу (например, корневые серверы не знают, где находится www.example.com), DNS-сервер будет интересоваться, какая информация у этого сервера есть, например. запись (и) NS. Как это работает, сложнее, чем вы думаете, но корневой сервер определенно возвращает своего рода «отказ», когда DNS-сервер пытается найти домен.
Если клиент запрашивал запись MX для электронной почты, или запись SRV, или запись TXT, или что-то еще, отвечающий DNS-сервер не будет просто искать любой тип записи, который соответствует указанному имени домена, он будет искать только тот же тип записи (за исключением случаев поиска записей A или AAAA, результаты для совпадения CNAME будут возвращены, если не совпадают записи A или AAAA). Также сервер может иметь записи «по умолчанию» или записи с подстановочными знаками, которые также могут совпадать, но подчинены прямым совпадениям. Лучше избегать таких ситуаций, если вы действительно не знаете, что делаете.
Нет такой вещи, как «приоритет» с записями A у разных провайдеров. Существует один авторитетный служба имен для вашего доменного имени. Я не могу извлечь из вашего объяснения, какой именно провайдер в вашем случае.
Но если вы можете сделать быстро dig +trace yourdomain.name вы увидите «цепочку» запрашиваемых DNS-серверов, начиная с корневой зоны. (Или просто передайте доменное имя, о котором идет речь.) Вы увидите, какой провайдер предоставит вам официальный адрес, по которому будет следовать ваш браузер.
Возможно, вас смущает тот факт, что DNS-информация о вашем домене хранится не только у провайдера. Это может иметь место по любой причине, но до тех пор, пока провайдер не хранит авторитетные записи, реальный клиент никогда не будет запрашивать его.
Ответ Криса наиболее актуален для ситуации с ОП. Однако это является Фактически возможно иметь NS и A-запись в одном и том же полномочном диспетчере DNS. В этом случае «что имеет приоритет» в ответе Криса прямо не рассматривается. Ответ заключается в том, что запись NS имеет приоритет над записью A.
Я использовал записи в Google Domains для тестирования. Поддомен не разрешается, пока оба существуют (запись NS указывает на серверы имен без записи для поддомена). Если я переименовываю NS-запись в другой поддомен, A-запись «открывается» и разрешается в указанный IP-адрес. Если я переименовываю NS-запись обратно, она снова «маскирует» A-запись и не дает действительного ответа.