CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

실제 시험 문제 26

프로토콜 추적 · Networking / DNS

시험 구조와 출제 신호Crypto / AuthNetwork / DNS / BGP / TLSWeb / Software SecurityPrivacy / Forensics / SecLab

프로토콜 추적

문제

근거 신뢰도 높음실제 시험지 대조 완료프로토콜 추적4점

독일어 원문

Direkt im Anschluss löst der Resolver beispiel.de auf. Welche Nameserver muss er nun kontaktieren? Begründen Sie Ihre Antwort!

한국어 해석

직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.

DNS resolution · cache trace

Client→Resolver→Root→.de TLD→Authoritative

TTL이 유효한 두 번째 질의에서는 cached .de delegation을 재사용합니다.

단계별 힌트

막혔을 때만 한 단계씩 여세요. 정답을 바로 읽는 것보다 기억을 꺼내는 시간이 중요합니다.

0/6
채점 기준으로 내 답안 점검하기
  • 직전 조회에서 cached .de NS를 재사용한다고 설명한다.
  • root nameserver를 다시 contact하지 않아도 되는 이유를 TTL/cache로 정당화한다.
  • beispiel.de authoritative server에는 새로 질의해야 함을 쓴다.

답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.

0/3 slots

프로토콜/시나리오 프레임 보기
sender

recursive resolver

receiver

cached .de TLD nameserver, then authoritative beispiel.de nameserver

message_content

DNS query for beispiel.de and referral/final RR answers

attacker_capability

none in original task

defense

respect TTL and validate DNSSEC if enabled

defense_limit

exact contacts depend on which NS/glue records are actually cached and still valid

정답과 핵심 해설 확인하기
summary_ko

일반 답: root는 건너뛰고 cached .de TLD nameserver -> authoritative NS for beispiel.de를 contact한다.

contact_sequence
  • .de TLD nameserver from cache
  • authoritative nameserver for beispiel.de
cache_reuse

previous tu-darmstadt.de resolution can reuse .de delegation records while TTL is valid

개념부터 다시 보는 상세 풀이

BEGINNER LESSON

5-(b) 직후 beispiel.de를 조회하면 왜 root를 다시 묻지 않을까?

ZERO-BASE START

정말 아무것도 모른다고 가정하고 시작합니다

전문 용어를 알고 있다고 가정하지 않습니다. 먼저 일상적인 장면을 보고, 그 장면의 사람과 행동에 실제 보안 용어를 하나씩 붙인 뒤, 시스템에서 일어나는 순서를 따라갑니다.

기초 개념 01

DNS와 resolver, cache를 처음부터 이해하기

1타 강사식 시작: 이름은 잠시 가리고 장면부터 봅시다

DNS는 이름으로 전화번호를 찾는 분산 전화번호부다. Resolver는 여러 전화번호부 기관에 대신 문의하는 안내원이고 cache는 최근 찾아본 번호를 메모해 두는 수첩이다.

지금은 이 비유를 완벽히 외울 필요가 없습니다. 누가 무엇을 가지고 있고, 무엇을 하려 하며, 어느 지점에서 문제가 생기는지만 찾으면 됩니다.

이제 실제 용어를 하나씩 붙여 봅시다

사람은 tu-darmstadt.de 같은 domain name을 사용하지만 packet은 IP address로 전달된다. DNS는 이름을 IP와 다른 정보로 바꾸는 분산 데이터베이스다. 사용자의 질문을 대신 처리하는 프로그램이 recursive resolver이고, authoritative nameserver는 특정 zone의 공식 record를 가진다. Resolver는 받은 답을 TTL 동안 cache해 같은 질문을 빠르게 답한다.

TERMS FROM ZERO

전문 용어를 한 단어씩 풀기

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

DNS

domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.

Recursive resolver

client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.

Cache

이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.

TTL

DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.

프로그램이나 프로토콜 안에서는 다음 순서로 움직입니다.

  1. 사용자 stub resolver가 recursive resolver에 이름을 묻는다.
  2. Cache에 유효한 답이 있으면 즉시 사용한다.
  3. 없으면 root, TLD, authoritative nameserver 방향으로 위임을 따라간다.
  4. 받은 record를 TTL 동안 저장한다.

왜 여기서 많이 틀릴까요?

Resolver와 authoritative nameserver를 같은 서버 역할로 쓰지 말고, cache에 오래된 거짓 답이 들어가는 cache poisoning과 전송 암호화를 구분한다.

조건을 생략하거나 서로 다른 기능을 같은 것으로 취급했는지 확인하세요. 정답 문장을 외우는 것보다 틀린 이유를 말할 수 있어야 변형 문제를 풀 수 있습니다.

기초 개념 02

Root부터 authoritative server까지 이름을 찾는 순서

1타 강사식 시작: 이름은 잠시 가리고 장면부터 봅시다

국가 안내소가 독일 지역 안내소를 알려 주고, 지역 안내소가 대학 담당 사무실을 알려 주며, 담당 사무실이 최종 방 번호를 알려 주는 과정이다.

지금은 이 비유를 완벽히 외울 필요가 없습니다. 누가 무엇을 가지고 있고, 무엇을 하려 하며, 어느 지점에서 문제가 생기는지만 찾으면 됩니다.

이제 실제 용어를 하나씩 붙여 봅시다

DNS 이름은 오른쪽에서 왼쪽으로 계층을 이룬다. tu-darmstadt.de에서 de는 top-level domain(TLD), tu-darmstadt는 그 아래 domain이다. Root nameserver는 최종 IP를 보통 직접 주지 않고 .de TLD nameserver를 알려 준다. TLD server는 tu-darmstadt.de의 authoritative nameserver를 알려 주고, authoritative server가 최종 A, AAAA, MX 같은 record를 답한다.

TERMS FROM ZERO

전문 용어를 한 단어씩 풀기

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

Root server

최상위에서 `.de`, `.com` 같은 TLD의 nameserver 방향을 알려주는 DNS server입니다.

TLD server

특정 top-level domain 아래의 authoritative server 방향을 알려줍니다.

Authoritative server

해당 zone의 실제 DNS record에 권한 있는 최종 답변자입니다.

Referral

최종 IP 대신 다음에 물어볼 nameserver 정보를 주는 응답입니다.

프로그램이나 프로토콜 안에서는 다음 순서로 움직입니다.

  1. Resolver cache에 최종 답이나 delegation이 있는지 먼저 본다.
  2. 없으면 root에 질의해 TLD nameserver referral을 받는다.
  3. TLD에 질의해 domain authoritative nameserver referral을 받는다.
  4. Authoritative server에 최종 record를 질의한다.
  5. 각 답과 delegation을 TTL 동안 cache한다.

왜 여기서 많이 틀릴까요?

모든 질의마다 반드시 root부터 시작하는 것은 아니다. 유효한 cache가 있으면 가장 구체적으로 알려진 지점부터 재개한다.

조건을 생략하거나 서로 다른 기능을 같은 것으로 취급했는지 확인하세요. 정답 문장을 외우는 것보다 틀린 이유를 말할 수 있어야 변형 문제를 풀 수 있습니다.

핵심부터 말하면 직전 tu-darmstadt.de 조회에서 resolver가 .de TLD nameserver의 NS/glue 정보를 TTL 동안 cache했으므로 root는 건너뛴다. cached .de TLD server에 beispiel.de의 authoritative NS를 묻고, 그 authoritative server에 최종 A/AAAA record를 질의한다.

이 글에서 익힐 것

  • DNS cache가 최종 IP뿐 아니라 delegation record도 저장함을 이해한다.

  • 두 domain의 공통 suffix `.de`를 찾아 재사용 가능한 계층을 판단한다.

  • TTL이 cache reuse 여부를 결정함을 설명한다.

  • 재사용 가능한 `.de` 정보와 새로 찾아야 하는 `beispiel.de` 정보를 구분한다.

  • 조건이 불명확할 때 cache hit/miss 가정을 답안에 명시한다.

개념부터 차근차근

  • resolver는 root에게 tu-darmstadt.de를 물어 .de TLD NS referral을 받았다.

  • resolver는 .de TLD에게 tu-darmstadt.de authoritative NS referral을 받았다.

  • resolver는 authoritative server에서 tu-darmstadt.de의 최종 record를 받았다.

  • 이 과정에서 최종 record만이 아니라 .de NS와 주소 glue, tu-darmstadt.de delegation도 각 TTL에 따라 cache할 수 있다.

헷갈리는 개념 비교하기

  • Domain

    tu-darmstadt.de

    Labels

    tu-darmstadt + de + root

  • Domain

    beispiel.de

    Labels

    beispiel + de + root

  • Shared suffix

    .de

    Consequence

    두 이름이 같은 TLD 아래 있으므로 cached .de delegation을 재사용할 수 있다.

  • Different zone

    tu-darmstadt.de vs beispiel.de

    Consequence

    beispiel.de의 authoritative NS와 final RR는 직전 조회만으로 알 수 없으므로 새로 질의해야 한다.

단계별로 따라가기

  1. Step

    1. Client → Resolver

    Message

    beispiel.de A/AAAA?

    Decision

    resolver가 cache를 먼저 검사한다.

  2. Step

    2. Root 단계 생략

    Message

    cached .de NS/glue가 아직 TTL 내

    Decision

    어느 .de server에 물어볼지 이미 안다.

  3. Step

    3. Resolver → cached .de TLD NS

    Message

    beispiel.de A/AAAA?

    Response

    beispiel.de authoritative NS referral + 필요 시 glue

  4. Step

    4. Resolver → authoritative NS for beispiel.de

    Message

    beispiel.de A/AAAA?

    Response

    최종 record

  5. Step

    5. Resolver → Client

    Message

    최종 answer

    Decision

    새 delegation과 answer를 각 TTL 동안 cache

정확한 의미 짚기

  • Cached item

    .de TLD NS/glue

    Reuse

    예

    Reason

    두 domain 모두 .de 아래이고 TTL이 유효함.

  • Cached item

    Root referral

    Reuse

    직접 사용할 필요 없음

    Reason

    .de server 주소를 이미 더 구체적으로 알고 있음.

  • Cached item

    tu-darmstadt.de authoritative NS

    Reuse

    아니오

    Reason

    다른 zone beispiel.de를 담당하지 않음.

  • Cached item

    tu-darmstadt.de A/AAAA

    Reuse

    아니오

    Reason

    질의 이름이 다름.

  • New item

    beispiel.de authoritative NS와 A/AAAA

    Reuse

    새로 획득

    Reason

    직전 lookup에서 알 수 없었던 다른 child zone 정보.

Ttl and edge cases

  • 직후라는 표현은 보통 .de NS TTL이 아직 만료되지 않았다는 출제 의도다.

  • TTL이 만료됐거나 resolver가 delegation을 cache하지 않았다면 root부터 다시 시작할 수 있다.

  • 이미 beispiel.de의 final answer가 다른 사용자의 이전 질의로 cache돼 있다면 authoritative server에도 가지 않고 즉시 답할 수 있다.

  • Negative cache에 beispiel.de 부재 정보가 유효하게 저장돼 있다면 그 negative answer를 재사용할 수 있다.

  • 시험의 일반 답은 별도 cache가 없고 직전 .de 정보만 유효하다는 가정 아래 root 생략 → .de → beispiel.de authoritative다.

Longest cached suffix rule

  • resolver는 질의 이름과 가장 구체적으로 일치하는 유효 cached delegation에서 시작한다.

  • 아무 정보가 없으면 root hints에서 시작한다.

  • .de NS만 있으면 .de에서 시작한다.

  • beispiel.de NS까지 있으면 그 authoritative server에서 바로 시작한다.

  • beispiel.de A answer까지 있으면 외부 질의 없이 cache에서 답한다.

Diagram template

  • Client ── beispiel.de A? ──▶ Resolver

  • Resolver cache: .de NS HIT, TTL valid

  • Resolver ── beispiel.de? ──▶ cached .de TLD NS

  • .de TLD ── referral: NS for beispiel.de ──▶ Resolver

  • Resolver ── A/AAAA? ──▶ authoritative NS for beispiel.de

  • Authoritative ── final answer ──▶ Resolver ──▶ Client

  • Root: not contacted

문제를 푸는 순서

  1. 1단계: 두 domain의 오른쪽 suffix를 비교해 공통 `.de`를 표시한다.

  2. 2단계: 직전 trace에서 .de NS/glue를 얻었다고 확인한다.

  3. 3단계: TTL이 유효하다는 가정을 적는다.

  4. 4단계: root를 건너뛰고 cached .de TLD server에 질의한다고 쓴다.

  5. 5단계: beispiel.de authoritative NS는 새로 받아 최종 record를 묻는다고 쓴다.

  6. 6단계: TTL 만료 시 root부터 다시 시작할 수 있다는 조건을 짧게 덧붙인다.

시험장에서는 이렇게 쓰기

Four point german

Der Resolver kann den Root-Nameserver überspringen, weil er aus der unmittelbar vorherigen Auflösung die .de-TLD-Nameserver samt Adressinformationen noch gemäß TTL im Cache hat. Er fragt daher einen zwischengespeicherten .de-Nameserver nach der Delegation für beispiel.de und anschließend den autoritativen Nameserver von beispiel.de nach dem gewünschten Record. Nur bei abgelaufenem oder fehlendem Cache müsste er wieder beim Root beginnen.

Compact sequence

Cache-Hit für .de → .de-TLD-NS → autoritativer NS für beispiel.de → finaler A/AAAA-Record; kein Root-Kontakt.

자주 틀리는 지점

  • domain이 바뀌었으므로 항상 root부터 시작한다고 쓰는 것.

  • tu-darmstadt.de authoritative server에 beispiel.de를 묻는 것. 서로 다른 zone이다.

  • .de TLD가 beispiel.de의 최종 IP를 반드시 직접 준다고 쓰는 것. 보통 authoritative NS referral을 준다.

  • cache에는 최종 A record만 저장된다고 생각하는 것. NS delegation과 glue도 cache될 수 있다.

  • 직후라는 말만 보고 TTL을 무시하는 것. 재사용 근거는 valid TTL이다.

  • root server 자체가 cache되므로 root에 다시 묻는다고 설명하는 것. 핵심은 더 구체적인 .de delegation cache로 root를 건너뛰는 것이다.

한 줄로 기억하기

어제 독일 `.de` 안내 데스크 위치를 알아뒀다면 오늘 다른 독일 회사 번호를 찾을 때 세계 root 안내소로 돌아갈 필요가 없다. `.de` 데스크부터 묻는다.

스스로 확인하기

  • 두 조회에서 재사용되는 핵심 cache 정보는?

    .de TLD nameserver의 NS와 접속 주소 정보.

  • 왜 tu-darmstadt.de authoritative NS는 재사용하지 않는가?

    beispiel.de는 별도의 zone이고 다른 authoritative server가 담당하기 때문이다.

  • TTL이 만료되면 어떻게 되는가?

    유효한 .de delegation이 없으므로 root부터 다시 조회할 수 있다.

  • beispiel.de A record 자체가 cache돼 있다면?

    외부 nameserver에 묻지 않고 즉시 cache answer를 줄 수 있다.

설명의 근거

  • Gedächtnisprotokoll Computersystemsicherheit WS2025_26.md, Networking / DNS, 5-(b), 4 Punkte.

  • CSS Exam SoSe22, p.14 — 연속된 두 번째 DNS lookup과 cache 문제.

  • Vorlesung 08 Domain Name System — DNS caching, TTL과 delegation reuse.

예제로 확인하기

  • DNS와 resolver, cache를 처음부터 이해하기을 구체적인 순서로 보기

    DNS는 이름으로 전화번호를 찾는 분산 전화번호부다. Resolver는 여러 전화번호부 기관에 대신 문의하는 안내원이고 cache는 최근 찾아본 번호를 메모해 두는 수첩이다.

    1. 사용자 stub resolver가 recursive resolver에 이름을 묻는다.

    2. Cache에 유효한 답이 있으면 즉시 사용한다.

    3. 없으면 root, TLD, authoritative nameserver 방향으로 위임을 따라간다.

    4. 받은 record를 TTL 동안 저장한다.

    각 단계에서 입력이나 message가 어떻게 달라지는지 확인한 뒤 현재 문제의 조건과 결론에 연결합니다.

  • Root부터 authoritative server까지 이름을 찾는 순서을 구체적인 순서로 보기

    국가 안내소가 독일 지역 안내소를 알려 주고, 지역 안내소가 대학 담당 사무실을 알려 주며, 담당 사무실이 최종 방 번호를 알려 주는 과정이다.

    1. Resolver cache에 최종 답이나 delegation이 있는지 먼저 본다.

    2. 없으면 root에 질의해 TLD nameserver referral을 받는다.

    3. TLD에 질의해 domain authoritative nameserver referral을 받는다.

    4. Authoritative server에 최종 record를 질의한다.

    5. 각 답과 delegation을 TTL 동안 cache한다.

    각 단계에서 입력이나 message가 어떻게 달라지는지 확인한 뒤 현재 문제의 조건과 결론에 연결합니다.

이 문제가 어려운 이유

짧은 문제 문장 ‘직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.’ 안에 정의, 조건, 처리 순서가 압축되어 있습니다. 아래 예시에서는 이를 한 단계씩 펼쳐 확인합니다.

AI 구두시험용 프롬프트

한 문항만 풀어라. 먼저 정답을 열지 말고 90초 안에 답안을 말한 뒤, css-ws2025-26-network-dns-002의 채점 프레임으로 스스로 채점하라. 문제: 직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.

학습 기록

이 문항을 얼마나 이해했나요?