/etc/resolv.conf가 127.0.0.53을 가리키는 이유는 무엇입니까?

/etc/resolv.conf가 127.0.0.53을 가리키는 이유는 무엇입니까?

내 DNS 확인자가 무엇인지 확인하려고 시도했는데 다음과 같은 사실을 발견했습니다.

user@ubuntu:~$ cat /etc/resolv.conf 

nameserver 127.0.0.53
options edns0

내가 찾고 있는 것은 192.168.1.1이것이 나의 기본 게이트웨이, 나의 라우터라는 것입니다.

왜 그것이 가리키는지 이해가 되지 않습니다 127.0.0.53. 해당 IP에 액세스하면 apache2가 해당 콘텐츠를 제공합니다. 누구든지 이 문제를 해결하도록 도와줄 수 있나요? 이 파일이 DNS 확인자 역할을 하는 기본 게이트웨이를 직접 가리켜야 하지 않습니까? 아니면 내가 선호하는 DNS를 직접 가리키는 것이 더 좋을까요 1.1.1.1?

추신: Wireshark를 사용하여 포트 53에서 DNS 패킷을 캡처할 때 보이는 것과는 다르게 192.168.1.1보입니다 .127.0.0.53

답변1

아마도 systemd-resolved서비스로 실행 중일 것입니다.

systemd-resolvedDNS 클라이언트 라이브러리(예: C 라이브러리의 BIND DNS 클라이언트 라이브러리)에서 선택적으로 사용하기 위해 두 개의 구성 파일이 동적으로 생성됩니다.

  • /run/systemd/resolve/stub-resolv.confDNS 클라이언트 라이브러리에 쿼리를 127.0.0.53으로 보내도록 지시합니다. systemd-resolved프로세스가 DNS 쿼리를 수신한 다음 쿼리를 전달하는 곳 입니다 .
  • /run/systemd/resolve/resolv.confsystemd-resolved구성 파일 및 DHCP 임대에 포함된 DNS 서버 정보에서 동적으로 얻은 IP 주소 로 쿼리를 보내도록 DNS 클라이언트 라이브러리에 지시합니다 . 효과적으로 이는 systemd-resolved전달 단계를 우회하지만 systemd-resolved특정 트랜잭션에 대해 실제로 무엇을 전달할지에 대한 복잡한 결정을 내리는 모든 논리도 우회하는 대가를 치르게 됩니다.

두 경우 모두 systemd-resolved도메인 이름 접미사 검색 목록이 구성되고 해당 구성 파일 및 DHCP 임대(이 답변의 범위를 벗어나는 메커니즘에 의해 알려짐)에서 즉석에서 다시 파생됩니다.

/etc/resolv.conf옵션은 다음과 같습니다:

  • 이들 중 하나에 대한 기호 링크;
  • 패키지에서 제공하는 심볼릭 링크를 가리킵니다.변화 없는/usr/lib/systemd/resolv.conf127.0.0.53을 지정하지만 동적으로 계산된 검색 도메인이 없는 의 파일 입니다.
  • 완전히 다른 문서.

이와 같은 심볼릭 링크가 있을 수 있습니다. 이 경우 192.168.1.1 설정이 (아마도) LAN의 DHCP 서버에 의해 DHCP 임대로 배포된다는 점을 이해하면 systemd-resolved관찰한 대로 쿼리 트래픽이 해당 서버로 전달된다는 의미입니다. 애플리케이션의 DNS 클라이언트 라이브러리 자체는 systemd-resolved.

아이러니하게도 그렇긴 하지만할 수 있다systemd-resolved127.0.0.53과의 루프백 인터페이스 트래픽을 제대로 캡처하지 않는 경우 이 트래픽이 (선택적으로) C 라이브러리의 BIND DNS 클라이언트를 우회하고 이 클래스를 생성하지 않기 때문에 이를 볼 수 없을 가능성이 높습니다. 트래픽이 캡처됩니다. .

C 라이브러리에 대한 플러그인인 systemd-resolvedNSS 모듈이 제공됩니다 . nss-resolve이전에 C 라이브러리는 nss-dnsDNS 프로토콜을 사용하여 나열된 서버를 쿼리 /etc/resolv.conf하고 여기에 나열된 도메인 접미사를 적용하는 BIND DNS 클라이언트라는 다른 플러그인을 사용했습니다.

nss-resolve상장되다첫 번째nss-dns파일을 /etc/nsswitch.conf삭제하면 C 라이브러리가 이름→주소 조회를 수행하기 위해 BIND DNS 클라이언트 또는 DNS 프로토콜을 전혀 사용하지 않게 됩니다. 대신 nss-resolve비표준 및 특수 프로토콜이 (시스템 전체) 데스크탑 버스를 통해 사용되며 systemd-resolved, 이는 192.168.1.1 또는 DHCP 임대 및 구성 파일에 명시된 모든 것에 대한 백엔드 쿼리를 다시 수행합니다.

가로채기저것dbus-monitor데스크톱 버스 트래픽을 모니터링하려면 이러한 도구를 사용해야 합니다 . 루프백 네트워크 인터페이스의 IP 트래픽은 물론 IP 트래픽도 아닙니다. 데스크톱 버스는 소켓을 통해 연결되기 때문입니다 AF_LOCAL.

1.1.1.1 또는 기타 IP 주소에 대해 타사 확인 프록시 DNS 서버를 사용하려는 경우 다음 세 가지 옵션이 있습니다.

  • 192.168.1.1을 전달하는 대신 이 주소를 전달하도록 DHCP 서버를 구성하십시오. systemd-resolvedDHCP 임대를 통해 이해되고 사용됩니다.
  • systemd-resolvedDHCP 임대에서 보는 것 대신에 이를 사용하려면 자체 구성 메커니즘을 통해 구성하십시오 .
  • /etc/resolv.conf기호 링크가 아닌 실제 일반 파일인 자신만의 파일을 만들고 그 안에 1.1.1.1을 나열한 다음 BIND DNS 클라이언트를 nss-resolve다시 사용할 수 있도록 닫아야 합니다.nss-dns

구성 systemd-resolved파일은 함께 그룹화된 다양한 디렉터리에 있는 파일 묶음이며, 위의 두 번째 옵션에 대해 구성하는 방법은 이 답변의 범위를 벗어납니다. resolved.conf(5) 매뉴얼 페이지를 읽어보십시오 .

답변2

전체 127.0.0.0/8CIDR 블록은 루프 라우팅에 사용됩니다. 귀하의 호스트는 특정 루프백 주소에서 자체 DNS 서버를 실행하고 있는 것으로 보입니다(또는 적어도 그렇게 생각합니다).

루프백 트래픽은 일반적으로 유선으로 이동하지 않으므로 Wireshark와 같은 클리핑 도구에서 TCP/53 트래픽이 표시되지 않는 것은 놀라운 일이 아닙니다. 기본 설정을 사용하여 루프백 트래픽을 모니터링하지 않기 때문입니다. ss(예)와 같은 도구를 사용하면 ss -plnt | grep ':53'추가 조사를 위해 해당 TCP 포트에서 수신 대기 중인 프로세스(있는 경우)가 표시됩니다.

가능한systemd-resolved관련하여 Ubuntu는 다음에서 설명한 대로 최신 버전에서 루프백 해결 프로그램을 사용하는 것으로 보입니다.이 답변AskUbuntu에서.

답변3

이는 네트워크 이름 확인을 위해 systemd-resolved 서비스를 사용하고 있기 때문입니다. 이 경우 resolvectl status명령을 사용할 수 있습니다. 네트워크(예: wlp1s0)로 이동합니다. 현재 DNS 서버를 확인하세요. 처음에는 내 라우터의 IP 192.168.xx였으며 208.67.222.123라우터 구성 페이지의 DHCP 서버 옵션에서 기본 DNS 서버를 (OpenDNS FamilyShield DNS 확인자)로 업데이트했습니다. 이제 NetworkManager를 다시 시작한 후 실행할 때 얻는 결과는 다음과 같습니다.resolvectl status

Link 3 (wlp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 208.67.222.123
       DNS Servers: 208.67.222.123

현재 DNS 서버가 내 라우터 IP에서 OpenDNS 서버로 변경되었는지 보려면.

관련 정보