DNS의 역사
70년대에 사람들은 액세스하려는 서버의 IP 주소를 기억하는 데 지쳤습니다. 동시에 숫자 호스트 주소 대신 더 간단하고 기억하기 쉬운 이름을 사용하자는 아이디어가 떠올랐습니다.
Stanford Research Institute의 직원들은 문자열 이름 목록과 ARPANET에 있는 컴퓨터의 해당 숫자 주소가 포함된 텍스트 파일 HOSTS.TXT를 내놓았습니다 .
주소는 수동으로 할당되었습니다. 호스트 이름과 주소를 요청하거나 마스터 파일에 컴퓨터를 추가하기 위해 사용자는 업무 시간 동안 전화로 Stanford의 네트워크 정보 센터에 문의했습니다.
1980년대 초반에는 단일 중앙 집중식 호스트 테이블을 유지하는 것이 느리고 번거로워졌으며, 성장하는 네트워크는 기술 및 인적 문제를 처리하기 위해 자동 이름 지정 시스템이 필요했습니다.
1984년에 4명의 UC Berkeley 학생이 계층적 도메인 이름 시스템의 첫 번째 버전을 작성했습니다. 현재 특히 Unix 시스템에서 널리 사용되고 있으며 여전히 인터넷에서 가장 널리 사용되는 DNS 소프트웨어입니다.
DNS 소개
DNS(도메인 이름 시스템)는 도메인에 대한 정보를 저장하고 검색하기 위한 배포 시스템입니다. 호스트 이름(컴퓨터 또는 장치)에서 IP 주소를 얻고 메일 라우팅 정보를 얻거나 도메인의 프로토콜에 대한 호스트를 제공하는 데 가장 일반적으로 사용됩니다.
시스템은 특정 프로토콜에 따라 상호 작용하는 DNS 서버의 특정 계층 구조 형태로 구성됩니다. DNS를 이해하기 위한 기본은 이름과 영역의 계층 구조를 이해하는 것입니다.
도메인 영역을 담당하는 각 서버는 도메인의 추가 부분에 대한 책임을 다른 서버로 이전할 수 있으므로 정보 관련성에 대한 책임을 도메인의 "자신의" 부분만을 담당하는 다양한 조직의 서버에 할당할 수 있습니다. 도메인 이름.
DNS 시스템에는 영역 계층에 해당하는 DNS 서버 계층이 포함되어 있습니다. 각 영역은 도메인에 대한 정보를 호스팅하는 하나 이상의 신뢰할 수 있는 DNS 서버에서 지원됩니다.
중요한! 이름과 IP 주소는 반드시 일대일로 서로 관련되지는 않습니다. 하나의 IP 주소는 여러 도메인 이름을 가질 수 있으므로 한 컴퓨터에서 여러 웹사이트를 지원할 수 있습니다(이를 공유 호스팅 이라고 함 ).
그 반대일 수도 있습니다. 많은 IP 주소가 하나의 도메인 이름과 연결될 수 있습니다. 이를 통해 로드 밸런싱을 생성할 수 있으며 CDN 네트워크에서 적극적으로 사용됩니다 .
시스템의 안정성을 높이기 위해 동일한 정보를 담고 있는 여러 서버를 사용하며 프로토콜은 서로 다른 서버에 있는 정보의 동기화를 유지하는 수단을 가지고 있습니다. 13개의 루트 서버가 있으며 해당 주소는 실제로 변경되지 않습니다.
흥미로운! DNS 프로토콜은 TCP 또는 UDP 포트 53을 사용하여 쿼리에 응답합니다. 전통적으로 요청과 응답은 단일 UDP 데이터그램으로 전송됩니다. TCP는 응답 데이터 크기가 512바이트를 초과할 때 사용됩니다.
DNS 레코드
DNS 서버는 각 도메인 이름에 대한 매개변수 집합을 저장합니다. 도메인 이름, IP 주소 및 다양한 서비스 정보에 대한 기록입니다.
총 수십 개의 항목이 있으므로 가장 인기있는 항목 만 고려할 것입니다.
ㅏ | 주소 | IP 주소 |
AAAA | 주소 IPv6 | IPv6 형식의 주소 |
CNAME | 정식 이름 | 별칭의 정식 이름 |
MX | 메일 교환기 | 도메인의 메일 게이트웨이 주소 |
NS | 네임서버 | 도메인 영역을 담당하는 노드의 주소 |
SOA | 권위의 시작 | 정보 권한 표시 |
SRV | 서버 선택 | 서비스에 대한 서버 위치 지정 |
PTR | 바늘 | 주소 이름 일치 - A 및 AAAA에 대한 역 일치 |
TXT | 텍스트 문자열 | 최대 255바이트의 임의 이진 데이터 쓰기 |
여기서 가장 흥미로운 것은 다음과 같습니다.
- A 레코드를 사용하면 도메인에 해당하는 IP 주소를 지정할 수 있습니다.
- CNAME을 사용하면 이름의 동의어를 설정할 수 있습니다(예: www.codegym.cc == codegym.cc).
- MX 레코드에는 메일 서버에 대한 정보가 포함되어 있습니다. 편지가 xxx@codegym.cc에 도착하면 수행할 작업입니다.
- NS - 이 도메인에 대한 정보를 포함하는 DNS 서버의 주소를 나타냅니다. 레코드가 기본이 아닌 노드에 캐시되고 저장될 때 유용합니다.
IP 주소 검색
DNS 시스템이 어떻게 작동하는지 봅시다.
브라우저에 api.codegym.cc를 입력했다고 가정해 보겠습니다. 브라우저는 로컬 DNS 서비스에 접속하여 api.codegym.cc 도메인에 대한 IP 주소를 제공하도록 요청합니다. 다음은 어떻게 될지...
먼저 DNS 서비스는 이 도메인이 컴퓨터의 로컬 호스트 파일에 있는지 확인합니다. 있는 경우 IP 주소를 가져옵니다. 그렇지 않은 경우 알려진 DNS 서버에 "api.codegym.cc의 IP 주소는 무엇입니까?"라는 요청을 보냅니다.
그러나 DNS 서버는 요청된 이름뿐만 아니라 전체 codegym.cc 도메인에 대해서도 알지 못할 수 있습니다. 이 경우 서버는 루트 서버(예: 198.41.0.4)에 접속합니다. 이 서버는 "이 주소에 대한 정보가 없지만 204.74.112.1이 ru 영역을 담당하고 있음을 알고 있습니다."라고 말합니다.
그런 다음 DNS 서버는 요청을 204.74.112.1로 보내지만 "이 서버에 대한 정보는 없지만 207.142.131.234가 codegym.cc 영역을 담당한다는 것을 알고 있습니다."라고 응답합니다. 마지막으로 동일한 요청이 세 번째 DNS 서버로 전송되고 클라이언트, 즉 브라우저로 전송되는 IP 주소인 응답을 받습니다.
이 경우 이름으로 IP를 검색하는 과정에서 다음 규칙이 작동했습니다.
- 브라우저가 알려진 DNS 서버에 재귀 요청을 보냈습니다 (이 유형의 요청에 대한 응답으로 서버는 IP 주소 또는 빈 응답 및 NXDOMAIN 오류 코드를 반환해야 함).
- 브라우저로부터 요청을 받은 DNS 서버는 비재귀적 요청을 연속적으로 보냈고, 요청된 영역을 담당하는 서버로부터 응답을 받을 때까지 다른 DNS 서버로부터 응답을 받았습니다.
- 언급된 나머지 DNS 서버는 요청을 비재귀적으로 처리하고 있었습니다(요청에 그러한 요구 사항이 있더라도 요청을 재귀적으로 처리하지 않았을 가능성이 큽니다).
때때로 요청된 서버가 "업스트림" DNS 서버에 재귀 쿼리를 보내고 준비된 응답을 기다리는 것이 가능합니다.
중요한! 재귀 쿼리 처리를 사용하면 모든 응답이 DNS 서버를 통과하고 이를 캐시할 기회를 얻습니다. 동일한 도메인 이름에 대한 반복 요청은 일반적으로 서버의 캐시를 벗어나지 않으며 다른 서버에 대한 호출은 전혀 발생하지 않습니다.
응답에 허용되는 캐시 시간은 응답과 함께 제공됩니다(리소스 레코드의 TTL 필드).
호스트 파일
첫 번째 검색이 로컬 호스트 파일에 있음을 확인했습니다. 이것은 ARPANET 시대에 발명된 HOSTS.TXT 파일의 상속자입니다. 예, 여전히 존재하며 계속 사용 중입니다.
경로를 따라 위치합니다.
- Linux의 /etc/hosts .
- Windows의 %SystemRoot%\system32\drivers\etc\hosts .
- /system/etc/hosts in android.
일반적으로 파일에는 localhost 노드에 대한 위치 정의가 포함됩니다.
127.0.0.1 localhost
그 구조는 매우 간단합니다. 먼저 IP 주소가 오고 도메인 이름이 옵니다.
유용한
호스트 파일을 사용하면 배너의 도메인 주소를 주소 127.0.0.0, 127.0.0.1 또는 0.0.0.0으로 리디렉션하여 광고를 필터링할 수 있습니다.
127.0.0.1의 사용은 일반적으로 권장되지 않습니다. 서버가 존재하지 않거나 잘못 구성된 경우 응답 시간 초과 및 관련 지연이 발생하기 때문입니다. 광고 도메인을 IP 주소 0.0.0.0에 매핑하면 해당 도메인에 대한 모든 요청이 즉시 중단됩니다.
퍼블릭 DNS 서버
인터넷 서비스를 연결할 때 일반적으로 인터넷 서비스와 함께 DNS 서버를 얻습니다. 그러나 이러한 무료 DNS 서버가 항상 최선의 선택은 아닙니다. 또한 ISP의 DNS 서버 사이트를 방문할 때마다 도메인 이름이 포함된 쿼리를 보내고 싶지 않을 수도 있습니다.
따라서 많은 사람들이 공개 무료 DNS 서버로 전환하는 것을 선호합니다. 첫째, 그들은 매우 빠르고 도메인 이름의 큰 캐시를 가지고 있습니다. 기술적인 문제가 발생할 가능성을 최소화하면서 사이트 로딩 및 가동 시간이 빨라집니다.
둘째, 안전. 일부 DNS 서비스는 피싱 및 악성 사이트에 대한 액세스를 차단하고 온라인에서 부적절한 콘텐츠로부터 어린이를 보호하기 위해 콘텐츠 필터링을 제공할 수 있습니다.
이러한 DNS 서버는 사기꾼과 싸울 수도 있습니다. 예를 들어 가짜 은행 웹사이트로 이동하면 DNS 서버가 사기꾼의 IP 주소가 아니라 보안 서비스를 제공합니다.
해당 서버 목록
클라우드플레어 | 1.1.1.1 1.0.0.1 |
Cloudflare는 방문자 데이터를 사용하여 광고를 제공하지 않으며 요청 소스 IP 주소를 디스크에 굽지 않을 것이라고 약속합니다. |
구글 퍼블릭 DNS | 8.8.8.8 8.8.4.4 |
문제 해결 및 진단을 위해 약 24-48시간 동안 요청 장치의 IP 주소에 대한 전체 정보를 저장합니다. |
Comodo 보안 DNS | 8.26.56.26 8.20.247.20 |
피싱 사이트를 차단하지만 멀웨어, 스파이웨어가 있는 사이트를 방문하려고 하면 경고도 합니다. |
얀덱스.DNS | 77.88.8.8 77.88.8.1 |
인기 있는 러시아 검색 엔진의 무료 DNS 서비스 |
GO TO FULL VERSION