일곱 번째 발걸음이름을 주소로, 다음 홉을 이웃으로 찾는다

사람은 문서 서비스의 이름을 기억하지만 IP는 숫자 주소를 사용합니다. 또 IP 경로가 다음 라우터를 정해도 이더넷 프레임은 그 라우터의 MAC 주소를 알아야 합니다. 서로 다른 두 빈칸을 채우는 기능이 DNS와 ARP입니다. DNS는 도메인 이름에 연결된 주소 등의 정보를 찾고, ARP는 IPv4의 같은 링크에서 다음 전달 대상의 IP와 MAC 관계를 알아냅니다. 두 기능을 “주소를 바꾸는 것”이라고만 외우면 범위를 혼동하기 쉽습니다.

DNS는 하나의 거대한 전화번호부 파일을 모두가 복사해 쓰는 방식이 아닙니다. 이름 공간을 계층적으로 나누고 각 영역의 권한 있는 서버가 해당 정보를 제공합니다. 단말은 보통 설정된 재귀 리졸버에 조회를 부탁합니다. 리졸버는 캐시에 유효한 답이 있으면 이용하고, 필요하면 계층의 안내를 따라 권한 있는 서버를 찾아 답을 얻습니다. 재귀는 질문한 쪽을 대신해 최종 결과를 구하는 역할이고, 반복적 조회는 다음에 물을 서버의 안내를 따라가는 과정으로 이해하면 됩니다.

주소를 묻는 대표 레코드는 IPv4의 A와 IPv6의 AAAA입니다. CNAME은 다른 정규 이름을 가리키는 별칭 관계를 나타내고, MX는 메일을 받을 서버 정보, NS는 영역의 이름 서버 정보를 나타냅니다. 종류가 다르면 같은 이름에 대한 질문도 답의 의미가 다릅니다. DNS 메시지에는 질의 이름과 유형, 거래를 구분하는 ID, 응답 코드와 여러 레코드가 담깁니다. 캐시의 TTL은 정보를 얼마나 재사용할지와 관계되며, IP 헤더의 홉 수명 제한인 TTL과 같은 기능은 아닙니다.

주소가 바뀌어도 캐시에 이전 답이 남아 있을 수 있습니다. 그래서 서버 설정을 바꾼 직후 모든 사용자가 동시에 새 주소를 보는 것은 아닙니다. DNS 조회 성공은 그 주소의 서버가 정상 업무를 제공하거나 믿을 만하다는 증거도 아닙니다. 위조된 응답을 받아들이면 다른 주소로 유도될 수 있으므로 응답과 질문의 ID·주소·포트·이름 등의 대응을 확인하는 처리가 필요합니다. DNSSEC 같은 검증과 서버 운영 설정은 방향5에서 다루며, 실제 서버의 신원을 확인하는 TLS의 원리는 방향4로 이어집니다.

이번에는 앞 절의 198.51.100.0/24 별도 경로가 없는 새 사례를 보겠습니다. DNS가 198.51.100.20을 알려 주었고 노트북은 10.20.0.10/24입니다. 목적지가 같은 링크에 없고 더 구체적인 경로도 없으므로 다음 홉은 기본 라우터 10.20.0.1입니다. ARP는 원격 서버의 MAC을 인터넷 전체에서 찾지 않습니다. 자기 링크에 “10.20.0.1을 가진 이웃은 누구인가”를 묻고, 답으로 받은 MAC을 이웃 정보에 저장합니다. 그 결과 프레임의 목적 MAC은 라우터, IP 패킷의 목적 주소는 원격 서버가 됩니다. 다음 라우터에서는 또 그 링크에 필요한 전달 정보를 사용합니다.

ARP의 기본 교환은 답한 이웃의 진짜 신원을 강하게 인증하는 방식이 아닙니다. IP와 MAC의 거짓 관계를 믿게 하면 트래픽이 다른 곳으로 향하거나 통신이 끊길 수 있습니다. 중간자 공격이 성립하려면 트래픽 경유와 전달 등 추가 조건도 필요하므로 ARP 값 하나가 바뀌었다고 모든 내용을 이미 도청당했다고 단정하지 않습니다. 이웃 관계의 통제와 상위 계층 암호화·서버 인증을 함께 두는 이유는 각기 다른 빈틈을 막기 위해서입니다.

참고　[66] · [83] · [84] · [85] · [86]