0 / 4
이름 → IP 주소: A와 AAAA
사람은 google.com 같은 이름을 쓰지만, 컴퓨터끼리는 IP 주소로 통신한다. 그래서 접속하기 전에 DNS 서버에 그 이름의 IP 주소를 묻는다. 무엇을 물을지는 레코드 종류로 정한다. A(Address)는 IPv4 주소를, AAAA는 IPv6 주소를 알려 준다.
예: 같은 이름 google.com을 A로 한 번, AAAA로 한 번 묻는다. 값은 실제로 조회한 결과다.
1 / 4
내 PC → DNS 서버: A 레코드 묻기
내 PC가 google.com의 A 레코드를 묻는다. 이름에 연결된 IPv4 주소를 달라는 질문이다.
2 / 4
DNS 서버 → 내 PC: IPv4 주소
DNS 서버가 IPv4 주소 142.250.197.46을 답한다. 점으로 나눈 숫자가 4개이고, 숫자 하나가 8비트라서 모두 32비트다.
3 / 4
내 PC → DNS 서버: AAAA 레코드 묻기
같은 이름을 이번에는 AAAA로 묻는다. AAAA는 IPv6 주소를 알려 주는 레코드다.
4 / 4
DNS 서버 → 내 PC: IPv6 주소
DNS 서버가 IPv6 주소를 답한다. 콜론으로 나눈 16진수로 적고, 0만 이어지는 칸은 ::로 줄여 적는다. 길이는 128비트다. IPv4 주소보다 4배 길어서 A를 네 번 써 AAAA라고 부른다.
1 / 4
내 PC → DNS 서버: A 레코드 묻기
내 PC가 www.github.com의 IPv4 주소를 알아내려고 A 레코드를 묻는다.
2 / 4
DNS 서버: 별명인지 확인하기
DNS 서버가 www.github.com을 찾아보니 A 레코드는 없고 CNAME 레코드가 있다. “이 이름은 별명이고 정식 이름은 github.com”이라는 뜻이다.
3 / 4
DNS 서버: 정식 이름으로 한 번 더 찾기
별명만으로는 IP 주소를 알 수 없다. 그래서 DNS 서버가 정식 이름 github.com의 A 레코드를 한 번 더 찾아 20.200.245.247을 알아낸다.
4 / 4
DNS 서버 → 내 PC: 두 줄을 함께 답하기
DNS 서버가 별명 줄과 주소 줄을 함께 돌려준다. 내 PC는 20.200.245.247로 접속한다. A는 IP 주소를 바로 답하고, CNAME은 다른 이름을 답해서 한 번 더 찾게 만든다.
1 / 4
내 PC → DNS 서버: PTR 레코드 묻기
DNS에는 늘 이름으로 묻는다. 그래서 IP 주소 8.8.4.4의 숫자를 거꾸로 적고, 끝에 역방향 조회 전용 이름인 in-addr.arpa를 붙여 묻는다. 도메인 이름은 오른쪽 끝(.com)이 가장 큰 범위인데, IP 주소는 왼쪽 끝이 가장 큰 범위다. 그래서 숫자를 거꾸로 적어 순서를 맞춘다.
2 / 4
DNS 서버 → 내 PC: 이름
DNS 서버가 8.8.4.4의 이름은 dns.google이라고 답한다.
3 / 4
내 PC → DNS 서버: 반대 방향으로 A 묻기
이번에는 받은 이름 dns.google의 A 레코드를 묻는다. PTR과 반대 방향이다.
4 / 4
DNS 서버 → 내 PC: IP 주소
dns.google의 IPv4 주소로 8.8.8.8과 8.8.4.4가 나온다. 처음 물은 IP가 들어 있어서 두 방향이 맞아떨어진다. 메일 서버는 이런 식으로 상대 IP를 양쪽에서 확인하기도 한다.
1 / 4
보내는 메일 서버 → DNS 서버: MX 레코드 묻기
보내는 메일 서버가 받는 사람 주소에서 @ 뒤의 naver.com을 떼어 MX 레코드를 묻는다.
2 / 4
DNS 서버 → 보내는 메일 서버: 메일 서버 이름
DNS 서버가 메일 서버 이름 mx6.mail.naver.com을 답한다. 앞의 20은 우선순위로, 숫자가 작을수록 먼저 쓴다. 실제 답에는 mx4·mx5도 우선순위 20으로 함께 나와서, 셋 중 어느 곳으로 보내도 된다.
3 / 4
보내는 메일 서버 → DNS 서버: A 레코드 묻기
MX의 답은 IP 주소가 아니라 서버 이름이다. 그래서 그 이름의 IP 주소를 A 레코드로 한 번 더 묻는다.
4 / 4
DNS 서버 → 보내는 메일 서버: IP 주소
IP 주소 202.131.24.29가 나온다. 보내는 메일 서버가 이 주소로 메일을 전달한다.
1 / 4
받는 메일 서버 → DNS 서버: TXT 레코드 묻기
받는 메일 서버가 보낸 사람 주소의 도메인 naver.com으로 TXT 레코드를 묻는다.
2 / 4
DNS 서버 → 받는 메일 서버: SPF 목록
답 가운데 v=spf1로 시작하는 줄이 SPF다. 그 안의 ip4: 뒤가 메일을 보내도 되는 IP 범위다. 예를 들어 111.91.135.0/27은 앞 27비트가 같은 IP들로, 111.91.135.0부터 111.91.135.31까지 32개다. 실제 목록에는 이런 범위가 8개 있다.
3 / 4
받는 메일 서버: 첫 번째 메일 확인
첫 번째 메일은 111.91.135.10에서 왔다. 목록의 111.91.135.0~31 범위 안이라 SPF 확인을 통과한다.
4 / 4
받는 메일 서버: 두 번째 메일 확인
두 번째 메일은 203.0.113.50에서 왔다. 목록 어디에도 없으니 naver.com을 사칭한 메일로 의심한다. 목록 끝의 ~all은 naver.com이 “목록 밖이면 의심하라(soft fail)”고 정해 둔 표시다. 그래서 받는 쪽은 메일을 받되 의심 표시를 하거나 스팸함으로 보낸다. 끝이 -all이면 거부해도 된다는 뜻이다.
1 / 5
내 PC → DNS 서버: NS 레코드 묻기
내 PC가 naver.com의 NS 레코드를 묻는다.
2 / 5
DNS 서버 → 내 PC: 네임서버 목록
naver.com을 맡은 네임서버로 ns1·ns2·ns3이 나온다. 한 대가 멈춰도 답할 수 있도록 여러 대를 둔다.
3 / 5
내 PC → DNS 서버: SOA 레코드 묻기
이번에는 naver.com 영역의 대표 정보를 SOA 레코드로 묻는다.
4 / 5
DNS 서버 → 내 PC: 영역 대표 정보
SOA 답에는 값 7개가 순서대로 들어 있다. 맨 앞은 원본을 가진 주 네임서버다. 다음은 관리자 메일이다. 레코드에서는 메일 주소도 도메인 이름처럼 적어서 @ 자리에 점이 들어간다. 그래서 webmaster.naver.com의 첫 점을 @로 바꿔 webmaster@naver.com으로 읽는다. 일련번호는 레코드를 고칠 때마다 올리는 번호로, 흔히 날짜 뒤에 그날 고친 순번을 붙인다.
5 / 5
SOA: 시간 값 네 개
보조 네임서버는 주 네임서버의 원본을 복사해 두고 답한다. 갱신 주기(6시간)마다 일련번호를 확인해, 번호가 올라갔으면 원본을 새로 복사한다. 확인에 실패하면 재시도 간격(30분)마다 다시 해 본다. 만료 시간(14일)이 지나도록 실패하면 복사본으로 더는 답하지 않는다. 최소 TTL(Time To Live, 3분)은 “그런 이름이나 레코드는 없다”는 답을 다른 DNS 서버가 기억해 두는 최대 시간이다.