Мы успешно управляем офисной сетью с различными серверами Linux (Ubuntu) и клиентами Windows+Linux уже несколько лет. Один сервер работает как внутренний DNS-сервер, используя пакет DNS-сервера DNSmasq light-weight.
И только сегодня я узнал, что команда
$ nslookup machine.domain.comработает, но
$ nslookup machine.domain.com/НЕ работает --> Несуществующий домен / NXDOMAIN
Это происходило как на машине с Ubuntu, так и на машине с Windows.
Это просто потому, что здесь (т. е. при использовании cmds типа "nslookup" или "host") косая черта в конце считается частью доменного имени, т. е. домен верхнего уровня - "com/"? Или это указывает на какую-то неправильную настройку нашего внутреннего DNS-сервера?
Очевидно, браузеры «обычно» обрабатывают этот слэш правильно в том смысле, что они используют только доменное имя без слэша для поиска DNS и таким образом получают ответ. Я поставил «обычно» здесь, потому что только сегодня я наткнулся на свежий Firefox, установленный на свежей установке Ubuntu 22.04 LTS, где ввод слэша в адресной строке браузера (т. е. machine.domain.com/) странным образом заканчивался сообщением об ошибке NXDOMAIN, упомянутым выше.
И - что еще более странно - только после успешного поиска путем удаления завершающего слеша, он также начал работать с "адресом с косой чертой". Последнее поведение может быть вызвано кэшированием Firefox...
У кого-нибудь есть какие-нибудь соображения для меня? Может быть, это даже комбинация моего непонимания того, как работает DNS (т. е. завершающий слеш или даже последующий путь на самом деле действительно указывает на "другой домен") и бага Firefox (т. е. ошибочное включение слеша в запрос DNS в установленной версии Firefox)? Спасибо!
решение1
Вы смешиваете стандарты; использование «косой черты» является правильным для протокола передачи гипертекста (HTTP).
Адрес, совместимый с HTTP, формируется из определения протокола, за которым следует полное доменное имя (FQDN) и унифицированный индикатор ресурса (URI).
напримерhttps://sub.domain.tld/uri/of/the/resource/being/requested
Протокол: https (протокол HTTP, инкапсулированный в TLS) Полное доменное имя: sub.domain.tld URI: /uri/of/the/resource/being/requested
В то время как DNS предназначен только для преобразования полного доменного имени в IP-адрес, к которому необходимо получить доступ, например
Полное доменное имя: one.one.one.one ipv4: 1.1.1.1
Домен верхнего уровня — это часть полного доменного имени, а именно последняя часть, следующая за .разделителем, например, .com .co.uk .siteи т. д.
Короче говоря, причина того, что любые переданные домены nslookupне разрешаются, заключается в том, что это /интерпретируется буквально, в то время как любой браузер распознает это как одну из частей протокола HTTP.
nslookup пытается разрешить sub.domain.tld/, и любой браузер «запихнет» ввод в полное доменное имя sub.domain.tldи URI/
Надеюсь, это внесет некоторую ясность.
решение2
Как уже упоминалось здесьсвязь(Microsoft) Домены могут содержать только буквенные символы, цифры и символ «-».
Все остальное не является законным.(Неправда, справедливо исправлено @Patrick Mevzek), nslookup, вероятно, не будет это анализировать, или ваш DNS-сервер справедливо отклонит такой глупый запрос :)
Все, что происходит в вашем веб-браузере после косой черты, не является частью DNS, и nslookup этого не понимает.
curl, например, не будет жаловаться и просто увидит это как корень веб-сервера.
curl example.com/
<!doctype html>
<html>
<head>
<title>Example Domain</title>