자원 레코드(resource record, RR)
- DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위해 자원 레코드를 저장한다.
- 각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답
자원 레코드의 구성
- 4개의 튜플(tuple)로 구성
→ {Name, Value, Type, TTL} TTL(time to live): 자원 레코드의 생존 기간- 자원이 캐시에서 제거되는 시간을 결정
Type의 종류
- Name과 Value의 의미는 Type에 따른다.
- 여기서의 서술은 TTL을 무시한 채 작성
- 여기서의 서술은 TTL을 무시한 채 작성
Type = A인 경우
- Type A 레코드는 표준 호스트 이름의 IP 이름의 IP 주소 매핑을 제공
Name: 호스트 이름Value: 호스트 이름에 대한 IP 주소- Type A 레코드 예시 → ( relay1.bar.foo.com, 145.37.93.126, A )
Type = NS인 경우
Name: 도메인(예 : foo.com)Value: 책임 DNS 서버의 호스트 이름- 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 알고 있음
- 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 알고 있음
- Type = NS 레코드 예시 → ( foo.com, dns.foo.com, NS )
Type = CNAME인 경우
- 질의 호스트에게 호스트 이름에 대한 정식 이름을 제공
- Name : 별칭 호스트 이름
- Value : Name에 대한 정식 호스트 이름
- Type=CNAME 예시 → ( foo.com, relay1.bar. foo.com, CNAME )
Type = MX인 경우
- Name : 별칭 호스트 이름
- Value : Name을 갖는 메일 서버의 정식 이름
- Type=MX 레코드 예시 → ( foo.com, mai1.bar.foo.com, MX)
- 해당 타입의 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용
- 한 메일 서버와 다른 서버들이 같은 별칭을 가질 수 있다.
- 한 메일 서버와 다른 서버들이 같은 별칭을 가질 수 있다.
- 메일 서버의 정식 이름을 얻는 방법
- 같은 서버에서 얻을 경우 → DNS 클라이언트가 MX 레코드에 대한 질의를 하는 것
- 다른 서버의 정식 이름을 얻기 위해 DNS 클라이언트는
CNAME 레코드에 대한 질의를 한다.
DNS 서버와 레코드 종류 관계
- 한 DNS 서버가 특별한 호스트 이름에 대한 책임 서버인 경우
- 그 DNS 서버는 그 호스트 이름에 대한
Type A 레코드를 포함한다. - 그 DNS 서버가 책임 서버가 아니더라도, 캐시에
Type A 레코드를 포함할 수 있다.
- 그 DNS 서버는 그 호스트 이름에 대한
- 서버가 호스트 이름에 대한 책임 서버가 아닌 경우
- 그 서버는 호스트 이름을 포함하는 도메인에 대한
Type NS 레코드를 포함 - 또한
Type A 레코드도 포함
→ NS 레코드의 Value 필드에 DNS 서버의 IP 주소를 제공하는 역할을 수행 - 예시 - 호스트 gaia.cs.umass.edu에 대한 책임 서버가 아닌 TLD 서버
- 해당 서버는 (umass.edu, dns.umass.edu, NS)를 포함한다.
- gagia.cs.umass.edu를 포함하는 도메인에 대한 레코드
- gagia.cs.umass.edu를 포함하는 도메인에 대한 레코드
- 또한 Type A 레코드도 포함 → 이는 DNS 서버 dns.umass.edu를 IP 주소로 매핑한다.
- 해당 서버는 (umass.edu, dns.umass.edu, NS)를 포함한다.
- 그 서버는 호스트 이름을 포함하는 도메인에 대한
DNS 메시지
- DNS의 유일한 2가지 메시지 유형 →
DNS 질의DNS 응답 메시지
DNS 메시지 포맷과 내부의 필드
- 요청과 응답 메시지는 모두 포맷을 가지고 있다.
헤더 영역(header section)
- 처음 12바이트는 헤더 영역으로, 여러 필드를 가지고 있다.
식별자- 첫 필드이자, 질의를 식별하는 16비트 숫자
- 질의에 대한 응답 메시지에 복사됨
→ 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별
플래그- 여러 개의 플래그가 존재
질의/응답 플래그(1비트): 메시지가 질의(0)인지 응답(1)인지 구별책임 플래그(1비트): DNS 서버가 질의 이름에 대해 책임 서버일 때의 응답 메시지 설정재귀 요구 플래그(1비트): 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정- DNS 서버가 레코드를 갖지 않을 때의 경우임
- 이때의 클라이언트 → 호스트 혹은 DNS 서버
재귀 가능 필드(1비트): DNS 서버가 재귀 질의를 지원하면 응답에 설정
- 여러 개의 플래그가 존재
- 4개의
개수 필드: 헤더 다음에 오는 데이터 영역의 4가지 타입에 발생 횟수를 의미질문 영역(question section): 현재 질의에 대한 정보를 포함- 포함하는 필드
- 이름 필드 : 질의되는 이름을 포함
- 타입 필드 : 이름에 대해 문의되는 질문 타입을 나타냄
- 이름과 연관된 호스트 주소(A 타입) or 이름에 대한 메일 서버(MX 타입)
- 이름과 연관된 호스트 주소(A 타입) or 이름에 대한 메일 서버(MX 타입)
- 포함하는 필드
답변 영역(answer section): 질의된 이름에 대한 자원 레코드를 포함- 각 자원 레코드에 Type을 지님
- 호스트 이름은 여러 개의 IP 주소를 가질 수 있다.
→ 응답으로 여러 개의 자원 레코드를 보낼 수 있다.- 예를 들어, 중복된 웹 서버 같은 경우
- 예를 들어, 중복된 웹 서버 같은 경우
책임 영역(authority section): 다른 책임 서버의 레코드를 포함추가 영역(additional section): 다른 도움이 되는 레코드를 포함- 메일 서버의 정식 호스트 이름에 대한 IP 주소를 제공하는 Type A 레코드 포함
- MX 질의에 대한 응답의 경우
- 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 가짐
DNS 데이터베이스에 레코드 삽입
- 처음에 어떻게 레코드를 데이터베이스에 넣는지에 대해 서술
과정
- 도메인 네임을 등록기관에 등록해야 함
등록기관(registrar)- 도메인 이름을 DNS 데이터베이스에 넣고, 요금을 받는 상업 기관
- 도메인 네임의 유일성을 확인해 줌
- 도메인 네임의 유일성을 확인해 줌
- 도메인 이름을 DNS 데이터베이스에 넣고, 요금을 받는 상업 기관
- 등록기관에게 주책임 서버와 부책임 서버의 이름과 IP 주소를 제공
- 두 책임 DNS 서버 각각에 대해 등록기관은
Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인- 주 책임 서버의 경우
→ 등록기관은 Type NS와 Type A 레코드를 DNS 시스템에 삽입
- 주 책임 서버의 경우
- 두 책임 DNS 서버 각각에 대해 등록기관은
- 웹 서버에 대한 Type A 자원 레코드와 메일 서버에 대한 Type MX 자원 레코드가
서버에 등록되는 것을 확인해야 함
DNS 서버의 취약점
DNS 공격의 유형
- DNS 서버에 대한
DDoS 대역폭 플러딩(flooding) 공격- 공격자는 다량의 패킷을 각 DNS 루트 서버로 보내려는 시도
→ 정상적인 많은 DNS 질의들이 응답을 받을 수 없게 됨 - DNS 최상위 도메인 서버들을 공격하면 더 효과적
- DNS 서버로 향하는 DNS 질의들을 필터링하기 더욱 어려움
- 최상위 도메인 서버들은 루트 서버처럼 우회하는 것이 어려움
- 공격자는 다량의 패킷을 각 DNS 루트 서버로 보내려는 시도
중간자 공격(main-in-the-middle attack)- 공격자는 호스트로부터의 질의를 가로채어 가짜 응답을 반환
DNS 중독(poisoning) 공격- 공격자는 DNS 서버로 가짜 응답을 보냄
→ 그 서버가 자신의 캐시에 가짜 레코드를 받아들이도록 속임수를 씀
- 공격자는 DNS 서버로 가짜 응답을 보냄
- 이러한 공격을 막아내기 위해 DNS 보안 확장 프로토콜이 개발되어 사용 중