오프라인 DNS 서버 사용 시도를 중지하기 위해 systemd-resolve를 얻으려면 어떻게 해야 합니까?

DNS 전문가들은 네트워크에서 DNS 서비스 탄력성을 원한다면 이 결정을 클라이언트 구현에 맡길 수 없다는 것을 오랫동안 알고 있었습니다.

이는 고객의 파서 구현으로는 내릴 수 없는 매우 중요한 결정입니다.

이론적으로는 첫 번째 DNS가 실패할 경우 클라이언트가 두 번째 DNS로 대체해야 하지만 여러 가지 이유로 일반적으로 이러한 일은 발생하지 않습니다. 내 경력에서 수년 동안 나는 사람들이 사물을 구현할 수 있을 만큼 똑똑하기 위해 클라이언트 OS 파서에 의존하는 완전한 네트워크에서 큰 실패를 보아왔습니다.

실제로 일반적으로 수행하는 작업은 루트 이름 서버가 수행하는 작업입니다. 즉, DNS 서버의 가상 IP 주소를 인계받을 DNS 클러스터를 생성하는 것입니다. 가장 일반적으로 사용되는 기술은 DNS 애니캐스트입니다. keepdalived를 사용하는 등 더 간단한 아키텍처를 시도해 볼 수도 있습니다.

하지만 무엇을 하든 결정을 고객에게 맡기지 말 것을 강조합니다.

바라보다Linux 및 Quagga를 사용하는 IPv4 Anycast

전통적인 보호 조치는 특정 사이트에 대해 여러 DNS 서버를 설정하는 것입니다. 네트워크의 모든 DNS 클라이언트는 각 서버의 IP 주소로 구성됩니다. 이러한 모든 서버에서 치명적인 오류가 발생할 가능성은 상당히 작으므로 어느 정도 안전 여유가 있습니다.

반면, 많은 스텁 확인자에는 두 개의 DNS 서버만 필요하므로 DNS 토폴로지에서 의미 있는 지리적 분산이 거의 불가능합니다. DNS 스텁 확인자는 일반적으로 구성된 두 개의 DNS 서버 중 첫 번째 서버만 독점적으로 사용합니다. 따라서 한 서버는 전체 쿼리 로드를 담당하고 다른 서버는 유휴 상태로 오류를 기다리게 됩니다. 최적은 아니지만, 그건 중복성의 대가입니다... 그렇죠? 반드시 그런 것은 아닙니다.

DNS 이중화 및 장애 조치는 애니캐스트의 일반적인 사용 사례입니다. 애니캐스트는 IP 주소를 가져와 여러 서버 간에 해당 주소를 공유하는 개념으로, 각 서버는 다른 서버를 인식하지 못합니다. DNS 루트 이름 서버는 애니캐스트를 광범위하게 사용합니다.

추신. 과거에는 ISP 2곳과 대학 1곳에서 iBGP와 OSPF를 사용하여 애니캐스트 DNS를 구현하여 DNS 서비스의 가동 시간 가용성을 크게 향상시켰습니다.

DHCP를 통해 여러 이름 서버를 사용하는 것은 중복성이 아닌 복원력을 위한 것입니다. 여러 개의 네임서버를 사용하려는 것 같습니다. 각 클라이언트는 네임서버가 응답하지 않는지 추적하고 사용을 중지하기 때문입니다. 이러한 유형의 동작/설계를 정말로 원한다면 DNS 서버 자체를 통해 이를 활용해야 하는데, 이는 일반적으로 DNS 클라이언트에서는 불가능합니다. 여기서 자주 볼 수 있는 접근 방식은 DNS 서버가 확인하는 업스트림 DNS 서버를 기준으로 DNS 서버 HA(고가용성)를 만드는 것입니다.

/etc/resolv.conf이것이 작동하지 않는 이유를 알아보려면 이 파일이 작동하는 방식을 살펴보세요 . DHCP에 여러 이름 서버를 추가하면 /etc/resolv.conf각 클라이언트에 해당 파일에 2개의 항목이 제공됩니다. 이 파일은 여러 이름 서버를 처리하기 위한 다음 메커니즘만 제공할 수 있습니다.

.conf를 수동으로 구문 분석

  nameserver Name server IP address

          Internet address of a name server that the resolver should query, either 
          an IPv4 address (in dot notation), or an IPv6 address in colon (and 
          possibly dot) notation as per RFC  2373. Up  to MAXNS (currently 3, see 
          <resolv.h>) name servers may be listed, one per keyword.  If there are 
          multiple servers, the resolver library queries them in the order listed.  
          If no nameserver entries are present, the default is to use the name 
          server on the local machine.  (The algorithm used is to try a name server, 
          and if the query times out, try  the  next, until out of name servers, 
          then repeat trying all the name servers until a maximum number of retries 
          are made.)

이 문장은 다음과 같이 말합니다.

여러 서버가 있는 경우 파서 라이브러리는 나열된 순서대로 쿼리합니다.

파서는 이 목록을 관리하기 위해 아무 작업도 수행하지 않으며 매번 첫 번째 항목부터 시작하여 두 번째 항목 등을 사용하여 맹목적으로 목록을 계속 사용합니다. 그것을 통제하기 위해 할 수 있는 유일한 일은 변화 timeout와 .retriesrotate

시간 초과: n

다른 이름 서버를 통해 쿼리를 재시도하기 전에 확인자가 원격 이름 서버의 응답을 기다리는 시간을 설정합니다. 초 단위 로 측정되며
기본값은 RES_TIMEOUT(현재 5, 아래 참조)입니다. 이 옵션의 값은 기본적으로 30으로 제한됩니다.

시도 횟수: n

호출 애플리케이션을 포기하고 오류를 반환하기 전에 확인자가 이름 서버에 쿼리를 보내는 횟수를 설정합니다. 기본값은 RES_DFLRETRY(현재 2, 아래 참조)입니다. 이 옵션의 값은 기본적으로 5로 제한됩니다.

회전하다

_res.options에서 RES_ROTATE를 설정하면 나열된 이름 서버의 라운드 로빈 선택이 발생합니다. 이는
모든 클라이언트가 매번 처음 나열된 서버를 먼저 시도하도록 하는 대신 나열된 모든 서버에 쿼리 로드를 분산시키는 효과가 있습니다 .

인용하다

• wget이 /etc/resolv.conf에서 두 번째 네임서버를 선택하지 않습니다.
• .conf를 수동으로 구문 분석