우리는 수년 동안 다양한 Linux 서버(Ubuntu) 및 Windows+Linux 클라이언트를 사용하여 사무실 네트워크를 성공적으로 운영해 왔습니다. 하나의 서버는 DNSmasq 경량 DNS 서버 패키지를 사용하여 내부 DNS 서버 역할을 합니다.
$ nslookup machine.domain.com그리고 바로 오늘 저는 명령이 작동하지만 작동하지 않는다는 것을 알았습니다
$ nslookup machine.domain.com/--> 존재하지 않는 도메인/NXDOMAIN
이는 Windows 시스템뿐만 아니라 Ubuntu 시스템에서도 발생했습니다.
이것은 단지 여기서(예: "nslookup" 또는 "host"와 같은 cmd를 사용할 때) 끝에 있는 슬래시가 도메인 이름의 일부로 간주되기 때문입니까, 즉 최상위 도메인이 "com/"입니까? 아니면 내부 DNS 서버의 구성이 잘못되었음을 나타내는 것입니까?
분명히, 브라우저는 DNS 조회를 위해 슬래시 없이 도메인 이름만 사용하여 응답을 얻는다는 점에서 "보통" 이 슬래시를 올바르게 처리합니다. 여기에 "보통"이라고 입력한 이유는 바로 오늘 브라우저 주소 표시줄(예: machine.domain.com/)에 슬래시를 입력하면 위에서 언급한 NXDOMAIN 오류 메시지로 이상하게 끝나는 새로운 Ubuntu 22.04 LTS 설치에 설치된 새로운 Firefox를 발견했기 때문입니다 .
그리고 심지어 낯선 사람이라도 후행 슬래시를 제거하여 검색에 성공한 후에야 "슬래시 주소"로 작업하기 시작했습니다. 후자의 동작은 Firefox 캐싱으로 인해 발생할 수 있습니다...
나에게 통찰력을 주는 사람이 있나요? 어쩌면 DNS 작동 방식에 대한 나의 이해가 부족한 것(예: 후행 슬래시 또는 후속 경로가 실제로 "다른 도메인"을 가리킴)과 Firefox 버그(예: 설치된 DNS 쿼리에 슬래시를 잘못 포함한 것)가 결합된 것일 수도 있습니다. 파이어폭스 버전)? 감사해요!
답변1
표준을 혼합하고 있습니다. HTTP(Hyper Text Transfer Protocol)에서는 "슬래시"를 사용하는 것이 정확합니다.
HTTP 호환 주소는 프로토콜 정의, FQDN(정규화된 도메인 이름) 및 URI(Uniform Resource Indicator)로 구성됩니다.
예를 들어https://sub.domain.tld/uri/of/the/resource/being/requested
프로토콜: https(TLS 캡슐화된 HTTP 프로토콜) FQDN: sub.domain.tld URI: /uri/of/the/resource/being/requested
반면, DNS는 FQDN을 도달할 IP 주소로 확인하는 용도로만 사용됩니다. 예:
FQDN: one.one.one.one ipv4: 1.1.1.1
최상위 도메인은 FQDN의 일부, 즉 .구분 기호 다음의 마지막 부분입니다(예: .com .co.uk .siteetc...).
nslookup간단히 말해서 전달된 도메인이 확인되지 않는 이유는 /모든 브라우저가 그것이 무엇인지 인식하는 동안 문자 그대로 해석되기 때문입니다. HTTP 프로토콜의 일부 중 하나입니다.
nslookup은 확인을 시도 sub.domain.tld/하고 모든 브라우저는 FQDN sub.domain.tld및 URI 에 대한 입력을 "척크"합니다./
바라건대 이것이 어느 정도 명확성을 제공하기를 바랍니다.
답변2
여기서 언급했듯이링크(microsoft) 도메인에는 알파벳 문자, 숫자 및 '-' 기호만 포함될 수 있습니다.
다른 것은 합법이 아닙니다.(사실이 아닙니다. @Patrick Mevzek이 올바르게 수정했습니다.) nslookup은 아마도 이것을 구문 분석하지 않거나 DNS 서버가 그런 어리석은 요청을 정당하게 거부합니다 :)
슬래시 이후 웹 브라우저에서 일어나는 일은 DNS의 일부가 아니며 nslookup은 이를 이해하지 못합니다.
예를 들어 컬은 불평하지 않고 이것을 웹 서버의 루트로 봅니다.
curl example.com/
<!doctype html>
<html>
<head>
<title>Example Domain</title>