사전 DNS
프로토콜

DNS

gabury1

이름을 값으로 바꿔 주는 규격입니다. 프로그램이 어떤 이름을 물으면 그 이름을 맡은 서버가 답을 돌려줍니다. 인터넷의 이름 전부를 한 서버가 들고 있지는 않습니다. 그래서 한 번 묻고 끝나지 않고 묻고 답하는 일이 이어집니다.

쉽고 빠른 이해

이름을 대면 값을 돌려주는 규격입니다. Mockapetris.ISI.EDU 같은 이름을 대면 그 이름을 맡은 서버가 접속에 쓸 주소를 돌려줍니다.

인터넷의 이름 전부를 한 서버가 들고 있을 수는 없습니다. 그래서 이름을 점으로 끊어 나무처럼 벌려 두었습니다. 가지마다 다른 조직이 자기 몫만 책임집니다.

  1. 묻는 쪽이 이름 하나와 원하는 정보의 종류를 댑니다.
  2. 답을 가진 서버를 모르면 위쪽 서버가 아래쪽 서버를 가리켜 줍니다. 그 가리킴을 따라 한 칸씩 내려갑니다.
  3. 이름을 맡은 서버가 값을 돌려줍니다. 받은 쪽은 그 값을 정해진 시간 동안 보관해 둡니다.

대가는 왕복입니다. 처음 찾는 이름은 여러 번 오가야 답이 나옵니다. 보관해 둔 값은 그 시간이 다하기 전까지는 출처에 다시 물어보지 않은 값입니다.

상세

DNS(Domain Name System, 도메인 네임 시스템)는 세 덩어리로 이루어집니다. 명세는 그 셋을 도메인 네임 스페이스와 리소스 레코드(RR, Resource Record), 네임서버, 리졸버라고 부릅니다. 아래에서는 리소스 레코드를 명세 표기 그대로 RR로 줄여 씁니다.

  • 도메인 네임 스페이스와 리소스 레코드 — 트리 구조의 이름 공간, 그리고 그 이름에 딸린 데이터를 정한 규격입니다. 개념적으로는 이름 공간 트리의 노드와 잎 하나하나가 정보 한 벌의 이름입니다. 질의는 특정 한 벌에서 특정 종류의 정보를 뽑아내려는 시도입니다. 질의는 관심 있는 도메인 이름을 대고, 원하는 자원 정보의 종류를 밝힙니다.
  • 네임서버 — 도메인 트리의 구조와 정보를 들고 있는 서버 프로그램입니다. 대체로 한 네임서버는 이름 공간의 일부에 대해서만 완전한 정보를 가집니다. 나머지는 도메인 트리의 다른 부분으로 이어 주는 다른 네임서버의 포인터로 대신합니다. 완전한 정보를 가진 부분에 대해 그 네임서버는 권한(authority)을 가진다고 말합니다.
  • 리졸버 — 클라이언트 요청을 받아 네임서버에서 정보를 뽑아내는 프로그램입니다. 리졸버는 최소한 하나의 네임서버에 닿을 수 있어야 합니다. 그 네임서버의 정보로 곧장 답하거나, 다른 네임서버로 가는 참조(referral)를 따라 질의를 이어 갑니다.

이름의 모양

도메인 이름은 하나 이상의 라벨로 된 순서 있는 목록입니다. 아래 수치는 전역 DNS(global DNS)의 이름에 대한 것입니다. 라벨 하나의 길이는 0옥텟에서 63옥텟 사이입니다. 완전한 도메인 이름(FQDN, Fully Qualified Domain Name)에서는 목록의 마지막 라벨이 길이 0입니다. 길이가 0일 수 있는 라벨은 이것뿐입니다. 이 라벨을 루트 또는 루트 라벨이라고 부릅니다. 전역 DNS의 도메인 이름은 와이어 포맷에서 최대 길이가 255옥텟이고, 루트가 그 계산에서 1옥텟을 차지합니다.

표기 형식은 루트에서 먼 라벨부터 차례로 늘어놓고 라벨 사이에 점을 찍은 것입니다. 표기 형식의 완전한 도메인 이름은 루트 라벨과 그 앞의 점을 포함합니다. 루트가 아닌 라벨이 둘인 완전한 도메인 이름은 표기 형식에서 언제나 example.tld 가 아니라 example.tld. 로 적힙니다.

flowchart TD
    ROOT["루트 라벨"] --> EDU["EDU"]
    EDU --> ISI["ISI.EDU"]
    ISI --> MOCK["Mockapetris.ISI.EDU"]

이름 하나는 루트에서 그 마디까지 내려온 경로입니다. 한 마디 내려갈 때마다 라벨이 하나씩 앞에 붙습니다. 표기 형식은 그 경로를 루트에서 먼 라벨부터 거꾸로 적은 것입니다.

존과 위임

권한 정보는 존(zone)이라는 단위로 묶입니다. 도메인 데이터베이스는 클래스로 한 번, 노드 사이를 자르는 컷으로 한 번 나뉩니다. 한 클래스 안에서 컷은 인접한 두 노드 사이 어디에나 낼 수 있습니다. 컷을 다 내고 나면 이어져 있는 이름 공간 한 덩이가 존 하나입니다. 그 존은 이어진 영역의 모든 이름에 대해 권한을 가진다고 말합니다.

나누는 자리는 어떤 조직이 하위 트리의 통제권을 가져가려는 지점입니다. 자기 존을 통제하게 된 조직은 존 안의 데이터를 혼자 바꾸고, 존에 이어지는 새 가지를 키우고, 있던 노드를 지우고, 자기 존 아래에 새 하위 존을 위임할 수 있습니다.

위임은 어떤 도메인의 정점 아래에 별도의 존이 생기는 과정입니다. 부모 존에 자식 원점(origin)을 가리키는 NS(name server) RRset(RR set, RR 묶음)이 더해질 때 일어납니다. 위임은 본래 존 컷에서 일어납니다.

flowchart TD
    subgraph P["부모 존"]
        ROOT["루트 라벨"] --> EDU["EDU"]
        EDU --> ISI0["ISI.EDU 의 NS RRset"]
    end
    subgraph C["자식 존"]
        ISI["ISI.EDU · 자식 원점"] --> MOCK["Mockapetris.ISI.EDU"]
    end
    ISI0 -. "존 컷" .-> ISI

두 상자가 각각 존 하나입니다. 컷을 다 내고 남은, 이어져 있는 이름 공간 한 덩이가 상자 안입니다. 상자를 건너는 점선이 위임입니다. 부모 존은 자식 원점을 가리키는 NS RRset을 들고 있을 뿐이고, 그 아래 이름들에 대한 권한은 자식 존이 가집니다.

부르는 이름

RFC 9499가 정리한 현행 용어는 이렇습니다.

이름 뜻
리졸버 클라이언트 요청에 응해 네임서버에서 정보를 뽑아내는 프로그램. 이름·타입·클래스로 질의하고 응답을 받는다
스터브 리졸버 해석 전부를 스스로 못 하는 리졸버. 대개 실제 해석은 재귀 리졸버에 맡긴다
재귀 모드 질의를 받아 로컬 캐시에서 답하거나, 최종 답을 얻으려고 다른 서버에 질의를 보내는 서버의 해석 방식
재귀 리졸버 재귀 모드로 도는 리졸버. 일반적으로 받은 답을 캐시하리라 기대되지만, 캐시하지 않는 재귀 리졸버도 있을 수 있다
반복 해석 클라이언트가 비재귀 질의를 되풀이하며 참조나 별칭을 따라가는 방식
권한 서버 로컬 지식으로 존의 내용을 아는 서버. 다른 서버에 묻지 않고 그 존에 대한 질의에 답할 수 있다

권한 서버는 존의 NS 레코드에 이름이 적힌 시스템입니다. 답할 존으로 설정된 질의에 대해 응답 헤더의 AA(Authoritative Answer, 권한 있는 응답) 플래그를 1로 세워 답합니다.

교환 순서

한 번의 이름 해석은 왕복 하나로 끝나기도 하고 여러 왕복으로 이어지기도 합니다. 갈림은 재귀 비트 두 개가 정합니다.

재귀 비트 협상

재귀 모드는 클라이언트와 네임서버가 둘 다 그 사용에 동의하는 경우로 한정됩니다. 동의는 질의와 응답 메시지의 두 비트로 협상합니다.

  • RA(Recursion Available, 재귀 가능) — 네임서버가 모든 응답에 세우거나 지웁니다. 클라이언트가 재귀 서비스를 요청했는지와 무관하게, 그 네임서버가 클라이언트에게 재귀 서비스를 제공할 뜻이 있으면 참입니다. 즉 RA는 사용이 아니라 가용을 알립니다.
  • RD(Recursion Desired, 재귀 요청) — 질의에 담깁니다. 요청자가 이 질의에 재귀 서비스를 원하는지를 나타냅니다. 클라이언트는 어느 네임서버에든 재귀 서비스를 요청할 수 있습니다. 다만 앞서 RA를 보내온 서버에서만 그것을 받으리라 기대해야 합니다.

RD가 선 질의가 재귀 서비스를 제공할 뜻이 있는 서버에 도착하면 재귀 모드가 됩니다. 클라이언트는 응답에 RA와 RD가 둘 다 서 있는지를 보고 재귀 모드가 쓰였음을 확인할 수 있습니다.

packet-beta
0: "QR"
1-4: "Opcode"
5: "AA"
6: "TC"
7: "RD"
8: "RA"
9-11: "Z"
12-15: "RCODE"

협상에 쓰는 두 비트는 메시지 헤더의 두 번째 16비트 워드에 들어 있습니다. RD와 RA는 그 안에서 한 칸 차이로 붙어 있습니다. 그림의 QR은 이 메시지가 질의인지 응답인지를 가르는 한 비트입니다. 같은 워드에 앞서 나온 AA도 있고, 뒤의 「실패」에서 다루는 TC(메시지가 잘렸음을 알리는 비트)와 RCODE(응답 코드)도 여기 들어갑니다.

한 번의 해석

sequenceDiagram
    participant 스터브 리졸버
    participant 재귀 리졸버
    participant 루트 네임서버
    participant EDU 네임서버
    participant 권한 서버
    스터브 리졸버->>재귀 리졸버: 질의 RD=1
    재귀 리졸버->>루트 네임서버: 비재귀 질의
    루트 네임서버-->>재귀 리졸버: 참조 · Authority 에 NS RR
    재귀 리졸버->>EDU 네임서버: 비재귀 질의
    EDU 네임서버-->>재귀 리졸버: 참조 · Authority 에 NS RR
    재귀 리졸버->>권한 서버: 비재귀 질의
    권한 서버-->>재귀 리졸버: 응답 AA=1 · Answer 에 RR
    재귀 리졸버-->>스터브 리졸버: 응답 RA=1

그림의 왼쪽 절반은 스터브 리졸버가 RD를 세워 재귀 리졸버에 한 번 묻는 왕복입니다. 오른쪽은 그 뒤에 재귀 리졸버가 혼자 도는 반복 해석입니다. 스터브 리졸버가 보는 왕복은 하나이고, 재귀 리졸버가 실제로 치른 왕복은 위임을 따라간 횟수만큼입니다.

리졸버가 도는 절차

절차에 나오는 이름 셋을 먼저 둡니다. SNAME은 리졸버가 지금 찾고 있는 이름입니다. SLIST(server list, 질의할 서버 이름 목록)는 그 이름을 물어볼 서버들의 이름을 담은 목록입니다. CNAME(Canonical Name, 정규 이름)은 어떤 이름의 정규 이름을 담은 RR입니다.

RFC 1034의 최상위 알고리즘은 네 단계입니다.

  1. 답이 로컬 정보에 있는지 봅니다. 있으면 클라이언트에게 돌려줍니다.
  2. 물어보기에 알맞은 서버들을 찾습니다.
  3. 하나가 응답을 돌려줄 때까지 그들에게 질의를 보냅니다.
  4. 응답을 분석합니다.
    • 질문에 답했거나 이름 오류를 담고 있으면 데이터를 캐시하고 클라이언트에게 돌려줍니다.
    • 다른 서버로 가는 더 나은 위임을 담고 있으면 위임 정보를 캐시하고 2번으로 갑니다.
    • CNAME이 있고 그것이 답 자체가 아니면 CNAME을 캐시합니다. 그리고 SNAME을 CNAME RR의 정규 이름으로 바꾼 뒤 1번으로 갑니다.
flowchart TD
    S1["1 · 로컬 정보를 본다"] -->|없다| S2["2 · 물어볼 서버를 찾는다"]
    S1 -->|있다| OUT["클라이언트에게 돌려준다"]
    S2 --> S3["3 · 응답이 올 때까지 질의를 보낸다"]
    S3 --> S4["4 · 응답을 분석한다"]
    S4 -->|답 또는 이름 오류| OUT
    S4 -->|더 나은 위임| S2
    S4 -->|CNAME · 찾는 이름을 바꾼다| S1

네 단계가 한 줄로 흐르지 않습니다. 4번에서 되돌아가는 고리가 둘입니다. 위임을 받으면 2번으로 돌아가 새 서버 목록을 짭니다. CNAME을 받으면 찾는 이름 자체가 바뀌므로 1번으로 돌아갑니다.

2번은 필요한 데이터를 물을 네임서버를 찾는 단계입니다. 전략은 SNAME에서 시작해 SNAME의 부모 도메인 이름, 조부모, 그렇게 루트 쪽으로 올라가며 로컬에 있는 네임서버 RR을 찾는 것입니다. SNAME이 Mockapetris.ISI.EDU 라면 Mockapetris.ISI.EDU, ISI.EDU, EDU, 그리고 루트 . 순으로 NS RR을 찾습니다. 이 NS RR들은 SNAME이나 그 위 존의 호스트 이름을 나열합니다. 그 이름들을 SLIST에 복사합니다. 대개는 루트 서버 둘과 그 호스트 도메인 서버 둘을 고릅니다. 둘씩인 이유는 이중화입니다. 루트 서버가 결국 도메인 공간 전체로 가는 길을 내줍니다.

3번은 응답이 올 때까지 질의를 내보냅니다. 전략은 모든 서버의 모든 주소를 전송 사이에 타임아웃을 두고 돌아가며 부르는 것입니다.

위임을 따라갈 때마다 리졸버 알고리즘은 SLIST를 다시 초기화합니다. 그래서 루트에서 아래로 내려가는 한 걸음마다 물어볼 서버 목록이 새로 짜입니다.

네임서버가 답하는 절차

RR이 존마다 하나씩, 그리고 캐시용으로 하나 더, 여러 트리 구조로 정리돼 있다고 가정한 절차입니다.

  1. 재귀 서비스를 제공할 뜻이 있는지에 따라 응답의 재귀 가능 값을 세우거나 지웁니다. 재귀 서비스가 가능하고 질의의 RD로 요청됐으면 5단계로, 아니면 2단계로 갑니다.
  2. QNAME의 가장 가까운 조상인 존을 사용 가능한 존들에서 찾습니다. 찾으면 3단계로, 아니면 4단계로 갑니다.
  3. 존 안에서 라벨 하나씩 아래로 맞춰 나갑니다. 맞추는 과정은 여러 방식으로 끝납니다.
    • QNAME 전체가 맞으면 노드를 찾은 것입니다. QTYPE에 맞는 RR을 전부 Answer 섹션에 복사하고 6단계로 갑니다.
    • 맞춰 나가다 권한 데이터 밖으로 나가게 되면 그것이 참조입니다. 존의 바닥을 따라 컷을 표시하는 NS RR을 가진 노드를 만났을 때 일어납니다. 하위 존의 NS RR을 응답의 Authority 섹션에 복사합니다. 쓸 수 있는 주소는 Additional 섹션에 넣습니다. 권한 데이터나 캐시에서 주소를 얻을 수 없으면 glue RR을 씁니다. 그리고 4단계로 갑니다.

캐시가 있으면 이 왕복은 잘립니다. 리졸버 알고리즘 1번이 로컬 정보를 먼저 보고, 4번이 답과 위임 정보를 캐시에 넣기 때문입니다. 캐시에 넣은 RR을 언제까지 그대로 써도 되는지는 그 RR의 TTL(Time To Live, 살아 있는 시간)이 정합니다. TTL은 정보의 출처에 다시 물어보기 전까지 그 RR을 캐시해 둬도 되는 시간 간격을 정합니다.

예시

RFC 1034 §6.2.1에 실린 질의 한 벌입니다. QNAME은 SRI-NIC.ARPA., QCLASS는 IN, QTYPE은 A 입니다.

메시지의 다섯 섹션

block-beta
columns 1
  h["Header"]
  q["Question"]
  an["Answer"]
  au["Authority"]
  ad["Additional"]

질의든 응답이든 메시지 한 벌은 다섯 섹션이 이 순서로 놓인 것입니다. 질의는 Header와 Question만 채우고 나머지 셋을 비워 보냅니다. 응답은 같은 자리에 값을 채워 돌려줍니다.

Question 섹션의 세 칸은 이렇게 정해져 있습니다. QNAME은 라벨의 나열로 표현한 도메인 이름이고, 각 라벨은 길이 옥텟 하나 뒤에 그 수만큼의 옥텟이 옵니다. 도메인 이름은 루트의 널 라벨을 뜻하는 길이 0 옥텟으로 끝납니다. QTYPE은 질의의 종류를 정하는 2옥텟 코드입니다. TYPE 필드에 유효한 모든 코드에 더해, RR 타입 하나보다 넓게 맞출 수 있는 일반 코드가 몇 개 더 들어갑니다. QCLASS는 질의의 클래스를 정하는 2옥텟 코드입니다. 인터넷이면 IN 입니다.

질의와 두 응답

같은 질의를 두 서버에 보냈습니다. 하나는 SRI-NIC.ARPA에 권한이 있는 C.ISI.EDU이고, 다른 하나는 권한이 없는 서버입니다. 섹션마다 실제로 실린 값은 이렇습니다.

섹션 질의 C.ISI.EDU 의 응답 권한 없는 서버의 응답
Header OPCODE=SQUERY OPCODE=SQUERY, RESPONSE, AA OPCODE=SQUERY,RESPONSE
Question QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A 질의와 같음 질의와 같음
Answer 비어 있음 SRI-NIC.ARPA. 86400 IN A 26.0.0.73 · 86400 IN A 10.0.0.51 SRI-NIC.ARPA. 1777 IN A 10.0.0.51 · 1777 IN A 26.0.0.73
Authority 비어 있음 비어 있음 비어 있음
Additional 비어 있음 비어 있음 비어 있음

응답의 헤더는 질의의 헤더와 같습니다. 다른 곳은 둘입니다. RESPONSE 비트가 서서 이 메시지가 질의가 아니라 응답임을 알립니다. AA 비트가 서서 Answer 섹션의 주소 RR이 권한 데이터에서 나왔음을 알립니다. Answer 섹션의 86400은 TTL, IN은 클래스, A는 타입, 그 뒤가 값입니다. 여기서 TTL은 이 RR을 86400초 동안 캐시해 둔 뒤 출처에 다시 물어보라는 뜻입니다.

두 응답이 갈리는 자리는 표의 두 칸입니다. 오른쪽 응답의 헤더에는 AA가 없습니다. 그리고 TTL이 86400이 아니라 1777입니다. 이 예에서 끌어낼 수 있는 추론은 데이터가 존이 아니라 캐시에서 나왔다는 것입니다. 두 응답을 갈라 본 자리가 이 두 곳입니다.

실패

응답 코드

RCODE(Response Code)는 응답의 일부로 세워지는 4비트 필드입니다. 값의 뜻은 이렇습니다.

값 이름 뜻
0 No error condition 오류 없음
1 Format error 네임서버가 질의를 해석할 수 없었다
2 Server failure 네임서버 자신의 문제로 이 질의를 처리할 수 없었다
3 Name Error 권한 있는 네임서버의 응답에서만 뜻이 있다. 질의가 가리킨 도메인 이름이 존재하지 않는다는 뜻이다
4 Not Implemented 네임서버가 요청된 종류의 질의를 지원하지 않는다
5 Refused 네임서버가 정책상의 이유로 지정된 연산 수행을 거부한다
6~15 — 앞으로 쓰려고 예약돼 있다

값 3은 권한 있는 네임서버가 낸 응답에서만 뜻을 가집니다. 캐시나 참조로 받은 응답에서 같은 값을 그대로 읽으면 판단이 어긋납니다.

잘린 응답

UDP(User Datagram Protocol)로 보내는 메시지는 서버 포트 53을 씁니다. UDP로 실어 나르는 메시지는 512바이트로 제한됩니다. IP 헤더와 UDP 헤더는 이 계산에 넣지 않습니다. 더 긴 메시지는 잘리고 헤더의 TC(TrunCation, 절단) 비트가 섭니다. TC는 전송 채널이 허용하는 길이를 넘어서 이 메시지가 잘렸음을 나타내는 필드입니다.

TC가 선 응답을 받은 쪽은 거기서 멈추지 않습니다. 같은 질의를 TCP(Transmission Control Protocol, 전송 제어 프로토콜)로 다시 보내 잘리지 않은 답을 받습니다. RFC 7766은 DNS 프로토콜의 본래 512바이트 한계를 넘는 크기의 메시지에 TCP가 자주 쓰인다고 적습니다. 전체 존 전송에는 TCP가 언제나 쓰입니다.

UDP는 존 전송에는 받아들일 수 없습니다. 다만 인터넷에서 표준 질의에는 권장되는 방식입니다. UDP로 보낸 질의는 유실될 수 있고, 그래서 재전송 전략이 필요합니다.

최적의 UDP 재전송 정책은 인터넷의 성능과 클라이언트의 필요에 따라 달라집니다. 명세가 권장하는 것은 둘입니다.

  • 클라이언트는 어떤 서버의 특정 주소로 질의를 되풀이하기 전에 다른 서버와 다른 서버 주소를 먼저 시도해야 합니다.
  • 재전송 간격은 가능하면 앞선 통계에 기반해야 합니다. 지나치게 공격적인 재전송은 커뮤니티 전체의 응답을 쉽게 지연시킬 수 있습니다. 클라이언트가 기대하는 서버에 얼마나 잘 연결돼 있는지에 따라 다르지만, 최소 재전송 간격은 2~5초여야 합니다.

전송 규격의 갱신

RFC 1123 §6.1.3.2는 원래 이렇게 적었습니다. DNS 리졸버와 재귀 서버는 존 전송이 아닌 질의를 보낼 때 UDP를 지원해야 하고(MUST), TCP를 지원해야 합니다(SHOULD). 일부 구현자는 이 문장을 TCP 지원이 DNS 프로토콜의 선택 기능이라는 뜻으로 받아들였습니다.

RFC 7766이 이 대목을 갱신했습니다. 지금은 TCP 지원이 완전한 DNS 프로토콜 구현의 필수(REQUIRED) 부분입니다. 모든 범용 DNS 구현은 UDP와 TCP 전송을 둘 다 지원해야 합니다(MUST).

  • 권한 서버 구현은 TCP를 지원해야 합니다. 그래야 응답 크기가 UDP 패킷 하나에 들어가는 만큼으로 제한되지 않습니다.
  • 재귀 서버 또는 포워더 구현은 TCP를 지원해야 합니다. 그래야 TCP를 쓸 수 있는 서버의 큰 응답이 TCP를 쓸 수 있는 클라이언트에 닿는 것을 막지 않습니다.
  • 스터브 리졸버 구현은 TCP를 지원해야 합니다. 그러지 않으면 자기 클라이언트와 상류 서버 사이의 상호운용성을 제한하게 됩니다.

언제 UDP를 쓰고 언제 TCP를 쓸지에 대해서도 갱신이 있었습니다. RFC 1123은 존 전송이 아닌 질의를 보내는 리졸버나 서버가 UDP 질의를 먼저 보내야 한다고(MUST) 적었습니다. 이 요구는 완화됐습니다. 스터브 리졸버와 재귀 리졸버는 로컬 운영상의 이유에 따라 TCP 질의든 UDP 질의든 골라 보낼 수 있습니다(MAY).

한 가지가 덧붙습니다. 모든 재귀 서버와 권한 서버는 질의가 도착한 것과 같은 전송으로 응답을 보내야 합니다(MUST). TCP인 경우에는 같은 연결이어야 합니다(MUST).

관련 항목

DNS를 이루는 구성 요소

도메인 네임 스페이스 · 도메인 이름 · 라벨 · FQDN · 루트 라벨 · 리소스 레코드 · RRset · 마스터 파일 · 데이터베이스

권한을 존으로 나누고 옮기는 장치

존 · 존 컷 · 위임 · 권한 · glue 레코드 · 존 전송 · AXFR

해석에 관여하는 역할·참여자

리졸버 · 스터브 리졸버 · 재귀 리졸버 · 재귀 모드 · 반복 해석 · 네임서버 · 권한 서버 · 루트 네임서버 · 포워더

메시지에 싣는 필드·비트

QNAME · QTYPE · QCLASS · RCODE · OPCODE · NXDOMAIN · SERVFAIL · QR 비트 · AA 비트 · TC 비트 · RD 비트 · RA 비트 · Header 섹션 · Question 섹션 · Answer 섹션 · Authority 섹션 · Additional 섹션 · NS 레코드 · A 레코드 · CNAME

리졸버가 해석·캐시 과정에서 쓰는 값

SNAME · SLIST · 타임아웃 · 성능 · 지연 · TTL · 네거티브 캐싱

DNS 위에 얹히는 프로토콜

EDNS(0)(Extension Mechanisms for DNS, DNS의 확장 메커니즘) · DNSSEC(Domain Name System Security Extensions, DNS 보안 확장) · DoH(DNS Queries over HTTPS, HTTPS로 실어 보내는 DNS 질의) · DNS over TLS

DNS가 딛고 서는 전송 계층

UDP · TCP · 포트 53

DNS를 실제로 구현하거나 호출하는 프로그램

BIND · Unbound · systemd-resolved · getaddrinfo(3)

DNS를 정의하는 표준·문서

RFC 1034 · RFC 1035 · RFC 1123 · RFC 2181 · RFC 2182 · RFC 2308 · RFC 4033 · RFC 6891 · RFC 7766 · RFC 7858 · RFC 8484 · RFC 9499

다른 이름: Domain Name System · 도메인 네임 시스템

이 용어를 쓴 노트 7

AWS 01-1 서버를 통째로 빌린다 — EC2·Lightsail·Beanstalk·CloudShell AWS 03-1 관계형 DB를 맡긴다 — RDS·Aurora·Aurora DSQL AWS 04-1 내 망 안쪽 — VPC·NAT Gateway·PrivateLink·Transit Gateway·Network Firewall·VPC Lattice·Cloud Map AWS 04-2 밖에서 들어오는 길 — Route 53·CloudFront·Global Accelerator·ELB·API Gateway AWS 05-2 비밀·인증서·방어막 — KMS·Secrets Manager·ACM·Private CA·WAF·Shield AWS 07-1 큐와 알림 — SQS·SNS·SES·Amazon MQ AWS 08 빌드·배포 자동화 — ECR·CodeBuild·CodePipeline·CodeDeploy·CloudFormation·CDK