Page semi-protected

도메인 네임 시스템

Domain Name System
"DNS"는 여기로 리디렉션됩니다.기타 용도는 DNS(동음이의)를 참조하십시오.
인터넷 프로토콜 모음
응용 계층
수송층
인터넷 계층
링크 계층

DNS(Domain Name System)는 인터넷 또는 기타 IP(Internet Protocol) 네트워크의 컴퓨터, 서비스 및 기타 리소스에 대한 계층적이고 분산된 이름 지정 시스템입니다.연결된 각 엔티티에 할당된 도메인 이름(식별 문자열)과 다양한 정보를 연결합니다.가장 눈에 띄는 것은 쉽게 기억되는 도메인 이름을 기본 네트워크 프로토콜을 사용하여 컴퓨터 서비스 및 장치를 찾고 식별하는 데 필요한 수치 IP 주소로 변환하는 것입니다.[1]도메인 네임 시스템은 1985년부터 인터넷 기능의 필수 요소였습니다.

도메인 이름 시스템은 각 도메인에 대해 권한 있는 이름 서버를 지정하여 도메인 이름을 할당하고 해당 이름을 인터넷 리소스에 매핑할 책임을 위임합니다.네트워크 관리자는 할당된 네임스페이스의 하위 도메인에 대한 권한을 다른 네임서버에 위임할 수 있습니다.이 메커니즘은 분산 및 내결함성 서비스를 제공하며 단일 대규모 중앙 데이터베이스를 피하도록 설계되었습니다.또한 DNS는 핵심인 데이터베이스 서비스의 기술적 기능을 지정합니다.DNS에 사용되는 데이터 구조 및 데이터 통신 교환의 세부 사양인 DNS 프로토콜을 인터넷 프로토콜 제품군의 일부로 정의합니다.

인터넷은 도메인 이름 계층과 IP 주소 공간, 두 개의 주요 이름 공간을 유지합니다.[2]도메인 이름 시스템은 도메인 이름 계층 구조를 유지하고 도메인 이름 계층과 주소 공간 사이에 번역 서비스를 제공합니다.인터넷 네임 서버와 통신 프로토콜은 도메인 네임 시스템을 구현합니다.DNS 네임 서버는 도메인에 대한 DNS 레코드를 저장하는 서버이며, DNS 네임 서버는 데이터베이스에 대한 쿼리에 대한 응답으로 응답합니다.

DNS 데이터베이스에 저장되는 가장 일반적인 레코드 유형은 SOA(Start of Authority), IP 주소(A 및 AAA), SMTP 메일 교환기(MX), 이름 서버(NS), 역 DNS 조회 포인터(PTR) 및 도메인 이름 별칭(CNAME)입니다.범용 데이터베이스로 의도되지는 않았지만 DNSSEC 레코드와 같은 자동 조회 또는 RP(Responsible Person) 레코드와 같은 인간 쿼리를 위해 다른 유형의 데이터에 대한 레코드를 저장하기 위해 시간이 지남에 따라 DNS가 확장되었습니다.일반 목적 데이터베이스로서 DNS는 실시간 블랙홀 목록(RBL)을 저장함으로써 요청하지 않은 전자 메일(스팸)을 방지하는 데에도 사용되어 왔습니다.DNS 데이터베이스는 일반적으로 구조화된 텍스트 파일인 존 파일에 저장되지만 다른 데이터베이스 시스템은 일반적입니다.

도메인 네임 시스템은 원래 UDP(User Datagram Protocol)를 IP를 통한 전송으로 사용했습니다.신뢰성, 보안 및 개인 정보 보호 문제로 인해 TCP(Transmission Control Protocol)를 사용하는 것은 물론 기타 수많은 프로토콜 개발이 이루어졌습니다.

기능.

DNS를 설명하기 위해 자주 사용되는 비유는 DNS가 인간 친화적인 컴퓨터 호스트 이름을 IP 주소로 변환함으로써 인터넷의 전화번호부 역할을 한다는 것입니다.예를 들어, 호스트 이름은www.example.com도메인 이름 example.com 내에서는 주소 93.184.216.34(IPv4) 및 2606:2800:220:1:248:1893:25c8:1946(IPv6)로 변환됩니다.DNS를 신속하고 투명하게 업데이트하여 동일한 호스트 이름을 계속 사용하는 최종 사용자에게 영향을 주지 않고 네트워크 상의 서비스 위치를 변경할 수 있습니다.사용자는 컴퓨터가 실제로 서비스를 찾는 방법을 알 필요 없이 의미 있는 URL(Uniform Resource Locators) 및 전자 메일 주소를 사용할 때 이러한 이점을 이용합니다.

DNS의 중요한 유비쿼터스 기능은 클라우드 서비스 및 콘텐츠 전송 네트워크와 같은 분산 인터넷 서비스에서 핵심적인 역할입니다.[3]사용자가 URL을 사용하여 분산 인터넷 서비스에 접속하면 URL의 도메인 이름이 사용자와 근접한 서버의 IP 주소로 변환됩니다.여기서 활용되는 DNS의 주요 기능은 DNS의 기존 전화번호부 보기와 다른 주요 지점인 동일한 도메인 이름에 대해 다른 번역을 동시에 받을 수 있다는 것입니다.DNS를 사용하여 사용자에게 근위 서버를 할당하는 이 과정은 인터넷에서 더 빠르고 신뢰할 수 있는 응답을 제공하는 핵심이며 대부분의 주요 인터넷 서비스에서 널리 사용되고 있습니다.[4]

DNS는 인터넷 상의 행정적 책임의 구조를 반영합니다.[5]각 하위 도메인은 관리자에게 위임된 관리자 권한 영역입니다.레지스트리에 의해 운영되는 영역의 경우, 레지스트리의 RDAP 및 WHOIS 서비스를 통해 관리 정보가 보완되는 경우가 많습니다.이 데이터는 인터넷 상의 특정 호스트에 대한 통찰력을 얻고 책임을 추적하는 데 사용될 수 있습니다.[6]

역사

호스트의 숫자 주소 대신 더 간단하고 기억에 남는 이름을 사용하는 것은 ARPANET 시대로 거슬러 올라갑니다.Stanford Research Institute (현재 SRI International)는 HOSTS라는 이름의 텍스트 파일을 유지했습니다.호스트 이름을 ARPANET에 있는 컴퓨터의 숫자 주소에 매핑한 TXT.[7][8]Elizabeth Feinler는 최초의 ARPANET 디렉토리를 개발하고 유지 관리했습니다.[9][10]할당된 번호 목록이라고 불리는 숫자 주소의 유지 관리는 SRI와 긴밀하게 협력한 서던캘리포니아 대학교 정보 과학 연구소(ISI)의 Jon Postel이 담당했습니다.[11]

주소는 수동으로 할당했습니다.호스트 이름과 주소를 포함한 컴퓨터는 업무 시간 동안 전화를 통해 Feinler가 지휘하는 SRI Network Information Center(NIC)에 연락하여 기본 파일에 추가되었습니다.[12]나중에 파인러는 리소스, 연락처 및 엔티티에 대한 정보를 검색하기 위해 NIC의 서버에 WHOIS 디렉토리를 설정했습니다.[13]그녀와 그녀의 팀은 도메인의 개념을 개발했습니다.[13]파인러는 도메인이 컴퓨터의 물리적 주소 위치를 기준으로 해야 한다고 제안했습니다.[14]예를 들어, 교육 기관의 컴퓨터는 도메인 에듀를 가지고 있을 것입니다.[15]그녀와 그녀의 팀은 1972년부터 1989년까지 호스트 네이밍 레지스트리를 관리했습니다.[16]

1980년대 초에는 중앙 집중식 단일 호스트 테이블을 유지하는 것이 느리고 통제하기 어려워졌고, 새롭게 등장한 네트워크는 기술 및 인력 문제를 해결하기 위해 자동화된 명명 시스템을 필요로 했습니다.포스텔은 폴 모카페트리스에 대한 5개의 경쟁적인 해결책 제안 사이에 타협안을 만드는 작업을 지휘했습니다.모카페트리스는 1983년 서던캘리포니아 대학교에서 도메인 네임 시스템을 만들었습니다.[12][17]

인터넷 엔지니어링 태스크 포스는 1983년 11월에 RFC 882와 RFC 883의 원래 사양을 발표했습니다.[18][19]이것들은 1986년 1월 RFC 973에서 업데이트 되었습니다.

1984년, UC 버클리의 4명의 학생인 Douglas Terry, Mark Painter, David Riggle, Songnian Zhou는 흔히 BIND라고 불리는 버클리 인터넷 이름 도메인을 위한 최초의 유닉스 이름 서버 구현을 작성했습니다.[20]1985년 DEC의 Kevin Dunlap은 DNS 구현을 상당히 수정했습니다.이후 마이크 카렐스, 필 알퀴스트, 폴 빅스가 BIND 유지보수를 맡았습니다.인터넷 시스템 컨소시엄은 1994년 Rick Adams, Paul Vixie 및 Carl Malamud에 의해 설립되었으며 BIND 개발 및 유지보수를 위한 보금자리를 제공하기 위해 특별히 설립되었습니다.4.9.3 이후의 BIND 버전은 ISC에 의해 개발되고 유지 관리되었으며 ISC의 후원자들이 지원했습니다.공동 설계자/프로그래머로서 밥 핼리와 폴 빅시는 1997년 5월 BIND 버전 8의 첫 번째 생산 준비 버전을 출시했습니다.2000년 이후 43개 이상의 다른 핵심 개발자들이 BIND를 작업해 왔습니다.[21]

1987년 11월, RFC 1034와[22] RFC 1035는[5] 1983년 DNS 규격을 대체하였습니다.주석 요청에 대한 추가 요청은 핵심 DNS 프로토콜에 대한 확장을 제안했습니다.[23]

구조

도메인 네임스페이스

도메인 이름 공간은 트리 데이터 구조로 구성됩니다.트리의 각 노드 또는 리프에는 도메인 이름과 관련된 정보를 보유하는 레이블과 0 이상의 RR(Resource Records)가 있습니다.도메인 이름 자체는 레이블로 구성되며 오른쪽의 상위 노드 이름과 연결되고 점으로 구분됩니다.[24]

트리는 루트 영역에서 시작하는 영역으로 세분화됩니다.DNS 영역은 영역 관리자가 선택한 수만큼의 도메인과 하위 도메인으로 구성될 수 있습니다.DNS는 별도의 클래스를 병렬 네임스페이스 트리의 배열로 간주할 수 있는 클래스에 따라 분할할 수도 있습니다.[25]

클래스 인터넷을 위한 계층적 도메인 이름 시스템으로, 영역으로 구성되며, 각 영역은 이름 서버에 의해 제공됩니다.

구역별 관리책임은 구역을 추가로 만들어 구분할 수 있습니다.새 구역에 대한 권한은 지정된 네임 서버에 위임된다고 합니다.상위 영역이 새 영역에 대한 권한을 중단합니다.[25]

도메인 이름 구문, 국제화

도메인 이름 형성 규칙에 대한 최종 설명은 RFC 1035, RFC 1123, RFC 2181 및 RFC 5892에 나와 있습니다.도메인 이름은 일반적으로 연결되고 example.com 과 같이 점으로 구분되는 레이블이라고 하는 하나 이상의 부분으로 구성됩니다.

맨 오른쪽 레이블은 최상위 도메인을 전달합니다. 예를 들어 도메인 이름 www.example.com 은 최상위 도메인 com에 속합니다.

도메인 계층은 오른쪽에서 왼쪽으로 내려갑니다. 왼쪽의 각 레이블은 오른쪽 도메인의 하위 영역 또는 하위 도메인을 지정합니다.예를 들어 레이블 예제는 com 도메인의 하위 도메인을 지정하고 www는 example.com 의 하위 도메인입니다.이 세분류 트리는 최대 127개의 레벨을 가질 수 있습니다.[26]

레이블에는 0~63자의 문자가 포함될 수 있습니다.길이가 0인 null 레이블은 루트 영역에 대해 예약됩니다.전체 도메인 이름은 텍스트 표현의 길이 253자를 초과할 수 없습니다.[22]DNS의 내부 이진 표현에서 최대 길이는 이름의 길이도 저장하므로 255 옥텟의 저장이 필요합니다.[5]

옥텟으로 표현할 수 있는 문자를 사용하는 도메인 이름 레이블을 방지하기 위한 기술적 제한은 없지만 호스트 이름은 기본 형식과 문자 집합을 사용합니다.레이블에 허용되는 문자는 ASCII 문자 집합의 하위 집합으로 a ~ z, A ~ Z, 0 ~ 9의 숫자 및 하이픈으로 구성됩니다.이 규칙을 LDH 규칙(글자, 숫자, 하이픈)이라고 합니다.도메인 이름은 대소문자 구분 없이 해석됩니다.[27]레이블은 하이픈으로 시작하거나 끝날 수 없습니다.[28]추가 규칙을 사용하려면 최상위 도메인 이름이 모두 숫자여야 합니다.[28]

DNS에 허용된 ASCII 문자의 제한된 집합으로 인해 네이티브 알파벳이나 스크립트에서 많은 언어의 이름과 단어를 표현할 수 없습니다.이를 가능하게 하기 위해 ICANN은 웹 브라우저와 같은 사용자 응용 프로그램이 유니코드 문자열을 퍼니코드를 사용하여 유효한 DNS 문자 집합에 매핑하는 IDNA(Internationalizing Domain Names in Applications) 시스템을 승인했습니다.2009년 ICANN은 국제화된 도메인 이름 국가 코드 최상위 도메인(ccTLDs)의 설치를 승인했습니다.또한 기존 최상위 도메인 이름(TLD)의 많은 레지스트리는 RFC 5890, RFC 5891, RFC 5892, RFC 5893에 의해 안내되는 IDNA 시스템을 채택했습니다.

서버명

도메인 이름 시스템은 클라이언트-서버 모델을 사용하는 분산 데이터베이스 시스템에 의해 유지 관리됩니다.이 데이터베이스의 노드는 이름 서버입니다.각 도메인에는 해당 도메인과 하위 도메인의 네임 서버에 대한 정보를 게시하는 권한 있는 DNS 서버가 하나 이상 있습니다.계층 맨 위에는 루트 네임 서버, 즉 TLD를 조회(해결)할 때 조회할 서버가 있습니다.

권한있는 네임 서버

권한 있는 네임 서버는 원래 소스(예: 도메인 관리자) 또는 동적 DNS 방식으로 구성된 데이터의 DNS 쿼리에 대한 응답만 제공하는 네임 서버로, 데이터 캐시만 유지하는 다른 네임 서버에 대한 쿼리를 통해 얻은 응답과는 다릅니다.

권한 있는 네임 서버는 주 서버 또는 보조 서버일 수 있습니다.역사적으로 마스터/슬레이브 및 프라이머리/세컨더리라는 용어는 때때로 혼용되었지만[29] 현재 관행은 후자의 형태를 사용하는 것입니다.주 서버는 모든 영역 레코드의 원본을 저장하는 서버입니다.보조 서버는 기본 레코드의 동일한 복사본을 유지하기 위해 기본 서버와 통신하는 DNS 프로토콜의 특별한 자동 업데이트 메커니즘을 사용합니다.

모든 DNS 영역에는 권한 있는 네임 서버 집합이 할당되어야 합니다.이 서버 집합은 NS(Name Server) 레코드와 함께 상위 도메인 영역에 저장됩니다.

권한 있는 서버는 응답에 "권한 있는 응답"(AA) 비트라고 하는 프로토콜 플래그를 설정하여 권한 있는 것으로 간주되는 최종 응답을 제공하는 상태를 나타냅니다.[5]이 플래그는 일반적으로 dig와 같은 DNS 관리 쿼리 도구의 출력에서 두드러지게 재생되어 응답 이름 서버가 문제의 도메인 이름에 대한 권한임을 나타냅니다.[5]

네임 서버가 권한 있는 데이터가 없는 도메인 이름의 권한 있는 서버로 지정되면 "lame destration" 또는 "lame response"라는 오류 유형이 나타납니다.[30][31]

작동

주소 해결 메커니즘

도메인 이름 확인기는 맨 오른쪽(상위) 도메인 레이블로 시작하는 일련의 쿼리에 따라 해당 도메인 이름을 담당하는 도메인 이름 서버를 결정합니다.

RFC 1034에서 요구하는 반복 접근 방식을 구현하는 DNS 확인기입니다. 이 경우 확인기는 완전한 도메인 이름 "www.wikipedia.org "을 확인하기 위해 세 개의 네임 서버와 상의합니다.

도메인 이름 확인기의 적절한 작동을 위해 네트워크 호스트는 루트 이름 서버의 알려진 주소의 초기 캐시(힌트)로 구성됩니다.관리자는 신뢰할 수 있는 소스에서 데이터셋을 검색하여 힌트를 주기적으로 업데이트합니다.

해결사에 프로세스를 가속화할 캐시된 레코드가 없다고 가정하면 해결 프로세스는 루트 서버 중 하나에 대한 쿼리로 시작됩니다.일반적인 작업에서 루트 서버는 직접 응답하지 않고 보다 권한 있는 서버에 대한 참조로 응답합니다. 예를 들어 "www.wikipedia.org "에 대한 쿼리는 org 서버를 참조합니다.이제 해결사는 참조된 서버를 쿼리하고, 권한 있는 답변을 받을 때까지 이 과정을 반복합니다.이 다이어그램은 정규화된 도메인 이름 "www.wikipedia.org "으로 명명된 호스트에 대한 이 프로세스를 보여 줍니다.

이 메커니즘은 인터넷의 모든 해결책이 루트에서 시작되어야 할 경우 루트 서버에 큰 트래픽 부담을 줄 것입니다.실제로 DNS 서버에서 루트 서버를 오프로드하기 위해 캐싱을 사용하기 때문에 루트 네임 서버는 실제로 모든 요청 중 비교적 적은 부분만 관련됩니다.

재귀적 및 캐싱 네임 서버

이론적으로 인터넷의 운영을 위해서는 권위 있는 네임 서버가 충분합니다.그러나 권한 있는 네임 서버만 작동하므로 모든 DNS 쿼리는 도메인 네임 시스템의 루트 존에서 재귀적 쿼리로 시작해야 하며 각 사용자 시스템은 재귀적 작동이 가능한 레졸버 소프트웨어를 구현해야 합니다.[32]

도메인 네임 시스템은 효율성을 개선하고, 인터넷 전체의 DNS 트래픽을 줄이고, 최종 사용자 애플리케이션의 성능을 향상시키기 위해 DNS 캐시 서버를 지원하며, DNS 쿼리 결과를 해당 도메인 네임 레코드의 구성(라이브 타임)에서 결정된 기간 동안 저장합니다.일반적으로 이러한 캐싱 DNS 서버는 DNS 루트로 시작하여 쿼리된 도메인의 권한 있는 이름 서버로 지정된 이름을 해결하는 데 필요한 재귀적 알고리즘도 구현합니다.이 기능을 네임 서버에 구현하면, 사용자 애플리케이션은 설계와 운영에서 효율성을 얻을 수 있습니다.

네임 서버에서 DNS 캐싱과 재귀적 기능의 조합은 필수 사항은 아니며, 특수한 목적을 위해 서버에서 독립적으로 기능을 구현할 수 있습니다.

인터넷 서비스 제공업체는 일반적으로 고객을 위해 재귀적 및 캐싱 네임 서버를 제공합니다.또한 많은 홈 네트워킹 라우터는 로컬 네트워크의 효율성을 향상시키기 위해 DNS 캐시와 재귀를 구현합니다.

DNS 확인기

DNS의 클라이언트 측을 DNS 확인기라고 합니다.해결사는 도메인 이름을 IP 주소로 변환하는 등 궁극적으로 추구하는 리소스의 전체 해결(번역)로 이어지는 쿼리를 시작하고 시퀀싱할 책임이 있습니다.DNS 확인기는 재귀적, 비재귀적, 반복적 등 다양한 쿼리 방법으로 분류됩니다.해결 프로세스에서는 이러한 방법을 조합하여 사용할 수 있습니다.[22]

비재귀 쿼리에서 DNS 확인자는 서버가 권한이 있는 레코드를 제공하거나 다른 서버를 쿼리하지 않고 부분적인 결과를 제공하는 DNS 서버를 쿼리합니다.캐싱 DNS 확인기의 경우 로컬 DNS 캐시의 비재귀 쿼리는 결과를 제공하고 업스트림 DNS 서버의 초기 응답 후 일정 기간 동안 DNS 리소스 레코드를 캐싱하여 업스트림 DNS 서버의 부하를 줄입니다.

재귀적 쿼리에서 DNS 확인자는 단일 DNS 서버를 쿼리하고, 요청자를 대신하여 다른 DNS 서버를 쿼리할 수 있습니다.예를 들어, 홈 라우터에서 실행되는 단순한 스터브 확인기는 일반적으로 사용자의 ISP에 의해 실행되는 DNS 서버에 재귀적 쿼리를 수행합니다.재귀적 쿼리는 DNS 서버가 필요에 따라 다른 네임 서버를 쿼리하여 쿼리에 완전히 응답하는 쿼리입니다.일반적으로 클라이언트는 캐시 재귀적 DNS 서버에 재귀적 쿼리를 발행하고, 이후 캐시 재귀적 DNS 서버는 비재귀적 쿼리를 발행하여 답변을 결정하고 클라이언트에 단일 답변을 다시 보냅니다.레졸버 또는 레졸버를 대신하여 재귀적으로 동작하는 다른 DNS 서버는 쿼리 헤더의 비트를 사용하여 재귀적 서비스의 사용을 협상합니다.DNS 서버는 재귀 쿼리를 지원하는 데 필요하지 않습니다.

반복 쿼리 절차는 DNS 확인자가 하나 이상의 DNS 서버 체인을 쿼리하는 프로세스입니다.현재 서버가 요청을 완전히 해결할 수 있을 때까지 각 서버는 체인의 다음 서버에 클라이언트를 참조합니다.예를 들어, www.example.com 의 가능한 해결책은 글로벌 루트 서버를 쿼리한 다음 "com" 서버를 쿼리하고 마지막으로 "example.com " 서버를 쿼리합니다.

원형 의존성 및 접착제 기록

위임의 이름 서버는 IP 주소가 아닌 이름으로 식별됩니다.즉, 확인 중인 네임 서버는 자신이 참조된 서버의 IP 주소를 찾기 위해 다른 DNS 요청을 발행해야 합니다.위임에 지정된 이름이 위임이 제공되는 도메인의 하위 도메인인 경우 순환 종속성이 있습니다.

이 경우 위임을 제공하는 네임 서버는 위임에서 언급된 권한 있는 네임 서버에 대해 하나 이상의 IP 주소도 제공해야 합니다.이 정보는 접착제라고 불립니다.위임 네임 서버는 DNS 응답의 추가 섹션에서 레코드 형태로 이 풀을 제공하고, 응답의 권한 섹션에서 위임을 제공합니다.풀 레코드는 이름 서버와 IP 주소의 조합입니다.

예를 들어 example.org 에 대한 권한 있는 네임 서버가 ns1.example.org 인 경우 www.example.org 을 확인하려는 컴퓨터가 먼저 ns1.example.org 을 확인합니다.ns1이 example.org 에 포함되어 있으므로 이를 위해서는 순환 종속성을 나타내는 example.org 을 먼저 확인해야 합니다.의존성을 없애기 위해 최상위 도메인 org의 네임 서버는 example.org 의 위임과 함께 글루를 포함합니다.글루 레코드는 ns1.example.org 의 IP 주소를 제공하는 주소 레코드입니다.확인자는 이러한 IP 주소 중 하나 이상을 사용하여 도메인의 권한 있는 서버 중 하나를 쿼리하므로 DNS 쿼리를 완료할 수 있습니다.

레코드 캐싱

애플리케이션에서 이름 확인을 구현하는 일반적인 방법은 로컬 또는 중간 확인자 호스트에서 결과를 캐싱하여 도메인 네임 시스템 서버의 부하를 줄이는 것입니다.DNS 요청에서 얻은 결과는 항상 결과를 폐기하거나 새로 고쳐야 하는 만료 시간인 TTL(Time to Live)과 연관됩니다.TTL은 권한 있는 DNS 서버의 관리자가 설정합니다.유효 기간은 몇 초에서 며칠 또는 몇 주까지 다양할 수 있습니다.[33]

이러한 분산 캐싱 아키텍처의 결과로 DNS 레코드에 대한 변경 사항이 네트워크 전체에 즉시 전파되지는 않지만 TTL 이후에 모든 캐시가 만료되고 새로 고쳐져야 합니다. RFC 1912는 적절한 TTL 값을 결정하기 위한 기본 규칙을 전달합니다.

프로토콜이 최대 68년 동안 캐싱을 지원하거나 캐싱을 전혀 지원하지 않기 때문에 일부 레졸버는 TTL 값을 재정의할 수 있습니다.부정적 캐싱, 즉 레코드가 존재하지 않는다는 사실에 대한 캐싱은 요청된 유형의 데이터가 없다고 보고할 때 SOA(Start of Authority) 레코드를 포함해야 하는 영역에 대해 권한이 있는 네임 서버에 의해 결정됩니다.SOA 레코드의 최소 필드 값과 SOA 자체의 TTL은 부정적 답변에 대한 TTL을 설정하는 데 사용됩니다.

역방향 조회

역 DNS 조회는 IP 주소를 알 때 도메인 이름에 대한 DNS 조회입니다.여러 도메인 이름이 IP 주소와 연결될 수 있습니다.DNS는 IP 주소를 도메인 이름 형태로 인프라 최상위 도메인 arpa 내의 PTR(Pointer) 레코드에 특수 포맷된 이름으로 저장합니다.IPv4의 경우 도메인은 in-addr.arpa 입니다.IPv6의 경우 역방향 조회 도메인은 ip6.arpa 입니다.IP 주소는 IPv4의 경우 역순 옥텟 표현, IPv6의 경우 역순 니블 표현에서 이름으로 표시됩니다.

역방향 조회를 수행할 때 DNS 클라이언트는 임의의 DNS 쿼리와 같은 위임 체인을 따르는 PTR 레코드의 이름을 쿼리하기 전에 주소를 이러한 형식으로 변환합니다.예를 들어 IPv4 주소(208.80.152.2)가 Wikimedia에 할당되었다고 가정하면 DNS 이름(2.152.80.208.in-addr.arpa )의 역순으로 표시됩니다.DNS 확인기가 포인터(PTR) 요청을 받으면 루트 서버를 쿼리하는 것으로 시작합니다. 루트 서버는 208.in-addr.arpa 영역에 대한 ARIN(American Registry for Internet Numbers) 서버를 가리킵니다.ARIN의 서버는 152.80.208.in-addr.arpa 을 위키미디어에 위임하고, 여기서 해결사는 2.152.80.208.in-addr.arpa 에 대한 다른 쿼리를 전송하고, 이는 권위 있는 응답으로 이어집니다.

클라이언트 조회

DNS 확인 순서

사용자는 일반적으로 DNS 확인자와 직접 통신하지 않습니다.대신 DNS 확인은 웹 브라우저, 전자우편 클라이언트 및 기타 인터넷 응용프로그램과 같은 응용프로그램에서 투명하게 수행됩니다.응용 프로그램에서 도메인 이름 조회가 필요한 요청을 하면 이러한 프로그램은 로컬 운영 체제에 있는 DNS 확인기로 확인 요청을 전송하고, 확인 요청은 필요한 통신을 처리합니다.

DNS 확인기에는 거의 항상 최근 조회를 포함하는 캐시(위 참조)가 있습니다.캐시가 요청에 대한 답변을 제공할 수 있는 경우, 해결사는 캐시의 값을 요청한 프로그램에 반환합니다.캐시에 답변이 포함되어 있지 않은 경우, 해결사는 하나 이상의 지정된 DNS 서버로 요청을 전송합니다.대부분의 가정 사용자의 경우, 컴퓨터가 연결하는 인터넷 서비스 공급자가 일반적으로 이 DNS 서버를 제공합니다. 이러한 사용자는 해당 서버의 주소를 수동으로 구성했거나 DHCP에서 설정할 수 있도록 허용했습니다. 그러나 시스템 관리자가 자신의 DNS 서버를 사용하도록 시스템을 구성한 경우,그들의 DNS 해결사는 별도로 유지되는 조직의 네임 서버를 가리킵니다.따라서 쿼리된 네임 서버는 결과를 성공적으로 찾거나 찾지 못할 때까지 위에 설명된 프로세스를 따릅니다.그런 다음 결과를 DNS 확인기에 반환합니다. 확인기는 결과를 발견했다고 가정하고 나중에 사용할 수 있도록 결과를 캐시하고 결과를 요청을 시작한 소프트웨어에 다시 전달합니다.

고장난 레졸버

일부 대형 ISP는 TTL을 준수하지 않거나 이름 서버 중 하나가 응답하지 않기 때문에 도메인 이름이 존재하지 않음을 나타내는 등 규칙을 위반하도록 DNS 서버를 구성했습니다.[34]

웹 브라우저와 같은 일부 응용 프로그램은 네트워크를 통한 반복적인 검색을 피하기 위해 내부 DNS 캐시를 유지합니다.이 방법은 DNS 문제를 디버깅할 때 이러한 데이터의 기록을 모호하게 하므로 추가적인 어려움을 가중시킬 수 있습니다.이러한 캐시는 일반적으로 1분 정도의 매우 짧은 캐싱 시간을 사용합니다.[35]

Internet Explorer는 IE 3.x까지의 버전이 기본적으로 24시간 동안 DNS 레코드를 캐시한다는 점에서 주목할 만한 예외를 나타냅니다.Internet Explorer 4.x 이상 버전(IE 8까지)은 기본 시간 초과 값을 30분으로 줄이고 기본 구성을 수정하여 변경할 수 있습니다.[36]

Google Chrome이 DNS 서버의 문제를 감지하면 특정 오류 메시지가 표시됩니다.

기타 어플리케이션

도메인 이름 시스템에는 몇 가지 다른 기능과 기능이 포함되어 있습니다.

일대일 관계에서 호스트 이름과 IP 주소가 일치할 필요는 없습니다.여러 호스트 이름은 단일 IP 주소에 해당할 수 있으며, 이는 여러 웹 사이트가 단일 호스트에서 제공되는 가상 호스팅에서 유용합니다.또는 단일 호스트 이름이 여러 IP 주소로 해결되어 기업 또는 글로벌 인터넷을 통해 여러 서버 인스턴스에 대한 내결함성 및 로드 분산을 용이하게 할 수 있습니다.

DNS는 이름을 IP 주소로 변환하는 것 외에 다른 목적으로도 사용됩니다.예를 들어, 메일 전송 에이전트는 DNS를 사용하여 전자우편을 배달할 최적의 메일 서버를 찾습니다.MX 레코드는 도메인과 메일 교환기 간의 매핑을 제공하며, 이를 통해 내결함성 및 부하 분산의 추가 계층을 제공할 수 있습니다.

DNS는 블랙리스트에 있는 전자 메일 호스트의 IP 주소를 효율적으로 저장하고 배포하는 데 사용됩니다.일반적인 방법은 주체 호스트의 IP 주소를 상위 도메인 이름의 하위 도메인에 배치하고 해당 이름을 긍정 또는 부정 표시를 나타내는 레코드로 확인하는 것입니다.

예를 들어,

  • 주소 102.3.4.5가 블랙리스트에 올라있습니다.127.0.0.1로 해결되는 5.4.3.102.blacklist.example을 가리킵니다.
  • 주소 102.3.4.6은 블랙리스트에 표시되지 않으며 6.4.3.102.blacklist.example을 가리킵니다.이 호스트 이름이 구성되어 있지 않거나 127.0.0.2로 확인됩니다.

전자 메일 서버는 블랙리스트에 연결된 특정 호스트가 있는지 확인하기 위해 blacklist.example을 쿼리할 수 있습니다.이러한 블랙리스트의 대부분은 구독 기반 또는 무료로 전자 메일 관리자와 안티스팸 소프트웨어에서 사용할 수 있습니다.

컴퓨터 또는 네트워크 장애 발생 시 복원력을 제공하기 위해 보통 각 도메인의 커버리지에 여러 DNS 서버가 제공됩니다.글로벌 DNS의 최상위 레벨에는 13개의 루트 네임 서버 그룹이 존재하며, 이 중 "복사본"이 애니캐스트 어드레싱을 통해 전 세계에 배포됩니다.

DDNS(Dynamic DNS)는 ISP 또는 모바일 핫스팟 간에 이동하거나 IP 주소가 관리적으로 변경되는 경우 등과 같이 클라이언트 IP 주소로 DNS 서버를 즉시 업데이트합니다.

DNS 메시지 형식

DNS 프로토콜은 쿼리와 응답이라는 두 가지 유형의 DNS 메시지를 사용합니다. 둘 다 동일한 형식을 가지고 있습니다.각 메시지는 머리글과 질문, 답변, 권한, 추가 공간 등 4개 섹션으로 구성됩니다.머리말 필드(플래그)는 이 4개 섹션의 내용을 제어합니다.[22]

헤더 섹션은 다음 필드로 구성됩니다.식별, 플래그, 질문 수, 답변 수, 권한 리소스 레코드(RR) 수, 추가 RR 수.각 필드의 길이는 16비트이며, 주어진 순서대로 표시됩니다.식별 필드는 응답을 쿼리와 일치시키는 데 사용됩니다.플래그 필드는 다음과 같이 하위 필드로 구성됩니다.

머리글 플래그 형식
들판 묘사 길이(비트)
QR 메시지가 쿼리(0)인지 회신(1)인지 나타냅니다. 1
OPCODE 유형은 QUREY(표준 쿼리, 0), IQUERY(역 쿼리, 1) 또는 STATUS(서버 상태 요청, 2)가 될 수 있습니다. 4
AA 응답에서 Authoritive Answer는 DNS 서버가 쿼리된 호스트 이름에 대해 Authoritive인지 여부를 나타냅니다. 1
TC TrunCation - 이 메시지가 길이 초과로 인해 잘렸음을 나타냅니다. 1
RD 원하는 재귀 - 클라이언트가 재귀 쿼리를 의미하는지 여부를 나타냅니다. 1
RA 응답에서 응답하는 DNS 서버가 재귀를 지원하는지 여부를 나타냅니다. 1
Z 0, 추후 사용을 위해 예약됨 3
RCODE 응답 코드는 NOERR(0), FORMERR(1, 포맷 오류), SERVFAIL(2), NXDOMAIN(3, 존재하지 않는 도메인) 등일 수 있습니다.[37] 4

플래그 뒤에 오는 각 섹션의 레코드 수를 같은 순서로 포함하는 4개의 16비트 정수로 헤더가 끝납니다.

질문란

질문 섹션의 형식은 다른 섹션에서 사용하는 리소스 레코드 형식보다 간단합니다.각 질문 기록(일반적으로 섹션에 하나만 있음)에는 다음 필드가 포함됩니다.

RR(Resource Record) 필드
들판 묘사 길이(옥텟)
이름. 요청된 리소스의 이름 변수
유형 RR의 종류(A, AAA, MX, TX 등) 2
학급 클래스코드 2

도메인 이름은 연결된 개별 레이블로 분할됩니다. 각 레이블은 해당 레이블의 길이 앞에 붙여집니다.[38]

리소스 레코드

도메인 이름 시스템은 네트워크 리소스에 대한 정보 요소 데이터베이스를 지정합니다.정보 요소의 유형은 DNS 레코드 유형 목록인 리소스 레코드(Resource Records, RR)로 분류되고 정리됩니다.각 레코드에는 유형(이름 및 번호), 만료 시간(살아있는 시간), 클래스 및 유형별 데이터가 있습니다.같은 유형의 리소스 레코드는 특별한 순서가 없는 RRset(Resource Record Set)으로 설명됩니다.DNS 확인자는 쿼리 시 전체 집합을 반환하지만 서버는 로드 밸런싱을 달성하기 위해 라운드 로빈 순서를 구현할 수 있습니다.반면 DNSSEC(Domain Name System Security Extensions)는 표준 순서대로 전체 리소스 레코드 집합에서 작동합니다.

인터넷 프로토콜 네트워크를 통해 전송되는 경우 모든 레코드는 RFC 1035에 지정된 공통 형식을 사용합니다.[39]

RR(Resource Record) 필드
들판 묘사 길이(옥텟)
이름. 이 레코드가 속해 있는 노드의 이름 변수
유형 숫자 형태의 RR 유형(예: MX RR의 경우 15) 2
학급 클래스코드 2
TTL RR이 유효한 상태를 유지하는 초수(최대 2-131, 약 68년) 4
RD Length RDATA 필드 길이(옥텟 단위로 지정) 2
RDATA 추가 RR별 데이터 RDLength에 따른 변수

NAME은 트리에[clarification needed] 있는 노드의 정규화된 도메인 이름입니다.유선상에서 이름은 라벨 압축을 사용하여 단축할 수 있으며 패킷에서 앞서 언급한 도메인 이름의 끝을 현재 도메인 이름의 끝으로 대체할 수 있습니다.

TYPE은 레코드 타입입니다.데이터의 형식을 나타내며 데이터의 용도를 암시합니다.예를 들어, A 레코드는 도메인 이름에서 IPv4 주소로 변환하는 데 사용되며, NS 레코드는 DNS 영역에서 검색에 응답할 수 있는 이름 서버를 나열하며, MX 레코드는 전자 메일 주소에 지정된 도메인의 메일을 처리하는 데 사용되는 메일 서버를 지정합니다.

RDATA는 주소 레코드의 IP 주소 또는 MX 레코드의 우선 순위 및 호스트 이름과 같은 유형별 관련성이 있는 데이터입니다.잘 알려진 레코드 유형은 RDATA 필드의 레이블 압축을 사용할 수 있지만 "알 수 없는" 레코드 유형은 사용할 수 없습니다(RFC 3597).

레코드의 CLASS는 인터넷 호스트 이름, 서버 또는 IP 주소를 포함하는 일반 DNS 레코드에 대해 IN(인터넷의 경우)으로 설정됩니다.또한, Chaos(CH)와 Hesiod(HS) 클래스가 존재합니다.[40]각 클래스는 DNS 영역의 위임이 서로 다를 수 있는 독립적인 이름 공간입니다.

도메인 이름 시스템은 존 파일에 정의된 리소스 레코드 외에도 존 전송(AXFR/IXFR)을 수행할 때나 EDNS(OPT)를 위한 경우와 같이 다른 DNS 노드(무선)와의 통신에서만 사용되는 여러 요청 유형을 정의합니다.

와일드카드 레코드

도메인 이름 시스템은 별표 레이블 '*'로 시작하는 이름(예: *.example)을 지정하는 와일드카드 DNS 레코드를 지원합니다.[22][41]와일드카드 도메인 이름에 속하는 DNS 레코드는 지정된 하위 항목을 포함하여 쿼리 이름의 일치하는 구성 요소로 전체 레이블을 대체하여 단일 DNS 영역 내에서 리소스 레코드를 생성하는 규칙을 지정합니다.예를 들어, 다음 구성에서 DNS 영역 x.example은 x.example의 하위 도메인을 포함한 모든 하위 도메인이 메일 교환기(MX) a.x.example을 사용하도록 지정합니다.메일 교환기 IP 주소를 지정하려면 a.x.example에 대한 A레코드가 필요합니다.이 도메인 이름과 하위 도메인이 와일드카드 일치에서 제외되므로 하위 도메인 a.x.example에 대한 추가 MX 레코드와 모든 하위 도메인에 대한 와일드카드 MX 레코드도 DNS 영역에 정의해야 합니다.

x.example.       MX   10 xx example *.x. example.     MX   10 xx example *.x. example.   MX   10 xx example xx example     MX   10 xx example xx example     아아아. 2001:db8::1

와일드카드 기록의 역할은 다음과 같이 정교화되었습니다. RFC4592, RFC1034의 원래 정의가 불완전하여 구현자가 잘못 해석했기 때문입니다.[41]

프로토콜 확장

원래의 DNS 프로토콜은 새로운 기능으로 확장할 수 있는 제한된 규정을 가지고 있었습니다.1999년, Paul Vixie는 RFC 2671 (RFC 6891에 의해 대체됨)에서 사용하지 않을 때 오버헤드를 증가시키지 않고 옵션 프로토콜 요소를 도입한 확장 메커니즘인 EDNS(Extension Mechanics for DNS)를 발표했습니다.이것은 프로토콜의 유선 전송에만 존재하는 OPT 의사 리소스 레코드를 통해 이루어졌지만, 어떤 존 파일에도 존재하지 않습니다.또한 UDP 데이터그램에서 DNS 메시지 크기를 증가시키는 것과 같은 초기 확장(EDNS0)이 제안되었습니다.

동적 영역 업데이트

동적 DNS 업데이트는 UPDATE DNS opcode를 사용하여 권한 있는 DNS 서버에 유지 관리되는 영역 데이터베이스에서 리소스 레코드를 동적으로 추가하거나 제거합니다.이 기능은 RFC 2136에 설명되어 있습니다.이 기능은 네트워크 클라이언트가 부팅되거나 네트워크에서 사용할 수 있게 될 때 DNS에 네트워크 클라이언트를 등록하는 데 유용합니다.부팅 클라이언트는 DHCP 서버로부터 매번 다른 IP 주소를 할당받을 수 있으므로 이러한 클라이언트에 정적 DNS 할당을 제공할 수 없습니다.

트랜스포트 프로토콜

1983년 그 기원 이래로 DNS는 IP를 통한 전송을 위해 사용자 데이터그램 프로토콜(UDP)을 사용해 왔습니다.이러한 한계는 이후 수십 년 동안 신뢰성, 보안, 프라이버시 및 기타 기준에 대한 수많은 프로토콜 개발에 동기를 부여해 왔습니다.

DNS over UDP/53 (Do53)
UDP는 쿼리를 수신하는 서버를 위해 포트 번호 53을 예약합니다.[5]이러한 쿼리는 클라이언트에서 단일 UDP 패킷으로 전송된 클리어 텍스트 요청으로 구성되며, 서버에서 단일 UDP 패킷으로 전송된 클리어 텍스트 응답으로 응답됩니다.답의 길이가 512바이트를 초과하고 클라이언트와 서버가 모두 EDNS(Extension Mechanism for DNS)를 지원하는 경우 더 큰 UDP 패킷이 사용될 수 있습니다.[42]UDP를 통한 DNS 사용은 무엇보다도 전송 계층 암호화, 인증, 신뢰할 수 있는 전달 및 메시지 길이의 부족으로 인해 제한됩니다.
TCP/53을 통한 DNS(Do53/TCP)
1989년, RFC 1123은 DNS 쿼리, 응답, 특히 구역 전송을 위한 선택적 전송 제어 프로토콜(TCP) 전송을 명시했습니다.긴 응답의 단편화를 통해 TCP는 응답 시간이 길어지고, 신뢰성 있는 전달이 가능하며, 클라이언트와 서버 간의 수명이 긴 연결을 다시 사용할 수 있습니다.
DNS over TLS(DoT)
DNS over TLS는 2016년에 암호화된 DNS에 대한 IETF 표준으로 부상하였으며, 단지 DNS 페이로드가 아닌 전체 연결을 보호하기 위해 TLS(Transport Layer Security)를 사용했습니다.DoT 서버는 TCP 포트 853에서 수신합니다.RFC 7858은 기회형 암호화 및 인증된 암호화를 지원할 수 있다고 명시하고 있지만 서버 또는 클라이언트 인증을 의무화하지는 않았습니다.
HTTPS를 통한 DNS(DoH)
DNS over HTTPS는 2018년 DNS 쿼리 전송을 위한 경쟁 표준으로 개발되었으며, HTTP over TLS를 전송하는 HTTPS를 통해 DNS 쿼리 데이터를 터널링합니다. DoH는 DNSCrypt와 같이 TCP 포트 443을 사용하기 때문에 실제로는 쉽게 구별할 수 있지만 웹 트래픽과 유사해 보이기 때문에 DNS에 대한 보다 웹 친화적인 대안으로 추진되었습니다.[43]
Odeconious DNS(ODNS) 및 Odeconious DoH(ODoH)
언컨셔스 DNS(ODNS)는 암호화되지 않은 DNS의 확장으로 프린스턴 대학교와 시카고 대학교의 연구자들에 의해 발명되고 구현되었으며, DoH가 표준화되고 널리 배포되기 전에.[44]애플과 클라우드플레어는 이후 DoH의 맥락에서 Obeconious DoH(ODoH)라는 기술을 구현했습니다.[45]ODoH는 입력/출력 분리(ODNS에서 발명됨)와 DoH의 HTTPS 터널링 및 TLS 전송 계층 암호화를 단일 프로토콜로 결합합니다.[46]
DNS over TOR
DNS는 VPN(Virtual Private Network) 및 터널링 프로토콜을 통해 실행될 수 있습니다.2019년부터 자주 사용되는 고유의 머리글자를 보증하기 위해 일반화된 사용은 DNS over Tor입니다.Oblivious DNS의 프라이버시 이득은 TLS에 의해 제공되는 전송 계층 암호화와 쌍을 이루는 입력 및 출력 노드의 기존 Tor 네트워크를 사용하여 얻을 수 있습니다.[47]
QUIC를 통한 DNS(DoQ)
인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force)에 의한 RFC 9250은 QUIC를 통한 DNS에 대해 설명합니다.
디엔에스크립트
2011년 IETF 표준 프레임워크 외부에서 개발된 DNS 암호화 프로토콜은 재귀적 레졸버(recursive resolver)의 다운스트림(downstream) 측에 DNS 암호화를 도입하였는데, 클라이언트는 서버의 공개키를 이용하여 쿼리 페이로드를 암호화하고,(타사 인증 기관에 의존하지 않고) DNS에 게시되며 DNSSEC 서명에 의해 보호될 수 있습니다.[48]DNSCrypt는 HTTPS 암호화된 웹 트래픽과 동일한 포트인 TCP 또는 UDP 포트 443을 사용합니다.이로 인해 쿼리 내용에 대한 개인 정보 보호뿐만 아니라 방화벽 통과 기능의 상당한 척도가 도입되었습니다.2019년에 DNSCrypt는 제안된 "Oblivious DNS"와 유사한 "익명화된" 모드를 지원하도록 추가로 확장되었으며, 이 모드에서는 입력 노드가 다른 서버의 공개 키로 암호화된 쿼리를 수신하여 해당 서버에 중계하고, 이 쿼리는 재귀적 해결을 수행합니다.[49]입력 노드는 쿼리의 내용을 알지 못하는 반면, 출력 노드는 클라이언트의 ID를 알지 못하기 때문에 사용자/쿼리 쌍의 개인 정보 보호가 생성됩니다.DNSCrypt는 OpenDNS에 의해 2011년 12월에 처음으로 구현되었습니다.ODoH를 추가로 통합하는 몇 가지 무료 및 오픈 소스 소프트웨어 구현이 있습니다.[50]유닉스, Apple iOS, Linux, Android, MS Windows 등 다양한 운영 체제에서 사용할 수 있습니다.

보안문제

원래, 네트워크가 일반 대중의 참여를 위해 개방되어 있지 않았기 때문에 보안 문제는 DNS 소프트웨어나 초기 인터넷 배포를 위한 소프트웨어의 주요 설계 고려 사항이 아니었습니다.그러나 1990년대 인터넷이 상업적 영역으로 확대되면서 데이터 무결성 및 사용자 인증을 보호하기 위한 보안 조치의 요구사항이 변경되었습니다.

악의적인 사용자가 여러 취약성 문제를 발견하고 이를 악용했습니다.이러한 문제 중 하나는 DNS 캐시 피독입니다. 권한 있는 오리진 서버인 것처럼 데이터가 캐싱 레졸버로 분산되어 데이터 저장소에 잠재적으로 잘못된 정보와 긴 만료 시간(생존 시간)을 오염시키는 것입니다.이어서 합법적인 응용프로그램 요청이 악의적인 의도로 운영되는 네트워크 호스트로 리디렉션될 수 있습니다.

DNS 응답에는 일반적으로 암호화 서명이 없으므로 많은 공격 가능성이 있습니다. DNSSEC(Domain Name System Security Extensions)는 DNS를 수정하여 암호화 서명 응답에 대한 지원을 추가합니다.[51]DNSCurve는 DNSSEC의 대안으로 제안되었습니다.TSIG와 같은 다른 확장 기능은 신뢰할 수 있는 피어 간의 암호화 인증을 지원하며 영역 전송 또는 동적 업데이트 작업을 승인하는 데 일반적으로 사용됩니다.

일부 도메인 이름은 스푸핑 효과를 얻기 위해 사용될 수 있습니다.예를 들어 paypal.com 과 paypa1.com 은 서로 다른 이름이지만 사용자가 선택한 서체에 따라 그래픽 사용자 인터페이스에서 구분할 수 없을 수도 있습니다.많은 글꼴에서 문자 l과 숫자 1은 매우 비슷하거나 심지어 동일하게 보입니다.IDN 호모그래프 공격으로 알려진 이 문제는 국제화된 도메인 이름을 지원하는 시스템에서 심각합니다. ISO 10646의 많은 문자 코드가 일반적인 컴퓨터 화면에 동일하게 나타날 수 있기 때문입니다.이 취약성은 피싱에서 종종 악용됩니다.[52]

순방향 확인 역 DNS와 같은 기법을 사용하여 DNS 결과의 유효성을 검사할 수도 있습니다.

또한 DNS의 구성에 주의를 기울이지 않으면 보안 연결이나 개인 연결에서 "누출"될 수 있으며 악의적인 사람이 방화벽을 우회하고 데이터를 유출하는 데 DNS를 사용한 경우도 있습니다.

개인 정보 보호 및 추적 문제

원래 퍼블릭, 계층적, 분산 및 캐시가 많은 데이터베이스로 설계된 DNS 프로토콜에는 기밀성 제어 기능이 없습니다.네트워크 패킷 스니핑, DNS 하이재킹, DNS 캐시 독살 및 중간자 공격을 가능하게 하는 사용자 쿼리 및 네임 서버 응답이 암호화되지 않은 상태로 전송됩니다.이러한 결함은 일반적으로 사이버 범죄자와 네트워크 운영자가 마케팅 목적, 캡티브 포털에서의 사용자 인증 및 검열을 위해 사용합니다.[53]

컨텐츠 전송 네트워크의 이점을 위해 DNS 쿼리(RFC 7871)에서 클라이언트 IP 정보 수준을 높이는 제안을 통해 사용자의 프라이버시가 더욱 노출됩니다.

DNS와 관련된 개인 정보 보호 문제를 해결하기 위해 사용되는 주요 접근 방식:

  • VPN 운영자에게 DNS 해상도를 이동시키고 로컬 ISP로부터 사용자 트래픽을 숨깁니다.
  • 기존 DNS 해상도를 익명의 .양파 도메인으로 대체하고 이름 해상도와 사용자 트래픽을 양파 라우팅 역감시 뒤에 숨기는 Tor,
  • 프록시 및 공용 DNS 서버: 실제 DNS 해상도를 타사 공급자에게 이동합니다. 타사 공급자는 일반적으로 요청 기록을 거의 또는 전혀 하지 않고 DNS 수준의 광고 또는 포르노 차단과 같은 선택적인 추가 기능을 약속합니다.
    • 퍼블릭 DNS 서버는 기존 DNS 프로토콜을 사용하여 쿼리할 수 있습니다. 이 경우 로컬 감시나 HTTPS를 통한 DNS, TLS를 통한 DNS 및 DNSCrypt로부터 이러한 보호를 제공하지 않습니다.

로컬 네트워크 운영자의 DNS 검사를 막는 솔루션은 기업의 네트워크 보안 정책과 인터넷 검열을 방해한다는 비판을 받고 있습니다.또한 사용자 트래픽을 수익화하고 일반적으로 인터넷에 유해한 것으로 인식되는 DNS 이름 해결을 중앙 집중화하는 것으로 알려진 소수의 회사의 손에 DNS 해결책을 넘겨주는 것으로 프라이버시 관점에서 비판을 받고 있습니다.[53]

Google은 Android에서는 플랫폼의 지배적인 공급자이며, Chrome에서는 브라우저, 8.8.8.8 서비스에서는 DNS 레졸버를 제공합니다.이 시나리오는 단일 기업체가 인터넷의 전체 네임스페이스를 지배하는 위치에 있는 경우가 될 수 있습니까?넷플릭스는 이미 앱이 실행되는 플랫폼과 독립적으로 자체 DNS 해결 메커니즘을 사용하는 앱을 필드에 넣었습니다.페이스북 앱에 DoH가 포함되어 있다면 어떨까요?Apple의 iOS가 DoH-resolution 메커니즘을 사용하여 로컬 DNS 확인을 무시하고 Apple 플랫폼의 모든 DNS 쿼리를 Apple이 운영하는 이름 확인기 세트로 조정하면 어떻게 됩니까?

— DNS Privacy and the IETF

도메인이름등록

도메인 이름을 사용할 권리는 ICANN(Internet Corporation for Assigned Names and Numbers) 또는 OpenNIC와 같은 인터넷의 이름과 번호 시스템을 감독하는 책임이 있는 다른 조직에 의해 인가된 도메인 이름 등록 담당자에 의해 위임됩니다.ICANN 외에도 각 TLD(Top-level domain)는 레지스트리를 운영하는 관리 조직에 의해 기술적으로 유지 및 서비스됩니다.레지스트리는 권한 있는 영역 내의 이름 데이터베이스를 운영하는 책임이 있지만, 이 용어는 TLDs에 가장 많이 사용됩니다. 등록자는 도메인 등록을 요청한 사람 또는 단체입니다.[23]레지스트리는 각 도메인 이름 등록 기관으로부터 등록 정보를 수신하며, 등록 기관은 해당 영역에 이름을 할당할 수 있는 권한을 부여(승인)하고 WHOIS 프로토콜을 사용하여 정보를 게시합니다.2015년 현재 RDAP의 사용이 검토되고 있습니다.[54]

ICANN은 TLD, TLD 레지스트리 및 도메인 이름 레지스터의 전체 목록을 게시합니다.도메인 이름과 관련된 등록자 정보는 WHOIS 서비스에서 액세스할 수 있는 온라인 데이터베이스에 유지됩니다.290개 이상의 국가 코드 최상위 도메인(ccTLD) 대부분의 경우 도메인 레지스트리는 WHOIS(등록자, 이름 서버, 만료 날짜 등) 정보를 유지 관리합니다.예를 들어, DENIC, Germany NIC는 DE 도메인 데이터를 보유합니다.2001년경부터 대부분의 GTLD(Generic Top-level domain) 레지스트리는 소위 두꺼운 레지스트리 접근법, 즉 WHOIS 데이터를 등록 기관 데이터베이스가 아닌 중앙 레지스트리에 유지하는 방식을 채택했습니다.

COM 및 NET의 최상위 도메인의 경우 씬 레지스트리 모델이 사용됩니다.도메인 레지스트리(예: GoDaddy, BigRock and PDR, VeriSign 등)는 기본 WHOIS 데이터(예: Registrar 및 네임 서버 등)를 보유합니다.반면 ORG를 사용하는 단체 또는 등록자는 공익 등록부에 독점적으로 등록되어 있습니다.

네트워크 정보 센터(NIC)라고도 불리는 일부 도메인 이름 레지스트리는 WHOIS 데이터셋에 대한 액세스를 제공하는 것 외에도 최종 사용자에게 레지스터 역할도 합니다.도메인 COM, NET 및 ORG와 같은 최상위 도메인 레지스트리는 많은 도메인 이름 레지스터로 구성된 레지스트리-레지스터 모델을 사용합니다.[55]이 관리 방법에서는 레지스트리가 도메인 이름 데이터베이스와 레지스터와의 관계만 관리합니다.등록자(도메인 이름 사용자)는 리셀러의 추가 하청을 통해 등록 기관의 고객입니다.

RFC 문서

도메인 이름 시스템은 인터넷 엔지니어링 태스크 포스(Internet Standards)에 의해 게시된 RFC(Request for Comments) 문서에 의해 정의됩니다.다음은 DNS 프로토콜을 정의하는 RFC 목록입니다.

표준궤도

  • RFC 1034, 도메인 이름 - 개념 및 설비
  • RFC 1035, 도메인 이름 - 구현 및 규격
  • RFC 1123, 인터넷 호스트 요구사항—응용 및 지원
  • RFC 1995, DNS에서의 증분존 전송
  • RFC 1996, 구역변경의 신속한 통보 메커니즘
  • RFC 2136, 도메인 이름 시스템의 동적 업데이트 (DNS UPDATE)
  • RFC 2181, DNS 명세의 명세
  • RFC 2308, DNS 쿼리의 네거티브 캐싱(DNS NCACHE)
  • RFC 2672, 비터미널 DNS 이름 리디렉션
  • RFC 2845, DNS를 위한 비밀키 트랜잭션 인증 (TSIG)
  • RFC 3225, DNSSEC의 Resolver 지원 표시
  • RFC 3226, DNSSEC 및 IPv6 A6 인식 서버/해결사 메시지 크기 요구사항
  • RFC 3596, IP 버전 6 지원을 위한 DNS 확장
  • RFC 3597, 알 수 없는 DNS 자원기록(RR) 유형의 처리
  • RFC 4343, 도메인 네임 시스템(DNS) Case Insensitive Clarification
  • RFC 4592, 도메인 네임 시스템에서 와일드카드의 역할
  • RFC 4635, HMAC SHATSIG 알고리즘 식별자
  • RFC 5001, DNS Name Server Identifier(Option)
  • RFC 5011, DNS 보안(DNSSEC) 신뢰 앵커의 자동 업데이트
  • RFC 5452, 위조된 답변에 대해 DNS를 보다 탄력적으로 만들기 위한 조치
  • RFC 5890, IDNA(Internationalized Domain Names for Applications):정의 및 문서 프레임워크
  • RFC 5891, 응용프로그램에서의 국제화 도메인 이름: 프로토콜
  • RFC 5892, 유니코드 코드 포인트와 국제화된 응용프로그램 도메인 이름
  • RFC 5893, IDNA(Internationalized Domain Name for Applications)를 위한 오른쪽에서 왼쪽으로의 스크립트
  • RFC 6891, DNS를 위한 확장 메커니즘 (EDNS0)
  • RFC 7766, TCP를 통한 DNS 전송 - 구현 요구사항

제안된 보안 표준

  • RFC 4033, DNS 보안 소개 및 요구사항
  • RFC 4034, DNS 보안 확장을 위한 리소스 레코드
  • RFC 4035, DNS 보안 확장을 위한 프로토콜 수정
  • RFC 4509, DNSSEC 위임서명자(DS) 자원기록에서의 SHA-256 사용
  • IMT2000 3GPP - NSEC 기록과 DNSSEC 온라인 서명을 최소한으로 다루는 RFC 4470
  • RFC 5155, DNS 보안(DNSSEC) 해시드 인증된 존재 거부
  • RFC 5702, DNSKEY에서 RSA를 사용한 SHA-2 알고리즘과 DNSSEC를 위한 RRSIG 자원 레코드의 사용
  • IMT2000 3GPP - 확장형 프로비저닝 프로토콜을 위한 도메인 네임 시스템 보안 확장 매핑
  • RFC 5933, DNSKEY에서 GOST 서명 알고리즘의 사용 및 DNSSEC를 위한 RRSIG 자원 레코드
  • RFC 7830, EDNS(0) 패딩 옵션
  • RFC 7858, DNS over Transport Layer Security (TLS) 규격
  • RFC 8310, DNS over TLS 및 DNS over DTLS를 위한 사용프로파일
  • RFC 8484, HTTPS를 통한 DNS 쿼리 (DoH)

실험용 RFC

  • RFC 1183, 새로운 DNS RR 정의

모범 사례

  • RFC 2182, 세컨더리 DNS 서버의 선정 및 운영 (BCP 16)
  • RFC 2317, 클래스리스 IN-ADDRARPA 대표단(BCP 20)
  • RFC 5625, DNS 프록시 구현 지침 (BCP 152)
  • RFC 6895, 도메인 네임 시스템 (DNS) IANA 고려사항 (BCP 42)
  • RFC 7720, DNS 루트명 서비스 프로토콜 및 배포 요구사항 (BCP 40)

정보성 RFC

이러한 RFC는 본질적으로 자문적이지만 표준이나 BCP를 정의하지 않음에도 불구하고 유용한 정보를 제공할 수 있습니다(RFC 1796).

  • RFC 1178, 컴퓨터 이름 선택 (FYI 5)
  • RFC 1591, 도메인 네임 시스템 구조와 위임
  • RFC 1912, 일반적인 DNS 운용 및 설정 오류
  • RFC 2100, 호스트명칭
  • RFC 3696, 명칭확인 및 변환을 위한 응용기술
  • RFC 3833.DNS(Domain Name System)의 위협분석
  • RFC 4892, 네임 서버 인스턴스를 식별하는 메커니즘에 대한 요구사항
  • RFC 5894, IDNA(Internationalized Domain Names for Applications):배경, 설명 및 근거
  • RFC 5895, IDNA (Internationalized Domain Name in Applications) 2008을 위한 매핑 문자
  • RFC 7626, DNS 프라이버시 고려사항
  • RFC 7706, 루프백에서 하나를 실행하여 루트 서버로의 액세스 시간 단축
  • RFC 7816, 개인정보 보호 향상을 위한 DNS 쿼리 이름 최소화
  • RFC 8499, DNS 용어

알 수 없는

이러한 RFC들은 알 수 없는 공식적인 상태를 가지고 있지만, 그들의 나이 때문에 그와 같은 라벨이 명확하게 붙어 있지 않습니다.

  • RFC 920, 도메인 요구사항 – 지정된 원래 최상위 도메인
  • RFC 1032, 도메인 관리자 가이드
  • RFC 1033, 도메인 관리자 운영 가이드
  • RFC 1101, 네트워크명과 다른 타입의 DNS 인코딩

참고 항목

참고문헌

  1. ^ Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). "Information fusion‐based method for distributed domain name system cache poisoning attack detection and identification". IET Information Security. 10 (1): 37–44. doi:10.1049/iet-ifs.2014.0386. ISSN 1751-8717. S2CID 45091791.
  2. ^ RFC 781, 인터넷 프로토콜 - DARPA 인터넷 프로그램 프로토콜 명세, 정보 과학 연구소, J. Postel (Ed.), 인터넷 학회 (1981년 9월)
  3. ^ J. 딜리, B.맥그스, J. 패리크, H. 프로콥, R. 시타라만, B.Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, September/October 2002, pp. 50–58" (PDF). Archived (PDF) from the original on 2015-04-17.
  4. ^ Nygren., E.; Sitaraman R. K.; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" (PDF). ACM SIGOPS Operating Systems Review. 44 (3): 2–19. doi:10.1145/1842733.1842736. S2CID 207181702. Archived (PDF) from the original on 2010-12-02. Retrieved November 19, 2012.
  5. ^ a b c d e f Mockapetris, Paul (November 1987). Domain Names - Implementation and Specification. IETF. doi:10.17487/RFC1035. RFC 1035.
  6. ^ Champika Wijayatunga (February 2015). "DNS Abuse Handling" (PDF). APNIC. Archived (PDF) from the original on 2015-12-22. Retrieved 18 December 2016.
  7. ^ RFC 3467, "DNS(Domain Name System)의 역할", J.C. Klensin, J. Klensin (2003년 2월)
  8. ^ Liu, Cricket; Albitz, Paul (2006). DNS and BIND (5th ed.). O'Reilly Media. p. 3. ISBN 978-0-596-10057-5.
  9. ^ 에반스 2018, 112쪽.
  10. ^ 에반스 2018, 113쪽.
  11. ^ IEEE 연보 [3B2-9] man2011030074.3d 29/7/011 11:54 74페이지
  12. ^ a b "Why Does the Net Still Work on Christmas? Paul Mockapetris - Internet Hall of Fame". internethalloffame.org. 23 July 2012.
  13. ^ a b 에반스 2018, 페이지 119.
  14. ^ 에반스 2018, 페이지 120.
  15. ^ 에반스 2018, 페이지 120-121.
  16. ^ "Elizabeth Feinler". Internet Hall of Fame. Archived from the original on 14 September 2018. Retrieved 2018-11-25.
  17. ^ "Paul Mockapetris Internet Hall of Fame". internethalloffame.org. Retrieved 2020-02-12.
  18. ^ Andrei Robachevsky (26 November 2013). "Happy 30th Birthday, DNS!". Internet Society. Retrieved 18 December 2015.
  19. ^ 엘리자베스 파인러, IEEE 연보, 3B2-9 man201030074.3d 29/7/011 11:54 74페이지
  20. ^ Terry, Douglas B.; et al. (June 12–15, 1984). "The Berkeley Internet Name Domain Server". Summer Conference, Salt Lake City 1984: Proceedings. USENIX Association Software Tools Users Group. pp. 23–31.
  21. ^ Internet Systems Consortium. "The History of BIND". History of BIND. Archived from the original on 2019-06-30. Retrieved 4 April 2022.
  22. ^ a b c d e Mockapetris, Paul (November 1987). Domain Names - Domain Concepts and Facilities. IETF. doi:10.17487/RFC1034. RFC 1034.
  23. ^ a b Paul Hoffman; Andrew Sullivan; Kazunori Fujiwara (December 2015). DNS Terminology. IETF. doi:10.17487/RFC7719. RFC 7719. Retrieved 18 December 2015.
  24. ^ Paul Mockapetris (November 1987). "Name space specifications and terminology". Domain Names - Domain Concepts and Facilities. IETF. sec. 3.1. doi:10.17487/RFC1034. RFC 1034. Retrieved 17 December 2015.
  25. ^ a b Paul Mockapetris (November 1987). "How the database is divided into zones". Domain Names - Domain Concepts and Facilities. IETF. sec. 4.2. doi:10.17487/RFC1034. RFC 1034. Retrieved 17 December 2015.
  26. ^ Lindsay, David (2007). International Domain Name Law: ICANN and the UDRP. Bloomsbury Publishing. p. 8. ISBN 978-1-84113-584-7.
  27. ^ IMT-2000 3GPP-망작업반, 2006년 1월 RFC 4343: 도메인네임시스템(DNS) Case Insensitive Clarification
  28. ^ a b RFC 3696, 명칭확인 및 변환을 위한 응용기술, J. Clensin
  29. ^ Fujiwara, Kazunori; Sullivan, Andrew; Hoffman, Paul (2019). "DNS Terminology". tools.ietf.org. doi:10.17487/RFC8499. Retrieved 2020-06-21.
  30. ^ Nemeth, Evi; Snyder, Garth; Hein, Trent R. (2006-10-30). Linux Administration Handbook. Addison-Wesley Professional. ISBN 978-0-13-700275-7.
  31. ^ Bissyande, Tegawendé F.; Sie, Oumarou (2017-10-09). e-Infrastructure and e-Services for Developing Countries: 8th International Conference, AFRICOMM 2016, Ouagadougou, Burkina Faso, December 6-7, 2016, Proceedings. Springer. ISBN 978-3-319-66742-3.
  32. ^ "DNS zone". IONOS Digitalguide. 27 January 2022. Retrieved 2022-03-31.
  33. ^ "What is DNS propagation?". IONOS Digitalguide. Retrieved 2022-04-22.
  34. ^ "Providers ignoring DNS TTL?". Slashdot. 2005. Retrieved 2012-04-07.
  35. ^ Ben Anderson (7 September 2011). "Ben Anderson: Why Web Browser DNS Caching Can Be A Bad Thing". Retrieved 20 October 2014.
  36. ^ "How Internet Explorer uses the cache for DNS host entries". Microsoft Corporation. 2004. Retrieved 2010-07-25.
  37. ^ "Domain Name System (DNS) Parameters". IANA. DNS RCODEs. Retrieved 14 June 2019.
  38. ^ 제임스 F.Kurose and Keith W. Ross, 컴퓨터 네트워킹: 하향식 접근법, 6thd.에섹스, 영국: 피어슨 에듀케이션.리미티드, 2012
  39. ^ RFC 5395, DNS(Domain Name System) IANA 고려사항, D이스트레이크 3차 (2008년 11월), 섹션 3
  40. ^ RFC 5395, DNS(Domain Name System) IANA 고려사항, DEastlake 3rd (2008년 11월), p. 11
  41. ^ a b RFC 4592, 도메인 이름 시스템에서 와일드카드의 역할, E. Lewis (2006년 7월)
  42. ^ RFC 2671, DNS를 위한 확장 메커니즘 (EDNS0), P. Vixie (1999년 8월)
  43. ^ Csikor, Levente; Divakaran, Dinil Mon (February 2021). "Privacy of DNS over HTTPS: Requiem for a Dream?" (PDF). National University of Singapore. We investigate whether DoH traffic is distinguishable from encrypted Web traffic. To this end, we train a machine learning model to classify HTTPS traffic as either Web or DoH. With our DoH identification model in place, we show that an authoritarian ISP can identify ≈97.4% of the DoH packets correctly while only misclassifying 1 in 10,000 Web packets.
  44. ^ Schmitt, Paul; Edmundson, Anne; Feamster, Nick (2019). "Oblivious DNS: Practical Privacy for DNS Queries" (PDF). Privacy Enhancing Technologies. 2019 (2): 228–244. arXiv:1806.00276. doi:10.2478/popets-2019-0028. S2CID 44126163. Archived (PDF) from the original on 2022-01-21.
  45. ^ "Oblivious DNS Deployed by Cloudflare and Apple". 9 December 2020. Retrieved 27 July 2022.
  46. ^ Pauly, Tommy (2 September 2021). "Oblivious DNS Over HTTPS". IETF.
  47. ^ Muffett, Alec (February 2021). ""No Port 53, Who Dis?" A Year of DNS over HTTPS over Tor" (PDF). Network and Distributed System Security Symposium. Archived (PDF) from the original on 2021-03-21. DNS over HTTPS (DoH) obviates many but not all of the risks, and its transport protocol (i.e. HTTPS) raises concerns of privacy due to (e.g.) 'cookies.' The Tor Network exists to provide TCP circuits with some freedom from tracking, surveillance, and blocking. Thus: In combination with Tor, DoH, and the principle of "Don't Do That, Then" (DDTT) to mitigate request fingerprinting, I describe DNS over HTTPS over Tor (DoHoT).
  48. ^ Ulevitch, David (6 December 2011). "DNSCrypt – Critical, fundamental, and about time". Cisco Umbrella. Archived from the original on 1 July 2020.
  49. ^ "Anonymized DNSCrypt specification". GitHub. DNSCrypt. Archived from the original on 25 October 2019.
  50. ^ "Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki". GitHub. DNSCrypt project. Retrieved 28 July 2022.
  51. ^ Herzberg, Amir; Shulman, Haya (2014-01-01). "Retrofitting Security into Network Protocols: The Case of DNSSEC". IEEE Internet Computing. 18 (1): 66–71. doi:10.1109/MIC.2014.14. ISSN 1089-7801. S2CID 12230888.
  52. ^ APWG "글로벌 피싱 설문조사:도메인 이름 1H2010의 사용 및 동향" 10/15/2010 apwg.org Wayback Machine에서 2012-10-03 보관
  53. ^ a b Huston, Geoff (July 2019). "DNS Privacy and the IETF" (PDF). The Internet Protocol Journal. Archived (PDF) from the original on 2019-09-30.
  54. ^ "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars". ICANN. 3 December 2015. Archived from the original on 22 December 2015. Retrieved 18 December 2015.
  55. ^ "Find a Registrar". VeriSign, Inc. Retrieved 18 December 2015.

원천

외부 링크

Wik variety에는 도메인 네임 시스템에 대한 학습 자료가 있습니다.