Cloud Native Operations

한국어

English

한국어

English

Appearance

DNS와 연결 진단 퀴즈 ​

마지막 업데이트: 2026년 9월 15일

본문을 참고하여 관측과 추론을 구분해 보세요. 내부망은 클라이언트 192.0.2.10/24, 서버 192.0.2.20/24이며 서버에는 DNS 서비스가 없습니다.

문제 ​

  1. /etc/hosts에 server.netlab.test가 .20으로 등록됐습니다. getent ahostsv4는 성공하지만 dig @192.0.2.20은 시간 초과입니다. 맞는 해석은 무엇인가요?
    • A) 모든 이름 해석이 고장 났다
    • B) 로컬 NSS 조회는 정상이며 질의한 서버가 기대하는 DNS 서비스를 제공하지 않는다
    • C) 관리 기본 경로를 삭제해야 한다
    • D) hosts 항목은 서버의 DNS 리스너도 자동 생성한다
정답 보기

정답: B) 로컬 NSS 조회는 정상이며 질의한 서버가 기대하는 DNS 서비스를 제공하지 않는다

설명: getent는 시스템 이름 서비스 소스를 사용하고 dig는 선택한 서버에 DNS 질의를 보냅니다. .20에는 의도적으로 DNS 리스너가 없습니다. 시간 초과는 제한 시간에 유효 응답이 없다는 뜻이며 NXDOMAIN 응답이 아닙니다. 시스템 DNS를 .20으로 바꾸지 말고 정상 hosts 매핑을 유지하세요.

  1. Ubuntu에서 dig @127.0.0.53 server.netlab.test. A가 /etc/hosts의 주소를 반환했습니다. 어떤 상황인가요?
    • A) Dig가 직접 NSS로 질의 이름을 읽었다
    • B) 공개 권한 서버가 로컬 hosts 항목을 학습했다
    • C) 클라이언트가 라우터가 됐다
    • D) Dig가 질의한 resolved stub이 로컬 hosts 데이터로 답했다
정답 보기

정답: D) Dig가 질의한 resolved stub이 로컬 hosts 데이터로 답했다

설명: Dig 자체는 질의 이름을 NSS로 해석하지 않습니다. 그러나 systemd-resolved는 일반적으로 hosts를 읽고 DNS stub을 통해 그 결과를 제공할 수 있습니다. 로컬 stub과 다른 상위 서버에 묻는 것은 서로 다른 실험입니다. 해당 기능이 꺼져 있다면 설정을 확인하세요.

  1. 한 DNS 질의에는 status: NXDOMAIN, 다른 질의에는 시간 초과가 나왔습니다. 차이는 무엇인가요?
    • A) NXDOMAIN은 부정 DNS 응답이며 시간 초과는 제한 시간에 유효 응답이 없었다는 뜻
    • B) 둘 다 이름이 없음을 증명
    • C) NXDOMAIN은 모든 IP 경로가 없음을 증명
    • D) 시간 초과는 권한 서버의 레코드 삭제를 증명
정답 보기

정답: A) NXDOMAIN은 부정 DNS 응답이며 시간 초과는 제한 시간에 유효 응답이 없었다는 뜻

설명: NXDOMAIN에는 철자·resolver view·부정 캐시를, 시간 초과에는 경로·resolver 접근·정책을 조사합니다. Dig는 NXDOMAIN을 받아도 0으로 끝날 수 있으므로 셸 종료 상태만 보지 말고 DNS 상태와 응답 내용을 읽으세요.

  1. TTL 300인 레코드의 권한 서버 TTL을 낮추고 resolved 로컬 캐시를 비웠습니다. 무엇을 말할 수 있나요?
    • A) 모든 클라이언트에 즉시 새 레코드가 보인다
    • B) 레코드가 정확히 라우터 300개를 통과할 수 있다
    • C) DNS TTL은 캐시 수명이며 다른 캐시에는 이전 값이 남을 수 있다, IP TTL과는 무관하다
    • D) /etc/hosts도 삭제됐다
정답 보기

정답: C) DNS TTL은 캐시 수명이며 다른 캐시에는 이전 값이 남을 수 있다, IP TTL과는 무관하다

설명: 로컬 서비스 하나의 캐시를 지워도 애플리케이션·상위 캐시는 지워지지 않습니다. 권한 서버 TTL 변경이 이전 캐시 수명을 다시 쓰지도 않습니다. IP TTL은 전달 홉을 제한하며 DNS TTL의 초 단위 수명과 단위·동작이 다릅니다.

  1. 클라이언트의 ip route get 192.0.2.20에 dev LAB_NIC src 192.0.2.10이 나오고 via는 없습니다. 무엇이 확인됐나요?
    • A) 서버 HTTP 애플리케이션이 정상
    • B) 로컬 경로가 같은 링크의 상대에 실습 NIC·출발지를 선택했으며 도달 가능성은 아직 미검증
    • C) VM 어디에도 기본 경로가 없음
    • D) DNS가 상대 MAC을 선택
정답 보기

정답: B) 로컬 경로가 같은 링크의 상대에 실습 NIC·출발지를 선택했으며 도달 가능성은 아직 미검증

설명: 로컬 경로 조회는 probe를 보내지 않습니다. 같은 /24의 상대에는 다음 홉 라우터가 필요 없으며 별도 관리 기본 경로는 남을 수 있습니다. 이웃 탐색·상대·반환 경로·애플리케이션은 따로 검사해야 합니다.

  1. 클라이언트 자신의 192.0.2.10 ping은 성공하지만 .20의 이웃 항목은 FAILED가 됩니다. 무엇을 먼저 확인하나요?
    • A) 실습 NIC에 공개 DNS 설치
    • B) 자기 ping으로 가상 케이블도 증명됐다고 판단
    • C) 관리 경로 테이블 일괄 삭제
    • D) 양쪽 내부망 연결, 상대 주소, carrier, 주소 충돌
정답 보기

정답: D) 양쪽 내부망 연결, 상대 주소, carrier, 주소 충돌

설명: 자기 주소 요청은 보통 로컬 처리되어 가상 링크를 검사하지 않습니다. 실패한 이웃 항목은 다음 홉 MAC 해석 실패의 단서이므로 애플리케이션 DNS보다 링크·주소를 확인합니다. 반면 STALE 자체는 실패한 매핑이 아닙니다.

  1. Traceroute에 *가 나오지만 클라이언트의 같은 서버 HTTP 요청은 성공합니다. 올바른 설명은 무엇인가요?
    • A) probe에 일치하는 응답이 제시간에 없었지만 일반 애플리케이션 전달은 동작할 수 있다
    • B) 별표 홉이 모든 패킷을 버린다
    • C) traceroute가 HTTP 결과를 캐시했다
    • D) 모든 가상 스위치는 IP 홉으로 보여야 한다
정답 보기

정답: A) probe에 일치하는 응답이 제시간에 없었지만 일반 애플리케이션 전달은 동작할 수 있다

설명: probe 프로토콜·제어 응답 정책은 애플리케이션 트래픽과 다릅니다. 필터링·응답 속도 제한·반환 경로 때문에 응답이 안 보일 수 있습니다. Ethernet 스위치는 라우터처럼 IP TTL을 줄이지 않습니다. 별표만으로 애플리케이션 손실을 측정할 수 없습니다.

  1. nc -z 또는 ncat -z가 18080에 연결됐지만 HTTP 요청은 아직 없습니다. 통과한 검사는 무엇인가요?
    • A) DNS 권한 검증
    • B) HTTP 인증·페이지 렌더링
    • C) 해당 끝점의 TCP 연결 수립
    • D) HTTPS 인증서 전체 검사
정답 보기

정답: C) 해당 끝점의 TCP 연결 수립

설명: 데이터 없이 연결만 검사하므로 원하는 HTTP 요청·응답을 검증하지 않습니다. 이어서 curl로 상태·헤더·본문을 확인해야 합니다. TCP 연결 성공만으로 기대 프로토콜의 서비스인지도 확정할 수 없습니다.

  1. 서버 자기 요청은 200, 리스너는 .20:18080, 클라이언트 TCP 요청은 시간 초과입니다. 적절한 기록은 무엇인가요?
    • A) 종단 간 HTTP가 완전히 정상
    • B) 로컬 서비스는 정상이나 원격 경로·이웃·반환 경로·호스트 정책은 추가 조사 필요
    • C) 숫자 주소를 사용했어도 무조건 DNS 장애
    • D) 서버 방화벽 전체 비활성화
정답 보기

정답: B) 로컬 서비스는 정상이나 원격 경로·이웃·반환 경로·호스트 정책은 추가 조사 필요

설명: 서버 자기 요청은 클라이언트 접근을 증명하지 않습니다. 방화벽은 후보이며 시간 초과 하나로 단정할 수 없습니다. 06장의 범위 한정 정책 실습을 위해 증거를 보존하세요. 로컬 성공으로 원격 실패를 대체하거나 방화벽을 우회해 성공을 만들지 않습니다.

  1. Curl이 /missing-page에 HTTP 404를 받고 0으로 끝났습니다. 어떤 의미인가요?
  • A) TCP 연결이 없었다
  • B) 서버 이름의 DNS 레코드가 없다
  • C) Curl이 반드시 서버 응답을 무시했다
  • D) 없는 리소스라는 HTTP 응답이며 --fail이 없으면 curl은 성공 종료할 수 있다
정답 보기

정답: D) 없는 리소스라는 HTTP 응답이며 --fail이 없으면 curl은 성공 종료할 수 있다

설명: HTTP 교환이 가능할 만큼 전송이 동작했지만 리소스가 없었습니다. HTTP 상태 줄을 읽고 경로·애플리케이션을 조사합니다. 이 의도적인 애플리케이션 오류를 DNS 변경으로 고치지 마세요.

  1. 숫자 HTTP는 성공, 이름 HTTP는 실패하며 --resolve server.netlab.test:18080:192.0.2.20을 붙이면 이름 요청도 성공합니다. 다음 행동은 무엇인가요?
  • A) getent/NSS로 일반 이름 조회를 조사, override는 이번 curl에만 적용됨
  • B) .20의 영구 경로 삭제
  • C) curl이 공개 DNS zone을 갱신했다고 판단
  • D) 모든 TLS 검증 비활성화
정답 보기

정답: A) getent/NSS로 일반 이름 조회를 조사, override는 이번 curl에만 적용됨

설명: 알려진 주소를 curl에 제공하면서 요청의 호스트명을 유지합니다. hosts·DNS 레코드 변경이 없으므로 원복도 없습니다. HTTPS에는 호스트명·SNI·인증서도 중요하며 이 HTTP 실습이 인증서 검증을 건너뛸 이유가 되지는 않습니다.

  1. 올바른 완료·정리 설명은 무엇인가요?
  • A) 공개 DNS가 성공해야 격리 실습도 통과
  • B) /tmp 전체 삭제와 hosts 파일 전체 초기화
  • C) 소유 서버 종료, 정확한 파일·디렉터리와 표시한 hosts 항목 제거, 정적 주소 보존, 공개 DNS는 선택 사항
  • D) 관측을 맞추려고 관리 NIC를 공개 DNS로 변경
정답 보기

정답: C) 소유 서버 종료, 정확한 파일·디렉터리와 표시한 hosts 항목 제거, 정적 주소 보존, 공개 DNS는 선택 사항

설명: 정리는 소유 범위를 따릅니다. foreground 서버는 5분 제한이며 임시 디렉터리는 기록하고 hosts 블록은 표시했습니다. 관련 없는 편집과 SSH 학습에 쓸 03장 주소를 보존하세요. 공개 질의는 기존 외부 접근·정책에 의존하며 격리 상대 경로의 증거가 아닙니다.

본문으로 돌아가기 · 다음 장: SSH 접속