LabHub

네트워크 기초 — 리눅스 VM 에서 손으로 · 라우팅과 DNS · 실습

이름이 풀리는 길을 끝까지 따라간다

LabHub 에서 이어서 보기

이 실습은 VM 에서 돕니다

우분투 24.04 는 systemd-resolved 가 이름 해석을 맡습니다. 여기에 dnsmasq
내 DNS 서버를 하나 더 세워 두 층을 오가며 이름이 어디서 답을 얻는지 봅니다.
dnsmasq 는 이미 설치되어 있지만 서비스가 실패한 채입니다 — 그 이유를 찾는
것이 3단계입니다.

목표

/etc/resolv.conf 의 스텁 주소가 무엇인지, 진짜 상류 서버는 어디인지, 내
DNS 서버를 특정 도메인에만 물리려면 어떻게 하는지, /etc/hosts 가 왜 DNS 를
이기는지를 명령으로 확인합니다.

왜 중요한가

"안 된다" 의 첫 갈림길이 이름입니다. 그런데 요즘 리눅스에서 이름 해석은
한 층이 아닙니다 — 애플리케이션은 libc 의 getaddrinfo 를 부르고, 그것은
nsswitch.conf 순서대로 /etc/hosts 를 먼저 보고, 그다음 resolv.conf
스텁(127.0.0.53)에 묻고, 스텁은 링크별 설정을 보고 상류로 넘깁니다. dig
이 중 마지막 단계만 직접 두드립니다. 그래서 dig 는 되는데 curl 은 안 되는
일이 실제로 생기고, 어느 층이 다른지 알아야 고칠 수 있습니다.

단계

1. /etc/resolv.conf 가 가리키는 실제 파일 경로와 nameserver 줄을 /root/dns/resolv.txt 에 저장하세요.
2. 스텁이 실제로 묻는 상류 DNS 서버 주소를 /root/dns/upstream.txtupstream=<주소> 한 줄로 저장하세요.
3. dnsmasq 가 왜 안 뜨는지 찾아, 포트 53 을 잡고 있는 프로세스를 보여 주는 ss 출력을 /root/dns/port53.txt 에 저장하세요.
4. 더미 인터페이스 dns010.53.0.1/24 를 붙이고, /etc/dnsmasq.d/lab.conf 로 dnsmasq 가 10.53.0.1 에서만 듣고 app.lab.internal10.53.0.10, db.lab.internal10.53.0.20 을 답하게 해서 서비스를 살리세요.
5. dig @10.53.0.1 app.lab.internal 의 전체 출력을 /root/dns/dig.txt 에 저장하세요.
6. resolvectldns0 링크에 DNS 서버 10.53.0.1 과 라우팅 도메인 ~lab.internal 을 지정해 getent hosts app.lab.internal 이 되게 하고, resolvectl status dns0/root/dns/link.txt 에 저장하세요.
7. /etc/hosts10.53.0.99 db.lab.internal 을 넣고, getentdig @10.53.0.1 의 답을 /root/dns/hosts.txtgetent=·dig= 두 줄로 저장하세요.
8. /root/dns/report.mdstub=·upstream=·local= 세 줄, dnsmasq 의 질의 로그에서 app.lab.internal 줄 하나, 그리고 /etc/hosts 가 DNS 를 이기는 이유를 적으세요.

참고

단계 8개

  1. resolv.conf 의 정체
  2. 진짜 서버는 어디인가
  3. dnsmasq 는 왜 안 뜨나
  4. 내 DNS 서버를 세운다
  5. dig 로 직접 묻는다
  6. 스텁에 내 서버를 물린다
  7. /etc/hosts 가 이긴다
  8. 무엇을 배웠나