1 DNS 구성
1.1 DNS 구성 보기
Linux의 DNS 구성은 /etc/resolv.conf에 있습니다. 먼저 컨테이너 구성을 살펴보겠습니다.
/ # cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.11
nameserver 192.168.1.12
이것은 실제로 호스트 시스템의 DNS 구성을 상속합니다.호스트 시스템에서 cat /etc/resolv.conf를 실행하면 동일한 결과를 볼 수 있습니다.
1.2 DNS 구성 수정
/etc/resolv.conf에서 네임서버를 수정하여 사용할 DNS 서버를 구성할 수 있습니다. 예를 들어, 내부 네트워크 환경은 내부 네트워크 도메인 이름 확인을 제공할 뿐만 아니라 공용 네트워크 도메인 이름 확인이 더 빠르기 때문에 자체 DNS 서버를 사용할 수 있습니다(네트워크 공급자의 공용 네트워크 DNS 서버에 비해).
2 DNS 공통 문제
2.1 머신에 DNS가 구성되지 않아 도메인 이름 조회 실패
1) 현상
네트워크가 연결되어 있지만(예: ping IP) DNS 쿼리가 항상 실패합니다.
2) 예비사유
기기에 구성된 DNS 서버가 없습니다.
3) 솔루션
/etc/resolv.conf를 수정하여 시스템에 적절한 DNS 서버를 구성합니다. 때때로 새로 시작된 시스템(물리적 시스템, 가상 시스템 또는 컨테이너)에 DNS 설정이 없어 도메인 이름.
4) 재현
일반 컨테이너에서 nslookup 도구를 사용하여 도메인 이름에 해당하는 IP 주소를 확인합니다.
/ # nslookup example.com
Name: example.com
Address 1: 93.184.216.34
Address 2: 2606:2800:220:1:248:1893:25c8:1946
도메인 네임의 IPv4 주소와 IPv6 주소를 각각 하나씩 획득한 것을 확인할 수 있다.
DNS 서버가 구성되지 않은 시나리오를 시뮬레이트하려면 #을 사용하여 /etc/resolv.conf의 DNS 서버 목록을 주석 처리하십시오.
다시 테스트:
/ # nslookup example.com
nslookup: can't resolve 'example.com': Try again
따라서 이런 종류의 문제가 발생하면 /etc/resolv.conf에서 DNS 서버가 구성되어 있는지 먼저 확인할 수 있습니다.
2.2 DNS 서비스가 너무 느림
1) 현상
DNS 조회가 너무 느림
2) 예비사유
구성된 DNS 서버가 비합리적입니다.
3) 솔루션
/etc/resolv.conf를 수정하여 적절한 DNS 서버 구성
각 회사는 일반적으로 인트라넷 DNS를 해결하는 데 사용될 뿐만 아니라 공용 네트워크 도메인 이름의 해결 속도를 높일 수 있는 자체 유지 DNS 서버를 가지고 있습니다.
dig는 또 다른 강력한 DNS 쿼리 도구입니다. 다음을 설치하세요.
/ # apk update && apk add bind-tools
먼저 인트라넷 DNS를 사용하여 도메인 이름 쿼리 지연을 확인합니다.
/ # dig example.com
...
example.com. 15814 IN A 93.184.216.34
;; Query time: 0 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
1ms 이내로 매우 빠르다는 것을 알 수 있습니다.
그런 다음 Google의 공용 DNS 서버 8.8.8.8을 사용하는 경우 지연이 어떻게 되는지 테스트합니다.
/etc/resolv.conf를 수정하고 다른 네임서버를 주석 처리하고 nameserver 8.8.8.8 라인을 추가합니다.
다시 테스트:
/ # dig example.com
...
example.com. 15814 IN A 93.184.216.34
;; Query time: 150 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
지연은 이전보다 150배 이상 큰 150ms가 됩니다.
따라서 DNS 쿼리가 특히 느린 시나리오의 경우 먼저 구성된 DNS 서버가 합리적인지 확인하십시오.
2.3 하드코드 /etc/hosts로 인해 DNS 쿼리가 건너뛰게 됨
1) 현상
도메인 이름에 대한 액세스가 너무 느리고, 도메인 이름은 항상 동일한 IP를 가리키며(여러 IP의 경우) 특정 시스템이 도메인 이름에 액세스할 수 없습니다.
2) 예비사유
/etc/hosts에는 하드코드 도메인 이름과 IP가 있습니다.
3) 솔루션
/etc/hosts 수정
앞에서 언급했듯이 대부분의 공용 도메인 이름은 여러 IP 주소에 해당하므로 각 DNS 쿼리에서 얻은 IP 주소는 다를 수 있습니다.핑을 사용하여 테스트할 수 있습니다.
/ # ping baidu.com
PING baidu.com (220.181.57.216): 56 data bytes
64 bytes from 220.181.57.216: seq=0 ttl=45 time=26.895 ms
64 bytes from 220.181.57.216: seq=1 ttl=45 time=26.701 ms
^C
/ # ping baidu.com
PING baidu.com (123.125.115.110): 56 data bytes
64 bytes from 123.125.115.110: seq=0 ttl=43 time=27.587 ms
64 bytes from 123.125.115.110: seq=1 ttl=43 time=27.757 ms
^C
두 ping 테스트(내부적으로 baidu.com의 해당 IP 주소를 먼저 쿼리)로 얻은 IP 주소가 서로 다른 것을 볼 수 있습니다. nslookup을 사용하여 baidu.com에 해당하는 모든 IP 주소인지 확인합니다.
/ # nslookup baidu.com
Name: baidu.com
Address: 220.181.57.216
Name: baidu.com
Address: 123.125.115.110
/etc/hosts에서 도메인 이름에 해당하는 IP 주소를 직접 하코딩할 수 있습니다. 그러면 시스템이 DNS 쿼리를 건너뛰고 이 IP를 도메인 이름의 IP로 직접 사용하게 됩니다. 확인합시다.
/etc/hosts를 수정하고 123.125.115.110 baidu.com 줄을 추가한 다음 다시 ping 테스트를 수행합니다.
/ # ping baidu.com
PING baidu.com (123.125.115.110): 56 data bytes
64 bytes from 123.125.115.110: seq=0 ttl=43 time=27.861 ms
^C
--- baidu.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 27.861/27.861/27.861 ms
/ # ping baidu.com
PING baidu.com (123.125.115.110): 56 data bytes
64 bytes from 123.125.115.110: seq=0 ttl=43 time=27.614 ms
^C
이는 몇 번을 실행해도 baidu.com에 해당하는 IP 주소는 변경되지 않습니다. 실제로 이 IP 주소는 최적의 IP 주소가 아닐 수 있으며 심지어 사용할 수 없어 baidu.com에 액세스하지 못할 수도 있습니다. 따라서 실제로는 /etc/hosts에서 하드코드를 사용하지 않도록 하십시오.
2.4 DNS 쿼리가 불안정합니다.
1) 현상
DNS 쿼리가 불규칙하고 간헐적으로 빠름
2) 예비사유
머신에 tc 또는 iptables 규칙이 있어 DNS 서버에 대한 패킷이 느리거나 손실됩니다.
3) 솔루션
tc/iptables 규칙 수정 또는 삭제
4) 테스트 시뮬레이션
tc를 사용하여 네트워크 지연을 시뮬레이션할 수 있습니다.
/ # apk add iproute2
먼저 tc 규칙이 있는지 확인합니다.
/ # tc -p qdisc ls dev eth0
기본적으로 규칙은 없습니다.
하나 추가: 각 패킷은 600ms 지연됩니다.
/ # tc qdisc add dev eth0 root netem delay 600ms
/ # tc -p qdisc ls dev eth0
/ # qdisc netem 8001: root refcnt 2 limit 1000 delay 600.0ms
시험:
/ # dig example.com
...
example.com. 15814 IN A 93.184.216.34
;; Query time: 600 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
보시다시피 DNS 쿼리는 600ms가 됩니다.
여기서 테스트는 고정 지연이며 이러한 종류의 문제는 쉽게 찾을 수 있습니다. 무작위 지연 또는 비례 지연 등을 테스트할 수도 있습니다.
/ # tc qdisc change dev eth0 root netem delay 600ms 10ms 25%
/ # tc qdisc change dev eth0 root netem delay 600ms 20ms distribution normal
이러한 규칙은 더 많은 임의 DNS 쿼리 속도를 생성합니다.
마지막으로 tc 규칙을 제거합니다.
/ # tc qdisc del dev eth0 root
iptables 규칙도 비슷한 문제를 일으킬 수 있습니다.
OpenStack, K8S 등과 같은 많은 소프트웨어는 실행 후 호스트에 tc 또는 iptables 규칙을 추가합니다. 따라서 이러한 종류의 임의 지연 문제가 발생하면 먼저 컴퓨터에 tc 또는 iptables 규칙이 있는지 확인할 수 있습니다.
2.5 DNS 역방향 조회가 불안정함
저는 온라인에서 이러한 문제에 직면했습니다. 컴퓨터에서 인트라넷 도메인 이름을 핑할 때 각 핑 패킷이 5~30초 동안 멈춘 것처럼 보이지만 CTL-C가 핑을 닫은 후 인쇄된 통계 정보에는 패킷 손실, 핑 대기 시간이 없습니다. 또한 매우 낮습니다(밀리초). 이는 매우 이상합니다. 다음:
-
dig, 매우 빠름, 밀리초 수준, DNS 쿼리에 문제가 없음을 나타냄
-
발굴은 도메인 이름에 해당하는 IP를 볼 수 있으며, 이 IP를 직접 ping하고 지연이 없음을 찾을 수 있습니다.
-
여전히 도메인 이름을 ping하고, tcpdump를 사용하여 패킷을 캡처하고, tcpdump -i eth0 host 및 icmp를 사용하여 ping 패킷이 즉시 응답하는지 확인하여 통계에서 ping 지연이 매우 낮다는 사실을 확인합니다.
위의 정보에 따르면 핑 지연의 문제는 이 기계에 의해 발생하며 핑 프로그램 자체의 시간 소모적인 작업이어야 함을 보여줍니다. 계속하다:
-
여전히 도메인 이름을 ping하고 동시에 ltrace -p를 사용하여 ping 프로세스를 추적하고 gethostbyaddr()라는 함수에 멈춘 것을 발견했습니다.
-
설명서를 확인하고 이 기능이 DNS와 상호 작용해야 하는 IP를 기반으로 호스트 이름을 역으로 쿼리하는 것임을 확인하십시오.
기본적으로 DNS 서버의 역방향 질의 문제인 것으로 판단되며, 다른 여러 명령줄 도구로 확인해보자.다음 세 가지 명령은 모두 IP 기반의 역방향 질의 호스트 이름이다.
-
nslookup
-
주인
-
너 -x
테스트 결과 위의 세 가지 명령이 모두 중단되는 것으로 나타났습니다. /etc/resolv.conf를 수정하고 DNS 서버를 변경한 후 문제가 사라졌습니다. 다음으로 DNS 서버 문제를 확인해야 합니다.