DNS 확장 메커니즘

Extension Mechanisms for DNS
"EDNS"는 여기서 리디렉션된다.대체 루트 시스템에 대해서는 eDNS(대체 DNS 루트)를 참조하십시오.

DNS를 위한 확장 메커니즘(EDNS)은 인터넷 엔지니어링 커뮤니티가 프로토콜의 기능성을 증가시키기 위해 너무 제한적이라고 간주하는 크기 제한이 있는 DNS(Domain Name System) 프로토콜의 여러 매개변수의 크기를 확장하기 위한 규격이다.최초의 연장은 1999년에 인터넷 엔지니어링 태스크포스에 의해 출판되었다. RFC2671, 2013년 RFC6891에 의해 업데이트된 EDNS0이라고도[1] 하며 약어를 EDNS(0)로 약간 변경하였다.[2]

동기

도메인 네임 시스템은 1980년대 초에 처음 개발되었다.그 이후, 프로토콜의 이전 버전과의 호환성을 유지하면서 새로운 기능으로 점진적으로 향상되었다.

기본 DNS 프로토콜에서 사용할 수 있는 여러 플래그 필드, 반환 코드 및 라벨 유형의 제한으로 인해 일부 바람직한 기능이 지원되지 않았다.더욱이 UDP가 전달하는 DNS 메시지는 인터넷 프로토콜(IP)과 전송 계층 헤더를 고려하지 않고 512바이트로 제한되었다.[3]TCP(Transmission Control Protocol)를 사용하여 가상 회로 전송에 의존하면 오버헤드가 크게 증가한다.이는 DNS에 새로운 기능을 추가하는 데 큰 걸림돌이 되었다.1999년 폴 빅시는 새로운 플래그와 응답 코드를 허용하고, 이전 구현과 역호환되는 프레임워크에서 더 긴 응답에 대한 지원을 제공하기 위해 DNS를 확장할 것을 제안했다.

메커니즘

DNS 헤더에 새로운 플래그를 추가할 수 없으므로, EDNS는 DNS 메시지의 "추가 데이터" 섹션에 포함된 유사 리소스 레코드("pseudo-RR")의 형태로 DNS 메시지에 정보를 추가한다.이 섹션은 요청과 응답 모두에 존재한다는 점에 유의하십시오.

EDNS는 다음과 같은 단일 의사-RR 유형을 도입한다.OPT.

유사 RR로서 OPT 타입 RR은 어떤 구역 파일에도 나타나지 않으며 DNS 참가자에 의해 조작된 메시지만 존재한다.

이 메커니즘은 이전 DNS 응답자가 요청에서 알 수 없는 OPT 유형의 RR을 무시하고 새로운 DNS 응답자는 요청에 OPT가 없는 한 응답에 OPT를 포함하지 않기 때문에 역호환성이 있다.요청에 OPT가 있다는 것은 응답에서 OPT를 어떻게 해야 할지를 아는 새로운 요청자를 의미한다.

OPT 사이비 레코드는 최대 16개의 플래그를 저장할 수 있는 공간을 제공하며 응답 코드 공간을 확장한다.UDP 패킷의 전체 크기와 버전 번호(현재 0)는 OPT 레코드에 포함되어 있다.가변 길이 데이터 필드는 향후 버전의 프로토콜에서 추가 정보를 등록할 수 있다.원래 DNS 프로토콜은 DNS 패킷(RFC 1035)의 처음 두 비트로 정의되는 두 가지 라벨 유형을 제공했다: 00(표준 라벨)과 11(압축 라벨).EDNS는 확장 라벨로서 라벨 타입 01을 도입한다.첫 번째 바이트의 하위 6비트를 사용하여 최대 63개의 새로운 확장 라벨을 정의할 수 있다.

예

dig 명령에 의해 표시되는 OPT 유사 레코드의 예:

;;;; OPT PHYOSECTION: ; EDNS: 버전: 0, 플래그: do; udp: 4096

"EDNS: 버전: 0"의 결과는 EDNS0의 완전한 준수를 나타낸다.[4]"플래그: do" 결과는 "DNSSEC OK"가 설정되었음을 나타낸다.[5]

적용들

EDNS는 DNSSEC(DNS Security Extensions)의 구현에 필수적이다.[6]EDNS는 또한 ECS(EndNS Client Subnet) 옵션의 형태로 클라이언트의 지리적 위치에 대한 일반 정보를 확인자에서 이름 서버로 보내는 데도 사용된다.[7]

EDNS를 사용하여 DNS 메시지[8] 주변에 얼마나 많은 패딩이 있어야 하는지, TCP 연결이 얼마나 오래 유지되어야 하는지 표시하기 위한 제안이 있다.[9]

문제들

실제로 일부 방화벽은 최대 DNS 메시지 길이를 512바이트로 가정하고 더 긴 DNS 패킷을 차단하기 때문에 EDNS를 통과하는 방화벽을 사용할 때 어려움이 발생할 수 있다.

EDNS가 비교적 작은 요청 패킷에 비해 매우 큰 응답 패킷을 촉진하기 때문에 EDNS의 도입으로 반사된 서비스 거부 공격의 일종인 DNS 증폭 공격이 실현되었다.

IETF DNS Extensions 워킹 그룹(dnsxt)은 RFC 6891로 발행된 EDNS0의 정교화에 관한 작업을 마쳤다.

참조

  1. ^ RFC 2671, DNS를 위한 확장 메커니즘 (EDNS0), P. Vixie, The Internet Society (1999년 8월)
  2. ^ RFC 6891, DNS를 위한 확장 메커니즘 (EDNS(0), J. 다마스, M. 그래프, P. 빅시, (2013년 4월)
  3. ^ RFC 1035, 도메인 이름 - 구현 및 사양, P. Mokapetris (1987년 11월)
  4. ^ IETF의 네트워크 작업 그룹, 1999년 8월, RFC 2671: DNS를 위한 확장 메커니즘(EDNS0), 3페이지, 이 규격의 완전한 준수는 버전 "0"으로 표시된다.
  5. ^ IETF의 네트워크 작업 그룹, 2001년 12월, RFC 3225: DNSSEC의 해결사 지원 표시, 3페이지, DNSSEC 보안 RR이 클라이언트의 수용(이해할 수 없는 경우) 능력을 명시적으로 통지하기 위해 선택한 메커니즘은 쿼리의 EDNS0 OPT 헤더에 있는 Z 필드의 가장 중요한 비트를 사용하고 있다.이 비트를 "DNSSEC OK"(DO) 비트라고 한다.
  6. ^ RFC 4035, DNS 보안 확장에 대한 프로토콜 수정, R.2005년 텔레매틱사 연구소 아렌즈.섹션 4.1 EDNS 지원
  7. ^ Contavalli, Carlo. "RFC 7871: Client Subnet in DNS Queries". tools.ietf.org. Retrieved 2018-02-02.
  8. ^ Mayrhofer, Alexander. "RFC 7830: The EDNS(0) Padding Option". tools.ietf.org. Retrieved 2018-02-02.
  9. ^ Wouters, Paul. "RFC 7828: The edns-tcp-keepalive EDNS0 Option". tools.ietf.org. Retrieved 2018-02-02.

참고 항목