2. Netzwerksicherheit · 실제 시험 Abschnitt 2.2
2.2. DNS (Domain Name System)
DNS resolution, cache 재사용, amplification과 DNSSEC, MX record를 시험지 1–4번 흐름대로 학습합니다.
이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.
ACTUAL EXAM · VERBATIM TRANSCRIPT
시험지 원문 1:1 전사
아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.
2.2. DNS (Domain Name System) (17 Punkte)
1. Ein DNS-Resolver versucht tu-darmstadt.de aufzulösen. Skizzieren Sie den Ablauf der Namensauflösung. (3 Punkte)
2. Direkt im Anschluss löst der Resolver beispiel.de auf. Welche Nameserver muss er nun kontaktieren? Begründen Sie Ihre Antwort! (4 Punkte)
3. Eve hat ein Botnetz und möchte es dafür verwenden, Alices Server my.server.com durch einen DNS-Amplification-Angriff unerreichbar zu machen.
• Zeichnen Sie in Abb. 1 die Kommunikation (mit beschrifteten Pfeilen) zwischen Eves Botnetz, den DNS-Resolvern und Alices Server my.server.com ein. (4 Punkte)
+------------------------+ [DNS Resolver]
| Eve's Botnetz |
| |
| 1.2.3.4 | [DNS Resolver]
| 5.6.7.8 |
| 9.10.11.12 |
+------------------------+
[my.server.com]Abbildung 1: DNS: Eve's Angriff
• Ändert es etwas am Angriff, wenn DNSSEC verwendet wird? (2 Punkte)
4. Alice erhält auf eine DNS-Anfrage folgende Antwort:
;; ANSWER SECTION:
tu-darmstadt.de. 86400 IN MX 10 b2681.mx.srv.dfn.de.
tu-darmstadt.de. 86400 IN MX 10 c2681.mx.srv.dfn.de.
tu-darmstadt.de. 86400 IN MX 10 a2681.mx.srv.dfn.de.Was sagen diese Resource Records aus? (4 Punkte)
근거: CSS_Altklausur_WiSe_2526.pdf 및 computersystemsicherheit_wise25-26_questions_only.md · Abschnitt 2.2
VISUAL MAP
DNS 질의에서 답변까지 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.- 01 Client
- 02 Resolver·Cache
- 03 Root
- 04 TLD
- 05 Authoritative
FIXED SOLVING METHOD
이 묶음의 고정 풀이 순서
- 질의 이름과 원하는 record type을 적습니다.
- Resolver cache에 재사용 가능한 referral 또는 answer가 있는지 먼저 봅니다.
- 필요한 경우 Root→TLD→authoritative 순서로 화살표를 그립니다.
- 각 응답이 referral인지 final answer인지 표시합니다.
- 공격 문제에서는 source IP, 응답 크기, 피해 보안 목표를 별도로 추적합니다.
ZERO-BASE CONCEPT LESSONS
이 묶음을 풀기 전에 필요한 개념
카드를 열고 닫는 방식 대신 한 방향으로 이어지는 글로 구성했습니다. 비유 → 용어의 쉬운 뜻 → 실제 작동 → 시험에서의 경계 순서로 천천히 읽으세요.
기초 개념 01
DNS와 resolver, cache를 처음부터 이해하기
먼저 장면으로 이해해 봅시다. DNS는 이름으로 전화번호를 찾는 분산 전화번호부다. Resolver는 여러 전화번호부 기관에 대신 문의하는 안내원이고 cache는 최근 찾아본 번호를 메모해 두는 수첩이다.
이제 전문 용어를 붙이면 다음과 같습니다. DNS은(는) domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다. Recursive resolver은(는) client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다. Cache은(는) 이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다. TTL은(는) DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
실제 시스템에서는 이렇게 작동합니다. 사람은 tu-darmstadt.de 같은 domain name을 사용하지만 packet은 IP address로 전달된다. DNS는 이름을 IP와 다른 정보로 바꾸는 분산 데이터베이스다. 사용자의 질문을 대신 처리하는 프로그램이 recursive resolver이고, authoritative nameserver는 특정 zone의 공식 record를 가진다. Resolver는 받은 답을 TTL 동안 cache해 같은 질문을 빠르게 답한다.
- 사용자 stub resolver가 recursive resolver에 이름을 묻는다.
- Cache에 유효한 답이 있으면 즉시 사용한다.
- 없으면 root, TLD, authoritative nameserver 방향으로 위임을 따라간다.
- 받은 record를 TTL 동안 저장한다.
여기서 넘지 말아야 할 경계: Resolver와 authoritative nameserver를 같은 서버 역할로 쓰지 말고, cache에 오래된 거짓 답이 들어가는 cache poisoning과 전송 암호화를 구분한다.
09. DNS resolution·Cache·Records 독립 강의 →기초 개념 02
Root부터 authoritative server까지 이름을 찾는 순서
먼저 장면으로 이해해 봅시다. 국가 안내소가 독일 지역 안내소를 알려 주고, 지역 안내소가 대학 담당 사무실을 알려 주며, 담당 사무실이 최종 방 번호를 알려 주는 과정이다.
이제 전문 용어를 붙이면 다음과 같습니다. Root server은(는) 최상위에서 `.de`, `.com` 같은 TLD의 nameserver 방향을 알려주는 DNS server입니다. TLD server은(는) 특정 top-level domain 아래의 authoritative server 방향을 알려줍니다. Authoritative server은(는) 해당 zone의 실제 DNS record에 권한 있는 최종 답변자입니다. Referral은(는) 최종 IP 대신 다음에 물어볼 nameserver 정보를 주는 응답입니다.
실제 시스템에서는 이렇게 작동합니다. 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를 답한다.
- Resolver cache에 최종 답이나 delegation이 있는지 먼저 본다.
- 없으면 root에 질의해 TLD nameserver referral을 받는다.
- TLD에 질의해 domain authoritative nameserver referral을 받는다.
- Authoritative server에 최종 record를 질의한다.
- 각 답과 delegation을 TTL 동안 cache한다.
여기서 넘지 말아야 할 경계: 모든 질의마다 반드시 root부터 시작하는 것은 아니다. 유효한 cache가 있으면 가장 구체적으로 알려진 지점부터 재개한다.
09. DNS resolution·Cache·Records 독립 강의 →기초 개념 03
DNS Resource Record 한 줄 읽는 법
먼저 장면으로 이해해 봅시다. 주소록 한 줄에 이름, 메모 유효 기간, 정보 분류, 전화·메일 같은 종류, 실제 값이 차례로 적혀 있다고 생각하면 된다.
이제 전문 용어를 붙이면 다음과 같습니다. Resource Record은(는) DNS에서 이름, type, 값, TTL 등을 담는 한 줄의 정보 단위입니다. A / AAAA은(는) Domain 이름을 각각 IPv4 또는 IPv6 주소에 연결하는 record type입니다. MX은(는) Domain의 mail을 받을 mail server와 우선순위를 지정하는 record입니다. NS은(는) 해당 DNS zone의 authoritative nameserver를 나타내는 record입니다.
실제 시스템에서는 이렇게 작동합니다. DNS의 정보 한 줄을 Resource Record(RR)라고 한다. 일반 형식은 NAME TTL CLASS TYPE RDATA다. NAME은 어느 이름의 정보인지, TTL은 몇 초 동안 cache할 수 있는지, CLASS의 IN은 Internet, TYPE은 정보 종류, RDATA는 실제 값이다. MX record는 해당 domain의 메일을 받을 mail server와 우선순위 값을 나타낸다.
- NAME에서 record가 속한 domain을 읽는다.
- TTL을 초 단위 cache 가능 시간으로 읽는다.
- TYPE이 A, AAAA, NS, MX, TXT 중 무엇인지 확인한다.
- MX RDATA의 작은 preference 값이 더 우선임을 확인한다.
- 끝의 점이 붙은 이름은 root까지 적은 FQDN임을 이해한다.
여기서 넘지 말아야 할 경계: MX의 숫자를 port나 TTL로 읽지 말고, 여러 MX가 있으면 preference 순서와 장애 대체 관계를 설명한다.
09. DNS resolution·Cache·Records 독립 강의 →기초 개념 04
DNS amplification: spoofing, reflection, amplification
먼저 장면으로 이해해 봅시다. 공격자가 여러 가게에 작은 주문서를 보내면서 배송 주소를 피해자 집으로 적어, 가게들이 큰 상자를 모두 피해자에게 보내게 하는 상황이다.
이제 전문 용어를 붙이면 다음과 같습니다. Source IP spoofing은(는) packet의 source IP를 victim 주소인 것처럼 위조하는 행위입니다. Reflection은(는) 공격자가 제3의 server들이 victim에게 response를 보내게 만드는 구조입니다. Amplification은(는) 작은 request로 더 큰 response를 만들어 공격 traffic 양을 증폭하는 효과입니다. Open resolver은(는) 불특정 외부 client의 recursive DNS 질의를 받아주는 resolver입니다.
실제 시스템에서는 이렇게 작동합니다. DNS amplification은 작은 DNS query로 큰 response를 만들고, query의 source IP를 victim 주소로 위조해 response가 victim에게 가도록 하는 DDoS 방식이다. Source IP spoofing은 발신 주소를 거짓으로 적는 것, reflection은 중간 DNS resolver가 victim에게 답을 보내게 하는 것, amplification은 요청보다 응답이 더 큰 비율을 이용하는 것이다.
- Bot은 source IP를 victim IP로 위조한 작은 UDP DNS query를 보낸다.
- Open resolver는 query를 처리한다.
- 큰 DNS response가 위조된 주소인 victim에게 전달된다.
- 많은 bot과 resolver의 응답이 victim의 bandwidth를 소모한다.
여기서 넘지 말아야 할 경계: DNSSEC는 response에 signature를 추가해 응답을 더 크게 만들 수 있으며, source spoofing과 open resolver 문제를 직접 제거하지 않으므로 이 DDoS를 자동 차단하지 않는다.
10. DoH·DNSSEC·Amplification 독립 강의 →기초 개념 05
DoH와 DNSSEC는 서로 다른 문제를 해결한다
먼저 장면으로 이해해 봅시다. DoH는 전화번호부 안내원에게 가는 통화를 도청하기 어렵게 암호화한 전화선이고, DNSSEC는 전화번호부 항목 자체에 발행 기관의 위조하기 어려운 도장을 찍는 것이다.
이제 전문 용어를 붙이면 다음과 같습니다. DoH은(는) DNS over HTTPS로 client와 resolver 사이 DNS message를 HTTPS 안에 암호화합니다. DNSSEC은(는) DNS record에 대한 signature chain으로 data origin과 integrity를 검증하는 확장입니다. Authenticity은(는) 받은 정보가 주장된 권한 있는 출처에서 왔는지를 확인하는 성질입니다. Transport encryption은(는) 통신 구간에서 제3자가 내용을 읽거나 쉽게 바꾸지 못하게 하는 보호입니다.
실제 시스템에서는 이렇게 작동합니다. DNS over HTTPS(DoH)는 사용자와 선택한 resolver 사이의 DNS message를 HTTPS 안에 넣어 전송한다. 주변 Wi-Fi나 단순한 중간 관찰자가 질문을 쉽게 읽거나 바꾸기 어렵게 하지만 resolver 자체는 질문을 본다. DNSSEC는 DNS record에 digital signature를 붙여 resolver가 authoritative data의 출처와 무결성을 검증하게 한다.
- 공격자가 사용자와 resolver 사이에 있는지 resolver의 cache를 공격하는지 구분한다.
- DoH는 transport privacy를, DNSSEC는 signed data validation을 제공한다.
- DoH만으로 악성 resolver나 poisoned cache의 거짓 답을 자동 검증하지는 못한다.
여기서 넘지 말아야 할 경계: HTTPS를 사용한다는 이유만으로 DNS answer의 진위성이 자동 보장된다고 쓰면 안 된다.
10. DoH·DNSSEC·Amplification 독립 강의 →ACTIVE RECALL
이 페이지를 닫기 전 확인
- Referral과 final answer의 차이는?
- TTL은 무엇을 결정하나요?
- DNS amplification에서 위조되는 값은 무엇인가요?
QUESTION-BY-QUESTION COMMENTARY
실제 시험 소문제별 해설
시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.
ACTUAL EXAM SUBSECTION 2.2
2.2. DNS (Domain Name System)
4개 학습 항목 · 17점
2.2.1 DNS resolver가 tu-darmstadt.de를 resolve하려고 한다. Namensauflösung Ablauf를 sketch하라. 기존 71문항 학습 번호 25 · 3점 프로토콜 추적
2.2.1 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
DNS resolver가 tu-darmstadt.de를 resolve하려고 한다. Namensauflösung Ablauf를 sketch하라.
TERMS FOR 2.2.1
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
사람은
tu-darmstadt.de같은 domain name을 쓰지만 IP packet을 보내려면 목적지 IP가 필요하다. DNS(Domain Name System)는 계층적으로 관리되는 이름과 Resource Record를 이용해 이 정보를 찾는다.사용자 기기의 stub resolver는 보통 설정된 recursive resolver에게 최종 답을 찾아 달라는 recursive request를 보낸다. Stub이 root, TLD, authoritative server를 직접 차례로 방문하는 것이 아니라 recursive resolver가 대신 순회한다.
DNS 이름은 오른쪽에서 왼쪽으로 계층을 읽는다.
tu-darmstadt.de.에서 맨 끝의 점은 root,de는 Top-Level Domain,tu-darmstadt는 그 아래 위임된 zone이다.Root server는 보통 최종 A/AAAA record를 주지 않고
.deTLD nameserver의 NS referral을 준다..deTLD server도 최종 주소 대신tu-darmstadt.de를 책임지는 authoritative nameserver의 referral을 주고, 그 authoritative server가 zone의 공식 A/AAAA 같은 answer를 준다.Recursive resolver는 받은 최종 answer뿐 아니라 NS delegation과 필요한 glue address도 각각의 TTL 동안 cache한다. Referral은 '다음에 누구에게 물을지'이고 authoritative answer는 '질문한 record의 공식 값'이므로 화살표에서 구분해야 한다.
2 · 일상 장면으로 먼저 잡기
학생이 중앙 안내원에게 연구실 전화번호를 부탁하고, 안내원이 국가 안내소→도시 안내소→대학 담당실을 차례로 찾아 최종 번호를 받아오는 장면
.deTLD nameservertu-darmstadt.deauthoritative nameserver와 최종 RR비유의 경계 실제 DNS에는 여러 root/TLD/authoritative instance, anycast, CNAME chain, DNSSEC 검증, retry가 있을 수 있다. 시험 기본 trace에서는 계층과 referral/answer 방향이 핵심이다.
tu-darmstadt.de이름 해석tu-darmstadt.de A/AAAA?, 최종 답을 요구하는 recursive request질의 후
.deTLD NS referral 수신.deTLD질의 후
tu-darmstadt.deauthoritative NS referral 수신최종 A/AAAA RR 수신
최종 answer 반환, RR와 delegation을 TTL cache
각 왕복에서 query sender는 resolver이고, root와 TLD의 response는 다음 server를 가리키는 referral이며 마지막만 최종 record다.
빈 cache에서
shop.example.org의 IPv4 주소 찾기주어진 것과 목표 Client C, recursive resolver R, root server Root,
.orgTLD server T,example.orgauthoritative server A가 있다. R의 관련 cache는 비어 있고 QTYPE은 A다.C가 R에
shop.example.org A?recursive request를 보낸다.왜? C는 최종 IPv4 answer를 대신 찾아 달라고 요청하기 때문이다.
중간 결과 R은 cache miss를 확인하고 iterative lookup 상태에 들어간다.
R이 Root에 같은 QNAME/QTYPE을 묻는다.
왜? 더 구체적인 delegation을 아직 모르기 때문이다.
중간 결과 Root→R 응답은
.orgNS referral과 필요한 glue다.R이 referral로 얻은
.orgTLD server T에 질의한다.왜?
example.org를 담당하는 nameserver를 찾기 위해서다.중간 결과 T→R 응답은
example.orgauthoritative NS referral이다.R이 authoritative server A에
shop.example.org A?를 묻는다.왜? A가 해당 zone의 공식 record를 보유하기 때문이다.
중간 결과 A→R로 예시 A record
192.0.2.25가 온다.R이 C에
192.0.2.25를 반환하고 answer와 delegation을 TTL 동안 저장한다.왜? 요청을 완료하고 다음 조회를 빠르게 하기 위해서다.
중간 결과 C가 그 IP로 연결할 수 있고 R의 cache 상태가 채워진다.
예제 결론 Client는 recursive resolver 한 곳에 묻고, resolver가 root referral→TLD referral→authoritative answer를 따라가 최종 값을 반환한다.
실제 시험으로 옮기기 예제의
.org,example.org, A를 시험의.de,tu-darmstadt.de, 필요한 A/AAAA record로 바꾸어 동일한 sender·receiver 화살표를 그린다.이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: DNS resolver가 tu-darmstadt.de를 resolve하려고 한다. Namensauflösung Ablauf를 sketch하라.
이 문제의 풀이 전략: 이 소문제에서는 가정과 최초 요청 → Root 단계 → TLD 단계 → Authoritative 단계 → 반환과 상태 변화 순서로 진행합니다. 마지막에는 ‘Client→Resolver는 recursive request이고 Resolver↔Root/TLD/Authoritative가 iterative lookup 흐름이다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
DNS resolver가 tu-darmstadt.de를 resolve하려고 한다. Namensauflösung Ablauf를 sketch하라.
관련 cache가 비었다고 명시하고 Client/Stub → Recursive Resolver에 `QNAME=tu-darmstadt.de, QTYPE=A 또는 AAAA`를 그린다.
Client가 root에 직접 묻는 그림이 아닌가?
최종적으로 구해야 하는 것
Resolver → Client로 최종 answer를 보내고 얻은 record·delegation을 각 TTL 동안 cache한다.
관련 cache가 비어 있다고 가정하면 Client는 recursive resolver에 `tu-darmstadt.de`의 A/AAAA를 요청한다. Resolver는 root에 질의해 `.de` TLD referral을 받고, `.de` server에 질의해 `tu-darmstadt.de` authoritative nameserver referral을 받는다. 이어 그 authoritative server에서 최종 record를 얻어 Client에 돌려준다. Resolver는 최종 answer와 delegation을 TTL 동안 cache한다.
사용할 공식·판정 관계
가정과 최초 요청 → Root 단계 → TLD 단계 → Authoritative 단계 → 반환과 상태 변화
각 왕복에서 query sender는 resolver이고, root와 TLD의 response는 다음 server를 가리키는 referral이며 마지막만 최종 record다.
가정과 최초 요청
구체적으로 관련 cache가 비었다고 명시하고 Client/Stub → Recursive Resolver에
QNAME=tu-darmstadt.de, QTYPE=A 또는 AAAA를 그린다.여기서 검산 Client가 root에 직접 묻는 그림이 아닌가?
다음 단계로 여기서 확인한 내용을 다음 ‘Root 단계’ 단계의 출발점으로 사용합니다.
Root 단계
구체적으로 Resolver → Root로 질의하고 Root → Resolver로
.deTLD nameserver의 NS referral과 필요 시 glue가 돌아온다.여기서 검산 Root가
tu-darmstadt.de최종 IP를 준다고 쓰지 않았는가?다음 단계로 여기서 확인한 내용을 다음 ‘TLD 단계’ 단계의 출발점으로 사용합니다.
TLD 단계
구체적으로 Resolver →
.deTLD NS로 질의하고 TLD → Resolver로tu-darmstadt.deauthoritative NS delegation이 돌아온다.여기서 검산 오른쪽 계층
.de를 빠뜨리지 않았는가?다음 단계로 여기서 확인한 내용을 다음 ‘Authoritative 단계’ 단계의 출발점으로 사용합니다.
Authoritative 단계
구체적으로 Resolver →
tu-darmstadt.deauthoritative NS로 같은 record를 묻고 공식 A/AAAA answer를 받는다.여기서 검산 NS referral과 A/AAAA answer를 다른 메시지로 표시했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘반환과 상태 변화’ 단계의 출발점으로 사용합니다.
반환과 상태 변화
구체적으로 Resolver → Client로 최종 answer를 보내고 얻은 record·delegation을 각 TTL 동안 cache한다.
여기서 검산 최종 receiver인 Client와 cache 상태를 표시했는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Client/stub -> recursive resolver -> root -> .de TLD -> authoritative tu-darmstadt.de -> final record, then cache.
정답이 이렇게 되는 이유
관련 cache가 비어 있다고 가정하면 Client는 recursive resolver에
tu-darmstadt.de의 A/AAAA를 요청한다. Resolver는 root에 질의해.deTLD referral을 받고,.deserver에 질의해tu-darmstadt.deauthoritative nameserver referral을 받는다. 이어 그 authoritative server에서 최종 record를 얻어 Client에 돌려준다. Resolver는 최종 answer와 delegation을 TTL 동안 cache한다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 Client가 root,
.de, TU authoritative server에 차례로 직접 묻고 root가 다음 server에 대신 연락한다.왜 틀렸나 일반적인 역할에서 Client는 recursive resolver에 맡기고, recursive resolver가 각 server에 iterative query를 보내 referral을 따라간다.
고쳐 말하면 Client→Resolver는 recursive request이고 Resolver↔Root/TLD/Authoritative가 iterative lookup 흐름이다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Root가
tu-darmstadt.de A?에 답할 때 가장 일반적으로 주는 것은 최종 IPv4 주소인가,.dedelegation인가?정답
.deTLD nameserver로 가라는 delegation/referral이다.이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
도메인 이름을 오른쪽에서 왼쪽으로 위임(referral)받는다고 생각하라.
DNS resolver가 tu-darmstadt.de를 resolve하려고 한다. Namensauflösung Ablauf를 sketch하라.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 흐름의 중간 메시지·광고·표 행 하나를 제거하거나 공격자가 바꿨다고 가정하세요. 바로 다음 상태가 무엇인지 sender, receiver, content, security impact 순서로 추적하세요.
고칠 답안: root server가 최종 IP를 준다고 쓰기
복구 힌트: 도메인 이름을 오른쪽에서 왼쪽으로 위임(referral)받는다고 생각하라.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Client/stub -> recursive resolver -> root -> .de TLD -> authoritative tu-darmstadt.de -> final record, then cache.
2.2.2 직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라. 기존 71문항 학습 번호 26 · 4점 프로토콜 추적
2.2.2 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.
TERMS FOR 2.2.2
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
최상위에서 `.de`, `.com` 같은 TLD의 nameserver 방향을 알려주는 DNS server입니다.
특정 top-level domain 아래의 authoritative server 방향을 알려줍니다.
해당 zone의 실제 DNS record에 권한 있는 최종 답변자입니다.
최종 IP 대신 다음에 물어볼 nameserver 정보를 주는 응답입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
DNS resolver cache에는 최종 A/AAAA record만 들어가는 것이 아니다. Root나 TLD가 준 NS delegation과 그 nameserver의 접속 주소인 glue도 각 TTL 동안 저장할 수 있다.
새 질의가 오면 resolver는 이름의 오른쪽 suffix와 일치하는 가장 구체적인 유효 cache 정보를 찾는다. 아무 delegation도 없으면 root에서 시작하고,
.deNS를 알고 있으면.de에서 시작하며, 해당 zone의 authoritative NS까지 알면 거기서 바로 시작한다.tu-darmstadt.de와beispiel.de는 왼쪽 label은 다르지만 공통 suffix.de를 가진다. 직전 조회로 얻은.deTLD nameserver 정보는 재사용할 수 있지만tu-darmstadt.de의 authoritative server는 다른 zone인beispiel.de를 책임지지 않는다.문제의 'direkt im Anschluss'는 일반적으로
.deNS/glue의 TTL이 아직 유효하다는 신호다. TTL이 만료됐거나 cache가 제거됐다면 root부터 다시 시작할 수 있다는 조건을 짧게 덧붙이면 정확하다.2 · 일상 장면으로 먼저 잡기
독일 업체 전화번호를 한 번 찾으며 독일 지역 안내소 위치를 메모했고, 바로 뒤 다른 독일 업체를 찾는 장면
.deTLD NS/glue cachetu-darmstadt.deauthoritative nameserverbeispiel.deauthoritative nameserver비유의 경계 실제 resolver cache에는 이전 사용자 질의의
beispiel.de최종 answer까지 이미 있을 수 있다. 시험은 직전.delookup으로 생긴 cache만을 중심으로 묻는다..de조회의 cache shortcut.deNS/glue HIT,beispiel.definal answer MISS유효
.dedelegation이 있어 contact하지 않음.deTLD NSbeispiel.deauthoritative NS referral 제공beispiel.deAuthoritative NS최종 A/AAAA answer 제공
이름이 완전히 같은지를 보지 말고 오른쪽에서 가장 긴 cached suffix가 어디까지 일치하는지 본다.
museum.org직후library.org를 찾기주어진 것과 목표 Resolver R이 방금
museum.org를 해석해.orgTLD NS는 cache했지만library.org정보는 없다. 모든 관련 TTL은 유효하다.R이
library.org A?요청을 받고 cache를 검사한다.왜? 외부 query 전에 가장 구체적인 유효 delegation을 재사용하기 위해서다.
중간 결과
.orgNS/glue cache hit,library.organswer miss가 난다.R이 root를 건너뛰고 cached
.orgTLD server에library.org A?를 묻는다.왜? 어느
.orgserver에 접속할지 이미 알고 있기 때문이다.중간 결과 TLD가
library.orgauthoritative NS referral을 반환한다.R이 새 authoritative NS에 최종 A record를 질의한다.
왜?
museum.org담당 server는library.orgzone의 공식 source가 아니기 때문이다.중간 결과
library.org의 최종 address를 얻는다.R이 Client에 answer를 보내고 새 delegation과 answer를 cache한다.
왜? 현재 요청을 완료하고 이후 조회를 줄이기 위해서다.
중간 결과 Root contact 없이 resolution이 끝난다.
예제 결론 공통 TLD delegation만 재사용하고 서로 다른 child zone의 authoritative 정보는 새로 얻는다.
실제 시험으로 옮기기 예제의
.org를.de로 바꾸면 root 생략→cached.deTLD→beispiel.deauthoritative→최종 answer가 시험 정답이다.이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: 직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.
이 문제의 풀이 전략: 이 소문제에서는 공통 suffix 표시 → 재사용 가능한 상태 → 첫 contact 결정 → 새 zone delegation → 조건 검산 순서로 진행합니다. 마지막에는 ‘유효한 `.de` cache에서 시작하고 `beispiel.de`의 authoritative delegation만 새로 구한다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.
`tu-darmstadt.de`와 `beispiel.de` 모두 `.de` 아래라는 공통점을 찾는다.
왼쪽 label이 다르다는 이유만으로 모든 cache를 버리지 않았는가?
최종적으로 구해야 하는 것
TTL이 만료된 경우에만 root부터 다시 시작할 수 있다고 제한한다.
직전 `tu-darmstadt.de` 조회에서 resolver가 얻은 `.de` TLD nameserver와 glue가 TTL 동안 cache되어 있다고 본다. 따라서 `beispiel.de` 조회에서는 root를 다시 contact할 필요가 없고, cached `.de` TLD server에 먼저 묻는다. TLD로부터 `beispiel.de`의 authoritative nameserver referral을 받은 뒤 그 server에 최종 record를 질의한다. `.de` cache가 만료됐다면 root부터 다시 시작할 수 있다.
사용할 공식·판정 관계
공통 suffix 표시 → 재사용 가능한 상태 → 첫 contact 결정 → 새 zone delegation → 조건 검산
이름이 완전히 같은지를 보지 말고 오른쪽에서 가장 긴 cached suffix가 어디까지 일치하는지 본다.
공통 suffix 표시
구체적으로
tu-darmstadt.de와beispiel.de모두.de아래라는 공통점을 찾는다.여기서 검산 왼쪽 label이 다르다는 이유만으로 모든 cache를 버리지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘재사용 가능한 상태’ 단계의 출발점으로 사용합니다.
재사용 가능한 상태
구체적으로 직전 lookup에서 받은
.deTLD NS와 glue가 TTL 내 cache되어 있다고 명시한다.여기서 검산 재사용 근거로 단순히 '직후'만 쓰지 않고 TTL을 연결했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘첫 contact 결정’ 단계의 출발점으로 사용합니다.
첫 contact 결정
구체적으로 Root는 생략하고 Resolver가 cached
.deTLD nameserver에beispiel.de를 질의한다.여기서 검산 Root 또는
tu-darmstadt.deauthoritative server를 첫 receiver로 쓰지 않았는가?다음 단계로 여기서 확인한 내용을 다음 ‘새 zone delegation’ 단계의 출발점으로 사용합니다.
새 zone delegation
구체적으로
.deTLD가beispiel.deauthoritative NS referral을 주면 Resolver가 그 server에 최종 A/AAAA를 묻는다.여기서 검산 TLD referral과 authoritative answer를 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘조건 검산’ 단계의 출발점으로 사용합니다.
조건 검산
구체적으로 TTL이 만료된 경우에만 root부터 다시 시작할 수 있다고 제한한다.
여기서 검산 항상 root를 생략한다는 무조건 명제로 만들지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
일반 답: root는 건너뛰고 cached .de TLD nameserver -> authoritative NS for beispiel.de를 contact한다.
정답이 이렇게 되는 이유
직전
tu-darmstadt.de조회에서 resolver가 얻은.deTLD nameserver와 glue가 TTL 동안 cache되어 있다고 본다. 따라서beispiel.de조회에서는 root를 다시 contact할 필요가 없고, cached.deTLD server에 먼저 묻는다. TLD로부터beispiel.de의 authoritative nameserver referral을 받은 뒤 그 server에 최종 record를 질의한다..decache가 만료됐다면 root부터 다시 시작할 수 있다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 두 domain이 다르므로 root부터 전 과정을 반복하거나, TU authoritative server에
beispiel.de를 묻는다.왜 틀렸나 공통
.dedelegation은 재사용 가능하지만tu-darmstadt.de와beispiel.de는 서로 다른 authoritative zone이다.고쳐 말하면 유효한
.decache에서 시작하고beispiel.de의 authoritative delegation만 새로 구한다.한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Resolver cache에 이미
beispiel.de A최종 answer가 유효한 TTL로 있다면 어느 nameserver를 contact해야 하는가?정답 아무 외부 nameserver도 contact하지 않고 cache에서 Client에게 바로 답할 수 있다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
tu-darmstadt.de와 beispiel.de가 공유하는 DNS suffix는 무엇인가?
직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 흐름의 중간 메시지·광고·표 행 하나를 제거하거나 공격자가 바꿨다고 가정하세요. 바로 다음 상태가 무엇인지 sender, receiver, content, security impact 순서로 추적하세요.
고칠 답안: 두 번째 이름이 다르다는 이유로 무조건 root부터 다시 시작하기
복구 힌트: tu-darmstadt.de와 beispiel.de가 공유하는 DNS suffix는 무엇인가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
일반 답: root는 건너뛰고 cached .de TLD nameserver -> authoritative NS for beispiel.de를 contact한다.
2.2.3 Eve가 Botnetz로 Alice의 server my.server.com을 DNS-Amplification-Angriff로 unerreichbar하게 만들려 한다. Botnetz, DNS-Resolver, Alice server 사이 communication을 표시하고 DNSSEC 사용 시 달라지는지 설명하라. 기존 71문항 학습 번호 27 · 6점 프로토콜 추적
2.2.3 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
Eve가 Botnetz로 Alice의 server my.server.com을 DNS-Amplification-Angriff로 unerreichbar하게 만들려 한다. Botnetz, DNS-Resolver, Alice server 사이 communication을 표시하고 DNSSEC 사용 시 달라지는지 설명하라.
TERMS FOR 2.2.3
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
DNS amplification은 DDoS의 reflection과 amplification을 함께 이용한다. Reflection은 공격자가 제3자인 DNS server로 하여금 피해자에게 응답하게 하는 것이고, amplification은 작은 query보다 큰 response를 만들어 피해자가 더 많은 bytes를 받게 하는 것이다.
전통적인 DNS query는 흔히 UDP를 사용한다. UDP는 TCP 3-way handshake처럼 source가 실제 그 주소를 보유했는지 연결 설정으로 확인하지 않으므로, 공격 network가 source-address filtering을 하지 않으면 bot이 packet header의 source IP를 Alice 주소로 위조할 수 있다.
DNS resolver는 UDP query의 source IP와 port를 response 목적지로 사용한다. 실제 packet sender가 bot이어도 header source가 Alice이면 resolver의 큰 response는 Alice 서버로 향한다.
증폭률은
response bytes ÷ query bytes다. Botnet의 분산된 많은 query와 여러 resolver의 큰 response가my.server.com에 집중되면 inbound bandwidth나 firewall·CPU 자원이 고갈되어 정상 사용자가 접속하지 못한다.DNSSEC는 DNS record의 서명과 진위를 검증하지만 UDP/IP source 주소를 인증하거나 대량 query를 rate-limit하지 않는다. RRSIG와 DNSKEY 같은 추가 data로 response가 커지면 오히려 사용할 수 있는 amplification factor가 커질 수도 있다.
2 · 일상 장면으로 먼저 잡기
Eve가 Alice의 반송 주소를 적은 작은 주문서 수천 장을 여러 식당에 보내고, 식당들이 큰 배달 상자를 Alice 집으로 보내는 장면
my.server.com의 bandwidth·resource exhaustion비유의 경계 현실의 packet source 주소는 domain 문자열이 아니라 Alice server의 IP이며, 모든 resolver가 open recursion을 제공하는 것은 아니다. Fragmentation, rate limiting, network filtering도 실제 규모에 영향을 준다.
my.server.com을 target으로 하라는 명령작은 UDP query, source IP=Alice로 spoof
더 큰 정상 DNS responses가 반사
원치 않는 traffic 집중, availability 상실
data authenticity는 제공하지만 source IP·flood는 미검사
Bot→resolver 화살표에는 실제 전송자와 spoofed source를 함께 쓰고, resolver→Alice 화살표에는 더 큰 response라고 표시한다.
50-byte query가 2,000-byte response가 되는 작은 공격
주어진 것과 목표 Bot B, DNS resolver R, 피해 server V가 있다. B는 V의 IP
192.0.2.80을 알고 있고 R은 외부 query에 응답한다.B가 R:53에 50-byte UDP DNS query를 보내며 IP header source를
192.0.2.80으로 쓴다.왜? R이 response를 실제 bot이 아니라 V에게 보내게 만들기 위해서다.
중간 결과 실제 sender=B, packet에 보이는 source=V인 위조 query가 R에 도착한다.
R이 query를 처리해 2,000-byte response를 만든다.
왜? 여러 RR 또는 추가 DNSSEC 자료가 포함된 큰 answer를 반환하기 때문이다.
중간 결과 증폭률은
2000 ÷ 50 = 40이다.R이 response를 header source였던 V로 보낸다.
왜? UDP request의 source address가 정상 reply destination으로 사용되기 때문이다.
중간 결과 V는 요청하지 않은 2,000 bytes를 받는다.
수천 bot과 resolver가 같은 과정을 반복한다.
왜? 분산·반사된 response를 V에 집중시켜 가용성을 깨뜨리기 위해서다.
중간 결과 V의 inbound link가 포화되고 정상 traffic이 손실된다.
R이 DNSSEC-valid answer를 제공하는 경우를 비교한다.
왜? 서명이 source spoofing이나 flood를 막는지 확인하기 위해서다.
중간 결과 응답은 진짜일 수 있지만 여전히 V로 반사되며 더 커질 수도 있다.
예제 결론 공격의 핵심은 거짓 DNS 내용이 아니라 spoofed source로 제3자의 큰 정상 응답을 피해자에게 보내는 것이다.
실제 시험으로 옮기기 예제의 B·R·V를 Eves Botnetz·DNS Resolver·Alice의
my.server.com으로 바꾸고 두 방향 화살표의 실제 sender, header source, message size를 표시한다.이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: Eve가 Botnetz로 Alice의 server my.server.com을 DNS-Amplification-Angriff로 unerreichbar하게 만들려 한다. Botnetz, DNS-Resolver, Alice server 사이 communication을 표시하고 DNSSEC 사용 시 달라지는지 설명하라.
이 문제의 풀이 전략: 이 소문제에서는 세 역할 배치 → 공격 query 표시 → 반사 response 표시 → 증폭과 피해 연결 → DNSSEC 하위 질문 → 직접 방어 구분 순서로 진행합니다. 마지막에는 ‘Bots→Resolvers는 spoofed small query, Resolvers→Alice는 amplified response이며 DNSSEC와 source filtering은 역할이 다르다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
Eve가 Botnetz로 Alice의 server my.server.com을 DNS-Amplification-Angriff로 unerreichbar하게 만들려 한다. Botnetz, DNS-Resolver, Alice server 사이 communication을 표시하고 DNSSEC 사용 시 달라지는지 설명하라.
왼쪽에 Eve의 botnet, 가운데 여러 DNS resolver, 오른쪽에 Alice의 `my.server.com`을 둔다.
Resolver라는 reflector를 생략하지 않았는가?
최종적으로 구해야 하는 것
근본 source spoofing 완화는 BCP 38 ingress/egress filtering이고 resolver 측에는 open recursion 제한과 response rate limiting이 직접적이다.
Bot들은 작은 UDP DNS query의 source IP를 Alice 서버 주소로 위조해 여러 resolver에 보낸다. Resolver는 요청 source가 Alice라고 믿고 더 큰 DNS response를 `my.server.com`으로 보내므로 reflection과 amplification이 발생한다. 이 응답이 대량으로 집중되면 Alice의 대역폭과 처리 자원이 고갈되어 가용성이 깨진다. DNSSEC는 DNS data를 인증할 뿐 IP source와 traffic volume을 검사하지 않아 공격을 막지 않으며 response를 더 크게 만들 수도 있다.
사용할 공식·판정 관계
세 역할 배치 → 공격 query 표시 → 반사 response 표시 → 증폭과 피해 연결 → DNSSEC 하위 질문 → 직접 방어 구분
Bot→resolver 화살표에는 실제 전송자와 spoofed source를 함께 쓰고, resolver→Alice 화살표에는 더 큰 response라고 표시한다.
세 역할 배치
구체적으로 왼쪽에 Eve의 botnet, 가운데 여러 DNS resolver, 오른쪽에 Alice의
my.server.com을 둔다.여기서 검산 Resolver라는 reflector를 생략하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘공격 query 표시’ 단계의 출발점으로 사용합니다.
공격 query 표시
구체적으로 각 Bot → Resolver에
small UDP DNS query, destination port 53,source IP = Alice server IP (spoofed)라고 쓴다.여기서 검산 실제 sender Bot과 header source Alice를 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘반사 response 표시’ 단계의 출발점으로 사용합니다.
반사 response 표시
구체적으로 각 Resolver →
my.server.com에large DNS response를 그린다. Resolver는 query source를 Alice로 보았기 때문에 그쪽에 reply한다.여기서 검산 Response가 Bot으로 돌아간다고 잘못 그리지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘증폭과 피해 연결’ 단계의 출발점으로 사용합니다.
증폭과 피해 연결
구체적으로 Response가 query보다 크고 여러 source에서 집중되어 bandwidth·처리 자원을 고갈시키며 서버가 unerreichbar해진다고 적는다.
여기서 검산 Bot 수 증가와 byte-size amplification을 둘 다 설명했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘DNSSEC 하위 질문’ 단계의 출발점으로 사용합니다.
DNSSEC 하위 질문
구체적으로 DNSSEC는 DNS data authenticity를 보장하지만 IP source spoofing과 flooding을 막지 않으며 signed response가 더 커질 수 있다고 답한다.
여기서 검산 DNSSEC가 공격 query의 발신자를 인증한다고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘직접 방어 구분’ 단계의 출발점으로 사용합니다.
직접 방어 구분
구체적으로 근본 source spoofing 완화는 BCP 38 ingress/egress filtering이고 resolver 측에는 open recursion 제한과 response rate limiting이 직접적이다.
여기서 검산 DNSSEC 하나만 방어로 제시하지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Bots -> resolvers: spoofed DNS queries with Alice as source; resolvers -> Alice: amplified DNS responses; DNSSEC does not automatically stop the availability attack.
정답이 이렇게 되는 이유
Bot들은 작은 UDP DNS query의 source IP를 Alice 서버 주소로 위조해 여러 resolver에 보낸다. Resolver는 요청 source가 Alice라고 믿고 더 큰 DNS response를
my.server.com으로 보내므로 reflection과 amplification이 발생한다. 이 응답이 대량으로 집중되면 Alice의 대역폭과 처리 자원이 고갈되어 가용성이 깨진다. DNSSEC는 DNS data를 인증할 뿐 IP source와 traffic volume을 검사하지 않아 공격을 막지 않으며 response를 더 크게 만들 수도 있다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 Botnet이 Alice에게 큰 DNS query를 직접 보내고 DNSSEC가 그 가짜 query를 서명 검사로 막는다.
왜 틀렸나 큰 traffic을 실제로 보내는 쪽은 제3자 resolver이고, DNSSEC는 일반 client query의 source identity를 인증하는 기술이 아니다.
고쳐 말하면 Bots→Resolvers는 spoofed small query, Resolvers→Alice는 amplified response이며 DNSSEC와 source filtering은 역할이 다르다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Query가 80 bytes이고 response가 3,200 bytes라면 amplification factor는 얼마이며, 누가 그 3,200 bytes를 받는가?
정답 Factor는
3200/80=40이고, source IP가 Alice로 spoof되었다면 Alice server가 response를 받는다.이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
증폭 공격에서 피해자는 query를 보내지 않았는데 왜 response를 받는가?
Eve가 Botnetz로 Alice의 server my.server.com을 DNS-Amplification-Angriff로 unerreichbar하게 만들려 한다. Botnetz, DNS-Resolver, Alice server 사이 communication을 표시하고 DNSSEC 사용 시 달라지는지 설명하라.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/4 slots
조건 변형: 흐름의 중간 메시지·광고·표 행 하나를 제거하거나 공격자가 바꿨다고 가정하세요. 바로 다음 상태가 무엇인지 sender, receiver, content, security impact 순서로 추적하세요.
고칠 답안: Bot들이 Alice에게 직접 DNS query를 보낸다고만 그리기
복구 힌트: 증폭 공격에서 피해자는 query를 보내지 않았는데 왜 response를 받는가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Bots -> resolvers: spoofed DNS queries with Alice as source; resolvers -> Alice: amplified DNS responses; DNSSEC does not automatically stop the availability attack.
2.2.4 Alice가 DNS query에 대해 'tu-darmstadt.de. 86400 IN MX ...' 형태의 여러 Resource Records를 받았다. 이 records는 무엇을 의미하는가? 기존 71문항 학습 번호 28 · 4점 단답형
2.2.4 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
Alice가 DNS query에 대해 'tu-darmstadt.de. 86400 IN MX ...' 형태의 여러 Resource Records를 받았다. 이 records는 무엇을 의미하는가?
TERMS FOR 2.2.4
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
HTTP request method 중 하나로 parameter가 흔히 URL query string에 들어갑니다.
작은 예: Login을 GET으로 보내면 ?user=alice&pw=secret이 history나 log에 남을 수 있습니다.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
최상위에서 `.de`, `.com` 같은 TLD의 nameserver 방향을 알려주는 DNS server입니다.
특정 top-level domain 아래의 authoritative server 방향을 알려줍니다.
해당 zone의 실제 DNS record에 권한 있는 최종 답변자입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
DNS Resource Record의 기본 형식은
NAME TTL CLASS TYPE RDATA다. NAME은 이 정보가 속한 owner name, TTL은 cache 가능 시간, CLASS는 주소 체계, TYPE은 정보 종류, RDATA는 type에 맞는 실제 값이다.tu-darmstadt.de.의 마지막 점은 DNS root까지 포함한 absolute Fully Qualified Domain Name(FQDN)임을 나타낸다.86400은 초 단위 TTL이며86400 ÷ 3600 = 24이므로 resolver가 최대 24시간 cache할 수 있다는 뜻이다.IN은 Internet class이고 incoming의 약자가 아니다.MX는 Mail Exchanger record로, 이 domain으로 들어오는 email을 어느 mail server에 배달할지 알려 준다.MX RDATA는
preference exchanger-hostname순서다. Preference 숫자가 낮을수록 먼저 시도하며, exchanger는 직접 IP가 아니라 hostname이므로 보내는 Mail Transfer Agent가 그 이름의 A/AAAA도 조회한다.시험의 세 record는 모두 preference 10이므로
b2681.mx.srv.dfn.de.,c2681.mx.srv.dfn.de.,a2681.mx.srv.dfn.de.가 같은 우선순위의 mail exchanger 후보다. 한 후보에 실패하면 다른 후보를 시도할 수 있으며, 동일 preference가 메일을 세 곳에 반드시 중복 전송한다는 뜻은 아니다.2 · 일상 장면으로 먼저 잡기
회사 택배 라벨에 회사명, 라벨을 기억할 시간, 주소 체계, 물류창고 종류, 같은 우선순위의 세 창고 이름이 적힌 장면
tu-darmstadt.de.비유의 경계 실제 SMTP delivery에는 retry queue, DNS resolver 동작, exchanger의 A/AAAA 선택과 네트워크 오류가 추가된다. MX record 자체는 개별 사용자 mailbox나 server의 안전성을 말하지 않는다.
tu-darmstadt.de.— root까지 쓴 owner FQDN86400seconds = 24 hours cacheIN= Internet,MX= Mail Exchanger세 줄 모두
10, 따라서 같은 우선순위b2681,c2681,a2681.mx.srv.dfn.de.왼쪽부터 공통 다섯 필드로 자르고, RDATA 안에서 preference 10과 exchanger hostname을 다시 분리한다.
두 단계 우선순위를 가진 작은 MX 집합
주어진 것과 목표
club.example. 600 IN MX 5 primary.club.example.과club.example. 600 IN MX 20 backup.club.example.두 record를 읽는다.각 token을 NAME, TTL, CLASS, TYPE, RDATA로 나눈다.
왜? 숫자 600과 5 또는 20의 역할을 혼동하지 않기 위해서다.
중간 결과 600은 cache 시간이고 5·20은 MX preference임을 구분한다.
보내는 MTA가 더 낮은 preference 5의
primary.club.example을 고른다.왜? MX에서는 작은 preference 숫자가 더 우선이기 때문이다.
중간 결과 Primary exchanger의 A/AAAA를 추가 조회하고 SMTP 연결을 시도한다.
Primary가 도달 불가능하면 preference 20의 backup을 시도한다.
왜? 여러 MX가 장애 시 대체 배달 경로를 제공할 수 있기 때문이다.
중간 결과 동일 메일을 즉시 두 곳에 복제하는 대신 순서에 따라 delivery를 재시도한다.
600초가 지난 cache 상태를 확인한다.
왜? TTL이 mail server 우선순위가 아니라 재조회 시점을 정한다는 점을 검산하기 위해서다.
중간 결과 Resolver는 authoritative DNS에 최신 MX를 다시 물을 수 있다.
예제 결론 TTL과 preference는 모두 숫자지만 전자는 cache 시간, 후자는 mail exchanger 선택 순서다.
실제 시험으로 옮기기 예제와 달리 시험에서는 세 record 모두 preference가 10이다. 정확한 세 hostname과 동일 우선순위, 86400초=24시간을 그대로 읽어 쓴다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: Alice가 DNS query에 대해 'tu-darmstadt.de. 86400 IN MX ...' 형태의 여러 Resource Records를 받았다. 이 records는 무엇을 의미하는가?
이 문제의 풀이 전략: 이 소문제에서는 Owner name 읽기 → TTL 환산 → Class와 Type → RDATA 세 줄 읽기 → 동일 preference 의미 → 다음 DNS 동작 순서로 진행합니다. 마지막에는 ‘TTL=86400초, preference=10, exchanger=세 hostname이며 동일 preference는 같은 우선순위 후보를 뜻한다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
tu-darmstadt.de.
IN / MX
a2681, b2681, c2681 MX server
최종적으로 구해야 하는 것
각 RR field의 의미와 세 mail exchanger가 같은 preference를 가진다는 해석
사용할 공식·판정 관계
Cache가 이 record를 재사용할 수 있는 최대 시간을 이해하기 위한 환산이다.
Owner name 읽기
구체적으로 세 RR 모두
tu-darmstadt.de.에 속하며 마지막 점은 absolute FQDN의 root label을 나타낸다.여기서 검산 각 exchanger hostname을 owner로 잘못 읽지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘TTL 환산’ 단계의 출발점으로 사용합니다.
TTL 환산
구체적으로
86400은 초 단위 TTL이고86400/3600=24이므로 resolver가 24시간 cache할 수 있다.여기서 검산 TTL을 query 횟수나 preference로 해석하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Class와 Type’ 단계의 출발점으로 사용합니다.
Class와 Type
구체적으로
IN은 Internet class,MX는 이 domain의 inbound mail exchanger를 지정하는 record type이다.여기서 검산 IN을 incoming의 약자로 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘RDATA 세 줄 읽기’ 단계의 출발점으로 사용합니다.
RDATA 세 줄 읽기
구체적으로 Preference 10의 exchanger는 각각
b2681.mx.srv.dfn.de.,c2681.mx.srv.dfn.de.,a2681.mx.srv.dfn.de.다.여기서 검산 시험에 나온 세 hostname과 preference 값을 모두 정확히 옮겼는가?
다음 단계로 여기서 확인한 내용을 다음 ‘동일 preference 의미’ 단계의 출발점으로 사용합니다.
동일 preference 의미
구체적으로 세 값이 모두 10이라 같은 우선순위의 후보이며 sender MTA가 한 후보를 선택하고 실패 시 다른 후보를 시도할 수 있다.
여기서 검산 숫자가 클수록 우선이거나 세 server에 항상 중복 발송한다고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘다음 DNS 동작’ 단계의 출발점으로 사용합니다.
다음 DNS 동작
구체적으로 MX target은 hostname이므로 실제 SMTP 연결 전 각 선택 target의 A/AAAA record를 조회해야 한다.
여기서 검산 MX 값 자체를 IP address라고 부르지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
tu-darmstadt.de의 email delivery용 Mail Exchanger records이며, 86400초 TTL과 IN class를 가진다.
정답이 이렇게 되는 이유
세 Resource Record는
tu-darmstadt.de.로 들어오는 mail을 받을 MX server들을 나타낸다. 각 record의 TTL은 86400초, 즉 24시간이고IN은 Internet class다. 세 exchanger는 각각b2681.mx.srv.dfn.de.,c2681.mx.srv.dfn.de.,a2681.mx.srv.dfn.de.이며 모두 preference 10이라 같은 우선순위다. 보내는 MTA는 선택한 exchanger hostname의 A/AAAA를 조회해 SMTP delivery를 시도하고 필요하면 다른 동일 우선순위 후보를 사용할 수 있다.초보자가 가장 자주 뒤집는 지점
잘못된 생각
86400이 MX 우선순위이고10이 port 번호이며 세 server에 메일을 동시에 보낸다.왜 틀렸나 86400은 공통 TTL, 10은 MX RDATA의 preference다. SMTP port와 배달 복제 여부는 이 RR에 그렇게 표현되지 않는다.
고쳐 말하면 TTL=86400초, preference=10, exchanger=세 hostname이며 동일 preference는 같은 우선순위 후보를 뜻한다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문
example.net. 300 IN MX 5 mail-a.example.net.과 preference 25인 backup이 있으면 어느 값을 먼저 시도하고 300은 무엇인가?정답 더 낮은 preference 5의 mail-a를 먼저 시도한다. 300은 resolver가 record를 cache할 수 있는 초 단위 TTL이다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
RR 한 줄은 owner, TTL, class, type, data 순서로 읽는다.
Alice가 DNS query에 대해 'tu-darmstadt.de. 86400 IN MX ...' 형태의 여러 Resource Records를 받았다. 이 records는 무엇을 의미하는가?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: MX를 IP address record로 설명하기
복구 힌트: RR 한 줄은 owner, TTL, class, type, data 순서로 읽는다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
tu-darmstadt.de의 email delivery용 Mail Exchanger records이며, 86400초 TTL과 IN class를 가진다.