☰

사람들이 자주 틀리는 혼란스러운 이름.

tag-icon • tag-icon dns terminology systemd-resolved
사람들이 자주 틀리는 혼란스러운 이름.

https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description설명하다

또한 systemd-resolved는 IP 주소 127.0.0.53의 로컬 루프백 인터페이스에 로컬 DNS 스텁 수신기를 제공합니다. 로컬 API를 우회하여 직접 DNS 요청을 하는 프로그램은 systemd-resolved에 연결하기 위해 이 스텁으로 연결될 수 있습니다.

`/etc/resolv.conf`의 형식을 어떻게 이해합니까?설명하다

DNS 서버와 확인자("스텁 확인자")는 다를 수 있습니다. DNS 요청을 127.0.0.53으로 전달하면 라우터로 전달되어 실제 DNS를 얻을 수 있습니다(예를 들어 로컬 호스트를 처리할 수 있지만 요청을 원격으로 전달할 수 있음). 호스트는 전체 DNS를 얻습니다)).

DNS 서버, 확인자, 스텁 확인자란 무엇입니까?

또한 두 가지 유형의 DNS 서버에 대해 들었습니다(하나는 "확인자"라고 하고 다른 하나는 잊어버렸습니다). 이 두 가지는 무엇을 의미합니까?

답변1

사람들이 자주 틀리는 혼란스러운 이름.

측면에서RFC 1034, "리졸버"와 "네임 서버"가 있습니다. "파서" 설명전체 하위 시스템사용자 프로그램은 특정 아키텍처에 관계없이 "네임 서버"에 액세스하는 데 사용됩니다. 이는 게시된 데이터에 대해 하나 이상의 "네임 서버"를 쿼리하고 아래에 설명된 방식으로 이 데이터를 쿼리 애플리케이션에 대한 최종 답변으로 연결하는 하위 시스템입니다.RFC 1034 § 5.3.3. "파서"는포괄적인쿼리를 실행하는 하위 시스템해결하다.

RFC는 이론적으로 이를 허용합니다.유닉스 중심이 아니다, 모든 쿼리 구문 분석 메커니즘이 각 개별 애플리케이션 내에서 실행되는 일종의 공유 하위 시스템으로 존재할 수 있는 시스템입니다.

RFC 1034 용어에서 "스텁 확인자"는 Unix 및 Linux 세계에서 일반적으로 사용됩니다. 애플리케이션 프로세스 내에서 실행되는 다소 어리석은 DNS 클라이언트 라이브러리로, 동일한 DNS/UDP 및 DNS/TCP 프로토콜에 대해 실행 중인 외부 프로그램과 통신합니다. 백엔드 트랜잭션을 가져와서 프론트엔드 응답을 구축함으로써 쿼리 구문 분석을 실제로 수행하는 또 다른 프로세스입니다.

"Resolver"는 매우 혼란스러운 용어이며 종종 RFC에 반하여 사용됩니다. 그래서 몇 년 전 저는 HTTP에서 빌린 용어를 사용하여 사람들에게 DNS를 설명하기 시작했습니다.프록시 서버,콘텐츠 서버, 그리고고객 데이터베이스신청서 링크.

  • 이것DNS 클라이언트 라이브러리귀하의 신청서에는거의항상 ISC의 BIND DNS 클라이언트 라이브러리입니다. Unix 및 Linux 시스템의 대부분의 C 라이브러리에는 BIND DNS 클라이언트 라이브러리가 포함되어 있습니다. 그러나 다른 여러 DNS 클라이언트 라이브러리가 존재하며 일부 애플리케이션에서 사용됩니다.

    DNS 클라이언트 라이브러리는 이름을 한정하고 추가 자료에 설명된 방식으로 통신할 DNS 프록시 서버를 찾습니다.

  • 초기의DNS 프록시 서버이 특정 설정에서는 systemd-resolved127.0.0.53을 수신합니다.

    이 작업을 수행하는 다른 Unix 및 Linux 소프트웨어로는 Daniel J. Bernstein의 dnscachePowerDNS Recursor, MaraDNS Recursor("Deadwood") 등이 있습니다. unbounddnsmasq

    개인적으로 로컬 인스턴스가 있습니다수정됨dnscache(수신 소켓을 상속할 수 있음) 127.0.0.1을 수신하는 모든 컴퓨터에서 이는 BIND DNS 클라이언트 라이브러리가 명시적인 구성 없이 프록시 DNS 서버가 위치할 것으로 예상하는 기본 위치이기도 합니다.

  • systemd-resolved다른 프록시 서버와 통신할 가능성이 가장 높은 다른 프록시 DNS 서버와 통신합니다.앞으로쿼리가 도달할 때까지 체인을 따라갑니다.해결하다프록시 서버.
  • 기본적으로,시스템화된 사람들이 무언가를 출시할 때바이너리 패키지를 만든 사람이나 로컬 시스템 관리자가 이를 변경하지 않는 한, 확인 프록시 DNS 서버는 Google Public DNS의 일부로 Google이 운영하는 서버가 되며, 일련의정방향 프록시 DNS 서버길이는 1입니다.
  • 시스템 관리자가 Google이 아닌 다른 프록시 DNS 서버를 사용하도록 구성한 경우 systemd-resolved체인이 길어집니다. 이러한 구성의 예로는 LAN에서 로컬로 확인되는 프록시 DNS 서버를 사용하거나 LAN 가장자리의 라우터/게이트웨이에서 실행되는 프록시 DNS 서버를 사용하거나 타사 프록시 DNS를 사용하는 것(대략 최고부터 최악의 순서까지)이 있습니다. 인터넷 프록시 DNS 서버를 통해 서버.
  • 이것프록시 DNS 서버 확인체인의 맨 끝에서 쿼리 구문 분석 및 쿼리와 같은 무거운 작업을 수행합니다.콘텐츠 DNS 서버데이터는 필요에 따라 결합되어 최종 응답을 형성한 다음 프록시 DNS 서버 체인( systemd-resolved체인의 가까운 끝 포함)을 따라 애플리케이션의 DNS 클라이언트 라이브러리로 다시 반환됩니다.

대조적으로, RFC 1034 용어에서 여기의 "확인자"는 실제로 BIND DNS 클라이언트 라이브러리인 systemd-resolvedGoogle Public DNS를 포함하는 거대한 블랙박스이며, RFC에서는 한쪽에 "사용자 프로그램"이 있는 것으로 정의합니다. 콘텐츠 DNS 서버(참조 및 데이터베이스 정보를 "직접" 제공) 사람들은 종종 이 용어를 오용합니다. 때로는 RFC 1034 아키텍처 중립적 "파서" 개념을 오해하여 단일 Unix 또는 Linux 서버 프로그램과 동일하다고 생각하기 때문에 그러나 사실은 그렇지 않습니다. HTTP 용어에는 거대한 블랙박스가 없습니다.

추가 읽기

답변2

systemd-resolved가 포함되어 있는 한 "stub-resolver"는 모든 DNS 확인을 자체적으로 수행하지 않습니다(즉, 루트 DNS 서버 -> tld/gtld 네임서버 -> 권한 있는 네임서버에 연결하지 않음). 대신 이름 확인을 위해 다른 확인자(일반적으로 네트워크 인터페이스 구성을 통해 구성됩니다. 예를 들어 8.8.8.8 또는 1.1.1.1 또는 ISP에서 제공)에 연결합니다.

그 목적은 각 프로그램/클라이언트가 확인자를 직접 쿼리하는 대신 결과를 캐시할 수 있는 스텁 확인자를 쿼리하여 전체 이름 확인 프로세스의 속도를 높일 수 있다는 것입니다. 몇 가지 추가 혜택이 있습니다.

파서와 다소 비슷하기 때문에 스텁이라고 부르지만, 기술적으로는 모든 기능이 결여되어 있기 때문에 파서가 아닙니다.

관련 정보