☰

systemd-resolved는 단일 레이블 DNS 조회 요청을 어떻게 처리합니까?

tag-icon • tag-icon dns systemd-networkd systemd-resolved
systemd-resolved는 단일 레이블 DNS 조회 요청을 어떻게 처리합니까?

나는 systemd-networkd와 systemd-resolved를 조사했습니다.

나는 몇 가지 단어에 대해 혼란스러워합니다.

  • systemd-resolved.service(8)

    단일 레이블 이름은 LLMNR 프로토콜을 사용하여 IP 멀티캐스트가 가능한 모든 로컬 인터페이스로 라우팅됩니다. 각 인터페이스 도메인 중 하나로 끝나는 호스트 이름에 대한 조회는 일치하는 인터페이스로만 라우팅됩니다.

  • 시스템 네트워크(5)

    "검색" 도메인과 "경로 전용" 도메인은 모두 DNS 쿼리 라우팅에 사용됩니다. 이러한 도메인으로 끝나는 호스트 이름(따라서 "검색 도메인"이 나열되어 있는 경우 단일 레이블 이름도 포함)에 대한 조회는 다음으로 라우팅됩니다. 이 인터페이스에 대해 구성된 DNS 서버입니다.

내 질문은: "검색 도메인"으로 구성되고 LLMNR이 활성화된 많은 수의 인터페이스가 있는 호스트의 경우 단일 레이블 조회 요청은 어디로 가나요?

내 혼란에 대한 자세한 내용은 다음과 같습니다.

  • 인터페이스가 검색 도메인 "mydomain"으로 구성되고 LLMNR이 비활성화된 경우 단일 레이블 조회 요청이 이 인터페이스로 라우팅됩니까?
  • 인터페이스가 검색 도메인 "mydomain"으로 구성되고 LLMNR이 활성화되고 "xyz"에 대한 조회 요청이 들어오는 경우 LLMNR을 통한 "xyz"와 지정된 DNS 서버를 통한 "xyz.mydomain"이 모두 발생합니까?

답변1

이 질문은 설명하는 데 오랜 시간이 걸립니다. 짧고 부정확한 설명은 다음과 같습니다.

단일 라벨 조회 요청은 어디로 가나요?

단일 라벨? ( localhost다른 사람을 기다리지 않음): 항상 LLMNR 시스템으로 이동합니다.

태그가 여러 개인가요? : 각 인터페이스에 대한 DNS 서버입니다. 실패 시(또는 구성되지 않은 경우) 글로벌 DNS 서버로 전송됩니다.

예, 일반적인 순서는 다음에 설명되어 있습니다.systemd-resolved.service(8) 하지만:

경로 조회는 각 인터페이스의 도메인 이름 구성에 따라 영향을 받을 수 있습니다. 바라보다시스템 네트워크(5)더 알아보기.

설정시스템 네트워크(5)DNS 확인을 위한 추가 리소스로 사용됩니다.

그리고, 이것을 알고RFC 4795에서:

LLMNR은 로컬 링크에서만 작동하므로 DNS를 대체한다고 간주할 수 없습니다.

순서(간체)는 다음과 같습니다.

  • 로컬, 구성CPU 이름범위별로 정렬된 모든 로컬로 구성된 IP 주소 또는 (구성되지 않은 경우) IPv4 주소 127.0.0.2(로컬 루프백에 있음) 및 IPv6 주소::1(로컬 호스트)로 확인됩니다.

  • 호스트 이름 "localhost" 및 "localhost.localdomain"(및 ".localhost" 또는 ".localhost.localdomain"으로 끝나는 모든 호스트 이름)은 IP 주소 127.0.0.1 및 ::1로 확인됩니다.

  • 호스트 이름 "_gateway"는 다음으로 확인됩니다.

  • /etc/hosts(이전 및 이후) 에 정의된 매핑을 포함합니다 .

  • 만약에검색할 이름에 점이 없습니다.(점으로 구분된 이름과 유사 home.) LLMNR 프로토콜에 의해 구문 분석됩니다.

    LLMNR 쿼리는 포트 5355에서 보내고 받습니다. RFC 4795

  • 특정 도메인 확장자(예: ".local", 전체 확장자 목록 참조)가 포함된 다중 단어(점 1개 이상) 이름은 systemd-resolve --statusMulticastDNS 프로토콜을 통해 확인됩니다.

  • Domains=목록과 여러 단어로 구성된 이름 확인시스템 네트워크(5) 인터페이스당일치하는 항목이 있으면 DNS 서버 목록을 표시합니다.저것인터페이스가 사용됩니다.

  • 다른 다중 레이블 이름은 구성된 DNS 서버가 있는 모든 로컬 인터페이스와 전역적으로 구성된 DNS 서버(있는 경우)로 라우팅됩니다.

#편집하다

귀하의 질문 제목은 다음과 같습니다.

systemd-resolved는 단일 레이블 DNS 조회 요청을 어떻게 처리합니까?

따라서 내 답변은 systemd-resolved전문적인 질문에 중점을 둡니다.

이제 당신은 묻습니다:

  1. 인터페이스가 검색 도메인 "mydomain"으로 구성되고 LLMNR이 비활성화된 경우 단일 레이블 조회 요청이 해당 인터페이스로 라우팅됩니까?

  2. 인터페이스가 검색 도메인 "mydomain"으로 구성되고 LLMNR이 활성화되고 "xyz"에 대한 조회 요청이 들어오는 경우 LLMNR을 통한 "xyz"와 지정된 DNS 서버를 통한 "xyz.mydomain"이 모두 발생합니까?

systemd-resolved이는 배타적 범위 내에 있지 않은 것으로 보입니다 .

그것들을 분석해 봅시다:

systemd-resolved비활성화/중지된 경우 없음LLMNR사용 중이지만(Avahi, Apple Bonjour 또는 이와 유사한 것을 설치하지 않는 한) 확실히 이는 systemd-resolved구성 범위를 벗어납니다.

이 경우 다음과 같은 질문을 던져야 합니다. 이름 확인이 실패하면 어떻게 됩니까? (서버가 응답할 수 없기 때문입니다.) 그건에서 구성nsswitch(문서 /etc/nsswitch.conf). Ubuntu(Debian과 같은)의 기본 구성에는 다음 줄이 포함되어 있습니다.

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

저것방법(nsswitch의 말에 따르면):

  1. 먼저 파일을 확인하십시오 /etc/hosts. 찾을 수 없으면 계속하세요.

  2. 노력하다 mdns4_minimal(Awashiet al.), 이름이 .local로 끝나는 경우에만 멀티캐스트 DNS를 통해 이름을 확인하려고 시도합니다. 그러한 mDNS 호스트가 존재하지만 찾을 수 없는 경우 mdns4_minimal은 NOTFOUND를 반환합니다. NOTFOUND에 대한 기본 이름 서비스 전환 응답은 다음에 나열된 서비스를 시도하지만 [NOTFOUND=return] 항목은 이를 덮어쓰고 이름이 확인되지 않은 채 검색을 중지합니다. mdns4_minimal이 UNAVAIL(실행 중이 아님)을 반환하면 dns로 이동합니다.

줄거리가 두꺼워진다모두가되고 싶어이름 목록의 첫 번째 이름을 해결하세요.각 사람은 모든 결의안을 스스로 완료하겠다고 제안합니다.

  1. dns항목nsswitch 사실 nss-resolve먼저 전화해nss-dns를 대체합니다.

    nss-resolve는 GNU C 라이브러리(glibc)의 GNU 이름 서비스 전환(NSS) 기능을 위한 플러그인 모듈로, systemd-resolved(8) 로컬 네트워크 이름 확인 서비스를 통해 호스트 이름을 확인할 수 있습니다. 이는 전통적으로 DNS를 통해 호스트 이름을 확인하는 nss-dns 플러그인 모듈을 대체합니다.

    이는 일반적으로 파일의 DOMAINS=몇 가지 항목 /etc/systemd/resolved.conf및/또는 각 인터페이스 에 따라 달라집니다 . /etc/systemd/network위에서 이미 설명했는데편집하다입구.

    sytemd-resolved가 nsswitch의 dns 항목 이전에 DNS 서버 자체를 쿼리할 수 있다는 점을 이해하세요.

  2. 아직 찾을 수 없으면( [notfound=return]항목 없음) DNS 서버가 시도됩니다. 이름이 .local로 끝나지 않으면 이 현상이 거의 즉시 발생하고, 그렇다면 전혀 발생하지 않습니다. [NOTFOUND=return] 항목을 제거하면 nsswitch는 유니캐스트 DNS를 통해 확인되지 않은 .local 호스트를 찾으려고 시도합니다. 이는 대부분의 요청을 결코 해결할 수 없는 인터넷 DNS 서버로 보내기 때문에 일반적으로 나쁜 일입니다. 분명히 이것은 꽤 자주 발생합니다.

  3. 최종myhostname​최후의 조치localhost, 호스트 이름, *.local 및 기타 기본 이름에 대한 확인자입니다.

만약에systemd-resolvedLLMNR=no하나 있다/etc/systemd/resolved.conf위에 적용된 것과 동일한 목록 에 있지만 systemd-resolved여전히 설정을 구문 분석 localhost하고 적용 할 수 있습니다 DOMAINS=(전역 또는 인터페이스별).

분명한systemd-resolved에는 LLMNR 설정이 있고 systemd-networkd에는 링크별 LLMNR 설정이 있습니다. 협회.

#이게 다 무슨 뜻인가요? 구성이 매우 구체적이지 않으면 어떤 일이 발생할지 판단하기가 어렵습니다. 서비스를 비활성화하고 어떤 일이 발생하는지 (귀하의 구성이 있는 컴퓨터에서) 시도해야 합니다.

#Q1

인터페이스가 검색 도메인 "mydomain"으로 구성되고 LLMNR이 비활성화된 경우 단일 레이블 조회 요청이 해당 인터페이스로 라우팅됩니까?

응, 물론이지가능한. LLMNR을 비활성화하면 로컬 구문 분석만 방지됩니다(다른 서버는 로컬에서 사용할 수 없습니다(예: .local) 네트워크에 질문이 표시되지만 이름 확인자는 (음수라도) 답을 찾아야 하므로가능한(없으면찾을 수 없음=반품예를 들어 mylocalhost.mylocaldomain확인이 시작되면 일치하는 인터페이스에 대한 DNS 서버에 확인을 위해 접속하고 검색 도메인에 mylocalhost항목이 있고 일치하는 인터페이스에 대한 DNS 서버에 확인을 위해 접속합니다. mylocaldomain답변일반적인의미가 거의 불가능하고 변수가 너무 많습니다.

#2분기

인터페이스가 검색 도메인 "mydomain"으로 구성되고 LLMNR이 활성화되고 "xyz"에 대한 조회 요청이 들어오는 경우 LLMNR을 통한 "xyz"와 지정된 DNS 서버를 통한 "xyz.mydomain"이 모두 발생합니까?

아니요.모든 것이 올바르게 구성되었다면단일 레이블 이름 "xyz"는 LLMNR로만 확인할 수 있으며 요청이 있어도 DNS 서버는 이를 확인하려고 시도해서는 안 됩니다. 글쎄, 그게 이론이다. 하지만 DNS 시스템은~ 해야 하다해결되었습니다 com(분명히 그렇지 않으면 네트워크가 지금처럼 다운될 것입니다). 하지만 쉽게 해결할 수 있는 방법이 있습니다. Ask com., 점이 있고 FQDN입니다. 어떤 경우든 NOERROR서버에 레이블에 대한 정보가 충분하지 않고 루트 서버에서 확인을 계속해야 하는 경우(의 경우 .) DNS 서버는 빈 A(또는 AAAA)로 응답해야 합니다. 또는 존재하지 않는 도메인을 처리하려면 NXDOMAIN(추가 구문 분석을 피하기 위한 최선의 답변)을 사용하세요.

이를 제어하는 ​​유일한 안전한 방법은 로컬 DNS 서버를 보유하고 확인할 이름과 확인하지 않을 이름을 선택하는 것입니다.

답변2

LLMNR 및 DNS를 사용하여 이러한 모든 응답으로 라우팅하고 수신된 첫 번째 응답이 사용됩니다.

시스템 구문 분석에 대해서는 맨페이지의 다음 섹션을 참조하십시오.

조회가 여러 인터페이스로 라우팅되는 경우 첫 번째 성공적인 응답이 반환됩니다. 따라서 일치하는 모든 인터페이스의 조회 영역이 효과적으로 병합됩니다. 모든 인터페이스에서 조회가 실패하면 마지막으로 실패한 응답이 반환됩니다.

관련 정보